每日新聞摘要

Kotlin Weekly #494 (18 January 2026) spotlights the promotion of Compose Hot Reload to stable 1.0.0 and a deep technical article explaining its DCEVM-based class reloading, bytecode analysis, state invalidation, and zero-config IDE integration. The issue curates practical articles covering Koin minimal DI for Kotlin Multiplatform, how to update projects for Android Gradle Plugin 9.0 and the new Android KMP library plugin, a deep dive into Retrofit internals, using IDE AI agents for iterative development, backpressure experiments with Netty WebSocket, and comprehensive Kotest setup across KMP targets. It also announces upcoming sponsored Compose courses, recommends videos and a podcast episode, and highlights new libraries such as Resilient, Llamatik, Nominatim Proxy, and a Kotlin Multiplatform State Machine, with a closing note of thanks to JetBrains.

Kotlin Weekly 第494期（2026-01-18）重点报道 Compose Hot Reload 升级为 1.0.0 稳定版，并提供技术深度剖析，涵盖基于 DCEVM 的类重载、字节码分析、状态失效与 IDE 的零配置整合。期刊汇总多篇实用文章：在 Kotlin Multiplatform 中使用 Koin 做最小化依赖注入、如何为 Android Gradle Plugin 9.0 更新 Kotlin 项目并迁移至新的 KMP Android library 插件、Retrofit 的内部机制解析、使用 IDE 集成 AI agents 的开发流程示例、Netty WebSocket 的背压实验，以及跨平台 Kotest 的完整设置。另有赞助的 Compose 课程公告、视频与播客推荐，以及若干值得关注的 Kotlin 库，结尾感谢 JetBrains 支持。

This Medium article by Yogendra presents a straightforward introduction to the trie (prefix tree) data structure. The provided introduction is brief (four lines) and points readers to the full Medium post for further detail. The article aims to explain what a trie is, how nodes represent characters and prefixes, and how common operations—such as inserting keys, searching for exact matches or prefixes, and deleting entries—are performed conceptually. It also highlights typical motivations for using tries, including efficient prefix queries and autocomplete-like features, and indicates that operation cost generally scales with the length of the key rather than the number of stored keys. Readers interested in examples, diagrams, and implementation details are encouraged to continue reading on the linked Medium page.

这篇由 Yogendra 在 Medium 发布的文章，提供了对 Trie（前缀树）数据结构的简洁入门说明。文中开头为四行导语并引导读者前往 Medium 原文继续阅读。文章旨在说明 trie 的定义与节点如何表示字符和前缀，概述基本操作的概念性做法，如插入键、进行精确或前缀查找以及删除条目，并指出使用 trie 的常见场景，例如提高前缀查询和自动补全的效率；其操作开销通常与键的长度相关而非与存储的键总数成正比。需要示例、图示或实现细节的读者，可点击原文链接深入阅读。

This article argues that analytics for Android apps need not be messy if you design an analytics module around clean, interface-driven architecture. By defining a stable analytics interface and keeping provider-specific code behind that interface, the same module can work with any backend—Google Analytics, Firebase, a custom server, or others—without changing app code. That separation reduces coupling, makes provider swaps straightforward, and simplifies unit testing and mocking. The approach emphasizes a consistent public API for events and telemetry, implementation encapsulation, and clear boundaries so teams can maintain, extend, or replace analytics providers with minimal disruption. The result is an analytics layer that is modular, testable, and easier to evolve as requirements or backends change.

文章指出，如果用清晰的接口驱动架构设计分析模块，Android 应用的分析就可以变得干净而有序。通过定义稳定的分析接口并把具体后端实现封装在接口之后，应用只需通过统一的 API 发送事件和遥测，无需关心后端是 Firebase、Google Analytics 还是自建服务器。此种分离能够降低耦合度，方便替换后端并简化单元测试与模拟。明确的边界与实现封装使团队能够在不影响应用行为的情况下维护、扩展或替换分析提供者，使分析层更具模块化并更容易演进。

The article "KSP v/s KAPT: Crushing the Android Build Time Bottleneck" opens by noting a shared experience among Android developers: the stare when builds slow down. It examines Kotlin Symbol Processing (KSP) and Kotlin Annotation Processing Tool (KAPT), framing them as alternatives for code generation and build-time processing. Rather than presupposing a winner, the piece explores how each approach affects incremental compilation, annotation processing overhead, and developer workflow, and how choosing the right tool can reduce the "build time bottleneck" that frustrates teams. The author aims to provide practical insights to help teams evaluate trade-offs, measure build impact, and adopt patterns or tools that shorten compile times. Readers are guided to consider project scale, processor demand, and integration costs when deciding between KSP and KAPT to improve iteration speed.

本文〈KSP v/s KAPT：突破 Android 构建时间瓶颈〉以「每位 Android 开发者共通的凝视」作为開端，指出缓慢构建导致的挫败。文章在 KSP（Kotlin Symbol Processing）与 KAPT（Kotlin Annotation Processing Tool）之间进行比较，讨论两者在代码生成、注解处理开销及增量编译上的影响。作者旨在提供实践层面的洞见，帮助团队评估权衡、量测构建影响，并考量专案规模、效能需求与整合成本，以便在不同情境下选择能降低编译时间、提升迭代速度的工具或方案。

In Jetpack Compose's LazyColumn, list items are reused and may be disposed when scrolled out of view, which can cause per-item animations to restart unexpectedly when the item is recycled. The article recommends a straightforward solution: pin items using a PinnableContainer so they are not disposed while their animations should continue. By keeping the composable instance alive, the framework preserves its animation state instead of disposing and recreating it, preventing visible restarts. This pattern is useful when you have ongoing or continuous animations inside list items that must remain uninterrupted or when their lifecycle should persist beyond normal recycling. The post highlights the practical PinnableContainer approach to maintain animation continuity in Compose lists.

在 Jetpack Compose 的 LazyColumn 中，项目可能在滚动时被重用与释放，导致内部动画在项目被回收或重建时重新启动。文章建议用 PinnableContainer 将项目“钉住”，避免被释放，使 composable 与动画状态得以保留，从而防止动画可见地重置。这种方法适用于需要持续运行或离开屏幕时仍需保持状态的列表项，提供了一种实用的模式以保持动画连续性并改善使用体验。

The article advocates structuring projects as a 'Modulith' and deliberately hiding REST controller implementations inside module implementation packages so that the public API surface remains minimal and clear. By moving controllers out of the visible API packages, the implementation details are encapsulated and module boundaries become more explicit. This approach reduces accidental coupling between modules, clarifies which classes are intended as the public API, and supports a cleaner separation of responsibilities between API and implementation. The recommendation is to treat controllers and other implementation classes as internal to a module, exposing only well-defined interfaces; doing so makes the project's architecture easier to reason about and helps maintain a stable, intentional API surface as the system evolves.

文章主张使用『Modulith』架构，将 REST 控制器等实现类放在模块的实现包中隐藏，避免出现在公开 API 的包路径里。这样能使公共接口更简洁、模组边界更清晰，减少模块间的意外耦合并强化关注点分离。将实现视为模块内部细节，仅暴露明确的接口，有助于让项目架构更易理解和维护，并使公开 API 面向更可控、更稳定的发展。