Daily Digest

每日新聞摘要

2026年08月21日

今日總結

內容會跟隨語言切換。

📝 今日焦點 - Android 相機競爭與相機總開關可讓背景錄影失敗，重試不保證恢復，專機專用最穩。 - KMP/Compose 在 iOS 匯出卡死、LazyColumn 只在正式版崩潰，顯示跨平台與並發副作用風險高。 🔧 效能最佳化 - 偵測並移除硬編碼機密，結合掃描、歷史重寫與後端代理，降低外洩與攻擊面。 🏗 架構設計 - 以 API/實作模組分享功能型 composable，清楚切分契約與細節，提升模組化。 - iOS 專屬流程應依是否可共用、回呼、記憶體與 UI 判斷，必要時改用 Swift。 ✅ 測試與品質 - Compose production 當機與相機失敗案例都提醒：需補強並發測試與失效回復驗證。

📝 Today's Highlights - Android camera contention and the system-wide toggle can break background capture; retries are not guaranteed, so dedicate the device if reliability matters. - KMP/Compose exposed iOS export hangs and a production-only LazyColumn crash, highlighting cross-platform and concurrency risks. 🔧 Performance Optimization - Remove hard-coded secrets with scanning, history rewriting, and backend proxying to cut exposure and attack surface. 🏗 Architecture Design - Share feature-level composables through API/implementation modules to keep contracts clean and modular boundaries clear. - For iOS-specific code, decide by reuse, callbacks, memory, and UI needs; move non-shared logic to Swift when needed. ✅ Testing & Quality - The Compose crash and camera failure cases both show the need for stronger concurrency testing and recovery validation.

Can Two Apps Use the Same Android Camera at Once? How the OS Picks a Winner - and Why a 24/7 Recording Is the One That Loses

Dev.to Kotlin 作者：Super Funicular 發布：08-21 07:19

Can Two Apps Use the Same Android Camera at Once? How Android Chooses the Winner—and Why 24/7 Recording Usually Loses

Android arbitrates the camera by priority, priority tracks user focus, and the losing app is notified rather than consulted.

重點摘要

Only one app can hold a given Android camera at a time; cross-app sharing is not supported.

Foreground activity gets priority, so an on-screen app can evict a background recorder.

A camera can be lost without a crash, including through onDisconnected, onError, or the device-wide camera toggle.

Android does not allow two third-party apps to use the same camera simultaneously. Camera access is decided by priority, and the app in the foreground usually wins; a background recorder is evicted and receives onDisconnected. The article explains the difference between losing the camera via onError versus being disconnected after having it, plus a quieter failure mode introduced by the Android 12 camera toggle, which can produce a blank feed without any error or disconnect. It also outlines what recovery is actually possible, how retry callbacks work, and why a phone used as a security camera should ideally be dedicated to that task.

两个 Android 应用能同时使用同一摄像头吗？系统如何决定胜负，以及为何 24/7 录制最容易失败

Android 按优先级仲裁摄像头，而优先级跟随用户当前看到的界面；失败的一方只会被通知，不会被询问。

重點摘要

Android 不支持两个第三方应用同时持有同一摄像头。

前台应用优先级更高，会把后台录制应用挤掉。

摄像头可能以多种方式被夺走，甚至只留下空白画面而没有错误。

Android 不允许两个第三方应用同时使用同一个摄像头，系统会按优先级分配资源，而前台应用通常会获胜，后台录制程序则会收到 onDisconnected。文章区分了 onError 与 onDisconnected 的含义，列出摄像头被夺走的五种文档化情况，并指出 Android 12 之后的全局摄像头开关可能让应用继续运行却只能得到空白画面，不一定触发错误。作者还说明了真正可依赖的恢复方式非常有限，重新打开摄像头本质上是再次参与竞争，因此把手机当作监控设备时，最稳妥的做法是专机专用。

兩個 Android App 能同時使用同一個相機嗎？系統如何決定勝負，以及為何 24/7 錄影最常輸

Android 以優先權仲裁相機，而優先權跟隨使用者目前看到的畫面；輸掉的一方只會被通知，不會被詢問。

重點摘要

Android 不支援兩個第三方 App 同時持有同一顆相機。

前景 App 具有較高優先權，會把背景錄影程式擠下線。

相機可能以多種方式被拿走，甚至只會得到空白畫面而沒有錯誤。

Android 不允許兩個第三方 App 同時使用同一個相機，系統會依優先權決定誰能取得裝置，而前景中的應用通常會勝出，導致背景錄影程式收到 onDisconnected。文章詳細說明 onError 與 onDisconnected 的差異、相機被奪走的五種錯誤狀況，以及 Android 12 之後的全裝置相機開關可能讓畫面變成空白但不觸發錯誤。文中也說明實際可行的恢復方式有限，重試只是一場重新競爭，而不是排隊等候，因此把手機當監視器時最好專機專用。

Where Kotlin Stops and Swift Starts in a Kotlin Multiplatform App

Dev.to Kotlin 作者：Kanon Fujita 發布：08-21 14:18

Where Kotlin Ends and Swift Begins in a Kotlin Multiplatform App

The question I should have been asking was not how to fix it, but why this code was in Kotlin at all.

重點摘要

The iOS video export hung because a completion handler never fired, causing a silent coroutine wait.

A four-question rule was adopted to decide when iOS code should stay in Kotlin or move to Swift.

Synchronous AVFoundation setup stayed in Kotlin, while callback-based, memory-manual, or UI components moved to Swift.

The author describes building Afterfade with Kotlin Multiplatform and Compose Multiplatform, then hitting an iOS-only hang in video export. A Kotlin wrapper around AVAssetExportSession waited forever when the completion handler never ran, and attempts to switch dispatchers or add a timeout did not solve the problem. The deeper issue was that the code belonged in Kotlin only in name: it could not be shared with Android and relied on callback-based iOS APIs that fit Swift better. The author formalized four questions for iOS work—whether Android can reuse the code, whether the API calls back, whether manual memory release is required, and whether the code is a UI component. Applying that rule moved most iOS-specific work to Swift, while synchronous AVFoundation setup remained in Kotlin.

在 Kotlin Multiplatform 应用中，何时停在 Kotlin、何时交给 Swift

我真正该问的不是怎么修，而是这段代码为什么会写在 Kotlin 里。

重點摘要

iOS 视频导出因 completion handler 未触发而卡死，协程一直等待。

作者总结出四个判断问题，用来决定 iOS 代码该留在 Kotlin 还是改写为 Swift。

可同步完成的 AVFoundation 设置保留在 Kotlin；回调、手动释放内存和 UI 组件则交给 Swift。

作者以 Afterfade 为例，说明自己如何用 Kotlin Multiplatform 和 Compose Multiplatform 同时开发 Android 与 iOS，但在 iOS 视频导出时遇到挂起问题。原本用 suspendCancellableCoroutine 包装 AVAssetExportSession 的 completion handler，却在某些情况下永远收不到回调，切换 dispatcher 或加超时也无法根治。作者因此反思，这段代码并不能与 Android 共享，只是把 iOS 专属逻辑包在 Kotlin 外层。随后他提出四个判断准则：是否能复用 Android 代码、API 是否会回调、是否需要手动释放内存、是否是 UI 组件，并据此将大多数 iOS 专属工作迁到 Swift，而可同步执行的 AVFoundation 设置继续保留在 Kotlin。

在 Kotlin Multiplatform 應用中，何時該停在 Kotlin、何時該交給 Swift

我真正該問的不是怎麼修，而是這段程式為什麼會寫在 Kotlin 裡。

重點摘要

iOS 影片匯出因 completion handler 未觸發而卡死，導致 coroutine 無限等待。

作者整理出四個判斷問題，決定 iOS 功能該留在 Kotlin 還是改用 Swift。

可同步完成的 AVFoundation 設定留在 Kotlin；回呼、手動釋放記憶體與 UI 元件則交給 Swift。

作者以 Afterfade 為例，說明自己如何用 Kotlin Multiplatform 與 Compose Multiplatform 開發 Android 與 iOS，卻在 iOS 影片匯出時遇到卡死問題。原本以 suspendCancellableCoroutine 包裝 AVAssetExportSession 的 completion handler，卻在某些情況下永遠收不到回呼，改 dispatcher 或加 timeout 也無法真正解決。作者因此反思：這段程式其實無法與 Android 共用，只是把 iOS 專屬邏輯包在 Kotlin 外殼裡。之後他提出四個判斷準則，依序檢查是否能共用、是否依賴回呼、是否需要手動釋放記憶體、是否屬於 UI 元件，並據此把多數 iOS 專屬工作移到 Swift，而可同步執行的 AVFoundation 設定仍保留在 Kotlin。

[REDACTED] — How to keep your mobile app’s secrets, a secret!

ProAndroidDev 作者：Ed Holloway-George 發布：08-21 13:58

[REDACTED] — How to Keep Your Mobile App’s Secrets Secret

As mobile developers, we often have scenarios that require us to consume or store secrets.

重點摘要

Use tools like betterleaks or gitleaks to find secrets in code and git history.

Remove exposed secrets by rewriting history with BFG Repo Cleaner or git-filter-repo.

Prefer backend proxies and key restrictions to minimize secrets stored in the app.

This article explains why hard-coded secrets in mobile apps are a serious security and business risk, especially in an era where modern AI can help attackers find them. It recommends first scanning codebases and git history with tools such as betterleaks or gitleaks, then rewriting history with BFG Repo Cleaner or git-filter-repo to remove exposed values. The author also advises migrating secrets out of source control, adding CI checks and code review to prevent reintroduction, and restricting API keys where possible. Ultimately, the safest option is to eliminate secrets from the app entirely by proxying requests through backend services.

[REDACTED]——如何让移动应用的秘密保持秘密

作为移动开发者，我们常常会遇到需要使用或存储秘密的场景。

重點摘要

使用 betterleaks 或 gitleaks 扫描代码和 git 历史中的秘密。

通过 BFG Repo Cleaner 或 git-filter-repo 重写历史并清除泄露内容。

尽量采用后端代理与密钥限制，降低 App 内保存秘密的风险。

本文指出，移动应用中硬编码秘密会带来严重的安全与商业风险，尤其在现代 AI 可能帮助攻击者更高效发现泄露信息的背景下更应警惕。作者建议先用 betterleaks 或 gitleaks 扫描代码库与版本历史，再借助 BFG Repo Cleaner 或 git-filter-repo 重写历史，移除已提交的敏感值。之后，应将秘密迁移出源码，并通过 CI 检查与代码审查避免再次引入，同时对 API 密钥设置来源与权限限制。最终，最安全的做法是通过后端代理来彻底避免应用直接持有秘密。

[REDACTED]——如何讓行動應用程式的機密保持機密

身為行動開發者，我們經常會遇到需要讀取或儲存機密的情境。

重點摘要

使用 betterleaks 或 gitleaks 掃描程式碼與 git 歷史中的機密。

透過 BFG Repo Cleaner 或 git-filter-repo 重寫歷史並移除外洩內容。

盡量以後端代理與金鑰限制降低 App 內保存機密的風險。

本文說明為何在行動應用中硬編碼機密是重大的資安與商業風險，尤其在 AI 能協助攻擊者更有效找出外洩內容的時代更需重視。作者建議先用 betterleaks 或 gitleaks 掃描程式碼與版本歷史，再以 BFG Repo Cleaner 或 git-filter-repo 重寫歷史，清除曾經提交的敏感值。接著可將機密移出原始碼，搭配 CI 檢查與程式碼審查防止再度混入，並在可行時對 API 金鑰做來源與權限限制。最終目標是透過後端代理，盡可能讓 App 不再直接持有機密。

Sharing Feature-Based Composables Through API Modules

Medium Kotlin 作者：Humbet Humbetov 發布：08-21 08:21

Sharing Feature-Based Composables Through API Modules

API and implementation modules are a familiar way to share data and domain contracts.

重點摘要

API and implementation modules separate contracts from implementation.

Repository interfaces or use cases can live in an API module.

The approach supports sharing feature-based composables cleanly.

The article introduces the idea of using API and implementation modules to share feature-based composables in a clean, modular way. It explains that this pattern is already familiar for sharing data and domain contracts, where repository interfaces or use cases are placed in an API module while the implementation remains separate. The same structure can be applied to composables, helping teams expose feature-level abstractions without leaking internal details. This keeps dependencies clearer and supports better modularization across a codebase.

通过 API 模块共享基于功能的 Composable

API 和实现模块是共享数据与领域契约的常见方式。

重點摘要

API 模块与实现模块可将契约和实现分离。

Repository 接口或 use case 可放在 API 模块中。

这种模式也适用于共享基于功能的 composable。

本文介绍了如何通过 API 和实现模块，以更清晰、模块化的方式共享基于功能的 composable。作者指出，这一模式在共享数据和领域契约时已经很常见，例如将 repository 接口或 use case 放在 API 模块中，而具体实现则留在独立模块里。相同思路也可以应用到 composable 上，帮助团队对外暴露功能级抽象，同时不泄露内部实现细节，从而让代码依赖关系更明确，并提升整体模块化程度。

透過 API 模組分享以功能為基礎的 Composable

API 與實作模組是分享資料與領域契約的常見方式。

重點摘要

API 模組與實作模組可分離契約與實作。

Repository 介面或 use case 可放在 API 模組中。

此模式也可用於分享功能導向的 composable。

本文介紹如何透過 API 與實作模組，乾淨地分享以功能為基礎的 composable。作者指出，這種做法在資料與領域契約的共享上已相當常見，例如將 repository 介面或 use case 放在 API 模組，而真正的實作則保留在另一個模組中。相同概念也能延伸到 composable，讓團隊能對外提供功能層級的抽象，同時避免洩漏內部細節，進而讓依賴關係更清楚、模組化更完整。

The Optional<Keywords> That Encapsulate A Generic Nerd

Medium Kotlin 作者：Rajeev chachra 發布：08-21 12:02

The Optional<Keywords> That Encapsulate a Generic Nerd

This is my first article on Medium, so a "Hello World" is warranted through "contract programming."

重點摘要

The author is publishing his first Medium article.

He frames the piece with a “Hello World” style introduction.

The article references contract programming and Kotlin-related themes.

This short Medium post is presented as the author’s first article, and it opens with a playful “Hello World” framing. The available text suggests the piece connects that introduction to contract programming and broader Kotlin or generic-programming ideas, but the excerpt is truncated and does not provide the full argument. As a result, the core takeaway is simply the author’s introductory, lighthearted setup rather than a detailed technical discussion.

包裹泛型极客的 Optional<Keywords>

这是我在 Medium 上的第一篇文章，因此用“Hello World”并借助“contract programming”来开场是顺理成章的。

重點摘要

作者说明这是他在 Medium 上的第一篇文章。

文章以“Hello World”式的方式作为开场。

正文提到了 contract programming 和 Kotlin 相关主题。

这篇 Medium 文章被作者视为自己的首篇作品，因此以带有趣味感的“Hello World”作为开场。就现有片段来看，文章把这一开头与 contract programming 以及 Kotlin 或泛型编程概念联系起来，但原文已被截断，无法看到完整展开。整体而言，这段内容的重点在于作者的引子与自我介绍，而不是一篇完整的技术论述。

包裹泛型書呆子的 Optional<Keywords>

這是我在 Medium 上的第一篇文章，因此用「Hello World」並透過「contract programming」作為開場是合理的。

重點摘要

作者表示這是他在 Medium 的第一篇文章。

文章以「Hello World」式的方式開場。

內文提及 contract programming 與 Kotlin 相關主題。

這篇 Medium 文章被作者定位為首篇發表，因此以輕鬆的「Hello World」方式開場。就目前可見內容來看，文章將這個開場與 contract programming 及 Kotlin 或泛型程式設計的概念連結，但原文片段已截斷，無法得知完整論述。整體而言，重點在於作者的自我介紹與帶有趣味性的技術引子，而非完整的技術分析。

Jetpack Compose LazyColumn Crash: “measure is called on a deactivated node” — Root Cause and Fix

Medium Kotlin 作者：Swaran Singh Aulakh 發布：08-21 13:41

Jetpack Compose LazyColumn Crash: “measure is called on a deactivated node” — Root Cause and Fix

How concurrent UI updates and repeated side effects triggered a production-only Compose layout crash, and what finally fixed it.

重點摘要

Concurrent UI updates triggered a layout crash in production.

Repeated side effects were part of the failure path.

The post explains the root cause and the eventual fix.

This article describes a Jetpack Compose production crash in a LazyColumn where layout measurement failed with the error “measure is called on a deactivated node.” The author traces the issue to concurrent UI updates combined with repeated side effects, which created a race-like condition during Compose layout. The post focuses on how the crash appeared only in production and how the underlying cause was identified before applying the final fix.

Jetpack Compose LazyColumn 崩溃：〈measure is called on a deactivated node〉— 根因与修复

并发的 UI 更新与重复的副作用，如何在生产环境触发 Compose 布局崩溃，以及最终如何修复。

重點摘要

并发的 UI 更新在生产环境引发布局崩溃。

重复的副作用是问题形成的一部分。

文章说明了根因分析与最终修复方式。

本文讲述了一起 Jetpack Compose 在生产环境中出现的 LazyColumn 崩溃，报错为“measure is called on a deactivated node”。作者分析后认为，问题源于并发的 UI 更新与重复触发的副作用，在 Compose 布局测量阶段形成了类似竞态的异常情况。文章重点在于该问题只在 production 中出现，并说明如何定位根因，最终完成修复。

Jetpack Compose LazyColumn 當機：〈measure is called on a deactivated node〉— 根因與修正

並發的 UI 更新與重複的副作用，如何在正式環境觸發 Compose 版面配置當機，以及最後如何修正。

重點摘要

並發的 UI 更新在正式環境引發版面配置當機。

重複的副作用是問題形成的一部分。

文章說明了根因分析與最終修正方式。

本文描述一個 Jetpack Compose 在正式環境中發生的 LazyColumn 當機，錯誤訊息為「measure is called on a deactivated node」。作者追查後指出，並發的 UI 更新加上重複觸發的副作用，讓 Compose 在版面配置測量時出現類似競態的問題。文章重點在於這個錯誤只在 production 出現，並說明如何找出根因，最後完成修正。

Flutter Meets Android Home Screen Widgets

Medium Kotlin 作者：Tom 發布：08-21 14:30

Flutter Meets Android Home Screen Widgets

A data boundary that survives app restarts

重點摘要

Explores Flutter integration with Android home screen widgets.

Focuses on keeping data boundaries intact across app restarts.

Article content provided is only a brief excerpt from Medium.

This article, titled "Flutter Meets Android Home Screen Widgets," appears to discuss how Flutter can work with Android home screen widgets. Based on the provided excerpt, the central idea is the use of a data boundary that survives app restarts, suggesting a design that preserves widget-related state or communication across app lifecycle changes. However, the available text is extremely limited and does not include the full technical implementation or examples, so any deeper interpretation would go beyond the source material.

Flutter 与 Android 主屏幕小组件的结合

一种在应用重启后仍能保留的数据边界

重點摘要

探讨 Flutter 与 Android 主屏幕小组件的整合。

重点是可跨应用重启保留的数据边界。

当前可见内容仅为 Medium 的极简摘要。

这篇文章《Flutter Meets Android Home Screen Widgets》从标题可判断，主题是 Flutter 与 Android 主屏幕小组件的整合。根据目前提供的片段，文章强调一种在应用重启后仍能保持存在的数据边界，说明作者关注的是小组件与应用之间状态传递或数据保存的设计思路。不过，现有正文信息非常有限，缺少完整技术细节和实现示例，无法进一步展开。

Flutter 與 Android 主畫面小工具的結合

一個能在應用程式重啟後仍然存在的資料邊界

重點摘要

探討 Flutter 與 Android 主畫面小工具的整合。

重點在於跨越應用程式重啟仍可保留的資料邊界。

目前提供的內容僅為 Medium 的極短摘要。

這篇文章〈Flutter Meets Android Home Screen Widgets〉從標題可知主題是 Flutter 與 Android 主畫面小工具的整合。依據目前提供的片段，文章強調一個能在應用程式重啟後仍然存在的資料邊界，暗示作者關注的是小工具與應用之間狀態傳遞或資料保存的設計方式。不過，現有內文只有非常簡短的摘要，無法得知完整實作或更多細節。