每日新聞摘要

Issue #487 (30 November 2025) summarizes recent Kotlin ecosystem news and resources. Key announcements include the KotlinConf 2026 Call for Papers (final week to submit) for the May 20–22 Munich event with a 20% ticket discount, and a free December 3 webinar about moving from Android to Kotlin Multiplatform featuring Jake Wharton and Zac Sweers. JetBrains published guides on scaling Kotlin adoption, released Amper 0.9.0 with a first custom-plugin extensibility preview plus performance improvements, and curated a “KMP Level Up” watchlist; Multiplatform docs have moved to kotlinlang.org. The issue also links to a JetBrains article on building AI agents in Kotlin (Part 2), sponsored training and a coroutines cheat sheet, an Android case study on Reddit’s R8 optimizations, videos on Koin and coroutine race conditions, and several new libraries and Ktor plugins.

第 487 期（2025-11-30）汇总了 Kotlin 生态的最新公告与资源。要点包括 KotlinConf 2026 征稿进入最后一周（5 月 20–22 日于慕尼黑举办，票券享 20% 折扣）、12 月 3 日关于从 Android 转向 Multiplatform 的免费网络研讨会（有 Jake Wharton、Zac Sweers 等人出演）、以及 JetBrains 发布的跨组织推广 Kotlin 指南。其他更新有 Amper 0.9.0（含自定义插件扩展预览、加速的依赖解析与增量 Java 编译）、KMP 学习精选清单、Multiplatform 文档迁移、关于在 Kotlin 中构建 AI agents 的系列文章、Android 上 Reddit 采用 R8 的性能案例、教学视频及若干新库与 Ktor 插件。

This brief post poses the question of how methods declared inside a Kotlin object are invoked at runtime and why developers might need to use the @JvmStatic annotation. It frames the topic as an exploration of internal call mechanics and the implications for Java–Kotlin interop, highlighting that the internal representation and call patterns can affect how Kotlin code is accessed from Java. The author invites readers to continue on Medium for a fuller explanation, implying the article will clarify the internal invocation flow and practical reasons to choose or omit @JvmStatic when exposing object methods to Java code.

本文通过一个问题切入：Kotlin 的 object 内的方法在运行时如何被调用，以及为何有时需要使用 @JvmStatic。作者将该主题作为对内部调用机制及其对 Java–Kotlin 互操作性影响的探讨，指出内部表示与调用模式会影响从 Java 访问 Kotlin 代码的方式。文章并邀请读者前往 Medium 阅读完整内容，后续将说明内部调用流程以及在何种情形下应考虑使用或省略 @JvmStatic。

This short notice introduces "Mastering Jetpack Compose Navigation 3: The Ultimate Guide" by Gal Machluf and signals a significant update to navigation in Jetpack Compose. The author describes Navigation 3 as a notable "glow-up" and urges readers to forget prior assumptions about NavController, indicating substantial changes to the API or workflow. The post functions as an announcement and gateway: it highlights that Navigation 3 represents an important shift for Compose navigation and directs readers to continue reading the full, detailed guide on Medium for explanations, examples, and migration guidance. The message is brief and promotional, emphasizing that developers should prepare for and learn the new Navigation 3 approach.

这则简短公告介绍了 Gal Machluf 的文章《精通 Jetpack Compose Navigation 3：终极指南》，指出 Navigation 3 是对 Compose 导航的重要更新，并以“导航刚刚焕然一新”为描述，强调应放弃对 NavController 的既有认知，暗示 API 或工作流将发生重大变化。文章主要作为提示与引导，提醒开发者关注这一变更并前往 Medium 阅读完整指南以获取详细说明、示例和迁移建议。

This Medium post by Kabi introduces Koin, describing it as a pragmatic and lightweight dependency injection framework implemented entirely in Kotlin and aimed at Kotlin developers. The brief excerpt highlights Koin’s Kotlin-native approach and its emphasis on practicality and minimalism. The article serves as an entry point for developers curious about Kotlin-focused dependency management, framing Koin as an option that aligns with Kotlin idioms. It points readers to the full Medium article for a deeper discussion. In general terms, dependency injection is a design pattern for supplying components with their required collaborators rather than creating them directly; a Kotlin-native DI like Koin is presented here as a straightforward, language-aligned alternative worth exploring for Kotlin projects.

Kabi 在 Medium 上的文章介绍了 Koin，指出它是一个务实且轻量的依赖注入框架，完全用 Kotlin 编写，面向 Kotlin 开发者。摘录强调了 Koin 的 Kotlin 原生特性与注重实用的设计，将其作为一种与 Kotlin 语言习惯相契合的依赖管理方案。该文为对 Kotlin 中依赖注入感兴趣的开发者提供入门指引，并引导读者在 Medium 上阅读全文。依赖注入是一种将组件所需协作对象提供给组件而非由组件自行创建的模式，Koin 在此背景下被推荐为一个值得了解的简洁替代方案。

This article by Fadi Bouteraa addresses the challenge of scaling Kotlin Multiplatform (KMP) in production contexts and advocates for a deliberate architectural approach. It presents the idea of a feature-oriented Clean Architecture as a way to organize cross-platform code for real products, arguing that KMP projects benefit from clear boundaries, modular features, and consistent architectural principles. The piece emphasizes why KMP needs a “real” architecture rather than ad hoc structures, and outlines the high-level rationale and goals behind adopting a feature-focused, clean architecture mindset when building apps that target multiple platforms. A section explicitly titled “Why Kotlin Multiplatform Needs a Real Architecture” highlights the motivations for this approach and its relevance to teams delivering production software.

作者 Fadi Bouteraa 讨论了在生产环境中扩展 Kotlin Multiplatform（KMP）时的挑战，主张采用明确的架构策略。文章提出一种面向功能的 Clean Architecture，用以组织跨平台代码，认为通过清晰边界、模块化功能和一致的架构原则，KMP 项目更适合生产化。文中强调 KMP 需要“真正的”架构，而不是临时拼凑，并阐述采纳功能导向与 Clean Architecture 思维的高层动机与目标。文献中有一节题为“Why Kotlin Multiplatform Needs a Real Architecture”，突出该方法对团队交付真实产品的相关性。

This article is written for Kotlin developers who want a conceptual grasp of RabbitMQ rather than just API mechanics. It focuses on developing mental models that make it easier to reason about messaging behavior, system interactions, and the trade-offs that come with asynchronous communication. By prioritizing understanding—how messages flow, how components relate, and what failure modes look like—the piece argues developers can design and debug messaging-based systems more effectively. The approach is pragmatic and explanatory, connecting RabbitMQ fundamentals to everyday development decisions so readers can decide when and how to use messaging in their applications. Overall, the article aims to leave Kotlin practitioners with a usable conceptual framework for approaching RabbitMQ-powered architectures.

本文为 Kotlin 开发者提供针对 RabbitMQ 的概念性讲解，侧重建立有助于推理与决策的思维模型，而不仅是 API 使用方法。文章主张，通过理解消息流、组件关系与可能的故障情形，开发者能在设计与调试基于消息的系统时做出更合理的取舍。内容以务实的解释为主，将 RabbitMQ 的基本观念与日常开发决策相连，帮助读者判断何时采用消息机制并将概念应用到实际架构中，从而提升异步系统的可靠性与可维护性。

This mini-project presents a compact, educational demonstration of UI–ViewModel communication within a classic MVI (Model-View-Intent) architecture for Android, written in Kotlin. Focused on clarity and minimal code, it illustrates how the UI and ViewModel can exchange intents, state, and events in a predictable, unidirectional flow that supports separation of concerns. The example is intentionally small in scope to keep concepts accessible, helping readers grasp interaction patterns without heavy boilerplate. Published on Medium by &Rey, the post serves as a concise, practical starting point for developers who want a clean, hands-on reference for applying MVI principles in an Android/Kotlin context and directs readers to the full article for code and further explanation.

该迷你项目在 Medium（作者：&Rey）上提供了一个简洁、教学用途的示例，展示在经典 MVI（Model-View-Intent）架构下，Android 与 Kotlin 环境中 UI 与 ViewModel 如何通信。内容以最小化代码与清晰表达为目标，说明单向数据流和职责分离如何帮助管理 intents、state 与事件，让读者在不被繁琐样板码干扰的前提下，快速理解交互模式。该文章适合作为想要入门或评估 MVI 应用的开发者的实用起点，并引导读者阅读完整文章以获取代码与更多说明。

The author describes a six-month follow-up after rewriting a Java monolith in Kotlin, focusing on measurable outcomes rather than anecdotes. The article highlights three core areas: performance metrics collected after the migration, team productivity data that showed how the change affected day-to-day development, and unforeseen hiring difficulties that complicated staffing. Rather than claiming unequivocal wins or losses, the piece presents data and reflections to help teams weigh trade-offs when considering a similar rewrite. It emphasizes that migrations can surface operational and hiring issues as much as technical ones, and encourages readers to examine empirical results and lessons learned before committing to large-scale language or platform changes.

作者描述了将公司 Java 单体重写为 Kotlin 后六个月的跟踪观察，侧重可量化的结果而非主观评价。文章围绕三大要点：迁移后收集到的性能指标、反映日常开发影响的团队生产力数据，以及迁移后出现的意外招聘难题。作者没有断言绝对的成功或失败，而是用数据与经验提醒读者，类似的大规模语言迁移不仅涉及技术问题，还会带来运营和人力方面的挑战，建議在决定前仔细评估实际数据与所得教训。

This Medium post by Ahmed Nabil is Episode 2 in a series titled "Jetpack Compose Side Effects: A Developer’s Journey." The visible content for this entry consists solely of the episode name — "The 'Fire and Forget' Nightmare" — followed by a prompt to continue reading on Medium. As presented, the excerpt does not include body text, examples, or concrete guidance; it serves as a teaser linking to the full article. From the episode title, the focus appears to be on issues related to the "fire-and-forget" approach to side effects in Jetpack Compose, but specific details and recommendations are not available in the snippet. Readers must follow the Medium link to read the complete discussion and technical content.

这篇由 Ahmed Nabil 撰写的系列第二集，标题为“Fire and Forget 噩梦”，属于探讨 Jetpack Compose 中副作用的开发者旅程。当前可见内容仅为该集的标题和一行提示，随后带有“Continue reading on Medium”的链接，提示读者在 Medium 上查看完整文章。依据标题可判断，本集关注点应是“fire-and-forget”类型的副作用模式及其潜在问题，但片段未包含具体示例或解决方案；想获取完整技术细节与作者分析，需要点击链接阅读原文。

This article introduces Kotlin extension functions as a language convenience that lets developers add behavior to existing types without modifying their source. It explains why such syntax can make everyday programming more enjoyable and productive, and outlines guidance for when and how to create extension functions to keep APIs clear and maintainable. The discussion covers practical considerations — such as choosing appropriate receivers, avoiding surprising behavior, and keeping functions discoverable — and offers principles to balance convenience against potential misuse. The piece aims to help readers design extension functions that enhance readability and usability while minimizing ambiguity and maintenance cost.

本文介绍了 Kotlin 的扩展函数概念：可以在不修改原类型源码的情况下为其添加行为，作为提升日常开发效率与可读性的便捷语法。文章强调设计扩展函数时应考虑接收者的适当性、避免引入令人迷惑的行为、以及如何保证函数的可发现性与可维护性。通过原则性建议与实用考虑，作者旨在帮助读者在便利性与可维护性之间取得平衡，编写既直观又安全的扩展函数。

This article, part six of a series on Android animations in Compose, addresses situations where Kotlin's native animation APIs are insufficient for high-fidelity, designer-authored motion. It explains the rationale for integrating two external animation formats—Lottie for rich JSON-based, cross-platform animations created in After Effects, and AnimatedVectorDrawable (AVD) for vector-based Android-native animations—to preserve visual fidelity and match design intent. The piece outlines the benefits of bridging these assets into Compose UIs, such as better collaboration with designers, reduced reimplementation effort, and support for complex timing or illustrator-driven motion. It also notes practical trade-offs when using third-party formats, like increased dependency surface and potential runtime overhead, and emphasizes choosing the right format depending on asset complexity and project constraints. Readers are invited to continue on Medium for implementation details.

本文为「Android Animations in Compose」系列第六篇，介绍当 Kotlin 的原生动画 API 无法满足高保真设计稿需求时，如何整合 Lottie 与 AnimatedVectorDrawable (AVD)。文章说明 Lottie 适合来自 After Effects 的复杂 JSON 动画，AVD 则适用于向量化的 Android 原生动画。将这些资产引入 Compose 有助于保留设计细节、减少重写工作并改善与设计师的协作，但也带来依赖增加与可能的运行时开销等权衡。文中建议根据资产复杂度和项目限制选择合适格式，并引导读者到 Medium 查看具体实现细节。

Compose Multiplatform (CMP) promises to fundamentally change mobile development by enabling teams to share roughly 95% of their UI code across Android and iOS. Instead of implementing and maintaining two separate interfaces, developers can write a single, composable UI layer that produces consistent visuals and behaviors on both platforms while still allowing platform-specific integrations when needed. This approach reduces duplicated work, simplifies maintenance, shortens release cycles, and helps product and design teams achieve parity across platforms. By focusing on a shared, performant, and expressive UI toolkit, CMP aims to make building beautiful cross-platform apps more practical — effectively moving the industry closer to the long-standing goal of writing mobile apps once rather than twice.

Compose Multiplatform（CMP）提出通过单一可组合的 UI 代码库同时支持 Android 与 iOS 的方案，声称可达到约 95% 的代码共享比例。这样团队无需为两个平台各自重写界面，能够减少重复工作、简化维护并缩短上线周期，同时在必要时保留平台特定集成的灵活性。对产品与设计团队而言，CMP 有助于实现跨平台的视觉与交互一致性；对工程团队而言，则能提升开发效率，让更多精力投入到性能和用户体验上。

Kotest is a Kotlin testing framework designed to make testing simple, expressive, and less burdensome. The article highlights how Kotest helps developers write cleaner tests by offering a flexible DSL, multiple test styles to match different preferences, and support for mocking and common testing patterns. It also emphasizes Kotest’s usefulness when writing tests for Android projects, providing utilities and integrations that fit typical Android workflows. Overall, the piece positions Kotest as a practical option for teams and developers who want more readable, maintainable test code in Kotlin, and points readers to ProAndroidDev for a full walkthrough and examples.

文章介绍了 Kotest 这款面向 Kotlin 的测试框架，主张测试应当简单且不造成额外负担。Kotest 提供灵活的 DSL、多样的测试风格以满足不同偏好，并支持 mock 与常见测试模式，从而让测试代码更易读、更易维护。文章还强调了 Kotest 在 Android 开发中的实用性，包含对 Android 测试流程与整合的支持，并指向 ProAndroidDev 获取详细示例与完整教程。