Daily Digest

每日新聞摘要

2026年07月04日

今日總結

內容會跟隨語言切換。

📝 今日焦點：Habit Arc 以自動化與回饋取代 streak，並維持資料只存本機；Kotlin Multiplatform 也持續擴展到共用 DI、網路層與整體 UI。 🔧 效能最佳化：Kotlin 協程不會自動把阻塞變非阻塞，仍需正確 dispatcher 或真正非同步 API；OpenHearing 以純 Kotlin 實作 DSP 與 limiter，兼顧即時處理與可測試性。 🏗 架構設計：Compose 的核心在 Composition、Layout、Drawing，且進階副作用可用來安全橋接狀態與 coroutine；FCM、MVC/MVP/MVVM/MVI、Koin 與 Ktor 文章則共同強調跨平台與現代 Android 架構的一致性。 ✅ 測試與品質：Jackson Kotlin Module 啟用 NullIsSameAsDefault 可避免空列表反序列化錯誤；OpenHearing 以 JVM 測試驗證限制，並用 no Internet 權限強化隱私承諾。

📝 Today’s focus: Habit Arc replaces streaks with automaticity-based progress and on-device data; Kotlin Multiplatform keeps pushing toward shared DI, networking, and even full UI. 🔧 Performance: Coroutines do not turn blocking calls into non-blocking work, so dispatchers and true async APIs still matter; OpenHearing uses pure Kotlin DSP and a limiter for safe real-time processing. 🏗 Architecture: Compose’s core phases are Composition, Layout, and Drawing, while its side-effect APIs bridge state and coroutines safely; FCM, MVC/MVP/MVVM/MVI, Koin, and Ktor all point to cleaner cross-platform and Android architecture. ✅ Quality: Jackson’s Kotlin module with NullIsSameAsDefault fixes null list deserialization, and OpenHearing backs safety with JVM tests plus a no-Internet-permission privacy model.

I stopped faking progress with a counter and measured automaticity instead

Dev.to Kotlin 作者：Mill1995 發布：07-04 13:31

I stopped faking progress with a counter and measured automaticity instead

A streak measures your obedience. Automaticity is the only part that outlives your motivation.

重點摘要

Streak counters reward compliance but collapse after a single miss.

The article argues that habit formation should measure automaticity, not days.

Habit Arc models habits with phases, recovery, and local-first privacy.

In this first part of a two-part series, the author explains why Habit Arc was built to measure something real instead of relying on a streak counter. Drawing on habit research, they argue that habits form through automaticity, not a universal 21-day timeline, and cite measures like the SRBAI to track whether a behavior is becoming automatic. The app therefore uses phases, a Growth Score, and weekly check-ins rather than punishing users for missed days. It treats misses as feedback, avoids auto-filling failure states, supports different habit types, and keeps all data on-device with no cloud or analytics. Part 2 will cover the Kotlin architecture behind the model.

我不再用计数器伪造进度，而是改为衡量自动化程度

连胜记录衡量的是服从；只有自动化，才会在动机消失后仍然留下来。

重點摘要

连胜计数器在一次中断后就会崩塌，难以反映真实习惯。

文章主张用自动化程度而非天数来衡量习惯形成。

Habit Arc 采用阶段、成长分数与本地存储，强调可持续与隐私。

这篇文章是 Habit Arc 两篇系列文的第一篇，重点讲理念与科学依据。作者认为，习惯养成不应依赖容易失真的连胜计数，而应衡量行为是否逐渐自动化；文中引用 SRBAI 和相关研究，指出习惯形成时间差异很大，并不存在统一的“21 天”标准。为此，Habit Arc 用阶段、成长分数和每周自评取代脆弱的 streak，把失误视为反馈而非失败。应用还避免自动标记错误，支持不同类型的习惯，并坚持所有数据只保存在手机上。

我不再用計數器假裝進度，而是改為衡量自動化程度

連勝紀錄衡量的是服從；只有自動化，才會在動機消失後仍然留下來。

重點摘要

連勝計數器會在一次中斷後崩潰，無法反映真實習慣。

文章主張以自動化程度取代天數，並引用相關研究與量表。

Habit Arc 採用階段、成長分數與本機儲存，強調可持續與隱私。

這篇文章是 Habit Arc 兩篇系列文的第一篇，重點在理念與科學基礎。作者認為，習慣養成不該靠容易失真的連勝計數，而應衡量行為是否逐漸自動化；文中引用 SRBAI 與相關研究，指出習慣形成時間差異很大，沒有通用天數。為此，Habit Arc 以階段、成長分數與每週自評取代斷裂式的 streak，並把失誤視為回饋而非失敗。應用程式也避免自動標記錯誤、支援不同類型習慣，且所有資料都只存在手機上。

Koin in Kotlin Multiplatform: One DI Graph to Rule Both Platforms

Medium Kotlin 作者：Shubham Tiwari 發布：07-04 08:52

Koin in Kotlin Multiplatform: One DI Graph for Both Platforms

Build one dependency injection graph that works seamlessly across Android and iOS without code generation.

重點摘要

Koin is presented as a DI solution for Kotlin Multiplatform

A single dependency injection graph can serve Android and iOS

The approach avoids code generation

This article introduces using Koin in Kotlin Multiplatform to share a single dependency injection graph across Android and iOS. The key idea is to simplify cross-platform architecture by avoiding code generation while still keeping dependency management consistent on both platforms. The post emphasizes that Koin can help teams build a seamless DI setup for multiplatform projects, reducing duplication and improving maintainability.

Kotlin Multiplatform 中的 Koin：一套 DI 图谱同时覆盖两个平台

构建一套可在 Android 与 iOS 间无缝运行、且无需代码生成的依赖注入图谱。

重點摘要

Koin 被用于 Kotlin Multiplatform 的依赖注入

单一 DI 图谱可同时服务 Android 与 iOS

这种方式避免了代码生成

本文介绍了在 Kotlin Multiplatform 中使用 Koin 的做法，目标是在 Android 和 iOS 之间共享同一套依赖注入图谱。文章强调，这种方案能够在不依赖代码生成的前提下，保持跨平台依赖管理的一致性，并让多平台项目的架构更简洁。通过减少重复配置，Koin 为 Kotlin Multiplatform 项目提供了一种更容易维护的 DI 实现方式。

Kotlin Multiplatform 中的 Koin：一套 DI 圖譜同時支援兩個平台

建立一個可在 Android 與 iOS 間無縫運作、且不需要程式碼生成的依賴注入圖譜。

重點摘要

Koin 被用於 Kotlin Multiplatform 的依賴注入

單一 DI 圖譜可同時服務 Android 與 iOS

此方法避免了程式碼生成

本文介紹如何在 Kotlin Multiplatform 中使用 Koin，建立一套可同時在 Android 與 iOS 運作的依賴注入圖譜。重點在於以更簡潔的方式維持跨平台的依賴管理一致性，同時不必依賴程式碼生成。作者強調，這種做法有助於多平台專案減少重複設定，並提升架構維護性與整體開發效率。

Ktor in Kotlin Multiplatform: The Android + iOS Networking Deep Dive I Wish I Had Earlier

Medium Kotlin 作者：Shubham Tiwari 發布：07-04 09:30

Ktor in Kotlin Multiplatform: An Android + iOS Networking Deep Dive

One HTTP client. Two platforms. Zero duplicated networking code.

重點摘要

Single HTTP client for both Android and iOS

Kotlin Multiplatform reduces duplicated networking code

The article focuses on Ktor networking architecture

This piece introduces Ktor as a networking solution for Kotlin Multiplatform, with the goal of sharing one HTTP client across Android and iOS. The core promise is simpler development through a single networking layer instead of duplicated platform-specific code. Based on the available text, the article emphasizes how Ktor can help unify networking in a multiplatform app and reduce redundancy between mobile platforms.

Kotlin Multiplatform 中的 Ktor：Android 与 iOS 网络通信深度解析

一个 HTTP 客户端，两个平台，零重复的网络代码。

重點摘要

Android 和 iOS 共享单一 HTTP 客户端

Kotlin Multiplatform 可减少重复的网络代码

重点在 Ktor 的跨平台网络架构

这篇文章介绍了 Kotlin Multiplatform 中的 Ktor，目标是让 Android 和 iOS 共享同一个 HTTP client，从而避免重复编写网络代码。就当前可见内容来看，作者强调通过单一网络层来统一跨平台开发，让移动应用的维护和扩展更加一致，也更高效。

Kotlin Multiplatform 中的 Ktor：Android 與 iOS 網路通訊深度解析

一個 HTTP 客戶端，兩個平台，零重複的網路程式碼。

重點摘要

Android 與 iOS 共用單一 HTTP 客戶端

以 Kotlin Multiplatform 減少重複的網路程式碼

重點在 Ktor 的跨平台網路架構

這篇文章介紹 Kotlin Multiplatform 中的 Ktor，目標是讓 Android 與 iOS 共用同一個 HTTP client，避免重複撰寫網路程式碼。從目前可見內容來看，作者強調的是以單一網路層整合跨平台開發，讓行動應用在維護與擴充上更一致，也更有效率。

Part 1: Under the Hood: Mastering the Jetpack Compose 3-Phase Layout Pipeline

Medium Kotlin 作者：Android Expert 發布：07-04 09:40

Part 1: Under the Hood: Mastering the Jetpack Compose 3-Phase Layout Pipeline

Stop treating Compose like a faster version of XML.

重點摘要

Focuses on the internal engine behind Compose.

Introduces Composition, Layout, and Drawing.

Encourages a deeper understanding of how Compose works.

This article argues that Jetpack Compose should not be treated as a faster replacement for XML. Instead, it encourages developers to understand the framework’s internal engine by learning its three core phases: Composition, Layout, and Drawing. The piece sets up a deeper technical exploration of how Compose renders UI, emphasizing that mastering these mechanisms is key to using the toolkit effectively.

第 1 部分：透视内部机制：掌握 Jetpack Compose 的三阶段布局管线

不要再把 Compose 当成更快的 XML 版本。

重點摘要

聚焦 Compose 背后的内部引擎。

介绍 Composition、Layout 和 Drawing 三个阶段。

强调理解 Compose 工作原理的重要性。

本文指出，Jetpack Compose 不应被简单地看作 XML 的更快替代方案，而应深入理解其背后的内部引擎。文章围绕 Composition、Layout 和 Drawing 三个核心阶段展开，帮助读者认识 Compose 如何完成 UI 渲染，并强调只有真正掌握这些机制，才能更有效地使用这套工具。

第 1 部分：深入原理：掌握 Jetpack Compose 的三階段版面配置流程

不要再把 Compose 當成更快的 XML 版本。

重點摘要

聚焦 Compose 背後的內部運作機制。

介紹 Composition、Layout 與 Drawing 三個階段。

強調理解 Compose 原理的重要性。

本文主張，不應把 Jetpack Compose 視為更快的 XML 替代品，而應深入理解其背後的內部運作機制。文章以 Composition、Layout、Drawing 這三個核心階段為主軸，引導讀者掌握 Compose 如何完成 UI 呈現，並強調只有真正理解這些流程，才能更有效地運用這套工具。

Share Your Entire UI Layer Across Android, iOS, and Desktop — A Real iOS Walkthrough

Medium Kotlin 作者：Reza Ramesh 發布：07-04 11:31

Share Your Entire UI Layer Across Android, iOS, and Desktop — A Real iOS Walkthrough

For about six years, the pitch for Kotlin Multiplatform came with an asterisk.

重點摘要

Kotlin Multiplatform was long promoted mainly for sharing business logic.

The article frames a shift toward sharing the entire UI layer.

It presents a real iOS walkthrough as the practical example.

For roughly six years, Kotlin Multiplatform was marketed with a caveat: it could share business logic across Android and iOS, but not the full app experience. This article signals a broader ambition—sharing the entire UI layer across Android, iOS, and desktop. Framed as a real iOS walkthrough, it suggests a practical path beyond the traditional limitations of cross-platform development and highlights a more complete shared-code approach.

在 Android、iOS 和桌面端共享整个 UI 层——一次真实的 iOS 实战导览

六年来，Kotlin Multiplatform 的宣传语前面总带着一个但书。

重點摘要

Kotlin Multiplatform 长期主打共享业务逻辑。

文章强调的新方向是连整个 UI 层也一起共享。

内容以真实的 iOS 实战导览作为示例。

过去大约六年里，Kotlin Multiplatform 的宣传往往带着一个前提：它能在 Android 与 iOS 之间共享业务逻辑，但还不是完整的应用体验。这篇文章则把目标推进到更进一步——跨 Android、iOS 和桌面端共享整个 UI 层。作者以一篇真实的 iOS 实战导览来说明这种做法的落地方式，展现了超越传统跨平台开发限制的可能性，也突出了更完整的共享代码方案。

在 Android、iOS 與桌面端共享整個 UI 層——一個真實的 iOS 實作導覽

六年來，Kotlin Multiplatform 的宣傳話術前面總帶著一個但書。

重點摘要

Kotlin Multiplatform 長期以共享商業邏輯為主要賣點。

文章強調的焦點是連整個 UI 層都能共享。

內容以真實的 iOS 導覽作為實作示範。

近六年來，Kotlin Multiplatform 的訴求多半帶著但書：它擅長在 Android 與 iOS 之間共享商業邏輯，但還不是完整共享應用體驗。這篇文章則把重點推進到更大的目標——讓整個 UI 層也能跨 Android、iOS 與桌面端共用。作者以真實的 iOS 實作導覽為例，呈現一條超越傳統跨平台限制的可行路徑，並凸顯共享程式碼更完整落地的可能性。

[Android Development] FCM Deep Dive: Your Android App Is Not Always Running

Medium Kotlin 作者：tahn98 發布：07-04 12:05

[Android Development] FCM Deep Dive: Your Android App Is Not Always Running

One common misunderstanding about Firebase Cloud Messaging is this:

重點摘要

Explains a common misconception about Firebase Cloud Messaging

Focuses on the fact that Android apps are not always running

Introduces a deeper look at how FCM works on Android

This article begins by highlighting a common misunderstanding about Firebase Cloud Messaging: many developers assume an Android app is always running and can directly receive messages at any time. In reality, Android apps may be stopped, backgrounded, or killed, so message delivery and handling depend on how FCM and the Android system work together. The piece sets up a deeper exploration of FCM behavior and the implications for Android app design.

[Android 开发] FCM 深入解析：你的 Android App 并不会一直运行

关于 Firebase Cloud Messaging，最常见的误解之一是：

重點摘要

指出对 Firebase Cloud Messaging 的常见误解

强调 Android App 并不会始终处于运行状态

引出 FCM 在 Android 上的工作机制

文章先指出一个关于 Firebase Cloud Messaging 的常见误解：许多开发者以为 Android App 会一直运行，因此消息可以随时直接送达。实际上，应用可能已停止、转入后台或被系统终止，消息的接收与处理取决于 FCM 与 Android 系统如何协同工作。本文以此为切入点，展开对 FCM 行为及其对 Android 设计影响的深入说明。

[Android 開發] FCM 深入解析：你的 Android App 不會一直在執行

Firebase Cloud Messaging 最常見的一個誤解是：

重點摘要

說明對 Firebase Cloud Messaging 的常見誤解

強調 Android App 並不會永遠保持執行

引出 FCM 在 Android 上的運作細節

本文先點出對 Firebase Cloud Messaging 的常見誤解：許多開發者以為 Android App 會一直在背景執行，因此訊息可以隨時直接送達。實際上，App 可能已停止、進入背景或被系統終止，訊息的接收與處理取決於 FCM 與 Android 系統的互動方式。文章以此為起點，帶出對 FCM 行為與 Android 設計影響的深入探討。

Android Architecture Design Patterns: MVC, MVP, MVVM & MVI (2026 Guide)

Medium Kotlin 作者：Halil Özel 發布：07-04 12:06

Android Architecture Design Patterns: MVC, MVP, MVVM & MVI (2026 Guide)

A practical comparison of Android’s most important architecture patterns, when to use each one, and why MVVM and MVI continue to dominate.

重點摘要

Compares MVC, MVP, MVVM, and MVI for Android apps

Explains when each architecture pattern is best used

Highlights why MVVM and MVI remain the leading choices

This article offers a practical comparison of Android’s key architecture design patterns: MVC, MVP, MVVM, and MVI. It explains the purpose of each pattern, when it may be appropriate to use, and how they differ in structuring Android applications. The piece also emphasizes that MVVM and MVI continue to be the most dominant choices in modern Android development, reflecting current preferences for clearer state handling and maintainable app design.

Android 架构设计模式：MVC、MVP、MVVM 与 MVI（2026 指南）

实用比较 Android 最重要的架构模式、各自适用的场景，以及为何 MVVM 与 MVI 依然占据主流。

重點摘要

比较 Android 的 MVC、MVP、MVVM、MVI

说明各架构模式的适用场景

指出 MVVM 与 MVI 仍然是主流选择

本文以实用视角比较 Android 几种重要的架构设计模式：MVC、MVP、MVVM 与 MVI，并说明每种模式的核心作用与适用场景。文章重点在于它们如何组织 Android 应用，以及在实际开发中该如何选择。同时指出，MVVM 和 MVI 之所以持续占据主流，与更清晰的状态管理和更好的可维护性密切相关。

Android 架構設計模式：MVC、MVP、MVVM 與 MVI（2026 指南）

實用比較 Android 最重要的架構模式、各自的適用時機，以及為何 MVVM 與 MVI 持續主導開發實務。

重點摘要

比較 Android 的 MVC、MVP、MVVM、MVI

說明各架構模式的適用時機

指出 MVVM 與 MVI 仍是主流選擇

本文以實用角度比較 Android 幾種重要的架構設計模式：MVC、MVP、MVVM 與 MVI，並說明各模式的核心用途與適用時機。文章聚焦於它們在 Android 應用程式中的分工方式與差異，同時指出在現代 Android 開發中，MVVM 與 MVI 之所以持續占主導地位，與更清楚的狀態管理及較佳的可維護性密切相關。

Coroutines Don’t Make Blocking Code Non-Blocking

Medium Kotlin 作者：Mohammad Hasan Mahdavi 發布：07-04 13:59

Coroutines Don’t Make Blocking Code Non-Blocking

Putting code inside a coroutine does not automatically make it asynchronous.

重點摘要

Coroutines do not change blocking APIs by themselves.

Blocking work still blocks the thread unless it is moved elsewhere.

Misunderstanding coroutines can lead to poor concurrency design.

The article explains a common Kotlin misconception: wrapping code in a coroutine does not magically turn blocking operations into non-blocking ones. If the underlying work is still blocking, the coroutine will still occupy a thread unless that work is delegated appropriately, such as to a different dispatcher or a truly asynchronous API. The key takeaway is that coroutines are a concurrency tool, not a replacement for non-blocking I/O or properly designed async code.

协程不会让阻塞代码变成非阻塞

把代码放进协程里，并不会自动让它变成异步。

重點摘要

协程本身不会改变阻塞式 API 的行为。

如果底层工作仍是阻塞的，线程依然会被占用。

误解协程可能导致不恰当的并发设计。

文章澄清了 Kotlin 协程的一个常见误区：把代码放进协程，并不会神奇地让阻塞操作变成非阻塞。只要底层调用仍然是阻塞式，它就会继续占用线程，除非把工作交给合适的 dispatcher，或改用真正的异步 API。核心观点是，协程是一种并发工具，而不是非阻塞 I/O 的替代方案。

協程不會讓阻塞程式碼變成非阻塞

把程式放進協程中，並不會自動讓它變成非同步。

重點摘要

協程本身不會改變阻塞式 API 的行為。

若底層工作仍會阻塞，執行緒依然會被占用。

誤解協程可能導致不佳的並行設計。

本文指出 Kotlin 協程常見的誤解：把程式包進協程，並不代表原本的阻塞操作會自動變成非阻塞。若底層呼叫本質上仍是阻塞式，它依然會占住執行緒，除非將工作轉移到適當的 dispatcher，或改用真正的非同步 API。重點在於，協程是並行工具，而不是非阻塞 I/O 的替代品。

Apple locked hearing assistance inside AirPods. So I built an open-source version for any earbuds.

Dev.to Kotlin 作者：Arun KT 發布：07-04 06:16

Apple Put Hearing Assistance Inside AirPods, So I Built an Open-Source Version for Any Earbuds

OpenHearing is a free GPLv3 Android app that turns ordinary earbuds into a hearing-assistance tool.

重點摘要

Pure Kotlin DSP keeps the safety-critical audio chain JVM-testable

Mono mic input is split into independent per-ear stereo processing

No Internet permission means the app cannot send data anywhere

Apple’s AirPods Pro hearing features inspired OpenHearing, an open-source Android app that brings a similar hearing-assistance pipeline to ordinary earbuds. The app performs a hearing check with an adaptive pure-tone test, fits results into a per-ear gain curve, and provides real-time amplification without root or special hardware. The author emphasizes safety by implementing the entire DSP chain in pure Kotlin, with a final lookahead limiter and JVM tests guarding every limit. OpenHearing also duplicates a mono microphone into independent left and right processing paths, and it avoids privacy tradeoffs by declaring no Internet permission. The project is still alpha and has not yet been validated on real hardware, especially for Bluetooth latency and feedback behavior.

Apple 把听力辅助锁在 AirPods 里，所以我做了一个适用于任何耳机的开源版本

OpenHearing 是一款免费的 GPLv3 Android 应用，可把普通耳机变成听力辅助工具。

重點摘要

用纯 Kotlin 实现安全关键的音频处理链

把单声道麦克风输入拆成左右耳独立处理

不申请 Internet 权限，因此无法向外发送数据

Apple 为 AirPods Pro 提供的听力功能启发了 OpenHearing：这是一个开源 Android 应用，目标是把类似的听力辅助流程带到普通耳机上。它先进行纯音听力测试，再根据左右耳结果拟合各自的增益曲线，并实时放大声音，无需 root 或特殊硬件。作者把安全放在首位，整条 DSP 链用纯 Kotlin 实现，末端由 limiter 兜底，所有限制都能通过 JVM 测试验证。OpenHearing 还将单声道麦克风复制为左右耳独立处理，并通过不申请 Internet 权限让隐私承诺由系统强制执行。项目目前仍处于 alpha 阶段，尚未在真实硬件上验证蓝牙延迟和反馈等关键问题。

Apple 把聽力輔助鎖在 AirPods 裡，所以我做了任何耳機都能用的開源版本

OpenHearing 是一款免費的 GPLv3 Android App，能把一般耳機變成聽力輔助工具。

重點摘要

以純 Kotlin 實作安全關鍵的音訊處理流程

將單聲道麥克風輸入分成左右耳獨立處理

不申請 Internet 權限，連資料傳輸都無法發生

Apple 的 AirPods Pro 聽力功能啟發了 OpenHearing：一款開源 Android App，讓一般耳機也能提供類似的聽力輔助流程。它先以純音測試做聽力檢查，再依左右耳結果建立各自的增益曲線，並即時放大聲音，無需 root 或特殊硬體。作者特別強調安全設計，整條 DSP 鏈以純 Kotlin 實作，最後再由 limiter 把關，所有限制都可用 JVM 測試驗證。OpenHearing 也把單聲道麥克風複製成左右耳獨立處理，並刻意不申請 Internet 權限，讓隱私承諾可被系統直接驗證。此專案目前仍是 alpha，尚未在真實硬體上完成驗證。

How to deal with empty lists that defaults to null in Jackson and Kotlin

Dev.to Kotlin 作者：Isaias Velasquez 發布：07-04 07:04

How to Handle Empty Lists That Default to Null in Jackson and Kotlin

The simplest fix is to declare the Jackson Kotlin Module manually and configure NullIsSameAsDefault.

重點摘要

Empty lists in Kotlin data classes can trigger null assertion errors during deserialization.

Use KotlinModule.Builder() with KotlinFeature.NullIsSameAsDefault set to true.

Add the jackson-module-kotlin 2.17+ dependency and register the module manually.

When deserializing Kotlin data classes with Jackson, empty list fields can sometimes arrive as null and cause a null assertion error. The article shows a simple fix: instead of relying on ObjectMapper.registerKotlinModule(), manually build the Jackson Kotlin Module and enable KotlinFeature.NullIsSameAsDefault. With this configuration, Jackson can treat null as the default value, allowing an empty list property to deserialize safely without errors. The example also notes the required dependency, jackson-module-kotlin 2.17+, and demonstrates how to register the module in a JacksonProvider object.

如何处理 Jackson 与 Kotlin 中默认变为 null 的空列表

最简单的做法是手动声明 Jackson Kotlin Module，并启用 NullIsSameAsDefault。

重點摘要

Kotlin data class 的空列表在反序列化时可能触发 null 断言错误。

改用 KotlinModule.Builder()，并将 KotlinFeature.NullIsSameAsDefault 设为 true。

需要添加 jackson-module-kotlin 2.17+，并手动注册模块。

本文介绍了在使用 Jackson 反序列化 Kotlin data class 时，列表字段若收到空值，可能会因为 null 断言而报错。作者给出的解决方案不是直接使用 ObjectMapper.registerKotlinModule()，而是手动构建 Jackson Kotlin Module，并启用 KotlinFeature.NullIsSameAsDefault。这样 Jackson 会把 null 当作默认值处理，使空列表字段能够正常反序列化而不抛出错误。文章同时说明所需依赖为 jackson-module-kotlin 2.17+。

如何處理 Jackson 與 Kotlin 中預設為 null 的空列表

最簡單的做法，是手動宣告 Jackson Kotlin Module，並啟用 NullIsSameAsDefault。

重點摘要

Kotlin data class 的空列表在反序列化時可能引發 null 斷言錯誤。

改用 KotlinModule.Builder()，並將 KotlinFeature.NullIsSameAsDefault 設為 true。

需要加入 jackson-module-kotlin 2.17+，再手動註冊模組。

本文說明在使用 Jackson 反序列化 Kotlin data class 時，若列表欄位收到空值，可能會因為 null 斷言而出錯。作者提供的解法是不要直接使用 ObjectMapper.registerKotlinModule()，而是手動建立 Jackson Kotlin Module，並啟用 KotlinFeature.NullIsSameAsDefault。如此一來，Jackson 會把 null 視為預設值，讓空列表欄位能正常反序列化，不再拋出錯誤。文章也補充了所需依賴為 jackson-module-kotlin 2.17+。

Jetpack Compose Advanced Side-Effects: Mastering Coroutine Bridges & State Synchronization

Medium Kotlin 作者：Android Expert 發布：07-04 05:33

Jetpack Compose Advanced Side Effects: Mastering Coroutine Bridges and State Synchronization

A deep dive into produceState, snapshotFlow, rememberCoroutineScope, and preventing the silent stale reference bug.

重點摘要

Explores advanced Jetpack Compose side-effect APIs

Covers produceState, snapshotFlow, and rememberCoroutineScope

Explains how to avoid silent stale reference bugs

This article takes a deep dive into advanced Jetpack Compose side effects, focusing on how to bridge coroutines with Compose state in a safe and predictable way. It highlights the roles of produceState, snapshotFlow, and rememberCoroutineScope, showing how each helps synchronize UI state with asynchronous work. The piece also calls out the silent stale reference bug, a subtle issue that can appear when captured values are not kept up to date, and explains why understanding these patterns is important for writing reliable Compose code.

Jetpack Compose 进阶副作用：掌握 Coroutine 桥接与状态同步

深入探讨 produceState、snapshotFlow、rememberCoroutineScope，以及如何避免静默的 stale reference bug。

重點摘要

介绍 Jetpack Compose 进阶副作用 API

说明 produceState、snapshotFlow 与 rememberCoroutineScope

分析如何避免 silent stale reference bug

本文深入解析 Jetpack Compose 的进阶副作用机制，重点介绍如何以安全、可预期的方式将 coroutine 与 Compose 状态进行桥接。文章说明 produceState、snapshotFlow 和 rememberCoroutineScope 的用途，并展示它们如何帮助同步 UI 状态与异步工作。同时，作者提醒读者注意 silent stale reference bug，这类问题往往因捕获到过期值而悄然发生，因此理解这些模式对于编写稳定可靠的 Compose 代码非常重要。

Jetpack Compose 進階副作用：掌握 Coroutine 橋接與狀態同步

深入探討 produceState、snapshotFlow、rememberCoroutineScope，以及如何避免沉默的 stale reference bug。

重點摘要

介紹 Jetpack Compose 進階副作用 API

說明 produceState、snapshotFlow 與 rememberCoroutineScope

分析如何避免 silent stale reference bug

本文深入解析 Jetpack Compose 的進階副作用機制，聚焦於如何安全且可預期地將 coroutine 與 Compose 狀態橋接起來。內容說明 produceState、snapshotFlow 與 rememberCoroutineScope 的用途，並展示它們如何協助同步 UI 狀態與非同步工作。文章同時提醒讀者注意 silent stale reference bug，這類問題常因捕捉到過期值而悄悄出現，因此理解這些模式對撰寫穩定可靠的 Compose 程式碼非常重要。