每日新聞摘要 - 2026年09月06日

01

Kotlin Weekly #527

Kotlin Weekly 作者：發布：09-06 10:28

Kotlin Weekly #527

Issue #527 — 6th of September 2026

重點摘要

Kotlin Toolchain 0.12 adds multiplatform publishing, Wasm app support, and stronger IDE tooling.

JetBrains has updated the Kotlin roadmap.

The issue also spotlights articles on SKIE, Compose, Android testing, and new Kotlin libraries.

Kotlin Weekly #527, dated 6 September 2026, rounds up the latest Kotlin ecosystem updates. The news section features Kotlin Toolchain 0.12.0, which brings multiplatform library publishing, Wasm application support, improved IDE tooling, and an MCP server for Compose Hot Reload, along with an updated Kotlin roadmap from JetBrains. The issue also curates articles on sharing ViewModels between Android and iOS with SKIE, combining Compose with kotlinx.html, and consuming SKIE Flows in SwiftUI. Additional sections cover Android testing, AI-assisted development, videos on Kotlin and GraphQL, and several new libraries.

Kotlin Weekly #527

第 527 期——2026 年 9 月 6 日

重點摘要

Kotlin Toolchain 0.12 新增多平台库发布、Wasm 应用支持和更强的 IDE 工具。

JetBrains 已更新 Kotlin 路线图。

本期还汇总了 SKIE、Compose、Android 测试和新 Kotlin 库相关内容。

Kotlin Weekly #527（2026 年 9 月 6 日）汇总了 Kotlin 生态的最新进展。新闻部分介绍 Kotlin Toolchain 0.12.0，带来多平台库发布、Wasm 应用支持、增强的 IDE 工具，以及用于 Compose Hot Reload 的 MCP server；同时也提到 JetBrains 更新了 Kotlin 路线图。文章部分收录了使用 SKIE 在 Android 与 iOS 间共享 ViewModel、将 Compose 与 kotlinx.html 结合，以及在 SwiftUI 中消费 SKIE Flows 的实践。除此之外，还有 Android 测试、AI 开发、视频和库推荐等内容。

Kotlin Weekly #527

第 527 期——2026 年 9 月 6 日

重點摘要

Kotlin Toolchain 0.12 新增多平台函式庫發佈、Wasm 應用支援與更強的 IDE 工具。

JetBrains 已更新 Kotlin 路線圖。

本期也整理了 SKIE、Compose、Android 測試與新 Kotlin 函式庫相關內容。

Kotlin Weekly #527（2026 年 9 月 6 日）整理了 Kotlin 生態系的最新動態。新聞區介紹 Kotlin Toolchain 0.12.0，包含多平台函式庫發佈、Wasm 應用支援、改進的 IDE 工具，以及用於 Compose Hot Reload 的 MCP server；同時也提到 JetBrains 更新了 Kotlin 路線圖。文章區收錄了以 SKIE 在 Android 與 iOS 間共享 ViewModel、將 Compose 與 kotlinx.html 結合，以及在 SwiftUI 中使用 SKIE Flows 的實作內容。另有 Android 測試、AI 開發、影片與函式庫推薦等整理。

02

Java Weekly, Issue 662

Baeldung 作者：baeldung 發布：09-06 09:25

Java Weekly, Issue 662

A hands-on tour of the three Loom pillars: virtual threads, scoped values, and structured concurrency.

重點摘要

Project Loom tools and features are in focus in IntelliJ IDEA.

Spring, Quarkus, WildFly, JHipster, Vert.x, Elasticsearch, Zuul, Micronaut, and Helidon all have new releases.

A critique of oversized code reviews argues the real fix lies earlier in the development flow.

This issue of Java Weekly highlights practical coverage of Project Loom in IntelliJ IDEA, including virtual threads, scoped values, and structured concurrency. It also rounds up notable ecosystem updates such as releases from IntelliJ IDEA, Compose Multiplatform, Quarkus, WildFly, JHipster, Vert.x, Elasticsearch, Zuul, Micronaut, and Helidon. In the technical reading section, Martin Fowler’s piece questions whether teams should review all this code, arguing that growing pull request sizes point to earlier process problems rather than a need to automate review away. The issue also features the free virtual IntelliJ IDEA Conf 2026 as the weekly pick.

Java Weekly，第 662 期

实地了解 Loom 的三大支柱：虚拟线程、Scoped Values 和结构化并发。

重點摘要

重点介绍 IntelliJ IDEA 中的 Project Loom 及其工具链支持。

多个 Java 生态项目和框架发布新版本。

Martin Fowler 讨论代码评审过载与流程前置问题。

本期 Java Weekly 主要聚焦 Project Loom 在 IntelliJ IDEA 中的实践介绍，涵盖虚拟线程、Scoped Values 和结构化并发等关键能力，并说明相关工具支持带来的价值。内容还汇总了多个生态更新，包括 IntelliJ IDEA、Compose Multiplatform、Quarkus、WildFly、JHipster、Vert.x、Elasticsearch、Zuul、Micronaut 和 Helidon 的新版本。技术与随想部分收录 Martin Fowler 对“是否该审查所有代码”的讨论，指出 PR 规模不断膨胀，根本问题在于开发流程前端，而不是简单把审查自动化掉。

Java Weekly，第 662 期

深入介紹 Loom 的三大支柱：虛擬執行緒、Scoped Values 與結構化並行。

重點摘要

聚焦 IntelliJ IDEA 中的 Project Loom 與相關工具支援。

多個 Java 生態系專案與框架釋出新版。

Martin Fowler 討論程式碼審查負擔過重與流程前端問題。

本期 Java Weekly 以 Project Loom 在 IntelliJ IDEA 的實作與工具支援為重點，介紹虛擬執行緒、Scoped Values 與結構化並行等核心能力。同時彙整多項生態系更新，包括 IntelliJ IDEA、Compose Multiplatform、Quarkus、WildFly、JHipster、Vert.x、Elasticsearch、Zuul、Micronaut 與 Helidon 的新版本。技術閱讀部分收錄 Martin Fowler 對「是否該審查所有程式碼」的討論，指出 PR 變大反映的是更前段流程的問題，而非單靠自動化審查就能解決。

03

Kotlin Multiplatform (KMP) Basics

Dev.to Kotlin 作者：Aviral Srivastava 發布：09-06 11:24

Kotlin Multiplatform (KMP) Basics

Write your logic once and let it run across Android, iOS, web, desktop, and backend targets.

重點摘要

Share common business logic, models, and utilities across platforms.

Use expect/actual to supply platform-specific implementations.

Compose Multiplatform extends the sharing story to UI as well.

This article introduces Kotlin Multiplatform (KMP) as a practical way to share code across Android, iOS, web, desktop, and backend targets while still keeping native UI experiences. It explains the core architecture of a shared module, the commonMain and platform-specific source sets, and the expect/actual mechanism for platform-dependent behavior. The post also outlines key benefits such as reduced duplication, faster development, easier maintenance, and gradual adoption, while noting tradeoffs like tooling maturity, learning curve, and platform-specific UI work. It further highlights supporting technologies like coroutines, serialization, Ktor, SQLDelight, and Compose Multiplatform.

Kotlin Multiplatform（KMP）基础

一次编写逻辑，即可让它运行在 Android、iOS、Web、桌面和后端平台上。

重點摘要

共享跨平台的业务逻辑、数据模型和工具函数。

通过 expect/actual 机制提供各平台的专属实现。

Compose Multiplatform 让 UI 共享也成为可能。

本文介绍 Kotlin Multiplatform（KMP）如何帮助开发者在 Android、iOS、Web、桌面和后端之间共享代码，同时保留原生 UI 体验。文章解释了共享模块的结构、commonMain 与各平台 source set 的分工，以及通过 expect/actual 机制处理平台差异的方法。随后总结了 KMP 的优势，如减少重复代码、提升开发效率、降低维护成本，并支持渐进式采用；同时也指出了工具成熟度、学习曲线和平台差异带来的挑战。文中还提到 coroutines、serialization、Ktor、SQLDelight 和 Compose Multiplatform 等相关技术。

Kotlin Multiplatform（KMP）基礎

一次撰寫邏輯，即可讓它在 Android、iOS、Web、桌面與後端平台上運行。

重點摘要

共享跨平台的商業邏輯、資料模型與工具函式。

透過 expect/actual 提供各平台專屬實作。

Compose Multiplatform 也讓 UI 共享更具可能性。

本文介紹 Kotlin Multiplatform（KMP）如何讓開發者在 Android、iOS、Web、桌面與後端之間共享程式碼，同時保留原生 UI。文章說明共享模組的概念、commonMain 與各平台 source set 的分工，以及用 expect/actual 處理平台差異的方法。接著整理 KMP 的優點，包括減少重複、提升開發速度、維護更容易與可逐步導入，也提醒工具成熟度、學習曲線與平台差異等限制。最後還提到 coroutines、serialization、Ktor、SQLDelight 與 Compose Multiplatform 等重要生態。

04

Protecting Encryption Keys with Android Keystore

Medium Kotlin 作者：Jevi Saputra 發布：09-06 08:35

Protecting Encryption Keys with Android Keystore

Encrypting local data isn’t enough if the encryption key is still hardcoded inside your Android app.

重點摘要

Hardcoded encryption keys weaken local data protection.

Android Keystore can help protect sensitive keys.

The article focuses on securing keys within Android apps.

The article argues that encrypting local data alone is not sufficient if the encryption key is still hardcoded inside an Android app. It highlights the security risk of keeping keys embedded in the app package and points to Android Keystore as a way to better protect sensitive encryption material. The core message is that proper key management is as important as data encryption itself.

使用 Android Keystore 保护加密密钥

如果加密密钥仍硬编码在 Android 应用中，仅加密本地数据还不够。

重點摘要

硬编码的加密密钥会削弱本地数据保护。

Android Keystore 可用于保护敏感密钥。

文章重点在于提升 Android 应用中的密钥安全。

本文指出，如果加密密钥仍然硬编码在 Android 应用中，那么即使本地数据已经加密，保护也并不充分。作者强调，把密钥直接放进应用包会带来安全风险，因此可以借助 Android Keystore 更妥善地保护敏感加密材料。文章传达的核心观点是：密钥管理和数据加密同样重要。

使用 Android Keystore 保護加密金鑰

如果加密金鑰仍硬編碼在 Android App 內，單純加密本地資料還不夠。

重點摘要

硬編碼的加密金鑰會削弱本地資料保護。

Android Keystore 可用來保護敏感金鑰。

重點在於提升 Android App 內金鑰的安全性。

本文指出，若加密金鑰仍硬編碼在 Android App 中，即使本地資料已經加密，整體保護仍然不夠。作者強調，把金鑰直接放在應用程式內會帶來安全風險，因此應考慮使用 Android Keystore 來更妥善地保護敏感的加密材料。文章的核心觀點是：金鑰管理和資料加密同樣重要。

05

Layered Root Detection: Why Any Single Check Fails

Medium Kotlin 作者：Alim Reshitov 發布：09-06 08:36

Layered Root Detection: Why Any Single Check Fails

Root and hooking detection as risk-scoring, not gatekeeping — and why the check that matters most doesn’t run on the device at all

重點摘要

Root and hooking detection should be treated as risk scoring, not a hard gate.

No single on-device check is sufficient to catch every compromise.

The most important check may happen off-device rather than on the device itself.

This article argues that root and hooking detection should be viewed as part of a broader risk-scoring approach rather than a simple pass-or-fail gate. Because attackers can bypass or evade individual checks, relying on any single on-device signal is inherently fragile. The key idea is to layer multiple signals and understand that the most meaningful verification may not even happen on the device. In other words, strong detection comes from combining checks and placing trust decisions in a wider security context, not from expecting one mechanism to be definitive.

分层式 Root 检测：为何任何单一检查都会失效

将 Root 和 hooking 检测视为风险评分，而非硬性门槛——而最重要的检查甚至根本不在设备上运行

重點摘要

Root 和 hooking 检测应被视为风险评分，而不是一刀切的拦截。

任何单一的设备内检查都不足以覆盖所有入侵情况。

最关键的验证，可能发生在设备之外。

本文提出，Root 与 hooking 检测不应只作为通过或拒绝的硬性门槛，而应纳入整体风险评分体系。由于攻击者可以绕过或规避单一检查，仅依赖某一个设备内信号本身就很脆弱。作者强调，应通过叠加多种信号来提升判断可靠性，并认识到最重要的验证未必发生在设备上。真正有效的安全决策，不是期待某一种机制给出唯一答案，而是将信任判断放到更广的安全上下文中。

分層式 Root 偵測：為何任何單一檢查都會失效

將 Root 與 hooking 偵測視為風險評分，而非硬性門檻——而最重要的檢查甚至根本不在裝置上執行

重點摘要

Root 與 hooking 偵測應被視為風險評分，而非一刀切的封鎖。

任何單一的裝置內檢查都不足以涵蓋所有入侵情況。

最關鍵的驗證，可能在裝置外完成。

本文主張，Root 與 hooking 偵測不應只被當成通過或拒絕的門檻，而是風險評分流程的一部分。由於攻擊者能繞過或規避單一檢查，僅依賴某一個裝置內訊號本質上十分脆弱。作者強調，應該把多種訊號分層組合，並理解最重要的驗證不一定在裝置上完成。真正有效的防護，不是期待某個機制能做出最終裁決，而是把信任判斷放進更完整的安全脈絡中。

06

Your ViewModel Is Doing Too Much: SOLID in Android Without the Boring Theory

Medium Kotlin 作者：Swatiomar 發布：09-06 10:49

Your ViewModel Is Doing Too Much: SOLID in Android Without the Boring Theory

A ViewModel should be a smart coordinator, not a junk drawer where logic goes to die.

重點摘要

A ViewModel should coordinate, not absorb every responsibility.

Business logic belongs in the right layer, not all in one class.

SOLID principles can improve Android architecture without heavy theory.

This piece argues that an Android ViewModel should act as a smart coordinator rather than a catch-all container for logic. The core message is that when a ViewModel starts accumulating too many responsibilities, it becomes harder to maintain, test, and reason about. By keeping concerns separated and applying SOLID principles in a practical way, developers can build cleaner Android architectures without getting lost in abstract theory.

你的 ViewModel 做得太多了：不谈枯燥理论也能在 Android 中实践 SOLID

ViewModel 应该是聪明的协调者，而不是让逻辑死掉的杂物抽屉。

重點摘要

ViewModel 应负责协调，不应包揽所有职责。

业务逻辑要放在正确的层，不要全塞进同一个类。

用实践方式应用 SOLID，可让 Android 架构更清晰。

本文指出，Android 中的 ViewModel 应扮演聪明的协调者，而不是把所有逻辑都收进来的“杂物抽屉”。当 ViewModel 负担过多职责时，代码会更难维护、测试和理解。作者强调，只要坚持职责分离，并以实用方式应用 SOLID 原则，开发者就能在不陷入抽象理论的前提下，构建更清晰、更易持续演进的 Android 架构。

你的 ViewModel 做太多了：不用無聊理論也能在 Android 實踐 SOLID

ViewModel 應該是聰明的協調者，而不是讓邏輯死去的雜物抽屜。

重點摘要

ViewModel 應負責協調，不該包辦所有職責。

商業邏輯應放在正確的層次，不要全塞進同一個類別。

以實作方式套用 SOLID，可讓 Android 架構更乾淨。

本文主張，Android 的 ViewModel 應該扮演聰明的協調者，而不是把所有邏輯都塞進去的萬用容器。當 ViewModel 承擔過多責任時，程式會變得更難維護、測試與理解。作者強調，透過保持職責分離，並以實務方式套用 SOLID 原則，開發者可以在不陷入抽象理論的情況下，建立更清晰、更可持續的 Android 架構。

07

Kotlin Flows in Android: A Clear Mental Model

Medium Kotlin 作者：Sehaj kahlon 發布：09-06 11:47

Kotlin Flows in Android: A Clear Mental Model

A practical guide to understanding Flow, StateFlow, and SharedFlow in Android development.

重點摘要

Introduces the core mental model behind Kotlin Flow.

Explains how StateFlow and SharedFlow fit into Android apps.

Aims to make reactive state and event handling easier to understand.

This article introduces a clear mental model for Kotlin Flows in Android. It highlights the terms Flow, StateFlow, and SharedFlow, which many Android developers encounter when building apps. Based on the available text, the piece appears to frame these APIs as part of understanding reactive data and state handling in Android. The article is presented as a practical explanation intended to help readers make sense of these concepts more intuitively.

Android 中的 Kotlin Flow：清晰的心智模型

一篇帮助理解 Android 开发中 Flow、StateFlow 与 SharedFlow 的实用指南。

重點摘要

介绍 Kotlin Flow 背后的核心心智模型。

说明 StateFlow 与 SharedFlow 在 Android 应用中的定位。

旨在让响应式状态与事件处理更容易理解。

这篇文章以清晰的心智模型切入，介绍 Android 开发中常见的 Kotlin Flow、StateFlow 与 SharedFlow。就目前可见内容来看，文章主要围绕这些 API 在 Android 中如何用于理解和处理响应式数据、状态与事件展开。整体风格偏向实务说明，目的是帮助读者更直观地掌握这些概念。

Android 中的 Kotlin Flow：清晰的心智模型

一篇協助理解 Android 開發中 Flow、StateFlow 與 SharedFlow 的實用指南。

重點摘要

介紹 Kotlin Flow 背後的核心心智模型。

說明 StateFlow 與 SharedFlow 在 Android 應用中的定位。

目標是讓反應式狀態與事件處理更容易理解。

這篇文章以清晰的心智模型切入，介紹 Android 開發中常見的 Kotlin Flow、StateFlow 與 SharedFlow。從目前可取得的內容來看，文章主要聚焦於這些 API 在 Android 裡如何用來理解與處理反應式資料、狀態與事件。整體方向偏向實務解說，目的在幫助讀者更直觀地掌握這些概念。

08

De boolean flags a sealed interfaces en Compose: cómo eliminar combinaciones inválidas por contrato

Medium Kotlin 作者：manuel cabezas caldero 發布：09-06 12:16

From Boolean Flags to Sealed Interfaces in Compose: How to Eliminate Invalid Combinations by Contract

There is a sign that almost always foretells problems in a Compose screen: too many flags trying to describe what is happening.

重點摘要

Too many boolean flags can signal poor state modeling in Compose.

Sealed interfaces help prevent invalid UI combinations by design.

A contract-based approach makes screen states clearer and safer.

The article points out a common warning sign in Jetpack Compose screens: when too many boolean flags are used to represent state, the model often becomes ambiguous and error-prone. It proposes replacing those flags with sealed interfaces so that only valid combinations can be expressed by contract. This approach improves clarity, reduces invalid UI states, and makes the code easier to reason about.

从 Boolean 标志到 Compose 的 sealed interfaces：如何通过契约消除无效组合

有一个几乎总是预示 Compose 页面出现问题的信号：太多标志试图描述正在发生的事情。

重點摘要

过多的布尔标志通常意味着 Compose 状态建模不佳。

sealed interfaces 可以在设计层面阻止无效的 UI 组合。

用契约表达状态能让页面逻辑更清晰、更安全。

文章指出，Jetpack Compose 页面中常见的一个危险信号，就是用过多布尔标志来描述状态，这往往会导致模型含糊且容易出错。作者建议改用 sealed interfaces，把状态限制在预先定义好的有效组合内，从而通过契约避免无效状态出现。这样不仅能提升代码可读性，也能降低错误概率，让维护更简单。

從 Boolean 旗標到 Compose 的 sealed interfaces：如何透過契約消除無效組合

有一個幾乎總是預示 Compose 畫面出問題的徵兆：太多旗標試圖描述正在發生的事情。

重點摘要

過多的布林旗標通常代表 Compose 狀態建模不佳。

sealed interfaces 能從設計上避免無效的 UI 組合。

以契約表達狀態可讓畫面邏輯更清楚、更安全。

本文指出 Jetpack Compose 畫面常見的警訊：用太多布林旗標來描述狀態，往往會讓模型變得含糊且容易出錯。作者主張改用 sealed interfaces，讓系統只能表達事先定義好的有效組合，並透過契約避免無效狀態出現。這種做法能提升可讀性、降低錯誤機率，也讓程式更容易維護。

09

Recomposition doesn’t re-run your screen. It re-runs the scopes that read what changed.

Medium Kotlin 作者：Rajan Maurya 發布：09-06 12:24

Recomposition doesn’t rerun your screen; it reruns the scopes that read what changed

Recomposition doesn’t re-run your screen. It re-runs the scopes that read what changed.

重點摘要

Explains recomposition as scope-based, not screen-wide, invalidation

Focuses on how Compose tracks reads to determine what should update

Clarifies a common misconception about UI refresh behavior

This article explains a key Jetpack Compose concept: recomposition does not rerun an entire screen. Instead, it reruns only the scopes that read the state that changed. By focusing on how Compose tracks state reads and invalidates the relevant parts of the UI, the article helps readers build a more accurate mental model of recomposition. The main takeaway is that efficient updates come from understanding which composable scopes depend on which pieces of state, rather than thinking in terms of whole-screen refreshes.

重组不会重新运行整个屏幕，而是重新运行读取了变化内容的作用域

重组不会重新运行你的屏幕，只会重新运行读取了变化内容的作用域。

重點摘要

说明重组是按作用域触发，而不是整屏重跑

强调 Compose 会依据状态读取来决定更新范围

澄清关于 UI 刷新的常见误解

本文澄清了 Jetpack Compose 中一个重要概念：重组不会让整个屏幕重新执行，而是只会重新运行那些读取了发生变化的状态的作用域。作者借此说明 Compose 如何追踪状态读取，并只对受影响的 UI 部分进行无效化与更新，帮助读者建立更准确的理解。核心观点是，与其把重组想成整屏刷新，不如关注各个 composable 作用域依赖了哪些状态。

重組不會重新執行整個畫面，而是重新執行讀取變更內容的作用域

重組不會重新執行你的畫面，只會重新執行讀取了變更內容的作用域。

重點摘要

說明重組是以作用域為單位，而非整個畫面重跑

強調 Compose 會根據讀取的狀態來決定哪些部分更新

澄清對 UI 重新整理的常見誤解

本文釐清 Jetpack Compose 中一個常見觀念：重組不會讓整個畫面重新執行，而是只會重跑那些曾讀取到變更狀態的作用域。作者透過這個角度說明 Compose 如何追蹤狀態讀取並只更新受影響的部分，幫助讀者建立更準確的心智模型。重點在於理解每個 composable 作用域依賴哪些狀態，才能真正掌握重組的運作方式與更新範圍。

10

A composable’s lifecycle is three events, and none of them is onDestroy

Medium Kotlin 作者：Rajan Maurya 發布：09-06 12:24

A Composable’s Lifecycle Is Three Events, and None of Them Is onDestroy

A composable’s lifecycle is better understood through three events, not an Android-style onDestroy callback.

重點摘要

A composable does not follow a traditional view lifecycle.

Its lifecycle is described through three distinct events.

onDestroy is not part of a composable’s lifecycle.

The article explains that a composable’s lifecycle should not be confused with the classic Android view or component lifecycle. Instead of relying on an onDestroy callback, composables are framed around three lifecycle events that more accurately reflect how they are created, updated, and removed in Compose. The core message is that developers should use Compose’s lifecycle model rather than expecting traditional destruction behavior.

Composable 的生命周期是三个事件，而且没有 onDestroy

Composable 的生命周期应通过三个事件来理解，而不是 Android 式的 onDestroy 回调。

重點摘要

Composable 不遵循传统 View 生命周期。

它的生命周期可由三个不同事件来描述。

onDestroy 不属于 Composable 的生命周期。

本文说明，Composable 的生命周期不应与传统 Android View 或组件生命周期混淆。它并不是依赖 onDestroy 回调来处理结束，而是通过三个生命周期事件来描述其创建、更新和移除。核心观点是，开发者应理解并采用 Compose 的生命周期模型，而不是期待旧式的销毁行为。

Composable 的生命週期是三個事件，且其中沒有 onDestroy

Composable 的生命週期應以三個事件來理解，而不是 Android 式的 onDestroy 回呼。

重點摘要

Composable 不遵循傳統 View 生命週期。

它的生命週期可用三個不同事件來描述。

onDestroy 不屬於 Composable 的生命週期。

本文說明，Composable 的生命週期不應與傳統 Android View 或元件生命週期混為一談。它不是依賴 onDestroy 回呼來處理結束，而是以三個生命週期事件來描述其建立、更新與移除。重點在於，開發者應理解並採用 Compose 的生命週期模型，而非期待舊式的銷毀行為。

11

11 GitHub Projects That Will Make You a Better Android Developer

Medium Kotlin 作者：Halil Özel 發布：09-06 14:10

11 GitHub Projects That Will Make You a Better Android Developer

A practical 2026 reading list for architecture, Compose, networking, testing, code quality, and performance.

重點摘要

Focuses on practical Android learning through real projects

Covers architecture, Compose, networking, testing, code quality, and performance

Presents a curated 2026 reading list on Medium

This article introduces a practical 2026 reading list for Android developers, centered on GitHub projects that can help improve skills across key areas such as architecture, Jetpack Compose, networking, testing, code quality, and performance. Rather than offering abstract advice, it points readers toward hands-on examples and real-world codebases. The piece is presented as a curated list on Medium and is aimed at developers who want to learn by studying and building from existing open-source projects.

11 个能让你成为更优秀 Android 开发者的 GitHub 项目

一份面向 2026 的实用阅读清单，涵盖架构、Compose、网络、测试、代码质量与性能。

重點摘要

通过实战型 GitHub 项目提升 Android 技能

覆盖架构、Compose、网络、测试、代码质量与性能

作为 2026 年的精选阅读清单发布于 Medium

这篇文章整理了一份面向 2026 年的实用阅读清单，主题是能够帮助 Android 开发者提升能力的 GitHub 项目。内容覆盖架构、Jetpack Compose、网络、测试、代码质量与性能等关键方向，强调通过真实项目和开源代码进行学习，而不是停留在抽象建议上。文章发布于 Medium，适合希望借助优秀项目的代码与实践来提升自身水平的开发者。

11 個能讓你成為更優秀 Android 開發者的 GitHub 專案

一份面向 2026 的實用閱讀清單，涵蓋架構、Compose、網路、測試、程式碼品質與效能。

重點摘要

以實作型 GitHub 專案提升 Android 開發能力

涵蓋架構、Compose、網路、測試、程式碼品質與效能

作為 2026 年的精選閱讀清單發布於 Medium

這篇文章整理了一份面向 2026 年的實用閱讀清單，主題圍繞能幫助 Android 開發者提升能力的 GitHub 專案。內容涵蓋架構、Jetpack Compose、網路、測試、程式碼品質與效能等核心領域，強調透過真實專案與開源程式碼學習，而不是只停留在理論建議。文章出自 Medium，適合希望藉由觀察與實作優秀專案來精進技能的開發者。

12

Clean Architecture for Frontend Apps: Layers, MVI, and Dependency Injection

Medium Kotlin 作者：Oleksandr Shcherbinin 發布：09-06 14:17

Clean Architecture for Frontend Apps: Layers, MVI, and Dependency Injection

I explain how to apply Clean Architecture to modern frontend applications.

重點摘要

Uses Kotlin and coroutines in the examples.

Focuses on applying Clean Architecture to frontend apps.

Covers layers, MVI, and dependency injection.

This article explains how to apply Clean Architecture to modern frontend applications. Using Kotlin and coroutines in the examples, the author introduces a frontend-friendly interpretation of the architecture and discusses how its layers fit into real app development. The piece also explores MVI as part of the approach and shows how dependency injection supports separation of concerns and maintainability.

前端应用中的 Clean Architecture：分层、MVI 与依赖注入

我将说明如何把 Clean Architecture 应用于现代前端应用。

重點摘要

示例使用 Kotlin 和协程。

重点介绍将 Clean Architecture 用于前端应用。

涵盖分层、MVI 和依赖注入。

本文说明如何将 Clean Architecture 应用于现代前端应用。作者以 Kotlin 和协程为示例，介绍一种适合前端开发的架构思路，并讲解各层在实际项目中的作用与组织方式。文章还进一步讨论 MVI 与依赖注入，作为提升关注点分离和可维护性的实现方法。

前端應用的 Clean Architecture：分層、MVI 與依賴注入

我將說明如何將 Clean Architecture 套用到現代前端應用程式。

重點摘要

範例使用 Kotlin 與協程。

說明如何將 Clean Architecture 應用於前端。

涵蓋分層、MVI 與依賴注入。

本文說明如何將 Clean Architecture 套用到現代前端應用程式。作者以 Kotlin 與協程作為範例，介紹適合前端開發的架構思路，並說明各層在實際專案中的角色與運作方式。文章也進一步提到 MVI 與依賴注入，作為提升關注點分離與維護性的實作手段。

13

Technical Notebook: Kotlin Fundamentals

Medium Kotlin 作者：Ahmed Elkrrai 發布：09-06 14:45

Technical Notebook: Kotlin Fundamentals

Chapter 1 introduces variables.

重點摘要

Focuses on Kotlin basics

Begins with Chapter 1: Variables

Continues the tutorial on Medium

This article is a technical notebook on Kotlin fundamentals, and the provided excerpt shows that it begins with Chapter 1, focused on variables. The content appears to be part of a broader learning series published on Medium by Ahmed Elkrrai. Based on the available text, the piece is an introduction to core Kotlin concepts rather than a full chapter summary.

技术笔记：Kotlin 基础

第一章介绍变量。

重點摘要

聚焦 Kotlin 基础概念

从第一章“变量”开始

内容可在 Medium 上继续阅读

这篇文章是关于 Kotlin 基础的技术笔记；目前可见内容显示，它从第一章“变量”开始，属于作者 Ahmed Elkrrai 在 Medium 上连载的学习系列。由于正文仅提供标题与章节开头，无法得知更完整的教学细节，但可以确认主题是 Kotlin 入门与基本语法概念。

技術筆記：Kotlin 基礎

第一章介紹變數。

重點摘要

聚焦 Kotlin 基礎概念

從第一章「變數」開始

內容可在 Medium 上繼續閱讀

這篇文章是關於 Kotlin 基礎的技術筆記；目前可見的內容顯示，它從第一章「變數」開始，屬於作者 Ahmed Elkrrai 在 Medium 上連載的學習系列。由於內文僅提供標題與章節開頭，無法得知更完整的教學細節，但可確認主題是 Kotlin 入門與基本語法概念。

14

Architecting a Low-Power Geofencing Engine: Lessons from Muffle's Location Services

Dev.to Kotlin 作者：Haseeb 發布：09-06 02:33

Architecting a Low-Power Geofencing Engine: Lessons from Muffle's Location Services

Battery life is your primary feature.

重點摘要

Use Google Play Services GeofencingClient instead of custom GPS polling.

Balance precision and power by relying on system-managed location updates.

Treat battery optimization limits, OEM quirks, and indoor GPS inaccuracy as core design constraints.

This article explains how Muffle’s silent-mode automation relies on a low-power geofencing engine rather than constant GPS polling. The author describes using Google Play Services’ GeofencingClient to let the system manage location sensing through cellular, Wi-Fi, and GPS data, reducing battery drain. A BroadcastReceiver handles enter/exit events while keeping the app process dormant until needed. The piece also highlights real-world challenges such as inaccurate GPS in dense urban areas, delayed trigger timing, and aggressive battery optimization on some Chinese OEM devices. The main lesson is that battery life must be treated as a primary feature, and that indoor automation often works better with Wi-Fi SSID-based triggers, using GPS only as a fallback.

设计低功耗地理围栏引擎：来自 Muffle 定位服务的经验

电池续航就是你的首要功能。

重點摘要

改用 Google Play Services 的 GeofencingClient，避免自建 GPS 轮询。

依靠系统托管的位置更新，在精度与功耗之间取得平衡。

将室内 GPS 误差、OEM 省电限制和中国机型差异纳入设计约束。

本文介绍了 Muffle 如何通过低功耗地理围栏引擎实现静音自动化，而不是持续轮询 GPS。作者使用 Google Play Services 的 GeofencingClient，让系统借助基站、Wi‑Fi 和 GPS 综合判断位置，从而降低耗电；并用 BroadcastReceiver 处理进入和退出事件，让应用在真正触发前保持休眠。文章还强调了高密度城市中 GPS 精度不足、触发延迟，以及部分中国 OEM 设备会过度杀掉进程等现实问题。作者的结论很明确：电池续航应被视为核心功能，室内自动化更适合以 Wi‑Fi SSID 作为主触发，GPS 只作备用。

設計低耗電地理圍欄引擎：從 Muffle 的定位服務學到的事

電池續航就是你的第一個功能。

重點摘要

改用 Google Play Services 的 GeofencingClient，避免自訂 GPS 輪詢。

以系統代管的定位更新平衡精準度與耗電量。

面對室內 GPS 誤差、OEM 省電限制與中國機型的特殊性，必須納入架構考量。

本文分享 Muffle 如何以低耗電的地理圍欄引擎實現安靜模式自動化，而非持續輪詢 GPS。作者改用 Google Play Services 的 GeofencingClient，讓系統透過基地台、Wi‑Fi 與 GPS 統合判斷位置，降低電量消耗；並以 BroadcastReceiver 處理進出區域事件，避免常駐服務耗電。文章也提到高樓密集區 GPS 不準、觸發延遲、以及部分中國 OEM 裝置過度殺進程等實務問題。核心結論是：電池續航必須被視為主要功能，室內情境更適合以 Wi‑Fi SSID 為主、GPS 為輔。

15

JSON to Kotlin data class: Gson vs Moshi vs kotlinx.serialization annotations

Dev.to Kotlin 作者：yuus_company 發布：09-06 04:41

JSON to Kotlin Data Classes: Gson vs Moshi vs kotlinx.serialization Annotations

The same JSON payload can behave very differently depending on which Kotlin serialization library you choose.

重點摘要

Gson can silently break Kotlin null-safety when fields are missing.

Moshi with codegen enforces nullability and supports default values clearly.

kotlinx.serialization is reflection-free, multiplatform, and needs config for unknown keys and default encoding.

Turning JSON into Kotlin data classes seems straightforward, but the choice of library changes how annotations, nullability, and defaults behave. Gson uses reflection and can silently write null into non-nullable properties when fields are missing, making crashes show up later. Moshi with KSP codegen enforces nullability at parse time and handles default values well, which fits Android stacks using Retrofit or OkHttp. kotlinx.serialization is compiler-plugin based, reflection-free, and multiplatform; it fails on unknown keys unless configured and skips default-valued fields unless encodeDefaults is enabled. The article recommends Moshi for Android/Retrofit and kotlinx.serialization for new or KMP projects.

JSON 转 Kotlin data class：Gson、Moshi 与 kotlinx.serialization 注解对比

同一份 JSON，因所选序列化库不同，会出现明显不同的处理结果。

重點摘要

Gson 在字段缺失时可能默默破坏 Kotlin 的 null 安全。

Moshi 搭配 codegen 会在解析阶段明确报错，并正确处理默认值。

kotlinx.serialization 无反射、支持多平台，但需配置未知键与默认值输出。

将 JSON 转为 Kotlin data class 看起来很简单，但不同库在注解、空值处理和默认值上的行为差异很大。Gson 依赖反射，字段缺失时可能把 null 写入非空属性，问题往往在后续才暴露。Moshi 配合 KSP codegen 能在解析时强制检查可空性，默认值也能正常工作，因此很适合已有 Retrofit 或 OkHttp 的 Android 项目。kotlinx.serialization 则基于编译器插件、无反射且支持 JVM、JS、Native、Wasm；不过默认会拒绝未知 JSON 键，序列化时若要输出默认值还需开启 encodeDefaults。

JSON 轉 Kotlin data class：Gson、Moshi 與 kotlinx.serialization 註解比較

同一份 JSON，會因為你選的序列化函式庫不同，而有截然不同的行為。

重點摘要

Gson 可能在缺少欄位時默默破壞 Kotlin 的 null 安全。

Moshi 搭配 codegen 會在解析時明確檢查可空性，且支援預設值。

kotlinx.serialization 無反射、支援多平台，但需設定 unknown keys 與預設值輸出。

把 JSON 轉成 Kotlin data class 看似簡單，但不同函式庫對註解、null 安全與預設值的處理差異很大。Gson 依賴反射，遇到缺少欄位時可能把 null 寫進非可空屬性，錯誤常在之後才爆發。Moshi 搭配 KSP codegen 能在解析時直接檢查可空性，且預設值運作正常，適合已使用 Retrofit／OkHttp 的 Android 專案。kotlinx.serialization 則以編譯器外掛運作、無反射且支援 JVM、JS、Native、Wasm；但預設會拒絕未知欄位，且需開啟 encodeDefaults 才會序列化預設值。

今日總結

Kotlin Weekly #527

重點摘要

Java Weekly，第 662 期

重點摘要

Kotlin Multiplatform（KMP）基礎

重點摘要

使用 Android Keystore 保護加密金鑰

重點摘要

分層式 Root 偵測：為何任何單一檢查都會失效

重點摘要

你的 ViewModel 做太多了：不用無聊理論也能在 Android 實踐 SOLID

重點摘要

Android 中的 Kotlin Flow：清晰的心智模型

重點摘要

從 Boolean 旗標到 Compose 的 sealed interfaces：如何透過契約消除無效組合

重點摘要

重組不會重新執行整個畫面，而是重新執行讀取變更內容的作用域

重點摘要

Composable 的生命週期是三個事件，且其中沒有 onDestroy

重點摘要

11 個能讓你成為更優秀 Android 開發者的 GitHub 專案

重點摘要

前端應用的 Clean Architecture：分層、MVI 與依賴注入

重點摘要

技術筆記：Kotlin 基礎

重點摘要

設計低耗電地理圍欄引擎：從 Muffle 的定位服務學到的事

重點摘要

JSON 轉 Kotlin data class：Gson、Moshi 與 kotlinx.serialization 註解比較

重點摘要