每日新聞摘要

Kotlin Weekly #491 (28 December 2025) wraps up the year with community news, resources, and a brief AI-curated review of notable Kotlin breakthroughs from 2025. Key announcements include the Kotlin Multiplatform Contest (deadline January 12) offering a trip to KotlinConf 2026 in Munich with tickets and hotels covered, the early access waiting list for the Junie CLI powered by Gemini 3 Flash, and practical guidance for mobile teams using Kotlin in 2025. The issue also links to technical articles covering limits of on-device tool calling with sub-1B models, semantic typing in Kotlin, ExoQuery’s SQL tooling, Ktor native backend tutorials, Circuit + SwiftUI for KMP iOS apps, and improved Kotlin support in Spring Boot 4. Additional items include a Compose Multiplatform experiment on Apple TV, an advanced Jetpack Compose course waitlist, a GitHub Actions troubleshooting sponsored post, an Android LLM crash course, and the ComposeWebView library. The newsletter closes with thanks to JetBrains.

Kotlin Weekly 第 491 期（2025/12/28）是今年的最后一期，汇集社区公告、教程与精选文章，并包含编辑团队请 AI 总结的年度 Kotlin 突破。公告重点有 Kotlin Multiplatform 比赛（1 月 12 日截止，奖品含到 KotlinConf 2026 慕尼黑的行程与住宿）、Junie CLI 的 EAP 候补列表，以及为移动开发团队提供的实用 Kotlin 建议。本文目录包括关于在设备端用 sub-1B 模型调用工具的限制、何时使用语义类型、ExoQuery 的编译时 SQL 与验证、Ktor native 后端教学、用 Circuit 与 SwiftUI 现代化 KMP iOS 架构、以及 Spring Boot 4 的 Kotlin 支持展望。另有 Compose Multiplatform 在 Apple TV 的实验、进阶 Compose 课程候补、Android 上运行 LLM 的速成课和 ComposeWebView 库，并感谢 JetBrains 的支持。

This piece advocates moving past pervasive try-catch nesting by embracing Kotlin's Result.fold() and functional patterns to manage errors. Instead of scattering try-catch blocks and producing deeply nested control flow (the "Pyramid of Doom"), treating outcomes as composable values clarifies success and failure paths, reduces boilerplate, and makes code more predictable. Functional handling centralizes error conversion and propagation, improves readability, and simplifies testing by separating error logic from business logic. For Android developers, applying Result.fold() and related patterns leads to safer, cleaner, and more maintainable code without relying solely on imperative exception handling.

本文建议通过 Kotlin 的 Result.fold() 和函数式设计，取代传统容易嵌套的 try-catch 写法。将结果视为可组合的值能够清晰区分成功与失败路径，减少样板代码并避免深层控制流（即“Pyramid of Doom”）。这种方法有助于集中处理错误的转换与传播、提高代码可读性与可测试性，从而使 Android 项目中的错误管理更安全、简洁且易于维护。文章并示范了在日常开发中如何应用这一模式以增强错误处理的一致性。

This piece advocates moving past the legacy RemoteViews approach and adopting Jetpack Glance to create home screen widgets in a declarative, state-driven way, leveraging Jetpack Compose. It highlights a shift toward Compose-style UI construction for widgets, emphasizing that widgets can be built using familiar, modern patterns that react to state rather than relying on the older imperative RemoteViews model. The article points developers to Jetpack Glance as the pathway to integrate Compose principles into widget development, enabling clearer, more maintainable code for home screen components while aligning widget creation with contemporary Android UI practices.

文章主张放弃传统的 RemoteViews 方法，转而使用 Jetpack Glance 配合 Jetpack Compose，构建声明式、以状态驱动的主屏小部件。该方法强调用 Compose 风格的 UI 构建替代命令式的 RemoteViews，使小部件代码更直观、更易维护，也更能响应应用状态变更。作者将 Jetpack Glance 视为将 Compose 原则引入小部件开发的途径，从而让主屏组件开发与现代 Android UI 实践保持一致。

Android apps frequently face the issue of UI state being lost as activities or fragments go through lifecycle changes. In MVVM, the ViewModel is designed to hold and manage UI-related data so it survives configuration changes (such as rotations) and decouples state management from the View. The View observes state exposed by the ViewModel (for example via LiveData) and updates UI accordingly, while the ViewModel avoids direct references to the View to keep concerns separated and improve testability. Using ViewModel reduces bugs caused by lifecycle-driven state loss and helps maintain a clear structure where the View handles rendering and the ViewModel handles state and business logic.

在 Android 应用中，界面（UI）状态常在 Activity 或 Fragment 的生命周期变更时丢失。采用 MVVM 架构时，ViewModel 用于保存与管理 UI 相关的数据，使其在配置更改（例如屏幕旋转）时依然存在，从而避免状态丢失。View 通过观察 ViewModel 暴露的状态（如 LiveData）来更新 UI，而 ViewModel 不直接引用 View，以实现关注点分离并提升可测试性和可维护性。将状态逻辑放在 ViewModel 中有助于减少由生命周期引起的问题，使界面渲染与状态管理职责明确。

This article provides a focused examination of Jetpack Compose best practices and performance optimization as of December 2025. It surveys advanced techniques for building Compose UIs, emphasizes approaches for controlling recomposition to avoid unnecessary work, and reviews the most recent framework updates released in December 2025 that affect performance strategies. The piece outlines practical considerations for developers aiming to write efficient, maintainable Compose code, highlights patterns for reducing wasted recompositions, and discusses how the latest changes to the library influence optimization trade-offs. Intended as a deep-dive resource, the article aims to help readers align their code and tooling choices with the newest Compose recommendations and performance guidance available at the end of 2025.

本文围绕 2025 年 12 月的 Jetpack Compose，深入介绍最佳实践与性能优化要点。文章讨论了构建高效 Compose 界面的进阶方法、如何控制重组以减少不必要的工作以及最新发布的 12 月更新对性能策略的影响。目标是为开发者提供可操作的建议与权衡考虑，帮助编写更高效、易维护的 Compose 代码，并说明新版库变更如何影响优化方向和测量工具的使用。

In this article Abhinay reflects on his early mistakes when adopting Jetpack Compose and uses those lessons to present best practices for building a real-world search feature. He highlights common pitfalls—such as introducing side effects inside composables and mishandling state—and emphasizes patterns that keep UI logic modular and predictable. The piece aims to translate experience into actionable guidance: how to structure composables, manage state and effects responsibly, and design a search flow that behaves reliably under recomposition. Intended for developers moving from traditional Android UI to Compose, the article balances candid personal anecdotes with pragmatic recommendations to help readers avoid typical errors and build more maintainable, testable Compose code for search interfaces.

作者 Abhinay 以自身经验为出发点，总结在使用 Jetpack Compose 时常见的问题与应对方法，并将这些经验应用到构建真实场景的搜索功能上。文章指出应避免在 composable 中引入副作用、妥善处理状态以及采用可预测的设计模式，进而保持 UI 逻辑的模块化与可维护性。针对如何组织 composable、管理副作用与设计在重组（recomposition）下稳定运行的搜索流程，文章给出务实建议，适合希望将传统 Android 界面迁移到 Compose 的开发者，帮助他们减少常见失误并构建更易测试与维护的搜索界面。

This tutorial explains how to mark and reset positions when reading streams in Java. It reviews InputStream's key methods—mark(), reset(), and markSupported()—and notes that the default InputStream implementation does not support marking. The article shows ByteArrayInputStream supports resetting (and the read-ahead limit is irrelevant because all data is in memory) and demonstrates BufferedInputStream wrapping a FileInputStream to enable marking, while emphasizing the need for a meaningful read-ahead limit and sufficient buffer to avoid invalidating the mark (which causes reset() to throw an IOException). As an alternative to stream-based backtracking, RandomAccessFile is presented, using getFilePointer() and seek() to emulate mark/reset behavior via random file access. Example test snippets illustrate each approach and the code is available on GitHub.

本文介绍了在 Java 中如何在读取流时回退位置。首先讲解 InputStream 的 mark()、reset() 与 markSupported()，并说明默认实现不支持标记。示例展示 ByteArrayInputStream 支持重置且创建时数据已在内存中，因此 read-ahead 限制无意义；BufferedInputStream 可用于文件读取并支持标记，但必须提供足够的 read-ahead limit 和内部缓冲，否则当读取超出限制或缓冲区时，调用 reset() 会抛出 IOException。文章还介绍了 RandomAccessFile，使用 getFilePointer() 与 seek() 可自由选择文件位置以模拟 mark/reset 的行为。示例代码可在 GitHub 找到。

This article documents a comprehensive effort to modernize an Android app after years of neglect, described as a complete technical overhaul aimed at "bringing stereogram fun back to life." The author recounts the motivations for revisiting an older codebase, the broad scope of work necessary to update and stabilize the project, and the practical trade-offs encountered during the process. Rather than a step-by-step tutorial, the piece focuses on the narrative of diagnosing issues, making design and tooling decisions, and applying lessons learned to restore functionality and user experience. It emphasizes the value of careful planning, prioritizing improvements, and iterating to achieve a maintainable, rejuvenated app while sharing insights useful to developers facing similar legacy modernization tasks.

本文记录了作者对一款多年未维护的 Android 应用所做的完整技术改造，目的在于“让 stereogram 的乐趣重现”。文章说明了回归旧代码库的动机、为更新与稳定化所需的广泛工作，以及在改造过程中遇到的关键挑战与取舍。作品以叙述与经验总结为主，涵盖问题诊断、设计与工具选择，以及通过迭代恢复功能和用户体验的过程。全文强调了周密规划、优先级排序与逐步改进的重要性，并对面临类似遗留系统现代化的开发者提供了可借鉴的见解。