每日新聞摘要

Java Weekly Issue 627 from Baeldung opens with a New Year greeting and gathers recent developments across the Java ecosystem. It highlights a detailed piece on virtual thread states that improves visibility for confirming unmounting behavior and spotting pinning issues that can stall high-concurrency applications on carrier threads. The edition also recommends related reads—STF Milestone 7 on safe cancellation, a piece on multi-tenant systems, coverage of an AI-themed QCon talk, an example of scalable oral exams using an ElevenLabs voice AI agent, and Troy Hunt’s update on 630 million additional pwned passwords processed by the FBI. Several webinars and podcasts are listed (including Mark Thomas on Tomcat, an episode with Georges Saab, an SRE AI agent talk, and a Foojay episode on conference organization). Finally, it flags upgrades for Spring Shell, Apache Camel, and Quarkus, and names Paul Graham’s “Life is Short” as the pick of the week, with Baeldung as the original source.

Baeldung 的 Java Weekly 第627期以新年问候开篇，汇总近期 Java 生态的主要资讯与资源。重点文章讨论了虚拟线程状态的更高可见性，可用于确认卸载行为并发现会让高并发应用在 carrier 线程上静默停滞的 pinning 问题。期刊同时推荐相关阅读（STF 第七里程碑：安全取消、偏好多租户系统、QCon AI 的议题、用 ElevenLabs 语音 AI 实现可扩展口试，以及 FBI 提供的额外被盗密码处理）。还列出若干播客与在线演讲，并提醒 Spring Shell、Apache Camel 与 Quarkus 的新版可升级。本期推荐文章为 Paul Graham 的《Life is Short》，来源为 Baeldung。

This article is a practical, production-ready guide to auditing Jetpack Compose performance. It identifies the main culprits—excessive recompositions, incorrect state boundaries, unstable objects and lambdas, and animations running in the wrong phase—and provides a focused checklist for composition/recomposition, object allocation, model stability, lazy layout keys, and animation phases. The author supplies an automated test that tracks recomposition counts, a step-by-step refactor of a Recording list so only changed items recompose, and concrete comparisons with View-based pitfalls. Recommended practices include using derivedStateOf, remember for heavy objects (Brush, Shape, TextStyle), stable models (@Immutable/@Stable), keys in Lazy layouts, and graphicsLayer for visual-only animations. Tools suggested: Layout Inspector, Recomposition Highlighter, and macrobenchmark. TL;DR: control state boundaries, ensure stability, choose the correct phase, and cover performance with tests to make Compose faster and more predictable.

本文为 Jetpack Compose 的性能审计提供了实用流程，指出主要问题来源：过度重组、错误的状态边界、不稳定对象与 lambda，以及动画运行在错误的阶段。文章给出详尽检查表（组合与重组、将重对象记忆化、使用 derivedStateOf、模型标记为 @Immutable/@Stable、在 Lazy 列表中提供键值、尽量将视觉动画放在绘制阶段使用 graphicsLayer），并提供一个将重组次数转为可测试的自动化测试示例、以及录音列表的逐步重构以只重组变更项。作者还比较了 Compose 与 View 的常见性能陷阱，并建议使用 Layout Inspector、Recomposition Highlighter 与 macrobenchmark 做性能验证。结论：掌握状态边界、模型稳定性与正确的执行阶段，可让 Compose 表现更快、更可预测且更易测试。

This guide explains using Macrobenchmark and Baseline Profile to measure, optimize, and lock Jetpack Compose performance. Macrobenchmark runs your release APK in a realistic environment (no debugger or tooling) to capture cold/warm/hot startup, frame timing, scroll behavior, and navigation costs—revealing jank, layout thrash, and excessive recomposition. Baseline Profile tells ART which code paths to compile ahead-of-time so release builds are fast from the first launch; generate it by exercising startup, navigation, and lazy lists and package the profile into the APK. Recommended workflow: write benchmarks, measure baseline, optimize Compose, regenerate the baseline profile, and enforce regressions in CI with thresholds that fail PRs. The guide also lists common Compose traps, setup snippets, a template repo, and before/after numbers showing substantial startup and jank improvements.

本文介绍如何使用 Macrobenchmark 与 Baseline Profile 来衡量、优化并锁定 Jetpack Compose 的性能。Macrobenchmark 在无调试器的真实 release APK 中运行，捕捉冷/暖/热启动、帧时间、滚动与导航开销，能发现卡顿、布局抖动与过度重组等问题；Baseline Profile 告诉 ART 将关键路径提前编译 (AOT)，使发布版从第一次启动即获得更快表现。推荐流程为撰写基准、量测、优化 Compose、重新生成 baseline profile，并在 CI 中以阈值阻断回归。文章还列出常见陷阱、配置示例、模板仓库与前后性能数据，强调以测量驱动优化并用 Profile 固化成果。

This article is a focused look at performance considerations in Jetpack Compose, emphasizing three interrelated topics: stable types, immutable data as the source of truth, and the compiler's skipping logic. It explains how recognizing and designing stable types can reduce unnecessary recompositions, and how treating state as immutable simplifies reasoning about UI updates. The piece also outlines how Compose's compiler can skip work when it can determine stability and unchanged inputs, and why structuring types and state to be predictable enables those optimizations. Practical guidance centers on aligning data modeling and state ownership with Compose's expectations so the framework can apply its intelligent skipping and deliver better runtime performance. This installment is part of a broader series on mastering Compose best practices.

本文聚焦 Jetpack Compose 的性能要点，讨论稳定类型、不可变数据作为事实源以及编译器的跳过逻辑如何协同提升性能。文章说明通过设计稳定类型可以避免频繁的 recomposition；以不可变数据管理状态能简化对 UI 更新的判断；并且当数据和类型结构清晰、可预测时，Compose 的编译器可以识别并跳过不必要的渲染或计算，从而提升运行效率。核心建议是按照 Compose 的期望调整数据建模和状态管理，以便框架发挥智能跳过和其他优化机制。该篇为作者系列文章的一部分。

This installment focuses on the layout phase of Jetpack Compose and how to build bespoke UI components by controlling measurement and placement. It emphasizes implementing custom measurement logic, leveraging intrinsic size calculations to determine component dimensions, and applying high-performance modifiers to optimize rendering and interactions. The discussion covers when to replace default composables with custom layouts, how measurement constraints affect child sizing, and why efficient modifier design reduces recomposition and expensive layout passes. It also touches on intrinsic measurements and the two-phase measure-and-place lifecycle, offering guidance on debugging layout issues and writing modifiers that minimize recomposition and extra layout passes. Overall, the piece guides Compose developers toward mastering low-level layout APIs to create tailored, reliable, and efficient UI primitives.

第七篇聚焦 Jetpack Compose 的 layout 阶段，说明如何打造定制化组件：掌握自定义测量逻辑、使用 intrinsic size 计算组件尺寸，以及设计高性能 modifier。文章讨论自定义 Layout 的时机、测量与放置（measure/placement）流程如何影响子组件尺寸，以及如何编写能降低重组与重复测量的 modifier 以提升性能。旨在引导开发者运用低阶 layout API，在灵活性与性能间取得平衡，构建可靠且高效的 UI 原件，并提供调试建议与实现考量，帮助排查布局问题与优化渲染效率。

This short piece introduces an exploration of AGSL effects applied to a single landing page view within modern Android development. It emphasizes that a landing page is not merely a static entry point but the first opportunity to capture user attention and set the tone for an app experience. The article frames AGSL as a tool to enhance visual presentation and interaction on that initial view, and it highlights practical interest in integrating graphical effects at the app’s first touchpoint. Authored by Veronica Putri Anggraini and published on ProAndroidDev, the write-up aims to prompt developers to consider creative shader or graphics techniques when designing landing pages to better engage users from the outset.

本文简要介绍了在单一 Landing Page 视图中探索 AGSL（Android 图形着色相关技术）特效的主题，并强调在现代 Android 开发中，Landing Page 不仅是静态入口，而是吸引用户并形成第一印象的首要机会。文章提出可利用图形或着色特效增强首屏的视觉呈现与交互体验，鼓励开发者在设计应用的首个接触点时考虑创意视觉效果，以提升用户参与度。作者為 Veronica Putri Anggraini，刊载于 ProAndroidDev。

Andre of AndroidLab argues that, despite continued advances in Android frameworks and tooling, memory leaks remain a real and recurring problem in 2026. The article emphasizes that modern frameworks do not automatically prevent the longstanding issue of holding onto objects that should have been released. It warns against overreliance on frameworks alone and underscores that retained references and design or coding choices continue to cause leaks. The piece serves as a cautionary reminder that developers must understand object lifecycles, proactively manage references and resources, and use diagnostics and good practices to find and fix leaks. For full details and examples, readers are referred to the original Medium post.

AndroidLab 的 Andre 提醒读者：即便到了 2026 年，Android 应用仍然会发生内存泄漏。文章指出，尽管现代框架和工具已有改进，但无法自动解决“保留应当释放的对象”这一老问题，框架无法替代对生命周期与引用管理的理解。作者强调不能单靠框架，开发者仍需主动管理引用与资源，进行代码审查与诊断。此短文作为警示，提醒工程师持续关注内存管理实践，并建议读者前往 Medium 阅读完整讨论与示例。

The article delivers a blunt message: most Android apps never get past their initial release, and a pervasive but overlooked cause is poor application architecture. It contends that architectural weaknesses — designs that hamper maintainability, inhibit evolution, or obstruct collaboration — are a frequent reason projects stall after version 1. Rather than focusing solely on features or marketing, the piece reframes the problem as structural, explains why these issues often go undiscussed, and promises practical guidance for diagnosing architectural flaws. Aimed at Android developers and teams, it calls for intentional, long-term architectural choices, continuous attention to code health, and strategies that make apps easier to extend and maintain. The overall goal is to help developers recognize and address the root causes so their apps can survive and evolve beyond the first public release.

文章直言指出：大多数 Android 应用无法度过第一个公开版本，而一个常被忽视的关键原因是应用架构问题。作者说明架构缺陷如何使维护、扩展和团队协作变得困难，导致项目在版本 1 之后停滞。文章强调这些问题经常被忽略，並提供诊断与预防的方向，呼吁开发者采取长期可维护的设计、重视代码结构与健康，从而避免因架构不良被迫放弃产品，帮助应用在首发之后继续演进与存续。

Andre's Medium post warns that migrating an existing Android app to Jetpack Compose can seriously damage your codebase if attempted without proper preparation. While Compose promises declarative UI benefits, the article emphasizes that many developers and community resources focus on those advantages while under-communicating the real migration risks and hidden costs. Unplanned migration can introduce regressions, create architectural mismatches, increase technical debt, and complicate testing and maintenance. The author advocates treating migration as a deliberate engineering project: inventory affected modules, evaluate compatibility and dependencies, plan incremental and reversible changes, and maintain thorough testing and monitoring. Teams should favor compatibility strategies and staged transitions rather than wholesale replacement, and seek practical, experience-based guidance before large-scale conversion.

Andre 在 Medium 的文章提醒，如果没有充分准备就将现有 Android 项目迁移到 Jetpack Compose，可能会毁掉代码库。尽管 Compose 带来宣告式 UI 的优势，社区与教程往往关注亮点，却少提迁移时的风险与隐性成本。未经规划的迁移可能引入回归错误、造成架构不匹配、增加技术债务，并使测试与维护更复杂。作者主张将迁移视为工程项目：盘点受影响模块、评估兼容性与依赖、采用可逆且渐进的变更，并保持完整的测试与监控。文章提醒团队在大规模转换前应谨慎规划并寻求实战经验。

The article argues that flaky or failing tests typically indicate problems in the system's architecture rather than defects in the test suite itself. Tests expose hidden coupling, nondeterministic behavior, environmental dependencies, and fragile integration boundaries; rather than repeatedly patching tests, developers should interpret failures as diagnostic signals. By investigating root causes — isolating dependencies, enforcing determinism, clarifying boundaries, and improving test harnesses and infrastructure — teams can eliminate the conditions that produce flakiness. The piece encourages treating tests as informative feedback about design quality and prioritizing architectural fixes over quick test-side workarounds so that the test suite becomes a reliable indicator of correctness instead of a source of intermittent noise.

文章论述，间歇性或失败的测试通常反映系统架构存在问题，而非测试套件本身完全失效。测试能暴露隐藏的耦合、非确定性行为、对运行环境的依赖以及脆弱的集成边界。与其反复修补测试，开发者应将失败视为诊断信号：追查根本原因、隔离依赖、增强确定性、明确边界并改进测试环境与基础设施。优先处理架构缺陷，才能消除导致不稳定的条件，使测试套件成为可信的质量指标，而非间歇性的噪声。

Kotlin Multiplatform (KMP) lets developers extract and reuse core business logic across Android, iOS, web, desktop, and backend targets while keeping platform-specific UI and integration layers separate. By enabling a single codebase for shared logic, KMP reduces duplication, helps maintain consistent behavior across platforms, and can speed development and testing. Teams can implement domain models, networking, and business rules once, then bind them to native or platform-specific UI and APIs. Adoption requires tooling, platform interop, and architecture choices to manage platform boundaries and native features, but when applied to appropriate layers KMP offers a practical compromise between code reuse and native experience. This article overview highlights KMP’s role in 2026 as a way to target many platforms from one codebase; see the full Medium piece for detailed examples and guidance.

本文介绍了 Kotlin Multiplatform（KMP）如何使开发者将核心业务逻辑从单一代码库共享到 Android、iOS、网页、桌面与后端等多个目标平台，同时保留各平台的 UI 与集成层可以分别实现。通过在共享层实现领域模型、网络与业务规则，KMP 可减少重复、维持一致性并加速开发与测试；但采用时仍需应对工具链、平台互通与架构设计等问题。文章概述了在 2026 年以一个代码库服务多个目标平台的思路，详情请参考原文。

Gabrielslevindo's article examines how to avoid excessive recompositions in Jetpack Compose by applying the Model–View–Intent (MVI) pattern. It begins by noting that Jetpack Compose was designed to handle recompositions well, but that uncontrolled or unnecessary recompositions can still degrade responsiveness or complexity in real apps. The piece argues that structuring app state and updates through MVI—centralized state, unidirectional data flow, and clear separation of UI and business logic—can reduce the frequency of redundant UI recompositions. It highlights considerations for state ownership and update granularity, and encourages developers to use architectural discipline to make recomposition behavior predictable. The article serves as a practical overview for Compose developers who want to keep UI updates efficient by aligning state management with a predictable MVI flow.

Gabrielslevindo 的文章探讨了如何通过 MVI（Model–View–Intent）在 Jetpack Compose 中避免过度的重组。文章首先指出 Jetpack Compose 的设计能够良好处理重组，但在实际应用中，失控或不必要的重组仍可能影响响应性和增加复杂度。作者提出通过 MVI 将状态和更新集中管理、采用单向数据流并清晰分离 UI 与业务逻辑，可以降低不必要的界面重绘频率。文章提醒开发者关注状态拥有权与更新粒度，并以架构规范使重组行为更可预测，为希望优化 Compose 重绘的开发者提供总体方向。

The author recounts an Android job interview in which a question about who "owns" a piece of app state — a topic they thought they understood — caused them to freeze once the interviewer began digging. The short piece uses that moment to highlight how follow-up questions can reveal gaps between surface-level knowledge and the ability to explain architecture decisions under pressure. It emphasizes that state ownership and component responsibilities in Android are areas where conceptual familiarity may not be enough when asked to justify choices or describe trade-offs. The article serves as a reminder to revisit core architecture concepts and practice articulating ownership and rationale before technical interviews.

作者回忆了一次 Android 面试：当面试官询问“谁拥有这个 state？”并不断追问时，他才发现自己无法从容回答而当场愣住。文章借此强调，后续的追问常能揭示出表面理解与在压力下清楚说明架构决策之间的差别，尤其是关于 state 的归属与组件职责问题。作者因此建议回顾关键架构概念、理清拥有权与责任，并练习在面试中明确阐述选择的理由与权衡。

This article explains how Kotlin data classes can become fragile when exposed in public APIs because of how constructors, generated bytecode, and implicit behaviors interact. It highlights that data classes produce specific constructor signatures and synthetic methods, and that seemingly minor evolutions—such as adding properties or changing default values—can alter the generated bytecode or method signatures in ways that break binary compatibility for previously compiled consumers. The author warns that these changes can cause runtime or linkage failures for downstream code. To reduce risk, the piece advises treating data classes cautiously in public-facing APIs: prefer explicit, stable interfaces, avoid relying on compiler-generated implementations across module boundaries, and understand the compiler artifacts before making API changes so you don’t inadvertently introduce compatibility regressions.

本文解释了为何在公共 API 中暴露 Kotlin 的 data class 可能导致二进制兼容性问题。由于编译器会为 data class 生成特定的构造函数、隐含方法和字节码，诸如新增属性或调整默认值的看似微小变更，可能改变生成的字节码或方法签名，从而使已编译的使用方在运行或链接时出现故障。作者提醒开发者在对外 API 中谨慎使用 data class：优先采用明确且稳定的接口设计，避免跨模块依赖编译器自动生成的实现，并在变更前理解编译器生成的工件以降低兼容性风险。