每日新聞摘要

Kotlin Weekly #493 (11 January 2026) compiles recent updates across the Kotlin ecosystem. The announcement spotlights Media3 1.9.0, which brings a new inspector and Compose Material3 UI module, an AV1 decoder rewrite, smarter preloading and memory management, simplified ExoPlayer and MediaSession APIs, plus experimental CompositionPlayer support for real‑time media editing previews. The issue highlights articles including a Kotlin brain teaser showing null + null concatenation, Block’s migration from Ktlint to Ktfmt and adoption of Detekt for auto-fixes and performance, a comprehensive Android dependency injection guide comparing manual DI, Hilt and Koin (and the upcoming Koin Compiler Plugin), a deep dive into Ktor Client pipelines and plugin design, and a walkthrough adding database migrations to Ktor using Exposed. It also lists a sponsored Practical Kotlin Deep Dive book, a Koin/Compose Multiplatform video, a Compose cheat-sheet, several Kotlin Multiplatform libraries, contribution info, and thanks to JetBrains.

Kotlin Weekly 第493期（2026-01-11）汇总近期 Kotlin 生态的重要更新。公告部分以 Media3 1.9.0 为主，带来了检视器和 Compose Material3 UI 模块、重写的 AV1 解码器、更智能的预加载与内存管理、简化的 ExoPlayer 与 MediaSession API，以及用于实时媒体编辑预览的实验性 CompositionPlayer。期刊精选文章包括示例说明 null + null 会导致字符串连接、Block 从 Ktlint 迁移到 Ktfmt 并采用 Detekt 以提升格式一致性和性能、一篇比较手动依赖注入、Hilt 与 Koin 的 Android DI 深入指南（并提及即将到来的 Koin Compiler Plugin）、Ktor Client pipeline 与插件设计的深入解析，以及用 Exposed 在 Ktor 中添加数据库迁移的实践演示。此外列出赞助书籍《Practical Kotlin Deep Dive》、Koin 在 Compose Multiplatform 的注入影片、Compose 备忘单与多个跨平台库，并感谢 JetBrains 的支持。

This article advocates a Contract-First approach for Kotlin Multiplatform (KMP) apps: put a shared Kotlin interface in a :network:api module and use it as the single source of truth for both clients and server. Client-side implementations are generated with Ktorfit (Retrofit-like), while a custom KSP processor generates server routing code, injecting a CallContext into coroutine contexts so server implementations can access the raw ApplicationCall or typed JWT without changing the shared signatures. The result is full-stack type safety—changing an API breaks builds on both client and server until both are updated. The author also covers trade-offs: you must maintain custom tooling, runtime limits around JWT type safety, stricter development discipline, and careful versioning to avoid breaking older clients. The setup is open-sourced as ModernArchitecture; Part 2 will address modularization and build-time scalability.

文章介绍了一种 Contract-First 的 KMP 架构：把 API 行为定义为共享的 Kotlin 接口，作为客户端与服务器的单一真相。客户端通过 Ktorfit 自动生成实现，作者编写的 KSP 处理器为服务器生成路由代码，并在请求运行时将 CallContext 注入协程上下文，让实现可以访问原始请求与类型化 JWT 而无需修改接口签名。这样一来，API 改动会在编译期让客户端和服务器同时报错，保障全栈类型安全。作者同时指出权衡：需维护自有工具、JWT 在运行时的类型安全局限、开发节奏更受限以及必须谨慎做向后兼容。该方案已开源，下一部分将讨论模块化与构建性能优化。

Blitzy is a small, minimal 2D game engine written in Kotlin, created by its author after encountering Kotlin engines that were overly complex, feature-poor, or poorly documented. It provides core game features including sound playback and control, keyboard and mouse input, simple hitboxes, a tile system (tilesets and CSV tilemap loading), entity classes, TTF font loading and text rendering, scene switching and saving, and simple shape drawing. The project is built on LWJGL3 with OpenGL rendering and is designed to be straightforward and easy to modify for learning or customization. The engine is fully open source under the LGPL; the author welcomes feedback, bug reports, and contributions, and has published example code, documentation, and a Pong demo on the project's GitHub.

作者在寻找 Kotlin 游戏引擎时常遇到过于复杂、功能不全或文档过时的情况，因此开发了 Blitzy——一个以简洁为目标的 2D 引擎。Blitzy 提供音效播放与控制、键盘与鼠标输入检测、简单碰撞箱、图块系统（含 tileset 与从 CSV 加载 tilemap）、实体类、加载 TTF 字体并渲染文字、场景快速切换与保存，以及简单几何图形绘制。引擎基于 LWJGL3 和 OpenGL，代码易于修改，适合学习与定制。项目以 LGPL 开源，作者欢迎反馈、错误报告与贡献，并在 GitHub 提供代码、文档与一个 Pong 示例。

The article explains that by 2026 Android development is being reshaped by Google's push toward large-screen devices, and as a result, landscape support is no longer optional for native apps. This shift elevates expectations for app layout, navigation, and user experience across tablets, foldables, and resizable windows. Developers are urged to treat landscape as a first-class mode, design responsive layouts, and expand testing across orientations and screen sizes. The change affects planning, QA, and release decisions: apps that ignore landscape may face degraded user experience and platform signal issues. Overall, the piece frames the 2026 orientation change as a practical imperative driven by device trends and Google’s platform strategy, requiring developers to update design patterns and testing practices for large-screen readiness.

文章指出，随着 Google 推动大屏设备，到了 2026 年，原生 Android 应用对横屏（Landscape）支持的要求发生了变化，横屏已不再是可选项。该变动提升了对应用布局、导航和用户体验的期望，涉及平板、可折叠设备和可调整窗口等多种情形。开发者需将横屏作为重要展示模式，采用响应式布局并在不同屏幕尺寸与方向上加强测试。对产品规划、质量控制与发布策略而言，忽视横屏可能导致体验下降或不符合平台新标准。总体上，文章将 2026 年的方向性调整视为由设备趋势和 Google 平台策略驱动的必然趋势，建议开发者尽快调整设计与测试实践以适应大屏化。

Shubham Kumar Gupta’s article examines Android 16’s new Live Activities feature, framing it as Google’s answer to iOS-style real-time persistent notifications. It explains why Live Activities matter: they allow apps to present continuously updating, glanceable content in the notification area so users can follow ongoing events without opening an app. The piece discusses building Live Activities on Android 16, compares the capability to iOS equivalents, and considers implications for user engagement, discoverability, and developer workflows. Gupta highlights common live-update scenarios — deliveries, sports scores, media playback, and rideshares — and argues that persistent, real-time notifications can enhance utility and retention. While noting that this brings Android closer to parity with iOS, the article also cautions developers to adopt the pattern thoughtfully to avoid notification fatigue.

Shubham Kumar Gupta 的文章审视了 Android 16 引入的 Live Activities，认为这是 Google 对 iOS 实时持久通知的回应。文章说明 Live Activities 的价值：允许应用在通知区持续更新可快速查看的内容，使用户无需打开应用也能跟踪正在进行的事件。作者讨论了在 Android 16 上构建 Live Activities 的相关议题，与 iOS 功能进行比较，并探讨对用户参与度、可见性和开发流程的影响。文章列举了外卖、赛事、媒体播放和共乘等常见应用场景，指出该功能有助于缩小平台差距并带来新的用户体验模式，同时提醒开发者在采用时需谨慎平衡通知的有用性与用户疲劳。

This short Dev Genius post by Aleksei Jegorov, titled "Kotlin sure operator !!", centers on Kotlin's sure operator (!!) and notes "Different types of pre-validation." The sure operator is used to assert that a nullable expression is non-null at runtime; if the value is null, the operator throws a NullPointerException. The excerpt indicates the article surveys approaches to validate values before using !! to avoid runtime failures. Because the provided snippet is minimal, readers are directed to the linked Dev Genius article for concrete code examples, comparison of validation approaches, and recommendations for safer null-handling patterns in Kotlin.

Aleksei Jegorov 在 Dev Genius 的短文《Kotlin sure operator !!》以 Kotlin 的 sure operator（!!）为主题，文中指出「不同类型的预先验证」。!! 用于在运行时断言可空表达式非空，若为 null 则会抛出 NullPointerException。摘录表明文章讨论在使用 !! 前对值进行验证的不同方法以避免运行时错误。由于原始片段信息有限，欲获取示例代码、验证方法比较及更详细的安全处理建议，请通过文章链接阅读全文。

During APM monitoring the team observed a stair-step pattern of sudden memory increases and initially suspected a G1 Old Generation memory leak. To verify, they compared the metric to similar past incidents and inspected the suspected leak points. Through systematic checking and correlation with other cases, they concluded that the observed pattern was not caused by an Old Gen leak as first thought. The post emphasizes validating initial assumptions with additional data and cross-checks rather than immediately attributing memory growth to Old Gen leaks, illustrating the importance of careful investigation when diagnosing JVM memory behavior.

在使用 APM 进行监控时，发现内存指标出现类似阶梯状的快速上升，最初怀疑为 G1 Old Generation 的内存泄漏。为验证这一假设，作者将该指标与类似案例进行比对，并检查潜在的泄漏点与相关数据。通过系统化的核查和交叉对比，最终确认观测到的内存增长并非由 Old Gen 泄漏引起。文章强调在诊断 JVM 内存问题时，应以更多数据和比对为依据来验证初步结论，而不是仓促将问题归因于 Old Gen。

The article analyzes the interaction between Micronaut's Kafka listener settings—specifically the RETRY_ON_ERROR error strategy and the batch=true mode—and the practical side effects that can follow. It explains how enabling retries at the listener level while processing messages in batches may lead to whole-batch reprocessing, complicating offset commits and increasing the risk of duplicate message handling. The author highlights that these behaviors are not always intuitive, and that side effects depend on how Micronaut and the Kafka consumer manage acknowledgements and commits during failures and retries. The piece advises developers to be aware of these interactions, test their consumer behavior thoroughly under failure scenarios, and consider alternative error handling or offset strategies to avoid unintended repeated processing or data inconsistencies.

本文分析了 Micronaut Kafka listener 在同时启用 RETRY_ON_ERROR 错误策略和 batch=true 处理模式时，可能产生的实际副作用。作者指出，对批处理启用重试可能导致整个批次被重新处理，从而使位移（commit）管理变得复杂，并提高消息重复消费的风险。这些副作用取决于 Micronaut 与 Kafka 消费端在失败与重试期间如何处理确认与提交，可能并不直观。文章建议开发者在故障场景下进行充分测试，关注错误处理与位移策略的选择，以避免意外的重复处理或数据不一致。

In "How Jetpack Compose Knows Exactly What to Recompose (And Why That's the Real Reason It's Fast)", Viineet Nigam explains how Jetpack Compose determines which parts of the UI to update and argues that selective recomposition is the primary source of its performance advantage. The article outlines the reactive model Compose uses to observe state changes, how it confines updates to the minimal necessary components, and why avoiding wholesale UI redraws reduces CPU work and latency. Nigam also connects these mechanisms to developer ergonomics, noting that clearer state boundaries and predictable recomposition help maintain responsive interfaces. The piece frames Compose's efficiency not as a byproduct of incidental optimizations but as a direct consequence of its design to track dependencies and re-execute only affected UI logic, resulting in faster and more scalable UIs on Android.

Viineet Nigam 在本文中说明 Jetpack Compose 如何确定哪些 UI 区块需要重新组合，并指出选择性重组（recomposition）的机制是其性能优势的核心。文章描述 Compose 如何根据状态变化监测依赖，将更新限制在必要的最小组件范围内，避免整个界面重绘，从而降低处理成本与延迟。作者也讨论这种设计对开发体验的正面影响：明确的状态边界与可预测的重组行为有助于保持界面响应速度。全文主张 Compose 的效率源于其设计能够追踪依赖并仅执行受影响的 UI 逻辑，而非偶然的优化。