Daily Digest
2026年06月25日
內容會跟隨語言切換。
📝 今日焦點：Kotlin 圈本日聚焦 FFmpeg 三種整合路線、Compose Multiplatform 3D 西洋棋、Kotlin/Java 型別底層差異與 typealias，並補上安全、反射與「未提供正文」的文章說明。 🔧 效能最佳化：Android 啟動速度、反射成本與背景任務耗電成為重點；以 WorkManager、GeofencingClient、AlarmManager 與編譯期產生取代低效做法，降低等待與電量耗損。 🏗 架構設計：MVI、supervisorScope 誤解、Muffle 的本機狀態機與跨平台遊戲案例，凸顯單向資料流、例外責任分離與多平台共碼的可維護性。 ✅ 測試與品質：Room 搭配 SQLCipher 與 Keystore 保障敏感資料，並提醒 OEM 省電、重開機與 GPS 抖動等真實環境問題，需用更韌性的設計應對。 🚀 語言演進：typealias 強化可讀性，而 Kotlin Multiplatform、Compose Multiplatform 與安全實作文章顯示 Kotlin 正從語法工具走向完整平台方案。
本文以可執行的 Kotlin 程式碼，介紹三種做法。
本文介紹在 Kotlin 中使用 FFmpeg 的三種方式：以 ProcessBuilder 直接執行本機 FFmpeg、以 Jaffree 作為 JVM 包裝器，以及透過 FFmpeg Micro 的 HTTP API 將轉檔工作交給雲端。作者比較了各方案在安裝成本、Docker 映像大小、無伺服器環境限制與相依性管理上的差異，並示範如何輪詢非同步任務、取得下載網址，以及用 OkHttp 或 Ktor 呼叫 API。文末也提醒了 PATH、Android 主執行緒與大檔上傳等常見問題。
Android 的可靠性不在於對抗系統，而是在電池管理規則內運作。
本文說明依賴背景執行的 Android 應用，常在 Samsung、Xiaomi 等裝置上因 OEM 激進省電而失效。作者開發 Muffle，用於依據祈禱時間與 GPS 自動切換聲音設定，發現單靠 AlarmManager 與長時間背景服務不足以撐過系統限制，因此把核心排程移到 WorkManager，並用 ExistingPeriodicWorkPolicy.UPDATE 維持重開機後的排程一致性；對時間敏感的任務則採用 expedited jobs。對於地理圍欄等即時需求，作者改用低優先級的前景服務、處理 onTaskRemoved 重啟，並在 App 內引導使用者至 dontkillmyapp.com 相關設定。
要保護本機儲存，必須使用 SQLCipher 加密資料庫，並在裝置的硬體支援 Keystore 內產生加密金鑰。
本文說明如何保護儲存在本機 Room SQLite 資料庫中的敏感資訊，方法是以 SQLCipher 進行加密，並將加密金鑰保存在 Android 硬體支援的 Keystore 中。作者指出，若資料庫未加密，原始帳密、OAuth token 與交易資料在 root 裝置或備份檔中都可能被直接讀取。實作步驟包含加入 SQLCipher 相依套件、在 TEE 中建立受生物辨識保護的 AES 金鑰、用 SQLCipher 的 open helper factory 初始化 Room，以及在通過生物辨識後解密通行字串。如此即使資料庫檔被複製，內容仍不可讀。
如果第一個畫面出現前就很慢，使用者不會在意你的 App 有多漂亮。
這篇文章指出，App 啟動時間是使用者體驗中非常關鍵的一環，因為使用者往往會在第一個畫面出現前就對應用程式形成印象。即使介面設計精美，若開啟過慢，仍會讓人感到不佳。文章主軸是提供 Android 啟動效能優化的實用方向，以降低等待感受並提升整體體驗。
一篇實務導向的深入探討，涵蓋可預測的 UI 狀態、單向資料流、reducer、middleware，以及何時選擇 MVVM、MVI 或 Redux-MVI。
本文以實務角度深入介紹如何用 MVI 建構可預測的 Android 畫面，重點放在可預測的 UI 狀態、單向資料流、reducer 與 middleware 等概念，說明它們如何讓畫面邏輯更清晰、可維護。文章也討論在不同情境下何時應選擇 MVVM、MVI 或 Redux-MVI，適合正在評估 Android 架構方案的開發者閱讀。
理解 supervisorScope 不會取消同層協程，但仍可能讓應用程式崩潰的原因。
本文說明 Kotlin 協程中的常見誤解：supervisorScope 雖然能避免某個子協程失敗時連帶取消其他同層協程，但並不等於例外會被自動消化。也就是說，它改變的是取消行為，不是例外處理責任。若例外未被妥善接住，仍可能一路傳遞到應用層並造成崩潰。文章重點在釐清「取消」與「例外傳遞」的差別，幫助開發者更精準地掌握協程失敗處理。
一切始於一個簡單的問題：一支手機能否透過藍牙向另一支手機發出指令，讓它執行動作？
文章從一個簡單問題出發：能否讓一支手機透過藍牙向另一支手機發送指令，並讓對方執行動作，例如拍照。原本只是一項針對單一功能的技術嘗試，後來卻逐步發展成更完整的方案，最終形成一個基於節點的自動化引擎。作者透過這段經歷呈現出概念如何從小型驗證原型，延伸為更有彈性的自動化系統。
學會使用編譯期別名來駕馭龐大的泛型，並在零執行期成本下提升程式可讀性。
這篇文章介紹 Kotlin 的 typealias 如何透過編譯期別名，將冗長或複雜的型別名稱簡化，讓程式更容易閱讀與維護。文章強調，typealias 特別適合用來處理繁瑣的泛型宣告，能在不改變程式行為的前提下提升可讀性。由於它只在編譯期展開，因此不會帶來任何執行期額外負擔，是一種輕量且實用的程式碼整理方式。
安全性不該是事後才想到的事。
這篇文章主張，在開發現代 Android 應用程式時，安全性不應被視為事後補救的工作，而應從一開始就納入考量。文章以 Kotlin 為核心，說明如何為應用程式建立更完善的防護，並將內容定位為供開發者參考的實務指南。根據目前可見的摘要，可知本文重點在於及早且系統化地整合安全措施，以提升行動應用的整體防護能力。
透過把監控交給平台原生的地理圍欄 API，我讓 Muffle 能夠全天候運作，且幾乎不影響日常電量。
本文介紹作者打造 Android 應用 Muffle 的經驗，重點在於如何在自動切換靜音模式的同時避免耗電。最初版本使用 LocationManager 搭配頻繁更新，導致 GPS 常駐與 CPU 反覆喚醒，電量消耗過大。後來改採 GeofencingClient，由系統在背景被動監控預設圓形區域，只有在進入或離開範圍時才喚醒應用。雖然地理圍欄的觸發速度可能比直接輪詢 GPS 稍慢，但對此類工具而言是合理取捨。作者也加入輔助 intent service 做最後確認，以避免短暫 GPS 抖動造成誤觸發，讓應用能長時間穩定運作。
真正的挑戰不只是切換設定，而是建立一個能在系統重新開機與 Doze 模式下持續運作的反應式系統。
本文介紹作者如何打造 Muffle，讓 Android 裝置能自動切換聲音模式，不必再手動調整。為了精準排程，作者選擇 AlarmManager 而非 WorkManager，並加入監聽 ACTION_BOOT_COMPLETED 的 BroadcastReceiver，在裝置重開機後從本機 Room 資料庫重新建立排程。整個狀態機完全保留在本機，GPS 觸發則由 GeofencingClient 處理，再透過 AudioManager 切換為靜音或震動；同時也以 NotificationManager.Policy 實作優先來電繞過。整體設計兼顧精準、韌性、隱私與電量效率。
Continue reading on Medium »
本次提供的輸入只有文章標題、作者、連結，以及「Continue reading on Medium」的提示，並未附上實際正文。因此無法根據原文整理 Kotlin 相較於 Java 的優勢或開發者偏好的具體理由。為避免虛構內容，此摘要僅能說明原始文章內容未提供，無法進一步歸納。
他如何以純 Kotlin 讓 3D 西洋棋在 Android、iOS、桌面與網頁上執行，並以少量 Swift 橋接 Stockfish 與 Filament。
本文說明作者如何使用 Compose Multiplatform，打造一款可在 Android、iOS、桌面與網頁運行的 3D 西洋棋遊戲。整體實作以純 Kotlin 為主，並透過少量 Swift 橋接整合 Stockfish 與 Filament。文章重點在於如何在跨平台共用大部分程式碼的同時，保留必要的原生整合能力。
身為 Kotlin 開發者，我們每天都會使用 Int、Long、Double 和 Boolean 這類型別。
本文聚焦於 Kotlin 開發者每天都會使用的 Int、Long、Double、Boolean 等型別，深入探討它們背後的原始型別與包裝類別概念。從標題與開頭可知，文章想從 Java 與 Kotlin 的角度，說明這些常見型別如何對應與運作，幫助開發者理解平常使用的資料型別不只是語法表面，而是有其底層設計與行為差異。
為什麼執行期魔法會拖慢應用程式、干擾 R8/ProGuard 混淆，以及如何轉向快速的編譯期程式碼產生。
本文探討 Android 開發中使用反射所帶來的隱藏成本。反射依賴執行期的檢查與呼叫，會增加額外開銷，特別是在效能敏感的路徑上更可能拖慢應用程式。它也可能讓 R8/ProGuard 的混淆與最佳化變得複雜，使建置結果較難預測。文章主張改採編譯期程式碼產生，把部分工作從執行期移到建置期，以獲得更快、更安全且更易維護的 Android 程式碼。
在過去幾週裡，我一直在思考接下來應該把時間投入在哪個技術上。
這篇文章看起來是作者首次接觸 Kotlin Multiplatform 與 Compose Multiplatform，並以「接下來該把時間投入哪個技術」作為切入點。就目前提供的片段來看，內容偏向導言性質，主要是在引出後續對這些框架的深入討論，並未包含更多技術細節。