Daily Digest
2026年09月02日
內容會跟隨語言切換。
📝 今日焦點：本地端 LLM、Compose Multiplatform 與 React Native/原生選型成熱點，重點在隱私、延遲與長期維護。 🏗 架構設計：KMPWorker、KMP 治理與 Firebase 抽象化都指向共享模組要靠介面、契約與隔離層，降低平台綁定與供應商鎖定。 🔧 效能最佳化：Muffle 的地理圍欄切換與 UI 重組迴圈案例提醒，背景任務要兼顧省電、去抖動與避免隱性渲染浪費。 ✅ 測試與品質：expect/actual 不宜預設，改用 DI 與 common test 才能支援替身、decorator 與多版本驗證。
直接在使用者裝置上執行大型語言模型，不需要伺服器或 API 金鑰。
這篇 Kotlin 教學示範如何在裝置端直接執行大型語言模型，不必依賴伺服器或 API 金鑰。文章先說明本地推論的優勢，包括可離線運作、保護隱私、降低延遲與免雲端費用，也提醒裝置端模型在能力上通常較小。接著以 NobodyWho 函式庫為核心，介紹如何從 Hugging Face 或本機路徑載入 GGUF 模型、建立基本聊天、串流輸出 token，以及處理圖片與音訊等多模態輸入，並延伸到語音轉文字、文字轉語音、語音活動偵測、工具呼叫與 RAG。
直接在使用者裝置上執行大型語言模型：不需要伺服器，也不需要 API 金鑰。
這篇教學示範如何用 NobodyWho 在 Python 中建立裝置端 AI 功能。NobodyWho 封裝 llama.cpp，可直接在本機執行 .gguf 模型。文章從基本聊天開始，逐步延伸到串流輸出、多模態輸入、語音轉文字、文字轉語音、語音活動偵測、工具呼叫與檢索增強生成。作者也說明本機推論的取捨：模型較小、能力不如雲端前沿模型，但可離線、保護隱私、延遲更低，且不產生雲端費用。
這是一篇 KMPWorker 的導覽，這個開源庫正是為了解決這個問題而建立的。
本文介紹 NeuralHeads 開發的開源 Kotlin Multiplatform 函式庫 KMPWorker，目標是在 Android 與 iOS 之間統一背景任務排程。作者說明兩大平台的差異：Android 的 WorkManager 支援網路、充電、閒置等限制與重試機制；iOS 的 BGTaskScheduler 則由系統主導，執行時間短且無法保證準時觸發。文章進一步解釋 KmpWorker 介面、TaskMonitor 狀態廣播、Android/iOS 對應實作、可恢復的任務鏈與初始化方式，並區分穩定與實驗性 API。
以實務角度比較效能、開發者體驗與長期可維護性——作者曾實際交付過兩種方案的產品。
本文以實務經驗出發，比較 React Native 與原生 Android 在效能、開發者體驗與長期可維護性上的差異。作者表示自己曾實際交付過兩種方案，因此分析並非只停留在理論層面。文章試圖回答在 2026 年，面對行動產品開發與後續維護時，哪一種做法更具優勢，以及團隊在選型時需要權衡哪些現實取捨。
你最小的螢幕，如今因宣告式 UI 而成為最大的機會。
本文主張，智慧手錶的狹小螢幕不應被視為限制，而是設計上的機會。透過宣告式 UI，開發者能以更清楚、更有效率的方式打造好看的手錶應用，減少小螢幕設計常見的複雜與挫折。文章核心在於：好的手錶 App 設計應兼顧清晰、簡潔與視覺質感，同時讓開發流程保持可控。
兩行防禦性程式碼、一個沉默的效能問題，以及那個幾乎被忽略的脆弱測試。
一個 UI 測試意外揭露了無限且不必要的重新組合迴圈，原因只是一段看似無害的兩行防禦性程式碼。這些程式碼原本是為了保護行為，卻悄悄帶來效能問題；而那個一開始看似可忽略的不穩定測試，最後反而成了找出問題的關鍵。文章強調，在 UI 框架中，細小的實作選擇可能造成巨大影響，連不穩定的測試也可能是效能或渲染問題的重要訊號。
多年來，跨平台開發大致都圍繞著同一個問題展開。
目前提供的內文只有文章開頭一句，內容指出多年來跨平台開發大致都圍繞著一個核心問題。僅從標題可推知，文章想探討 Compose Multiplatform 如何重新思考行動、桌面與網頁之間的應用架構。不過因為缺少完整正文，能可靠摘要的只有標題與開頭所透露的方向。
真正的挑戰不只是觸發鈴聲模式變更，而是在不讓使用者感受到定位服務耗電的前提下完成這件事。
本文分享作者打造 Android 應用 Muffle 的經驗：以地理圍欄自動切換手機音量，並盡量降低耗電。作者因一次禮拜場合忘記靜音的尷尬經驗，反思手動操作與高頻定位輪詢的不足，改採 Google Play Services 的 GeofencingClient、PendingIntent 與 BroadcastReceiver，讓系統在進出圍欄時喚醒應用。文章也指出 Doze、App Standby 可能延遲觸發，且在高樓密集區 GPS 漂移會造成重複切換，因此需要前景服務與去抖動機制來提升穩定性。
把常見程式碼交給它擁有的介面，再注入平台實作。
文章指出，Kotlin Multiplatform 教學常把 expect/actual 放在最前面，但它不應成為預設。expect/actual 本質上是編譯期綁定，適合每個平台只有一個固定實作的狹窄場景；一旦需要測試替身、decorator、A/B 版本或在 commonTest 中驗證行為，就會變得難用。作者以 PaymentsLab 的付款邏輯測試為例，說明共享模組被平台宣告綁死後，測試會受限。更好的做法是在 common code 定義介面，平台提供實作，並透過 DI 注入；expect/actual 只留給少數真正需要焊死的節點。
為什麼到 2026 年，關於 Kotlin Multiplatform 的討論已從語法轉向編譯器、產物、二進位契約與治理。
本文指出，到 2026 年，Kotlin Multiplatform 的討論焦點已不再只是語法與開發體驗，而是更深入的平台工程議題。當共享程式碼擴大到企業規模時，能否成功取決於編譯器行為、產物管理、二進位契約與治理機制。文章將 KMP 描述為一套需要被妥善管理的技術與組織系統，而不只是跨平台開發的簡單做法，以確保共享程式碼長期穩定、可維護且具延展性。
像 Firebase 這類未經抽象化的 SDK，會悄悄把你的 Android 應用鎖進特定供應商；Ports & Adapters 則能讓替換更便宜也更安全。
本文指出，Android 應用若直接依賴 Firebase 這類 SDK，而未先建立抽象層，就可能在不知不覺中形成供應商鎖定。當業務邏輯與特定 API 緊密綁定時，日後更換服務不僅成本高，也更容易引發風險。作者主張採用 Ports and Adapters 架構，將外部依賴包在穩定介面後方，讓未來替換供應商時更安全、較便宜，也較不會擾動整體程式碼。