每日新聞摘要

On Day 4 the author sets up CI/CD so every push to main automatically builds, tests, and deploys the app. A GitHub Actions workflow checks out the repo, sets up JDK 21 and Node 20, runs frontend and API tests, then builds and pushes a single multi-stage Docker image that bundles the React frontend into the Spring Boot JAR. The deploy job logs into a Hetzner VPS via SSH and runs docker compose pull and docker compose up -d to restart the service. The Dockerfile uses three stages (frontend build, backend build with static resources, minimal runtime) producing an image around 250MB. The VPS runs a simple docker-compose with app and Postgres and keeps secrets in a server .env. The approach favors simplicity (no Kubernetes, Terraform, or blue‑green for now) and the full pipeline ran in about four minutes — shipping is now just git push.

第4天作者在项目早期就建立 CI/CD，让每次推送到 main 自动构建、测试并部署。使用 GitHub Actions 安装 JDK 与 Node，执行前端与 API 测试，采用多阶段 Dockerfile：先构建前端，再将编译后静态文件置入 Spring Boot 的 resources 并生成 JAR，最后以精简 JRE 运行镜像（约 250MB）。工作流将镜像推到 GitHub Container Registry，然后通过 SSH 在 Hetzner VPS 执行 docker compose pull/up 重启服务。服务器上用 docker-compose 管理 app 与 Postgres，敏感信息保存在服务器的 .env。此策略以简化为主，暂不采用 Kubernetes、Terraform 或蓝绿部署；验证流程约 4 分钟，从此只要 git push 即可部署。

Kotlin Weekly issue #492 (4 January 2026) curates recent Kotlin-focused articles, tools and community news. Key items include a multipart guide explaining why Kotlin Multiplatform (KMP) is a low‑risk, production‑ready way to share business logic while keeping native performance and maintainability; a practical CI optimisation showing that killing the Kotlin compile daemon before R8 can cut peak memory and speed up Android release builds; and a walkthrough of using Gradle Version Catalogs to centralise app versioning across Android, iOS and shared UI. The issue also links to deep technical posts on using static exceptions for flow control and on Jetpack Compose node types, a sponsored Practical Kotlin book, a refactoring video, an upcoming webinar on Compose modifiers, and new open‑source KMP libraries (Amplitude SDK, KMPLiquidGlass, KtEmbed).

Kotlin Weekly 第492期（2026年1月4日）整理了近期 Kotlin 生态的文章与资源。要点包括：多篇关于 Kotlin Multiplatform 的实践指南与白标应用案例，说明它如何在保留原生性能的同时实现共享逻辑；一则实用优化展示了在 Android release 构建中于 R8 之前杀掉 Kotlin 编译 daemon 可显著降低内存占用并加速 CI；以及使用 Gradle 版本目录作为跨平台版本单一来源的实作方法。期刊还推荐了关于在 JVM 上用静态异常减少垃圾与延迟、Jetpack Compose 节点类型的技术深度解析，另外列出赞助书籍、教学视频、Compose 修饰子线上研讨会与多个开源 KMP 库（Amplitude SDK、KMPLiquidGlass、KtEmbed）。

This article highlights how Jetpack Compose has transformed Android UI development and assembles practical Kotlin tips to help developers write working, clean, performant, and scalable Compose code. Aimed at Android engineers adopting Compose or improving an existing codebase, the piece emphasizes pragmatic patterns and real‑world considerations rather than abstract theory. It offers actionable guidance to avoid common pitfalls, improve maintainability, and keep runtime performance in mind while leveraging Compose APIs alongside Kotlin idioms. The author frames these tips as essential knowledge for developers who want to take full advantage of Compose while producing robust, efficient UI code suitable for real projects.

本文说明了 Jetpack Compose 如何重塑 Android 界面开发，并汇集了实用的 Kotlin 技巧，帮助开发者编写可运行、干净、性能良好且可扩展的 Compose 代码。面向希望采用 Compose 或改进现有代码库的开发者，文章侧重务实模式和真实项目中的注意点，提供可操作的建议以避免常见陷阱，提升代码可维护性与运行效率，帮助读者在实际项目中更好地使用 Compose。

Jaewoong Eum announces Landscapist Core, a new image-loading library for Android and Compose Multiplatform in a ProAndroidDev post. The article frames image loading as a fundamental, longstanding challenge in mobile and cross-platform development and presents Landscapist Core as a project created to address that space within Android and Jetpack Compose Multiplatform contexts. It outlines the motivation and platform scope of the library and points readers to the full article for implementation details, examples, and usage guidance. Eum highlights the ongoing need for performant, easy-to-use image loaders in Compose projects and encourages developers to evaluate Landscapist Core for cross-platform UI work, inviting feedback and further discussion via the linked post.

本文由 Jaewoong Eum 在 ProAndroidDev 发布，宣布推出 Landscapist Core——一款面向 Android 与 Compose Multiplatform 的新图像加载库。文章指出图像加载长期以来是移动与跨平台开发的核心挑战，并介绍 Landscapist Core 的推出动机与适用平台范围，提醒读者查阅完整文章以获取示例与使用说明。作者同时邀请使用 Compose 的 Android 与跨平台开发者评估该方案、关注后续更新并提供社区反馈。

Recomposition is the mechanism in Jetpack Compose that re-executes composable functions when observed state changes. Instead of rebuilding the entire interface, Compose identifies the composables that depend on the changed state and reruns only those functions, updating just the affected portions of the UI. This state-driven, selective approach keeps updates efficient and localized, preventing unnecessary work on unchanged UI elements. Grasping recomposition helps developers understand when code inside composables is rerun and how state changes propagate to visible updates, which is important for writing responsive and performant Compose applications.

Recomposition（重新组合）是 Jetpack Compose 在观察到状态变化时重新执行 composable 函数的过程。Compose 会识别哪些 composable 依赖于已改变的状态并只重新运行那些函数，因此仅更新受影响的 UI 部分，而不是重建整个界面。这种以状态驱动的选择性重组使更新更高效且局部化，避免对未改变的组件进行不必要的处理。理解 recomposition 有助于掌握 composable 内代码何时被重执行以及状态如何触发界面更新，对编写响应迅速且性能良好的 Compose 应用至关重要。

In this short piece, Ayyappan Karunan calls attention to a single Kotlin constructor rule that many developers overlook. That overlooked rule, the author argues, quietly leads to developer confusion, subtle bugs, and poor API designs. The article explains how neglecting this rule can make object initialization ambiguous, create surprising behavior for library consumers, and propagate fragile or hard-to-use public interfaces. Rather than dwelling on abstract theory, the author emphasizes practical implications and offers advice: be deliberate about which constructor forms you expose, prefer explicit and consistent initialization patterns, and review constructor visibility and defaults to avoid accidental misuse. The core takeaway is that careful constructor design prevents correctness and maintainability problems.

作者指出一条常被忽视的 Kotlin 构造函数规则，会悄然引发开发者混淆、隐性错误与低质量 API 设计。文章说明此规则如何使对象初始化出现歧义，让客户端遇到意外行为，并连带产生难以维护或误用的公共接口。作者以实例说明影响，并提出实务建议：明确选择并暴露哪种构造函数、保持初始化模式一致、审视构造函数可见性与默认值，以避免无意间的误用。重点是通过谨慎的构造函数设计改善正确性与可维护性。

This article uses the seed-to-tree metaphor to describe how a small annotation can lead to large amounts of generated code, centering on Kotlin Symbol Processing (KSP). It explains, at a conceptual level, how an annotation acts as the starting point that tools like KSP read and interpret to produce additional source artifacts. The piece highlights the idea of a lifecycle from the initial annotation to parsing of symbols, processing logic, and eventual code generation, and it frames these steps in accessible terms rather than deep technical detail. Readers are invited to consider the practical implications of annotation-driven generation for developer productivity and code structure, with KSP presented as a practical mechanism within the Kotlin ecosystem for this kind of automated transformation.

本文以“从种子到树”的比喻，阐述一个小小的注解如何在开发过程中催生出大量生成代码，并将重点放在 Kotlin Symbol Processing (KSP) 这个工具上。文章用概念性语言描绘注解作为起点，如何被解析、符号被处理并最终生成额外的源代码文件，强调注解到生成的生命周期与各阶段的意义，而非深入底层实现细节。读者可以理解注解驱动生成对开发效率和代码结构的影响，并将 KSP 视为 Kotlin 生态中实现此类自动化转换的实用手段。

This short piece introduces the Notification mechanism for Android and emphasizes its importance as a way to interact with users even when an application is not running in the foreground. Written in the context of Kotlin, the article positions notifications as a primary tool for maintaining user engagement and delivering timely information. The content serves as an introduction or gateway, directing readers to the original Medium post for further explanation and implementation details. Rather than presenting exhaustive code within the snippet, the author highlights the concept and practicality of notifications on Android and invites readers to continue reading on Medium for concrete examples, setup steps, and best practices using Kotlin.

本文简要介绍了 Android 的 Notification（通知）机制，强调即便应用程序未在前台运行，通知依然是与用户保持互动的有力工具。文章以 Kotlin 为背景，点出通知在传递即时信息和维持用户参与度方面的价值。由于这是摘要片段，文中并未展开完整代码或具体步骤，而是将读者引导至 Medium 原文以获取更详尽的说明与实作示例，便于读者学习如何在 Kotlin 中创建、配置和管理 Android 通知。

This article examines what happens behind the scenes when Swift calls Kotlin code on iOS using Kotlin Multiplatform. It outlines the compilation pipeline—how Kotlin/Native translates Kotlin to intermediate representations and then uses LLVM to produce machine code and linkage artifacts—and how interop artifacts or headers are generated so Swift/Objective‑C can call Kotlin symbols. The piece highlights how ABI and calling conventions are reconciled across languages, and it explains the responsibilities of the Kotlin runtime on iOS, including initialization, memory management interplay, and object representation that enable safe cross-language calls. The goal is to clarify the compile‑time and runtime steps developers need to understand when integrating Kotlin Multiplatform libraries into iOS apps so they can make informed decisions about performance and interoperability trade‑offs.

本文介绍了当 Swift 在 iOS 上调用 Kotlin 时底层发生的情况。文章概述了 Kotlin Multiplatform 编译到原生的流程，Kotlin/Native 如何借助 LLVM 生成机器码并产出与 Objective‑C/Swift 互操作的接口或头文件，ABI 与调用约定如何在两种语言间协调以完成函数调用，以及 Kotlin 运行时在初始化、内存管理和对象表示方面的职责。文章还涉及编译器阶段、符号与二进制布局以及链接与启动时需要注意的事项，旨在帮助开发者理解将 Kotlin Multiplatform 集成到 iOS 应用时的性能与互操作性权衡。

The article—whose title summarizes the main claim—describes a migration from Java to Ktor/Kotlin for a system serving five million users that yielded roughly $15,000 per month in cloud cost savings. It opens by calling out high cloud bills as the motivating problem, then walks through why the team chose a JVM-based Kotlin framework, how they staged and validated the migration, and which measurements demonstrated reduced resource use and cost. Rather than deep-diving into a single technical recipe, the piece focuses on practical considerations: identifying cost drivers, performing incremental changes, validating performance and deployment impacts, and capturing lessons to help other teams evaluate whether a similar runtime/framework change could reduce their recurring cloud expenses.

本文（根据标题）介绍了将为 500 万用户提供服务的系统从 Java 迁移到 Ktor/Kotlin 的过程，并因此每月大约节省 15,000 美元云端开支。作者以过高的云端费用为出发点，说明选择 Kotlin/Ktor 的原因、如何分阶段执行迁移并验证效果，以及通过资源使用和部署变化来衡量成本降低。文章侧重实践建议，强调识别成本驱动因素、逐步迁移与定量评估的重要性，并提供能帮助其他团队判断是否值得进行类似迁移的要点和经验。

The article, titled "Kotlin Multiplatform in 2026: Why We Finally Deleted Our Flutter Code" by Sivaraaj reports that in 2026 the author and their team ultimately removed their Flutter implementation after moving to Kotlin Multiplatform. The piece highlights a pivotal change referenced as "The Commit That Changed Everything" as the moment that enabled or justified deleting the prior Flutter code. While the provided snippet is limited, the title and excerpt indicate the author outlines the rationale for the switch, the consequences for their codebase, and the practical implications of relying on Kotlin Multiplatform for cross-platform development. Readers are referred to the full Medium post for the detailed narrative, technical reasoning, and any examples or metrics supporting the decision.

本文作者 Sivaraaj 在标题为「2026 年的 Kotlin Multiplatform：为什么我们终于删除了 Flutter 代码」的文章中表明，2026 年他们在采用 Kotlin Multiplatform 后，最终移除了原先的 Flutter 实现。标题与片段提到一条被称为“改变一切的提交”的关键事件，成为迁移的分水岭。由于提供的内容仅有简介，可知文章会解释迁移决策的动机、对代码库和开发流程的影响，以及相关的实践考量。欲阅读更完整的叙述、技术理由与示例，请前往 Medium 原文。