每日新聞摘要

This issue of Java Weekly spotlights performance updates in JDK 27, including measured improvements in HashMap operations, cryptography, and vectorization. It also warns that placing a workload generator in the same JVM as the system under test can pause request scheduling during garbage collection and skew tail-latency results. Beyond the lead items, the newsletter collects recent reads, webinars, and release notes spanning Spring, Quarkus, Micronaut, Kotlin, and related Java ecosystem topics.

本期 Java Weekly 聚焦 JDK 27 的性能改进，涵盖 HashMap 操作、密码学和向量化等项目的实测提升。文中也提醒，如果 workload generator 与被测系统运行在同一个 JVM 中，垃圾回收暂停可能会中断请求调度，从而扭曲 tail latency 的测量结果。除此之外，这一期还汇总了 Spring、Quarkus、Micronaut、Kotlin 等相关内容，以及近期的发布说明和演讲资料。

This article recounts how the author built Leben in DE: Einbürgerungstest, a free Android app for preparing for Germany’s Leben in Deutschland test, using Kotlin Multiplatform and Compose Multiplatform. The project began as a way to learn KMP by shipping a real consumer app, then evolved after the MVP when the original plan for a paid tier was reconsidered. The author explains why a simple feature flag was not enough, how sign-in, sync, and payments were moved into separate modules and build flavors, and what was learned about sharing code, wrapping third-party libraries, setting up CI, handling secrets, testing releases, and planning for platform-specific work.

这篇文章讲述作者如何使用 Kotlin Multiplatform 和 Compose Multiplatform 开发 Leben in DE: Einbürgerungstest，一款用于准备德国 Leben in Deutschland 测试的免费 Android App。作者最初希望通过交付一个真实产品来学习 KMP，随后在完成 MVP 后重新评估付费方案，决定先以完全免费形式发布。文中详细说明了为什么单靠 feature flag 不够、如何把登录、同步和支付拆成独立模块并提供 free/full 两种构建，以及他在共享代码、封装第三方库、CI 自动化、密钥管理、测试和平台差异处理方面得到的经验。

This article explains how the author organized a first Kotlin Multiplatform app for Google Play. The project is split into Gradle modules: composeApp as the main app, iosApp as the Xcode launcher, several library modules under libs, and shared build logic. Inside composeApp, the code uses Clean Architecture with presentation, domain, and data layers, and the app follows horizontal slicing because multiple features share the same questions and progress data. The article also describes KMP source sets, with most logic in commonMain and platform-specific code in androidMain and iosMain. It ends by showing how expect/actual is used for platform-only behavior such as in-app review, while keeping shared code testable with Koin and Robolectric.

这篇文章介绍作者如何组织第一个要发布到 Google Play 的 Kotlin Multiplatform 应用。项目被拆成多个 Gradle 模块：composeApp 作为主应用模块，iosApp 负责启动 iOS 应用，libs 下包含 domain-api、auth、payment 和 telemetry-core 等库模块，另有 build-logic 统一 Gradle 配置。composeApp 内部采用 Clean Architecture，分为 presentation、domain 和 data 三层，并因为多个功能共享同一套题目与进度数据而采用水平切分。文章还说明了 KMP source set 的用法：大部分共享逻辑放在 commonMain，平台差异则通过 expect/actual 处理，例如应用内评分。

This article explains how the author uses Android product flavors in a Kotlin Multiplatform codebase to build two app variants from one shared project: a free version with only core features and a full version with sign-in, sync, and payments. The free build excludes the auth and payment modules, along with their SDKs and billing permission, while the full build includes them through flavor-specific dependencies. Shared code talks only to interfaces defined in a domain-api module, and each flavor supplies its own implementation at startup via separate source sets. The article also describes a CI check that verifies paid SDKs do not leak into the free release classpath.

本文介绍作者如何在 Kotlin Multiplatform 代码库中，通过 Android product flavors 从同一套项目构建两个版本：只保留核心功能的免费版，以及包含登录、同步和支付的完整版。免费版不会加入 auth 和 payment 模块，也不会带入相关 SDK 和 billing 权限；完整版则通过 flavor 专属依赖和 source set 将它们接入。共享代码只依赖 domain-api 模块里的接口，各版本在启动时提供自己的实现。文章最后还提到，作者在 CI 中增加了检查，防止付费 SDK 意外进入免费版。

Android UI Renderer MCP already supported classic Android UI, but Jetpack Compose required a different approach because there is no layout file to inflate. The author set a constraint that the project should not need a special renderer entry point, then asked a coding agent to solve it. The agent built `render_compose`, which parses a top-level composable signature, converts JSON into typed Kotlin values, generates a temporary probe, and renders Compose output to PNG plus a semantics tree. It also fixed two follow-up problems: missing class names in semantics serialization and a Gradle repositoriesMode issue in the demo project. The result is support for both XML/View and Jetpack Compose, with the author emphasizing the shift from researching the problem personally to specifying the desired outcome and constraints.

Android UI Renderer MCP 原本已经支持传统 Android UI，但 Jetpack Compose 没有可直接 inflate 的布局文件，因此需要完全不同的处理方式。作者先要求项目端不要额外编写专用 renderer entry point，再把这个研究问题交给编码代理完成。代理实现了 `render_compose`：解析 top-level composable 签名、把 JSON 转成有类型的 Kotlin 值、生成临时 probe，最终输出 PNG 和 semantics tree。过程中又修复了 semantics 节点缺少 className 的序列化问题，以及 demo 项目的 Gradle repositoriesMode 限制。最终工具同时支持 XML/View 和 Jetpack Compose，作者强调的变化是：先精确定义结果与约束，再让代理补上自己没法一开始就展开的研究与实现。

This article highlights a common Android modularization pain point: a build that passes on every developer machine but fails in CI with an error seemingly unrelated to recent changes. The premise points to reproducible differences between local environments and automated pipelines, especially in CI/CD workflows. It frames the problem as one of hard-to-reproduce build failures rather than a confirmed root cause, and the article itself is only partially available from the provided text.

本文描述了 Android 模块化中常见的棘手问题：在每位开发者机器上都能通过的构建，到了 CI 却失败，而且报错看起来与最近的修改无关。这说明本地环境与自动化流水线之间可能存在差异，尤其是在 CI/CD 流程里更容易出现难以复现的构建故障。根据目前提供的文本，文章重点是这种问题现象本身，而不是已经确认的根因，且原文仅给出了部分摘要。

The article argues that in senior Android interviews, the first answer is often not the deciding factor. Instead, the follow-up questions determine whether a candidate truly demonstrates depth, clarity, and practical understanding. Drawing on experience from more than 500 technical interviews, the author emphasizes that interviewers should pay close attention to what comes next, because that is where senior-level thinking is most visible.

这篇文章指出，在高级 Android 面试中，候选人的第一轮回答往往并不是决定性因素，真正起作用的是后续追问。作者基于 500 多场技术面试的经验，强调面试官应关注接下来提出的问题，因为那里最能看出候选人的深度、表达清晰度和实际理解。对于高级岗位而言，追问比初始回答更能反映真实能力。

The provided text is only a short excerpt from a Medium article about Kotlin Multiplatform in 2026. It says the team built a KMP sharing layer and frames it as the result of Kotlin 2.4 plus a year of KMP code-sharing experience. Because the full article content is not included, no further conclusions can be drawn about the team’s migration scope, outcomes, or whether native Android was actually replaced.

这段内容只是 Medium 文章的简短摘录，主题是 2026 年的 Kotlin Multiplatform。文中提到团队构建了 KMP 共享层，并将其描述为 Kotlin 2.4 与一年 KMP 代码共享经验的结果。由于没有提供全文，无法判断团队替代原生 Android 的具体范围、实际效果或最终遇到的限制。

The article examines Compose Multiplatform through the lens of running an Android Compose UI on iOS, desktop, and the browser. It focuses on what the technology does well, where it still falls short, and whether it is a worthwhile bet for Android developers. The piece is positioned as a practical assessment rather than a feature announcement, and it underscores that the question is not just whether Compose can reach multiple platforms, but whether it is ready enough to rely on in real development work.

这篇文章以将 Android Compose UI 运行在 iOS、桌面和浏览器上的体验为切入点，评估 Compose Multiplatform 的实际表现。作者重点讨论它做得好的地方、目前仍然不足的部分，以及 Android 开发者是否应该把它视为值得投入的技术。文章并不是宣称它已经完全成熟，而是从实践角度判断它是否足以承担真实开发需求。

The article describes a one-day experiment that connects Claude to Android Studio through AWS Bedrock by inserting a small local Kotlin proxy. The setup is designed to look like a Local LLM, allowing Android Studio to talk to it without requiring a new API key or a new vendor contract. The piece frames the approach as a lightweight workaround rather than a formal product integration, and the key idea is the proxy layer that bridges the IDE and Bedrock-backed model.

本文介绍了一次在一天内完成的实验：作者通过 AWS Bedrock，把 Claude 接入 Android Studio，中间使用一个小型 Kotlin 本地代理服务器进行转接。该代理被设计成看起来像 Local LLM，使 Android Studio 能直接与之通信，而不需要新的 API 密钥或新的供应商合同。文章强调的是这种轻量的桥接方案，而不是正式的产品级集成。

This post’s teaser asks why the technical quality of an Android app directly affects its ASO on Google Play. The title suggests a focus on improving app performance with R8, WebP, and AGP 9+, but the provided content does not include the full article. As a result, only the central theme can be stated with confidence: technical implementation details may influence store visibility and app presentation, but the excerpt itself does not provide the specific arguments, recommendations, or results discussed in the complete piece.

这篇文章的导语提出一个问题：为什么 Android 应用的技术质量会直接影响其在 Google Play 上的 ASO。标题显示作者将围绕 R8、WebP 和 AGP 9+ 讨论如何通过性能与打包层面的优化提升应用表现。但目前提供的只有简短引言，没有完整正文，因此只能确认文章主旨，无法得出其中具体的分析、建议或结论。

The article describes how Muffle was built as an offline-first Android app that automates silent/vibrate behavior using geofencing while minimizing battery drain. Instead of polling, it relies on GeofencingClient, PendingIntent, and a local Room-based priority stack to react to ENTER and EXIT events. The author also covers real-world Android constraints, including aggressive OEM battery optimization, the need for REQUEST_IGNORE_BATTERY_OPTIMIZATIONS, and the interaction between AudioManager and Do Not Disturb access. Finally, the piece argues for transparent feedback, local logic, and a possible future hybrid approach that combines geofencing with activity recognition.

本文讲述作者如何为 Muffle 设计一款以离线优先为目标的 Android 应用，通过地理围栏自动切换静音和震动，同时尽量减少电量消耗。实现上并未采用持续轮询，而是依赖 GeofencingClient、PendingIntent 和本地 Room 优先级栈来响应 ENTER、EXIT 事件。作者也总结了 Android 生态中的现实限制，包括各家 OEM 激进的电池优化、REQUEST_IGNORE_BATTERY_OPTIMIZATIONS 权限，以及 AudioManager 与勿扰模式的交互。文章最后强调要提供可见反馈、保持本地逻辑，并可考虑未来结合活动识别的混合方案。

The author reflects on how a cluttered, notification-heavy home screen undermined personal focus, then introduces Minimalist-Focus-Launcher, an open-source Android launcher built for digital wellness. Its design removes colorful app icons in favor of a text-only interface, aiming to reduce mindless app opening. A pure black background reinforces a simple, tool-like aesthetic and is also OLED-friendly. The launcher further combines task management and app locks on the home screen to create a more intentional, self-contained productivity hub. The project is implemented in Kotlin and uses Jetpack Compose for the UI, with Compose’s declarative approach simplifying real-time state handling for app filtering and task integration.

作者从自己被杂乱且通知繁多的主屏幕分散注意力的经历出发，介绍了开源项目 Minimalist-Focus-Launcher。这款自定义 Android 启动器面向数字健康，放弃了色彩丰富、容易让人上瘾的 App 图标网格，改为纯文字界面，以降低无意识打开应用的冲动。纯黑背景既适合 OLED 屏幕省电，也强化了手机作为工具的简洁定位。它还把任务管理和 App 锁整合到主屏幕上，形成一个更独立的生产力中心。项目使用 Kotlin 开发，UI 则完全基于 Jetpack Compose。

The article opens with the author reflecting on a long-standing habit: applying full Clean Architecture from the first day of every project, regardless of whether the feature actually needed that level of structure. It frames the piece as a discussion of moving from deep modules toward Clean Architecture through incremental, forced changes, rather than introducing everything upfront. The excerpt does not provide implementation details or results, but it clearly signals a pragmatic shift away from overengineering and toward evolving architecture one slice at a time.

文章开头回顾作者长期以来的做法：不管功能是否真的需要，几乎每个项目从第一天就全面采用完整的 Clean Architecture。本文把讨论放在从 deep modules 逐步走向 Clean Architecture 的演进路径上，重点不是一次性把所有架构都搭好，而是通过一次次被迫的变更，让系统随着成长逐步调整。由于截取内容很短，没有提供具体实现或结果，但可以看出作者想强调的是一种更务实、避免过度设计的渐进式架构做法。

The article argues that a modular Jetpack Compose architecture should be enforced by the build, not by code review or documentation alone. It describes a capability split into api and impl modules, with app as the only composition root allowed to depend on implementations. Gradle checks block illegal module dependencies, Kotlin internal keeps impl details private, navigation routes stay internal, Koin’s compiler plugin validates DI, sealed types model failures exhaustively, and a source check verifies that every feature and route is registered. Where enforcement is not possible, the author recommends tooling that makes the correct setup the easiest one.

文章主张，模块化 Jetpack Compose 架构不应只依赖 Code Review 或文档，而应直接由构建系统强制约束。作者把每个 capability 拆成 api 与 impl 两个模块，并以 app 作为唯一的 composition root。Gradle 规则阻止错误依赖，Kotlin internal 保护 impl 细节，路由只能由各 feature 自己创建，Koin 编译器插件负责验证 DI，sealed type 让错误处理保持穷尽，而 source 检查则确认每个 feature 和 route 都已注册。对于无法强制的部分，则通过生成器和工具链降低正确做法的成本。

The article frames Kotlin coroutines as a topic that many candidates can mention, but fewer can explain in depth. It points to failure scenarios as a useful way to test real understanding, especially what happens when a coroutine fails halfway through. Rather than treating coroutines as a résumé keyword, the piece emphasizes probing whether a candidate can reason about their behavior under failure and other nontrivial conditions.

这篇文章指出，许多 Kotlin 求职者都能在简历上写出 coroutines，但真正能够深入解释其行为的人并不多。作者以协程在执行到一半失败时会发生什么为例，说明这类问题很适合用来测试候选人是否真的理解 coroutine，而不只是知道这个术语。文章强调的重点，是对失败处理和运行机制的理解深度。

This article outlines how to implement biometric authentication in Android using the AndroidX Biometric library and BiometricPrompt. It describes checking whether biometrics are available, displaying the prompt, handling authentication callbacks, and falling back to device credentials when biometric authentication is not available or not suitable. The piece is presented as a practical Kotlin-focused guide for integrating these Android authentication flows.

本文介绍了如何在 Android 中使用 AndroidX Biometric library 和 BiometricPrompt 实现生物识别认证。内容包括检查设备是否支持生物识别、展示认证提示、处理认证回调，并在生物识别不可用或不适用时回退到设备凭据。文章以 Kotlin 为中心，适合希望接入 Android 认证流程的开发者参考。