每日新聞摘要

This issue rounds up Java and JVM-related reading across Spring, Quarkus, Kotlin, Jetty, Vert.x, Elasticsearch, and Micronaut, along with webinars and upgrade announcements. The featured Spring piece argues for living specifications that stay close to code and remain testable as systems evolve. In the technical section, Werner Vogels compares useful agent memory to the brain, while other links examine AI evaluation, debugger use by agents, and context engineering. The week’s pick highlights how Cloudflare saved 100 terabytes of memory by optimizing its 1.1.1.1 DNS cache.

本期汇总了 Spring、Quarkus、Kotlin、Jetty、Vert.x、Elasticsearch 和 Micronaut 等 Java/JVM 相关文章，也包括网络研讨会与升级公告。重点文章主张将规格更贴近代码，使其在系统演进中依然可测试、可维护。技术板块从 Werner Vogels 将代理记忆类比为大脑展开，延伸到 AI 评估、代理调试与上下文工程等主题。本周精选则介绍 Cloudflare 如何通过优化 1.1.1.1 的 DNS 缓存，节省 100 TB 内存。

The author revisits a three-state execution model—EXECUTED, DENIED_CONFIRMED, and DENIED_UNRESOLVED—and explains that an unresolved state is only useful if it is eventually reconciled. Without recurring re-query, promotion on evidence, and escalation for stale cases, it becomes a renamed form of uncertainty. A commenter also reveals a second gap: parameter-bound confirmation tokens stop recipient or message drift, but not world drift such as a calendar slot filling or permissions changing. The piece concludes that both token binding and independent re-verification are required, and that the same honesty test applies to local writes as well as external providers.

作者重新审视三态执行模型：EXECUTED、DENIED_CONFIRMED 和 DENIED_UNRESOLVED，并指出未解决状态只有在最终能够被厘清时才有意义。如果没有周期性重查、证据出现后的状态晋升，以及超时后的升级提示，未解决就会退化成另一种不确定。文章还补出第二个缺口：参数绑定的确认 token 可以防止收件人或消息等参数漂移，却无法阻止日历被占用、权限变化这类世界漂移。结论是，token 绑定和独立复验都必须存在，而且本地写入同样需要“能否廉价读回”的诚实检查。

PennyRush is built around a narrow privacy contract: bank statements and receipts are read into memory, parsed, and then discarded before they are written to disk, storage, logs, or analytics. The app keeps only structured transaction fields such as amount, date, merchant, note, type, and category. CSV imports run fully on-device with defensive checks for file type, size, line count, headers, and malformed values. Receipt scanning uses on-device OCR through ML Kit, while merchant extraction and categorization rely on deterministic rules. The tradeoff is less automation and no silent reprocessing later, but the result is a system whose privacy guarantees come from its architecture, not just its policy.

PennyRush 的核心隐私设计，是把银行对账单和收据先读入内存、解析后立刻丢弃，不写入磁盘、对象存储、日志或分析系统。系统只保留金额、日期、商家、备注、类型和分类等结构化字段。CSV 导入完全在设备端进行，并会检查文件类型、大小、行数、表头与异常值。收据扫描使用 ML Kit 的本地 OCR，商家提取与分类采用规则式处理。这样的做法虽然减少了自动化能力，也无法在之后静默重解析，但让隐私保证直接由架构本身支撑。

A bug in a short-video SDK let a canceled upload appear as a successful publication, leaving a ghost item in the grid until refresh removed it. The root cause was a pair of silent failures: the executor interrupted the worker but never set the cancellation flag, and the upload library swallowed the interrupt exception during polling and returned normally. Because routing depended on the flag, the task reported Done instead of Canceled. The eventual fix was deliberately small: set the flag before interrupting, then check it both during progress callbacks and after upload() returns. The article also explains why tests missed the issue and why a larger synchronous-cancellation API was later removed.

这篇文章拆解了短视频 SDK 中一个上传取消误报成功的缺陷：用户点击取消后，界面先停留在处理中，随后却被当成已成功发布，直到刷新才消失。根因来自两处静默失误：executor 只中断了线程，却没有先设置取消标志；而上传库在轮询时吞掉了中断异常，使流程正常返回。由于任务路由只依据标志判断，最终走到了成功分支。实际上线的修补很小：先设置标志，再在进度回调和 upload() 返回后各增加一次检查。文章还解释了为什么测试没有覆盖到这个问题，以及更大的同步取消 API 为什么最终被删除。

A Compose screen that looked calm in Android Studio’s Layout Inspector was doing far more work than expected. By inspecting memory allocations, the author found thousands of object creations tied to recomposition internals such as recomposeToGroupEnd and ComposableLambdaImpl. The root causes were unstable data classes, interface-based lists, repeatedly recreated annotated strings, unstable lambdas, missing list keys, and an unnecessary wrapper composable. After adding @Immutable, switching to ImmutableList, using remember, stabilizing callbacks, and simplifying the hierarchy, allocations dropped sharply. The main lesson is that recomposition counts alone can be misleading; allocation profiling reveals hidden work that the Layout Inspector may not show.

作者在排查一个生产中的 Compose 页面时发现，Layout Inspector 里的重组次数看起来正常，但内存分配分析却显示大量对象创建。深入检查后，他找到了几个关键原因：未标注 @Immutable 的数据类、使用 List 接口导致稳定性无法证明、每次重组都会重新构建的 annotated string、捕获可变值的 lambda、lazy 列表缺少 key，以及一个只负责转发参数的多余包装 composable。经过修正后，分配数明显下降。文章的核心结论是：只看重组计数不够，分配分析才能揭示隐藏成本。

This post gives a high-level account of how a streaming app team ended up maintaining a fork of Compose Multiplatform with tvOS support. The author explains the app’s path from Android Views to Jetpack Compose and then to Compose Multiplatform, driven by the need to share UI across Android, desktop, iOS, and tvOS. A SwiftUI approach for Apple TV was tested but abandoned because its focus handling could not match Android TV behavior. The post outlines what tvOS is, why Kotlin Multiplatform targets made the port substantial, and how the work was split across the Gradle plugin and runtime modules. It also describes the module-by-module porting order, the shared uiKitMain source set, and the hardest parts of the effort: input, focus, rendering, and keeping up with upstream changes.

这篇文章以概览方式回顾了一个流媒体应用团队如何走到维护支持 tvOS 的 Compose Multiplatform 分支。作者先说明项目从 Android Views 到 Jetpack Compose，再到为了在 Android、桌面、iOS 和 tvOS 之间共享 UI 而采用 Compose Multiplatform 的过程；原本 Apple TV 方案尝试用 SwiftUI，但由于焦点管理无法满足 Android TV 的行为而放弃。文章随后解释 tvOS 与 iOS 的差异、Kotlin Multiplatform 目标带来的移植成本，以及 Gradle 插件和 runtime 两条修改路径。最后总结模块移植顺序、uiKitMain 的共享设计，以及最难处理的输入、焦点、渲染和持续跟进上游变化。

This article presents a production-ready Android template that removes the repetitive setup work often required before application development begins. Inspired by Google’s Now in Android repository, it separates concerns into a feature-based multi-module structure, centralizes build logic with Kotlin convention plugins, and enforces architecture and design standards with custom lint checks. It also provides reusable Flow and StateFlow helpers, an isolated design system, and Hilt-based dispatcher and scope management. To make onboarding faster, the repository includes an automation script that renames the package and branding from a single terminal command, helping teams start new projects with less boilerplate and fewer setup errors.

这篇文章介绍了一个面向生产环境的 Android 模板，旨在减少新项目开发前大量重复的基础配置工作。模板参考 Google 的 Now in Android，将项目组织为以功能为主的多模块结构，并通过 Kotlin Convention Plugins 统一管理构建逻辑，同时用自定义 lint 规则约束架构边界与设计系统规范。它还提供可复用的 Flow/StateFlow 辅助工具、独立的设计系统，以及由 Hilt 管理的 dispatcher 与作用域。为了加快上手，仓库附带自动化脚本，可通过单条命令完成包名和品牌替换，从而降低样板代码与设置错误。

This article proposes a DI-driven Android startup pattern that replaces the common “God Class” split between Application and ViewModel startup logic. It recommends using multi-binding to let feature modules contribute startup tasks into a global set, then executing them through phase-based orchestrators for cold start, foreground, and session lifecycles. The design emphasizes idempotency, main-safety, and structured error handling so retries are safe and non-critical failures do not crash the app. It also explains why Jetpack App Startup is useful for raw framework initialization but unsuitable for app-specific logic that depends on DI or user consent. Finally, it advocates lifecycle-aware UI loading and lazy screen data fetching to reduce flicker, battery drain, and test complexity.

本文提出一种由 DI 驱动的 Android 启动方案，用多重绑定把各功能模块的启动任务汇集到统一集合，再由分阶段的 orchestrator 按冷启动、前台和用户登录状态执行。作者强调任务应当幂等、主线程安全，并通过统一的错误处理区分致命与非致命失败，使重试不会重复破坏已完成的工作。文章也说明 Jetpack App Startup 适合处理原生框架初始化，但不适合依赖 DI 或用户同意的业务逻辑。最后建议 UI 以生命周期感知方式观察启动状态，并让页面数据按需加载，以减少闪烁、耗电和测试复杂度。

This article compares Kotlin’s traditional double-property pattern with Explicit Backing Fields. The old approach uses a private MutableStateFlow plus a public StateFlow wrapper, which adds a small allocation but creates a strong architectural boundary. Explicit Backing Fields remove the wrapper and make the code cleaner, but the underlying object is still mutable. That means an external consumer can downcast the public reference back to MutableStateFlow and change internal state. The author argues this is usually acceptable for application code, since the same tradeoff exists with Kotlin collections and teams should rely on code reviews and static analysis. However, for public libraries or closed-source SDKs, defensive wrappers remain the safer choice.

本文对比了 Kotlin 传统的双属性封装与显式后备字段。旧方案用私有的 MutableStateFlow 搭配公开的 StateFlow 包装，虽然多了一点分配开销，却能提供更强的架构边界。显式后备字段省去了包装对象，代码更简洁，但底层对象仍然是可变的，因此外部若故意将公开引用下转型为 MutableStateFlow，就可能绕过封装直接修改内部状态。作者认为，这种取舍对大多数应用开发团队来说并非问题，因为 Kotlin 集合也存在类似做法；但对于公开库或 SDK，仍应优先使用 .asStateFlow() 这类防御性包装。

The article tests a common Kotlin Flow belief: that buffer() and flowOn() fuse into a single channel. By instrumenting runtime behavior instead of relying on folklore, the author shows that fusion is real but fragile. Adjacent fusible operators share one underlying channel through FusibleFlow, yet inserting ordinary operators such as map(), catch(), onEach(), or distinctUntilChanged() breaks that chain. Measurements using reflection, coroutine debug dumps, and custom dispatcher logging show extra wrapper objects, an additional coroutine, and more thread hops when fusion is interrupted. conflate() is the exception because it is implemented as a form of buffer(). The practical advice is to group fusible operators together and not assume simple-looking transforms are free, especially in high-throughput pipelines.

本文验证了一个常见的 Kotlin Flow 说法：buffer() 与 flowOn() 会融合成单一 channel。作者没有停留在经验判断，而是通过反射、协程 debug dump 和自定义 dispatcher 直接测量运行时行为。结果表明，FusibleFlow 只会在相邻的可融合运算子之间生效；一旦在中间插入 map()、catch()、onEach() 或 distinctUntilChanged()，融合就会被打断，从而带来更多包装层、更多 coroutine 和更多线程切换。相对地，conflate() 因为内部就是以 buffer() 的方式实现，所以仍能保持融合。文章建议在高吞吐场景中把可融合运算子放在一起，不要把看似简单的转换当成完全没有成本。

This article promises a practical deep dive into how an Android app’s size was reduced by 82%, shrinking from more than 100 MB to 17.76 MB. It focuses on APK analysis and the kinds of factors that commonly inflate app size, including R8, native dependencies, ABI duplication, and Compose Multiplatform. Based on the available text, the piece is positioned as a technical walkthrough rather than a high-level overview, with an emphasis on understanding where the bloat came from and how it was addressed.

本文讲述了一个 Android 应用体积缩小 82% 的实战案例，从 100 多 MB 降到了 17.76 MB。内容聚焦 APK 分析，以及常见的体积膨胀来源，例如 R8、本地依赖、ABI 重复与 Compose Multiplatform。根据目前可见的文字，这是一篇偏技术落地的深度拆解，重点在于找出体积膨胀的原因并逐步处理。

This article introduces the idea of designing a versioned encryption layer on Android so an app can support multiple encryption schemes over time. The goal is to make migrations safer while preserving backward compatibility, rather than forcing a single scheme for all data. The provided text is only a brief excerpt, so it does not include implementation details, performance claims, or specific Kotlin techniques.

本文介绍如何在 Android 上设计一个版本化加密层，使应用能够随着时间支持多种加密方案，而不必把所有数据都绑定到单一做法上。这样的设计重点在于保留向后兼容性，并让加密机制的切换与迁移更安全。由于原文仅有简短摘要，未提供实现细节、性能数据或具体 Kotlin 方案。

This article frames certificate pinning for 2026 and highlights a practical concern many tutorials leave out: how to rotate pins without breaking an app. It points to Network Security Config and OkHttp as the relevant Android mechanisms, and emphasizes the need for a rotation runway rather than treating pinning as a one-time setup. The piece is presented as guidance on managing pin changes safely while preserving app connectivity.

这篇文章以 2026 年的证书固定为主题，强调许多教程常常忽略的一个问题：如何在轮换 Pin 时避免把应用程序弄坏。文中提到 Android 相关的 Network Security Config 和 OkHttp，并指出证书固定不能只做一次配置就结束，而需要预留轮换缓冲期，才能在调整证书时尽量保持应用连通性与可用性。

The article focuses on coroutine stack trace recovery in Android. It explains that this feature is disabled by default, then describes how to enable it so coroutine failures become easier to understand. It also warns about subtle pitfalls that can silently take stack trace recovery away, making debugging less informative than expected.

本文围绕 Android 上的 coroutine stack trace recovery 展开。作者指出该功能默认处于关闭状态，并介绍如何将其开启，以便在 coroutine 出错时更容易理解调用路径、提升排查效率。同时，文章还提醒读者注意一些隐蔽的陷阱，因为它们可能会悄然让 stack trace recovery 失效，使调试信息不如预期完整。

This article introduces JetImagePicker v2.0.0+ and notes that the library has changed significantly since version 1. The main emphasis is on improved permissions handling, positioning the update as a more streamlined image-picking experience in Jetpack Compose. The excerpt does not add implementation details beyond this version note and the focus on permission-related improvements.

本文介绍 JetImagePicker v2.0.0+，并指出该库自 v1 以来已有明显演进。文章重点放在权限处理的改进，说明新版更强调减少权限相关顾虑，让 Jetpack Compose 中的图片选择体验更加顺畅。就目前提供的内容来看，摘要仅能确认版本范围与权限改善，未包含其他实现细节。

This article sets up a practical, non-biased comparison between Kotlin and Java in 2026 from the perspective of a developer with 17 years of Java experience. Rather than promoting one language as universally better, it aims to identify where each language has real strengths, where Java has closed gaps, and how developers can decide based on actual needs. The excerpt does not provide technical benchmarks or feature claims, so the piece should be read as a balanced opinion on choosing between the two languages rather than a definitive performance analysis.

本文以一位拥有 17 年 Java 经验的开发者视角，对 2026 年的 Kotlin 与 Java 做务实、不中立偏颇的比较。作者并不是要为任何一门语言站台，而是希望说明两者各自真正擅长的场景、Java 已经补齐的差距，以及开发者应如何根据实际需求做选择。由于摘录内容未提供具体技术细节、基准测试或功能结论，因此这篇文章可理解为关于语言选择的平衡观点，而非性能定论。

The article examines how many hidden channels Kotlin Flow creates and questions common beliefs about operator behavior. The author specifically tests the idea that buffer() and flowOn() fuse into one channel when chained, then uses code to verify the actual behavior. During that investigation, four seemingly harmless cases surfaced, showing that many developers may misunderstand which operators create channels and how they interact.

这篇文章探讨 Kotlin Flow 会产生多少隐藏通道，并质疑人们对操作符行为的常见理解。作者先验证 buffer() 和 flowOn() 串联时是否真的会融合成单一通道，再用代码观察实际表现。在研究过程中，又发现四种看似无害的情况，说明许多开发者可能误解了哪些操作符会创建通道，以及它们之间如何交互。

Kotlin Weekly #528, dated 13 September 2026, rounds up the latest Kotlin ecosystem news, articles, videos, and libraries. The headline news is the release of Kotlin 2.4.20 by JetBrains, alongside Shopify’s shift back from React Native to Swift and Kotlin for mobile development. Article picks include Compose Desktop Native, JWT-based user management with Ktor and Exposed, offline support for Compose Web, RevenueCat integration for Kotlin Multiplatform, and the new Google Gen AI SDK for Kotlin. The issue also spotlights Android paywall animation work, several conference-style videos, and new libraries such as ARTEMIS and Library Insight.

Kotlin Weekly #528（2026 年 9 月 13 日）汇总了 Kotlin 生态的最新新闻、文章、视频与库。头条新闻包括 JetBrains 发布 Kotlin 2.4.20，以及 Shopify 在 AI 时代将移动开发从 React Native 转回 Swift 和 Kotlin。文章部分介绍了 Compose Desktop Native、使用 Ktor 和 Exposed 设计基于 JWT 的用户管理系统、让 Compose Web 支持离线、在 Kotlin Multiplatform 中接入 RevenueCat，以及新发布的 Google Gen AI SDK for Kotlin。期刊还收录了 Android 支付墙动画、多个视频，以及 ARTEMIS、Library Insight 等新库。