Daily Digest
2026年05月05日
內容會跟隨語言切換。
📝 今日焦點：Kotlin 持續朝更簡潔表達前進，集合字面值、Flow／Channel 選型、LiveData 轉 Flow 與 Kotlin／Java 入門討論，反映開發者正加速整理基礎抽象。 🔧 效能最佳化：語意搜尋結合向量嵌入與 RAG，搭配 Gemini Nano、AICore 與全裝置端推論，可降低延遲、成本與隱私風險。 🏗 架構設計：KMP 在大規模產品中重點是整合治理，需處理 Swift 橋接、二進位體積與跨團隊協作，並以 wrapper、RFC 和 CODEOWNERS 降低 parity drift。 ✅ 測試與品質：AI 產生的 Kotlin 常不夠道地，建議以 CLAUDE.md 約束工具，並落實 Testcontainers、CancellationException 與 sealed error 等規範。 🚀 語言演進：Kotlin 2.2、context receivers、KSP 與 Kotlin DSL 持續推進生態，而 Compose 與新語言特性正重塑 Android 開發節奏。
Kotlin 新增了一項讓集合建立更簡潔、更具表達力的功能。
本文介紹 Kotlin 的集合字面值功能，這是一項用來讓集合建立更簡潔且更具表達力的新特性。文章強調此功能的目的在於提升程式碼可讀性與便利性，讓常見的集合建立情境能以更精簡的語法完成，並體現 Kotlin 持續簡化日常開發工作的設計方向。
我們現在可以完全在裝置端完成這件事——沒有雲端延遲、沒有高額 API 費用，並且完全保護使用者隱私。
本文說明行動應用如何從關鍵字搜尋進化到語意搜尋，並結合向量嵌入與檢索增強生成（RAG）建立更實用的 AI 管線。作者介紹 Gemini Nano 與 Android AICore 如何支援完全裝置端運算，降低延遲、成本與隱私風險，並解析 cosine similarity、四階段 RAG 流程，以及 AICore 作為系統層模型服務的價值。文章也把 Kotlin 2.x 的 Flow、kotlinx.serialization、context receivers 對應到實作情境，最後提醒主執行緒推論、重複嵌入與模型升級後重建索引等常見陷阱。
把 CLAUDE.md 放在專案根目錄，AI 每次執行任務前都會先讀它。
本文指出，AI 工具常因訓練資料充斥轉寫自 Java 的 Kotlin、Android 教學與零散範例，而產出不夠道地的 Kotlin。作者 Olivia Craft 建議在專案根目錄放入 CLAUDE.md，先約束模型再工作。文中提出七條實務規則：不要用 !!、絕不用 GlobalScope、以建構子注入 dispatcher、用 sealed type 表示可恢復錯誤、正確處理 CancellationException、以 KSP 與 Kotlin DSL 取代 kapt 和 Groovy Gradle，並用 Testcontainers 在真實資料庫上測試 repository。
在大型生產環境裡，往往是「一次撰寫，到處除錯，還要讓所有人步調一致。」
作者指出，Kotlin Multiplatform 在正式生產環境中不是單純的「寫一次、到處執行」方案。面對超過 150 個 Gradle 模組與數百萬月活用戶，真正的難題是跨平台整合成本：Kotlin 與 Swift 的橋接、二進位體積，以及多團隊協作。團隊透過 iOS 友善的包裝層、依賴審查、明確的快照持久化機制，以及 RFC 與共同 CODEOWNERS 流程來降低摩擦。雖然 KMP 增加了一些維護與建置負擔，但也減少了邏輯不一致與 parity drift，提升跨平台的一致性。
在 Kotlin 協程中最常見的「該用 X 還是 Y」問題之一，就是：Channel 還是 Flow？
本文從 Kotlin 協程中常見的問題切入：該選用 Channel 還是 Flow。依據摘要可知，兩者在文件中看起來相似，因此作者以此作為討論主軸，說明何時應該使用哪一種抽象。這篇文章屬於 Kotlin channels 系列的一部分，重點在於幫助讀者理解兩者差異，避免在不適合的情境下選錯工具。
Android 的格局正在劇烈變化——Kotlin 2.2、AI 原生 UX 與無伺服器後端，已不再是「可有可無」的選項。
Android 開發正在快速轉變，文章指出 Kotlin 2.2、AI 原生 UX 與無伺服器後端已不再只是加分項，而是現代 Android 應用的核心能力。這代表開發者不能只沿用舊方法，而必須主動學習新工具與新架構，才能跟上生態系的變化。雖然目前可見內容有限，但核心訊息很明確：想維持競爭力的 Android 開發者，現在就應開始為這些趨勢做準備。
你以為自己熟悉的 Android UI 工具包，其實還藏著不少技巧。
本文以「10 個 Jetpack Compose 功能」為主軸，強調這套 Android UI 工具包其實還有許多未被善用的能力，可能改變開發者打造 Android App 的方式。由於目前提供的內容僅是導讀，未列出實際功能細節，但可看出文章意在帶領讀者探索 Compose 中容易被忽略的技巧與用法。
所以我為你寫了一個簡單的說明。
這篇文章針對許多人在開始學習 Android 前常會困惑的問題——該選 Kotlin 還是 Java——提供一個入門式的簡單說明。從目前可見的內文來看，作者表示已為讀者整理了易懂的解釋，但完整內容需到 Medium 才能閱讀。就現有摘要而言，文章主要目的是幫助新手理解兩種語言的選擇，而未在片段中展開更多技術細節。
AOSP 的白名單其實沒有變，Honor 的 PowerGenie 只是依照呼叫情境改寫了 API 回傳值。
作者在 Honor、MagicOS 9.0 裝置上排查 Android App 的電池最佳化問題時，發現一個詭異現象：設定畫面明明顯示已加入白名單，但背景執行的 watchdog 週期性呼叫 PowerManager.isIgnoringBatteryOptimizations() 卻一直回傳 false；使用者打開 App、進入前景後，同樣的 API 又回傳 true。經過比對日誌與時間戳後，作者判斷這不是競態條件，而是 Honor 的 PowerGenie 介入了回傳值。AOSP 白名單仍然存在，只是背景程式會被額外判定為未忽略電池最佳化。
最聰明的做法，有時不是多寫程式碼，而是知道何時不必寫。
文章指出，開發者常常一再重寫百分比、比率、EMI 公式與單位換算等基本計算邏輯，這雖然不難，卻很耗時。對於正式上線的程式仍應自行實作，但在原型開發、除錯、內部工具與快速驗證時，外部計算器能更快確認結果，避免臨時寫腳本或反覆檢查公式。作者強調，提升工作流程與維持程式碼整潔同樣重要；有時候，最有效率的做法不是再寫一段程式，而是知道何時不必重寫。
Not a Member? Read Here: Continue reading on Medium »
目前提供的內容只有 Medium 的續讀提示，未包含文章的完整論述與實作細節。僅根據標題可知，作者宣稱自行打造了一個更精簡的 Kotlin Multiplatform Supabase SDK，並說明其架構設計更具優勢。不過，因為原文內文缺失，無法在不臆測的前提下進一步擴充摘要。
十年前，LiveData 強勢登場，幫助我們擺脫令人頭痛的 AsyncTask。
本文是「從 LiveData 遷移到 Kotlin Flow」系列的第一篇，先回顧 LiveData 為何在當年成為重要工具。文章指出，約十年前 LiveData 作為對付難用且容易出錯的 AsyncTask 的方案而快速普及。作者將 LiveData 定位為一項在其時代相當有效的技術，雖然後續有更新的響應式工具出現，但它曾幫助 Android 開發者建立更容易維護的應用程式。