每日新聞摘要 - 2026年04月04日

01

Turn Any Android App Into a Lock Screen Widget — Here's How

Dev.to Kotlin 作者：Alex Devson 發布：04-04 07:43

Turn Any Android App Into a Lock Screen Widget — Here's How

Display any Activity on the lock screen with a single-line call — no root, no boilerplate.

重點摘要

Displays any Android Activity directly on the lock screen

One-line integration: call LockscreenHelper.init(this) in onCreate

No root required, lightweight library with examples and docs

AndroidAppLockscreen is an open-source library that displays any Android Activity directly on the device lock screen, giving apps a widget-like, interactive presence without requiring root. Integration is intentionally simple: add the dependency and call LockscreenHelper.init(this) in your Activity's onCreate, and the Activity can appear on the lock screen. Typical use cases include music controls, alarms and timers, news headlines, quick replies, and compact dashboards. Developers praise the project for its one-line setup, minimal size, compatibility with any Activity, and clear documentation with examples. Installation uses the implementation 'p32929:AndroidAppLockscreen:LATEST_VERSION', and the source is hosted on GitHub at github.com/p32929/AndroidAppLockscreen. For apps that lose engagement while phones are locked, this library offers a lightweight way to keep content and controls immediately accessible at a glance.

把任何 Android 应用变成锁屏小组件 — 操作指南

只需一行代码即可在锁屏显示任意 Activity，无需 root 或繁琐设置。

重點摘要

在锁屏上直接显示任意 Activity

在 Activity 的 onCreate 中调用 LockscreenHelper.init(this)

无需 root，体积轻量且配有示例与文档

AndroidAppLockscreen 是一个开源库，可在 Android 锁屏上直接展示任意 Activity，带来类似交互式小组件的体验且无需 root。集成非常简单：添加依赖 implementation 'p32929:AndroidAppLockscreen:LATEST_VERSION'，并在 Activity 的 onCreate 调用 LockscreenHelper.init(this)，即可让该 Activity 出现在锁屏。常见场景包括锁屏音乐控制、闹钟/计时器、新闻摘要、快速回复界面与仪表盘小组件。开发者称赞其一行代码启用、零样板、体积小、兼容任意 Activity，且有清晰的文档与示例。源码托管在 GitHub（github.com/p32929/AndroidAppLockscreen），适合需要锁屏可见性的应用使用。

將任何 Android 應用變成鎖定畫面小工具 — 操作教學

只需一行程式碼即可在鎖定畫面顯示任意 Activity，無需 root 或繁複設定。

重點摘要

可在鎖定畫面直接顯示任意 Activity

在 Activity 的 onCreate 呼叫 LockscreenHelper.init(this) 即可

不需 root、輕量且附範例與文件

AndroidAppLockscreen 是一個開源函式庫，可在 Android 鎖定畫面直接顯示任意 Activity，提供類似互動小工具的體驗且不需 root。整合非常簡單：加入 implementation 'p32929:AndroidAppLockscreen:LATEST_VERSION' 並在 Activity 的 onCreate 呼叫 LockscreenHelper.init(this)，即可在鎖定畫面呈現該 Activity。常見應用包括鎖屏音樂控制、鬧鐘/計時器、新聞摘要、快速回覆介面與儀表板小工具。開發者喜歡它的零樣板程式碼、一行啟動、輕量體積、相容任何 Activity，並有完整範例與文件。原始碼與說明可在 GitHub（github.com/p32929/AndroidAppLockscreen）找到，適合需維持鎖屏可見性的應用。

02

TheActivity — The Android Library That Makes Permission Handling a One-Liner

Dev.to Kotlin 作者：Alex Devson 發布：04-04 10:37

TheActivity — The Android Library That Makes Permission Handling a One-Liner

TheActivity is an open-source Android library that simplifies runtime permission handling into clean, chainable one-liners.

重點摘要

One-line permission requests with callbacks

Start activities for result without request codes

Lightweight (~15KB), zero boilerplate, works with Activities and Fragments

TheActivity is an open-source Android library that collapses the usual runtime-permission boilerplate into concise, chainable one-liners. Instead of overriding onActivityResult, managing request codes, or manually checking permission states (including “Don't ask again” cases), developers can call a single requestPermissions(...) line with a callback for granted/denied. The library also supports starting activities for result without request codes, picking files, images, and contacts, and works with Activities and Fragments. It's designed to be zero-configuration and minimal (~15KB), and the author reports it has been used in production to handle Android edge cases. For developers tired of repetitive permission handling code, TheActivity offers a lightweight replacement that saves time and reduces boilerplate. The project is available on GitHub (github.com/p32929/TheActivity).

TheActivity — 将 Android 权限处理简化为一行的库

TheActivity 是一个开源 Android 库，将运行时权限处理简化为简洁、可链式的一行调用。

重點摘要

一行请求权限并以回调处理

启动 Activity 返回结果无需请求码

轻量（约15KB）、零样板、支持 Activity 与 Fragment

TheActivity 是一个开源的 Android 库，将复杂的运行时权限处理简化为简洁、可链式的一行调用。开发者无需覆写 onActivityResult、管理请求码或手动检查权限状态，也能自动处理“不再询问”等边界情形。除了单行请求权限并以回调处理允许/拒绝外，库还支持无需请求码的启动 Activity 返回结果、选择文件/图片/联系人，并能在 Activity 或 Fragment 中使用。体积轻量（约 15KB）、零样板和零配置，已在生产环境中使用并处理各类 Android 边界案例。项目在 GitHub（github.com/p32929/TheActivity）公开，若有帮助请点星。

TheActivity — 將 Android 權限處理簡化為一行的函式庫

TheActivity 是一個開源 Android 函式庫，將執行時權限處理濃縮為簡潔、可串接的一行呼叫。

重點摘要

一行請求權限並以回呼處理

啟動 Activity 取得結果無需請求代碼

輕量（約15KB）、零樣板、支援 Activity 與 Fragment

TheActivity 是一個開源的 Android 函式庫，將複雜的執行時權限處理濃縮為簡潔、可串接的一行呼叫。開發者不需覆寫 onActivityResult、管理請求代碼或手動檢查權限狀態，也能自動處理「不再詢問」等邊界情況。除了一行請求權限並以回呼處理允許/拒絕外，函式庫還支援無須請求代碼的啟動 Activity 取回結果、選取檔案/圖片/聯絡人，並可在 Activity 或 Fragment 中使用。體積輕量（約 15KB）、零樣板與零設定，已在生產環境中使用並處理各類 Android 邊界案例。專案於 GitHub（github.com/p32929/TheActivity）公開，若對你有幫助請幫忙點星。

03

Compose Slot Table Explained: I Read the Runtime Source, So You Don’t Have To

Medium Kotlin 作者：Nikhil Bajpai 發布：04-04 12:12

Compose Slot Table Explained: I Read the Runtime Source, So You Don’t Have To

Gap buffers, positional memoization, and recomposition — verified against the official Android design docs, with real code and interview tips.

重點摘要

Breaks down Compose’s slot table internals

Covers gap buffers and positional memoization

Provides code examples and interview guidance

This article walks through the internals of Jetpack Compose’s slot table by reading the runtime source and cross-checking the official Android design documentation. It explains core mechanisms such as gap buffers — a technique for efficient insertions and deletions in a contiguous storage — and positional memoization, which helps the runtime track and reuse composition slots. The author also describes how recomposition leverages these structures to update UI efficiently without rebuilding everything. Throughout the piece, real code snippets illustrate how the slot table operates in practice, and the author highlights common pitfalls and interview-relevant concepts. The goal is to demystify the slot table for engineers so they can better understand Compose performance, debugging, and design trade-offs without having to wade through the runtime source themselves.

Compose Slot Table 详解：我读了 Runtime 源码，替你整理重点

间隙缓冲（gap buffers）、位置记忆（positional memoization）与重组（recomposition）——已结合官方 Android 设计文档验证，含实际代码与面试提示。

重點摘要

解析 Compose 的 slot table 内部细节

说明 gap buffer 与位置记忆的作用

附上代码示例与面试重点提示

本文通过阅读 Compose runtime 源码并对照官方 Android 设计文档，详尽解析 slot table 的工作原理与实践应用。文章介绍了 gap buffer 在连续存储中如何高效处理插入与删除、位置记忆如何帮助运行时追踪并重用 composition slot，以及重组机制如何借助这些结构仅更新必要的 UI 部分。作者以真实代码片段演示 slot table 的操作流程，指出常见误区并整理出面试中可能被问到的核心概念。目标是帮助开发者更好理解 Compose 的性能与调试要点，避免必须直接阅读大量 runtime 源码。

Compose Slot Table 解讀：我讀了 Runtime 原始碼，替你整理重點

間隙緩衝（gap buffers）、位置備忘（positional memoization）與重組（recomposition）——結合官方 Android 設計文件驗證，並附上實際程式碼與面試提示。

重點摘要

拆解 Compose 的 slot table 內部機制

說明 gap buffer 與位置備忘的角色

提供程式範例與面試重點提示

本文以閱讀 Compose runtime 原始碼為出發，並對照官方 Android 設計文件，系統性說明 slot table 的運作原理與實際應用。文章解釋了 gap buffer 如何在連續儲存中有效處理插入與刪除、位置備忘如何幫助追蹤與重用 composition slot，以及重組機制如何利用這些結構只更新必要的 UI 部分。作者以實際程式碼片段示範操作流程，點出常見誤區並給出面試相關的概念整理。目標是幫助工程師理解 Compose 的性能與除錯要點，減少直接閱讀大量 runtime 原始碼的負擔。

04

Swift, KMP: Type-Safe Feature Flags for Scaled Teams

Medium Kotlin 作者：Yeskendir Salgara 發布：04-04 13:00

Swift, KMP: Type-Safe Feature Flags for Scaled Teams

A safe, reliable feature flag system for developers and users — and why Firebase’s approach falls short at scale.

重點摘要

Advocates type-safe feature flags for Swift and Kotlin Multiplatform.

Aims to provide a safe, reliable system for both developers and users.

Argues Firebase’s approach is inadequate when teams and usage scale.

In "Swift, KMP: Type-Safe Feature Flags for Scaled Teams," Yeskendir Salgara emphasizes the need for a safe, reliable feature-flag system that serves both developers and end users, and explains why Firebase’s approach can fall short at scale. The article centers on type-safety and cross-platform concerns—particularly for Swift and Kotlin Multiplatform (KMP)—as essential for predictable rollouts and reduced risk in large teams. It highlights the importance of design choices that improve developer experience, prevent configuration or runtime mistakes, and maintain parity across platforms. By critiquing common hosted solutions, the piece encourages engineering teams to adopt patterns and tooling that better enforce correctness and reliability as their product and organization grow.

Swift、KMP：为大规模团队的类型安全功能开关

为开发者与用户提供安全、可靠的功能开关系统——以及为什么 Firebase 的方法在规模化时力不从心。

重點摘要

主张在 Swift 与 KMP 中实现类型安全的功能开关。

强调系统需对开发者和终端用户都保持可靠与安全。

指出 Firebase 的方案在团队扩展与规模增长时存在局限。

文章探讨为大规模团队设计类型安全的功能开关的重要性，聚焦 Swift 与 Kotlin Multiplatform（KMP），强调通过类型与良好设计降低发布风险、提升开发体验。作者指出，一套对开发者与用户都可靠的开关系统可以减少配置或运行时错误并保持跨平台一致性，同时批评 Firebase 在规模化使用下可能无法充分应对这些需求，建议工程团队采用能增强正确性与可维护性的模式与工具。

Swift、KMP：為大型團隊設計型別安全的功能旗標

為開發者與使用者打造安全、可靠的功能旗標系統──以及為何 Firebase 的做法在規模擴張時不敷使用。

重點摘要

主張在 Swift 與 KMP 中實現型別安全的功能旗標。

強調系統需同時對開發者與最終使用者安全可靠。

指出 Firebase 的方法在團隊與使用量擴大時存在缺陷。

本文討論為大型團隊設計型別安全的功能旗標的重要性，聚焦 Swift 與 Kotlin Multiplatform（KMP）環境，主張透過型別與設計降低釋出風險並提升開發體驗。作者說明一套對開發者與使用者都可靠的旗標系統能避免設定或執行時錯誤，並維持跨平台的一致性；同時指出 Firebase 在規模化情境下的做法可能不足以應對這些挑戰，建議團隊採用能強化正確性與可維護性的模式與工具。

05

When Coroutines Break: Why Some Architectures Stay Predictable — and Others Fall Apart

Medium Kotlin 作者：Oliver Bozhinovski 發布：04-04 15:00

When Coroutines Break: Why Some Architectures Stay Predictable — and Others Fall Apart

Examines why coroutines can make some architectures predictable while causing others to become brittle and fail.

重點摘要

Coroutines simplify async code but can introduce implicit control flow and hidden concurrency.

Architectures that isolate side effects and enforce clear boundaries remain predictable with coroutines.

Improper coroutine use scatters state and timing assumptions, creating hard-to-debug failures.

In "When Coroutines Break," Oliver Bozhinovski examines how coroutines affect architectural predictability in Android applications. He argues that while coroutines streamline asynchronous programming, they can also introduce implicit control flow, hidden concurrency, and lifecycle coupling that undermine reasoning about system behavior. The article contrasts architectures that keep side effects localized and responsibilities well-defined—remaining predictable when coroutines are used—with architectures that allow coroutine-driven interactions to scatter state and timing assumptions, becoming brittle and difficult to debug. Bozhinovski outlines common pitfalls and trade-offs, and advocates design patterns that limit side effects, enforce ownership and scopes, and preserve observability so that coroutine-driven code remains robust and maintainable.

When Coroutines Break：为什么有些架构保持可预测，而有些崩溃

探讨协程如何让某些架构保持可预测性，同时使其他架构变得脆弱并失效。

重點摘要

协程简化异步代码，但可能引入隐含控制流与隐藏的并发问题。

将副作用封装并明确责任边界的架构，与协程搭配时更可预测。

不当使用协程会分散状态和时序假设，导致难以调试的失败。

Oliver Bozhinovski 在《When Coroutines Break》一文中探讨协程对 Android 应用架构可预测性的影响。作者指出，协程虽能使异步代码更简洁，但也可能带来隐含的控制流程、隐藏的并发行为和生命周期耦合，从而削弱对系统行为的推理能力。文章对比了能封装副作用、明确定界责任与作用域的稳健架构，以及允许协程跨界操作、使状态与时序假设分散的脆弱架构，说明常见陷阱与权衡并提出实践建议，强调限制副作用、明确所有权与保持可观测性以维持稳定性和可维护性。

When Coroutines Break：為何有些架構保持可預測，而有些則崩潰

探討協程如何讓某些架構保持可預測性，同時使其他架構變得脆弱而失效。

重點摘要

協程讓非同步程式碼更簡潔，但可能引入隱性控制流程與隱藏的併發問題。

能將副作用封裝並明確界定責任的架構，與協程搭配時較為可預測。

不當使用協程會分散狀態與時序假設，導致難以除錯的崩潰。

Oliver Bozhinovski 在〈When Coroutines Break〉一文中討論協程對 Android 應用架構可預測性的影響。作者指出，協程雖然能簡化非同步程式，但也可能帶來隱含控制流程、隱藏的併發行為與生命週期耦合，讓系統行為難以推理。文章比較能將副作用封裝、明確責任與作用域的穩定架構，與允許協程跨界操作、散佈狀態與時序假設而變得脆弱的架構，並說明常見陷阱與權衡。作者建議採用限制副作用、明確擁有權與維持可觀察性的設計模式，使協程使用既高效又可維護。

06

Why I Stopped Using Callbacks in Android and Switched to Flow + ViewModel Events

Dev.to Kotlin 作者：Baharudin Maulana 發布：04-04 02:19

Why I Stopped Using Callbacks in Android and Switched to Flow + ViewModel Events

After months of debugging nested callbacks and lifecycle issues in a production POS app, I migrated to Flow + ViewModel Events and haven't looked back.

重點摘要

Callbacks cause lifecycle blindness, race conditions, and hard-to-test code

Use sealed event classes + SharedFlow for one-time events and StateFlow for UI state

Collect events with repeatOnLifecycle inside viewLifecycleOwner.lifecycleScope

The author explains why callbacks became untenable while maintaining a production POS Android app: nested callback pyramids made lifecycle tracking, race conditions, and testing painful. The recommended pattern centralizes UI events in a ViewModel using sealed classes, emits one-time events with MutableSharedFlow/SharedFlow, and keeps persistent UI via StateFlow. The UI collects events inside repeatOnLifecycle within viewLifecycleOwner.lifecycleScope. This avoids callbacks firing after Activity/Fragment destruction, reduces race conditions, and simplifies tests and debugging. Important gotchas include never collecting outside repeatOnLifecycle, avoiding replay=1 on event flows, not using tryEmit for critical events, and using viewLifecycleOwner in Fragments. After migration the team saw zero lifecycle crashes from event handling, faster debugging, cleaner tests, and clearer screen flow.

我为何停止在 Android 使用回调，转而采用 Flow + ViewModel 事件

在维护生产环境的 POS 应用时，巢状回调让生命周期和除错变得痛苦，我改用 Flow 与 ViewModel 事件后不再回头。

重點摘要

回调会导致生命周期盲点、竞态问题与难以测试的样板代码

使用 sealed class + SharedFlow 发一次性事件，StateFlow 保存持久 UI 状态

在 viewLifecycleOwner.lifecycleScope 的 repeatOnLifecycle 中收集事件

作者在维护生产级 POS Android 应用时发现，嵌套回调造成追踪生命周期、处理竞态和编写测试都非常困难，於是改由 ViewModel 发出以 sealed class 表示的事件，使用 MutableSharedFlow/SharedFlow 传递一次性事件，并借助 StateFlow 保存持续的 UI 状态；UI 端在 viewLifecycleOwner.lifecycleScope 内以 repeatOnLifecycle 收集事件。该方案避免组件销毁后仍触发事件、降低竞态、简化测试与除错。需注意：不要在 repeatOnLifecycle 外收集、不要为事件流设置 replay=1、避免使用 tryEmit、Fragment 必须用 viewLifecycleOwner。迁移后团队减少了因事件处理导致的崩溃，除错更快，测试更清晰。

為什麼我不再在 Android 使用 Callback，而改用 Flow + ViewModel Events

在維護生產環境的 POS 應用時，巢狀回呼導致難以追蹤的生命週期與除錯問題，因此我改用 Flow 與 ViewModel 事件。

重點摘要

回呼會造成生命周期盲點、競態與難以測試的樣板程式

用 sealed class + SharedFlow 傳一次性事件，StateFlow 保存持久 UI 狀態

畫面端須在 viewLifecycleOwner.lifecycleScope 的 repeatOnLifecycle 中收集

作者在維護生產用 POS Android 應用時，因巢狀 callback 引發生命週期錯誤、競態條件與難以測試的代碼，決定改以 ViewModel 發出以 sealed class 表示的事件，使用 MutableSharedFlow/SharedFlow 傳遞一次性事件，並以 StateFlow 保存持久 UI 狀態；畫面端在 viewLifecycleOwner.lifecycleScope 裡以 repeatOnLifecycle 收集事件。此模式避免在 Activity/Fragment 銷毀後仍觸發事件、降低競態、讓測試與除錯更乾淨。注意事項包括：別在 repeatOnLifecycle 外收集、不要為事件流設 replay=1、避免用 tryEmit、Fragment 要用 viewLifecycleOwner。遷移後團隊減少生命週期崩潰、除錯更快、測試更簡潔。

07

Beyond the Foreground Service: Reliable Background BLE Connection Management on Android 12+

Dev.to Kotlin 作者：Ble Advertiser 發布：04-04 05:22

Beyond the Foreground Service: Reliable Background BLE Connection Management on Android 12+

Combine WorkManager, PendingIntent-based GATT callbacks, and short-lived ForegroundService to maintain BLE connections despite process deaths and reboots.

重點摘要

Use WorkManager to orchestrate and persist BLE connection attempts across process deaths and reboots

Pass a PendingIntent to connectGatt so the system delivers GATT events when the app process is dead

Temporarily promote a Worker to a ForegroundService only during active GATT operations to satisfy API 31+ rules

Android 12+ tightens background execution and power management, making a long-running ForegroundService alone unreliable for persistent BLE connections. The article proposes a hybrid approach: use WorkManager to schedule and retry connection attempts resiliently; supply a PendingIntent to BluetoothDevice.connectGatt so the system owns GATT callbacks and can notify a BroadcastReceiver even if the app process is gone; and elevate the Worker to a short-lived ForegroundService only while performing active GATT operations to comply with API 31+ requirements. Implementation details cover required permissions and manifest entries, a BroadcastReceiver that enqueues reconnection work on disconnect, and a BluetoothWorker using CompletableDeferred, setForeground(ForegroundInfo), proper GATT cleanup, and WorkManager retry policies. Best practices include avoiding autoConnect for initial connections, meticulous GATT resource handling, and maintaining a connection state machine.

超越前台服务：在 Android 12+ 上可靠的后台 BLE 连接管理

结合 WorkManager、传递 PendingIntent 的 GATT 回调与短暂的 ForegroundService，可在应用进程死亡或重启后仍维持 BLE 连接。

重點摘要

使用 WorkManager 编排与重试，确保连接尝试能跨进程死亡与设备重启持续执行

在 connectGatt 中传入 PendingIntent，让系统在应用不在时仍能投递 GATT 事件至 BroadcastReceiver

仅在执行实际 GATT 操作时暂时提升为 ForegroundService，以符合 API 31+ 要求并降低耗电

Android 12 之后对后台执行与省电管理更严格，单靠长时间运行的 ForegroundService 无法稳定维持 BLE 连接。本文提出混合策略：使用 WorkManager 排程与重试连接、在 connectGatt 传入 PendingIntent 让系统在应用进程死亡时仍能将 GATT 回调送达 BroadcastReceiver、并在需要实际执行 GATT 操作时短暂将 Worker 提升为 ForegroundService。文中列出必要权限与 manifest 配置，示范 BroadcastReceiver 与 BluetoothWorker 的实现要点（setForeground、CompletableDeferred、关闭 GATT），并建议避免初次使用 autoConnect、维护连接状态机与妥善释放资源，以提升连接韧性并符合系统限制。

超越長駐 ForegroundService：在 Android 12+ 下可靠的背景 BLE 連線管理

透過 WorkManager、在 connectGatt 傳入 PendingIntent 的系統層 GATT 回調，以及短暫的 ForegroundService 結合，能在 app 程序死亡或重啟後仍維持連線。

重點摘要

以 WorkManager 排程與重試，讓連線嘗試能跨程序死亡與重開機持續執行

傳入 PendingIntent 至 connectGatt，系統會在應用進程不存在時仍送達 GATT 事件

僅在執行實際 GATT 操作時短暫提升為 ForegroundService，符合 API 31+ 規範且節省電量

Android 12 以後對背景執行與省電管理更嚴格，單靠長時間運行的 ForegroundService 無法穩定維持 BLE 連線。本文提出混合策略：以 WorkManager 排程與重試連線、在 connectGatt 傳入 PendingIntent 使系統在 app 程序死掉時也能送出 GATT 回調給 BroadcastReceiver、以及在需要實際執行 GATT 操作時短暫提升 Worker 為 ForegroundService。文章說明必要權限與 manifest 設定、示範 BroadcastReceiver 在斷線時排隊重連的做法，以及 BluetoothWorker 的實作要點（setForeground、CompletableDeferred、close GATT），並建議避免初次使用 autoConnect、維護連線狀態機與謹慎釋放資源，以提升連線韌性並遵守系統政策。

08

Demystifying Android BLE 'GATT Status 133': Common Causes and Robust Solutions for Connection Failures

Dev.to Kotlin 作者：Ble Advertiser 發布：04-04 05:33

Demystifying Android BLE 'GATT Status 133': Common Causes and Robust Solutions for Connection Failures

GATT Status 133 is a generic error from the native Android Bluetooth stack indicating an unspecified connection failure during the BLE connection lifecycle.

重點摘要

Status 133 originates in the native Bluetooth stack (Bluedroid/Fluoride) and signals an unspecified connection failure.

Prefer autoConnect=false for direct user-initiated connects; use autoConnect=true only for background reconnection.

Manage BluetoothGatt lifecycle, implement retries with exponential backoff, and enforce a single-operation BLE state machine.

GATT Status 133 is a generic connection error emitted by the Android native Bluetooth stack (Bluedroid/Fluoride) when a BLE ATT/GATT link fails for unspecified reasons. It commonly appears during the CONNECTING phase and can be caused by radio interference, peripheral unavailability, resource leaks, or internal stack instability. Practical mitigations include ensuring correct runtime permissions, using connectGatt with autoConnect=false for direct connects (reserve autoConnect=true for opportunistic reconnection), closing and nullifying BluetoothGatt only after STATE_DISCONNECTED, and avoiding concurrent BLE operations by designing a clear state machine. Implement retry logic (e.g., exponential backoff), keep BluetoothGattCallback work off the binder thread, and check for system-level issues (toggle Bluetooth or reboot device) when errors persist. Applying these lifecycle, threading, and resource-management best practices substantially reduces 133 occurrences and improves BLE reliability.

揭秘 Android BLE 的 GATT Status 133：连接失败的常见原因与稳健解决方案

GATT Status 133 是来自 Android 原生蓝牙堆栈的通用错误码，表示在 BLE 连接流程中发生了未指明的连接失败。

重點摘要

133 来源于原生蓝牙堆栈（Bluedroid/Fluoride），表示未指定的连接错误。

用户主动连接应使用 autoConnect=false，autoConnect=true 仅用于后台重连场景。

正确管理 BluetoothGatt 生命周期、实现指数退避重试并保持单一操作状态机以避免竞态。

GATT Status 133 是 Android 原生蓝牙子系统在尝试建立或维护 BLE 连接时返回的通用错误码，常在 CONNECTING 阶段出现。可能原因包括无线干扰、外设不可用、未正确关闭的 BluetoothGatt 导致资源占用，或底层堆栈不稳定。建议做法：确保清楚权限并请求运行时权限；对直接连接使用 connectGatt(..., autoConnect=false)，仅在已建立连接后用 autoConnect=true 做后台重连；在接收到 STATE_DISCONNECTED 后再调用 gatt.close() 并将引用置空；在管理器中实现明确的状态机，避免同时扫描与连接；将耗时操作从 BluetoothGattCallback 转移到后台线程；遇到持续错误时可切换蓝牙或重启设备以排查系统层问题。

破解 Android BLE 的 GATT Status 133：連線失敗的常見原因與穩健解法

GATT Status 133 是來自 Android 原生藍牙堆疊的通用錯誤碼，表示在 BLE 連線流程中發生未指定的連線失敗。

重點摘要

133 為原生藍牙堆疊（Bluedroid/Fluoride）回報的未指明連線錯誤。

對使用者主動連線請用 autoConnect=false，autoConnect=true 僅用於背景重連情境。

妥善管理 BluetoothGatt 生命週期、實作指數退避重試並維持單一操作的狀態機。

GATT Status 133 是 Android 原生藍牙子系統在建立或維持 BLE 連線時回報的通用錯誤，常於 CONNECTING 階段出現。可能成因包括無線干擾、週邊裝置不可用、BluetoothGatt 未正確關閉而佔用資源，或底層堆疊錯誤。建議採取的對策有：確認權限並請求執行時權限；對直接連線使用 connectGatt(..., autoConnect=false)，僅在背景重連時使用 autoConnect=true；在 STATE_DISCONNECTED 後才呼叫 gatt.close() 並將參考設為 null；避免同時進行掃描與連線，實作明確的狀態機；在 callback 中把重作業轉到背景執行；必要時重啟藍牙或裝置以排查系統層問題。

09

Why I Stopped Using Callbacks in Android and Switched to Flow + ViewModel Events

Medium Kotlin 作者：Rudy DevKits 發布：04-04 02:02

Why I Stopped Using Callbacks in Android and Switched to Flow + ViewModel Events

Not because it's trendy — because my sanity was at stake.

重點摘要

Callbacks caused complexity and mental overhead

Kotlin Flow provides structured, reactive streams

ViewModel events enable clearer, lifecycle-aware handling

The author explains they abandoned traditional callbacks in Android development and adopted Kotlin Flow combined with ViewModel events, not as a fashionable choice but to preserve their sanity. Callbacks had led to nested, hard-to-follow code and fragile state management. Switching to Flow introduced a more declarative, stream-based approach that integrates with coroutines, making asynchronous flows easier to compose and reason about. Using ViewModel events alongside Flow provided a lifecycle-aware conduit for one-off events and UI communication, improving predictability and testability. Overall, the move reduced cognitive load, simplified event propagation, and made the codebase easier to maintain and evolve.

为何我不再使用 Callback，而改用 Flow 与 ViewModel 事件

不是因为流行，而是为了保住我的理智。

重點摘要

Callback 带来复杂性与心理负担

使用 Kotlin Flow 可获得更具声明性的数据流

ViewModel 事件使事件处理更符合生命周期、便于测试

作者说明他放弃在 Android 中频繁使用 callback，转而采用 Kotlin Flow 与 ViewModel 事件，原因并非追随潮流，而是为了保护自己的理智。传统 callback 常导致嵌套、难以跟踪的异步流程和脆弱的状态管理；使用 Flow 提供更声明式的流处理，并能与 coroutine 无缝整合，降低组合与推理异步逻辑的难度。配合 ViewModel 事件可以建立符合生命周期的单次事件传递路径，提高可预测性与可测性，整体减少认知负担并促进代码维护。

為何我不再使用 Callback，而改用 Flow 與 ViewModel 事件

不是因為流行，而是為了保住我的理智。

重點摘要

Callback 帶來複雜性與心智負擔

使用 Kotlin Flow 可得更具宣告性的資料流

ViewModel 事件讓事件處理更符合生命週期、易於測試

作者說明他放棄在 Android 中頻繁使用 callback，轉而採用 Kotlin Flow 與 ViewModel 事件，原因並非趨勢，而是為了保護自己的理智。傳統 callback 常造成巢狀、難以追蹤的非同步流程與脆弱的狀態管理；改用 Flow 提供更宣告式的串流處理，並能與 coroutine 無縫整合，降低組合與推論非同步邏輯的難度。搭配 ViewModel 事件可建立符合生命週期的單次事件傳遞路徑，提升可預測性與測試性，整體減少心智負擔並促進程式碼維護。

10

Kotlin Scope Functions Explained (with Examples)

Medium Kotlin 作者：Suman Shil 發布：04-04 02:25

Kotlin Scope Functions Explained (with Examples)

If you've worked with Kotlin, you've likely come across five scope functions: let, run, with, apply, and also.

重點摘要

Introduces five primary Kotlin scope functions

Explains usage and differences with examples

Aims to help choose the right function for concise code

The article introduces Kotlin's five primary scope functions—let, run, with, apply, and also—and explains their roles and typical use cases. Through annotated examples, the author shows how each function affects the context object, return value, and code readability, and suggests when to prefer one over another to make code more concise and idiomatic. Aimed at Kotlin developers who have encountered these functions, the piece clarifies common confusions about parameter versus receiver scope and demonstrates practical patterns for object initialization, null-safety handling, and chaining operations. It also provides practical tips and common pitfalls to avoid, enabling developers to write safer, more readable Kotlin while reducing boilerplate in everyday tasks.

Kotlin 范围函数解析（含示例）

如果你使用过 Kotlin，很可能见过五个范围函数：let、run、with、apply 和 also。

重點摘要

介绍五个主要的 Kotlin 范围函数

通过示例说明使用情境与差异

帮助选择合适函数以简化代码并提高可读性

本文介绍 Kotlin 的五个 scope function：let、run、with、apply、also，并通过示例解释它们的用途与差异。文章演示每个函数如何影响作用域对象与返回值，并指出在对象初始化、空值处理与链式操作时应如何选择相应函数以提升代码简洁性与可读性。同时提供实用建议与常见误区提醒，适合作为希望理清 scope function 行为、减少样板代码并写出更具表达力 Kotlin 代码的开发者参考。

Kotlin 範圍函式解析（含範例）

若你使用過 Kotlin，應該會遇到五個範圍函式：let、run、with、apply 與 also。

重點摘要

介紹五個主要的 Kotlin 範圍函式

以範例說明各自的用法與差異

協助選擇適合的函式以簡化與增進可讀性

本文介紹 Kotlin 的五個 scope function：let、run、with、apply、also，並以範例說明其用途與差異。作者示範每個函式如何影響作用域物件與回傳值，並說明在物件初始化、處理 null 值與串接操作時，何時應選擇特定函式以提升可讀性與簡潔度。文章也提供實務建議與常見誤區說明，適合想釐清 scope function 行為並寫出更具表現力與低樣板碼 Kotlin 的開發者作為快速參考。

今日總結

將任何 Android 應用變成鎖定畫面小工具 — 操作教學

重點摘要

TheActivity — 將 Android 權限處理簡化為一行的函式庫

重點摘要

Compose Slot Table 解讀：我讀了 Runtime 原始碼，替你整理重點

重點摘要

Swift、KMP：為大型團隊設計型別安全的功能旗標

重點摘要

When Coroutines Break：為何有些架構保持可預測，而有些則崩潰

重點摘要

為什麼我不再在 Android 使用 Callback，而改用 Flow + ViewModel Events

重點摘要

超越長駐 ForegroundService：在 Android 12+ 下可靠的背景 BLE 連線管理

重點摘要

破解 Android BLE 的 GATT Status 133：連線失敗的常見原因與穩健解法

重點摘要

為何我不再使用 Callback，而改用 Flow 與 ViewModel 事件

重點摘要

Kotlin 範圍函式解析（含範例）

重點摘要