每日新聞摘要 - 2026年08月28日

01

Stop Hardcoding Breakpoints: A Practical Guide to WindowSizeClass in Jetpack Compose

Dev.to Kotlin 作者：YADNYESH RANA 發布：08-28 08:34

Stop Hardcoding Breakpoints: A Practical Guide to WindowSizeClass in Jetpack Compose

The bug you're avoiding isn't a crash, it's the slow drift of five screens each guessing a slightly different number.

重點摘要

Hardcoded dp breakpoints are brittle and inconsistent across screens

WindowSizeClass provides shared COMPACT, MEDIUM, and EXPANDED buckets

Use one adaptive screen with slots instead of separate phone/tablet composables

Many Android apps still treat tablet support as a stretched phone UI, which fails on real large screens and foldables. The article argues against hardcoded width checks such as if (screenWidthDp > 600) and recommends WindowSizeClass instead. By computing the size class once near the app root and passing it down, developers avoid inconsistent thresholds and rely on device-independent buckets like COMPACT, MEDIUM, and EXPANDED. The post also notes that height matters, that layouts should adapt within one screen using slots, and that WindowSizeClass is helpful but not sufficient for foldables, predictive back, or newer adaptive Compose APIs.

不要再硬编码断点：Jetpack Compose 中 WindowSizeClass 的实用指南

你要避免的不是崩溃，而是五个界面各自猜不同数字造成的缓慢漂移。

重點摘要

硬编码的 dp 阈值脆弱，且在各屏幕间容易不一致

WindowSizeClass 用 COMPACT、MEDIUM、EXPANDED 统一分类

用一个自适应屏幕配合 slots，而不是拆成手机版和平板版组件

文章指出，很多 Android 项目的“平板支持”其实只是把手机布局拉宽，面对真实平板或折叠屏就会失效。作者反对使用 if (screenWidthDp > 600) 这类硬编码阈值，转而推荐 WindowSizeClass，用 COMPACT、MEDIUM、EXPANDED 这样的跨设备分类来决定布局。最佳做法是在应用根部计算一次并向下传递，避免不同界面各自猜测阈值。文章还强调高度尺寸同样重要，并说明 WindowSizeClass 只是基础方案，无法单独解决折叠铰链、预测返回和更新的自适应 Compose API 等问题。

別再硬編 Breakpoint：Jetpack Compose 中 WindowSizeClass 的實用指南

你要避免的不是當機，而是五個畫面各自猜不同數字所造成的慢性漂移。

重點摘要

硬編的 dp 閾值脆弱，且容易在不同畫面間不一致

WindowSizeClass 以 COMPACT、MEDIUM、EXPANDED 提供共用分類

用單一自適應畫面搭配 slots，而不是分成手機版與平板版元件

本文指出，許多 Android 專案所謂的平板支援，其實只是把手機版介面拉寬，遇到真實平板或摺疊機就失效。作者反對以 if (screenWidthDp > 600) 這類硬編閾值判斷，改主張使用 WindowSizeClass，讓應用以 COMPACT、MEDIUM、EXPANDED 這種跨裝置的分類來決定版面。做法是先在根節點計算一次並往下傳遞，避免各畫面各自猜測。文章也提醒高度同樣重要，且 WindowSizeClass 只是基礎，無法單獨涵蓋摺疊鉸鏈、預測返回與更新的自適應 Compose API。

02

Shipping OneSignal push in a Kotlin Multiplatform app

Dev.to Kotlin 作者：Behzod Halil 發布：08-28 13:57

Shipping OneSignal Push in a Kotlin Multiplatform App

Most of a push-notification implementation has nothing to do with the product.

重點摘要

Switched from direct FCM to OneSignal by addressing users, not devices

Kept the legacy FCM path live behind configuration for safe rollout and rollback

Designed push as best-effort by saving durable inbox rows first and then delivering notifications

StockPlus migrated its Kotlin Multiplatform push pipeline from direct Firebase Cloud Messaging to OneSignal, but the main architectural change was not the vendor—it was addressing users instead of devices. The rollout stayed behind configuration so the old path remained the default and fully functional. The system also treats push as best-effort: it saves a durable inbox record first, then sends the notification. Along the way, the team uncovered four silent failures, including misleading HTTP success responses, logging that hid misconfiguration, platform-specific control-flow issues, and a Firebase dependency conflict that broke Android delivery.

在 Kotlin Multiplatform 应用中接入 OneSignal 推送

大部分推送实现其实与产品本身无关。

重點摘要

从直接 FCM 转为以用户为单位的 OneSignal 寻址

通过配置并行保留新旧管线，确保可安全回滚

先写入持久化收件箱，再尽力发送推送

StockPlus 将 Kotlin Multiplatform 的推送管线从直接使用 Firebase Cloud Messaging 切换到 OneSignal，但真正改变的并不是供应商，而是把寻址单位从设备改成用户。上线采用配置开关，新旧路径并行，旧的 FCM 方案仍是默认且可正常工作。系统还遵循先持久化、后推送的原则：先保存收件箱记录，再尝试发送通知。迁移过程中团队排查出四个静默失败，包括会误导判断的 HTTP 成功响应、掩盖配置问题的日志、跨平台控制流带来的隐性错误，以及 Firebase 依赖冲突导致 Android 订阅失效。

在 Kotlin Multiplatform App 中導入 OneSignal 推播

大部分推播實作其實與產品本身無關。

重點摘要

從直接 FCM 改為以使用者為單位的 OneSignal 尋址

以設定切換新舊管線，保留可回退的舊 FCM 路徑

先寫入持久化收件匣，再嘗試推播，讓通知成為 best-effort

StockPlus 將 Kotlin Multiplatform 的推播管線從直接使用 Firebase Cloud Messaging 轉為 OneSignal，真正的架構變化不是供應商，而是把尋址單位從裝置改成使用者。上線採用設定控制，讓舊的 FCM 路徑持續可用且預設生效。系統也採取先持久化再推播的設計：先寫入收件匣紀錄，再盡力送出通知。過程中還排查出四個安靜失敗，包括誤導性的 HTTP 成功回應、難以察覺的錯誤日誌、平台控制流問題，以及 Firebase 依賴衝突導致 Android 無法正常訂閱。

03

Implementing an Update Queue: Recovering Missed Updates After a Socket Reconnect

Medium Kotlin 作者：MohammadrezaAbbaszadeh 發布：08-28 12:27

Implementing an Update Queue: Recovering Missed Updates After a Socket Reconnect

How we built reliable update synchronization for a messaging client — and the two bugs that taught us more than the design doc did.

重點摘要

Builds reliable update syncing for a messaging client

Uses an update queue to recover missed messages after reconnect

Two bugs revealed important lessons beyond the design doc

This article describes how the team built a reliable update-synchronization mechanism for a messaging client, focused on recovering missed updates after a socket reconnect. The core idea is an update queue that helps the client catch up when the connection drops and resumes. Along the way, the authors encountered two bugs that exposed practical issues the design document had not fully anticipated. Those incidents became valuable learning moments, shaping a more robust implementation and deepening the team’s understanding of real-world synchronization problems.

实现更新队列：Socket 重连后恢复遗漏的更新

我们如何为消息客户端构建可靠的更新同步——以及两个比设计文档更能带来教训的 bug。

重點摘要

为消息客户端构建可靠的更新同步

通过更新队列在重连后恢复遗漏数据

两个 bug 带来了超出设计文档的实战经验

本文介绍团队如何为消息客户端实现可靠的更新同步机制，重点是当 Socket 断开并重新连接后，如何恢复期间遗漏的更新。作者通过更新队列让客户端在连接恢复时补齐进度，减少数据不一致的风险。实现过程中出现的两个 bug 也暴露出设计文档未充分覆盖的实际问题，并促使团队调整方案与细节处理，从而让整体同步逻辑在真实环境中更加稳健。

實作更新佇列：在 Socket 重新連線後補回遺失的更新

我們如何為訊息用戶端建立可靠的更新同步機制——以及兩個比設計文件更有教訓價值的 bug。

重點摘要

為訊息用戶端建立可靠的更新同步

以更新佇列在重新連線後補回遺失資料

兩個 bug 帶來了比設計文件更深的實作教訓

本文說明團隊如何為訊息用戶端建立可靠的更新同步機制，重點是當 Socket 斷線並重新連線後，如何補回期間遺失的更新。作者透過更新佇列讓客戶端在連線恢復時能追上進度，避免資料不一致。實作過程中遇到的兩個 bug，也揭示了設計文件未完全涵蓋的實務問題，並促使團隊修正架構與流程，進一步強化系統在真實環境中的穩定性。

04

Kotlin Variance: The in and out Keywords, Demystified

Medium Kotlin 作者：Wagner Franchin 發布：08-28 12:28

Kotlin Variance: The in and out Keywords, Demystified

Why a List<Cat> won't fit where a List<Animal> is expected — and the two tiny words that solve it

重點摘要

Explains why generic types in Kotlin are not freely interchangeable.

Introduces the `in` and `out` keywords as the core variance tools.

Shows how variance helps make type-safe APIs more flexible.

This article explains Kotlin variance and the role of the `in` and `out` keywords in generic type safety. It starts from a common problem: a `List<Cat>` cannot be used where a `List<Animal>` is expected, even though Cat is a subtype of Animal. The post motivates variance as the mechanism that controls how generic types relate to each other, and shows how Kotlin uses declaration-site variance to express whether a type parameter is producer-like (`out`) or consumer-like (`in`). The goal is to make APIs both flexible and type-safe without resorting to unsafe casts.

Kotlin 变型：深入解析 in 和 out 关键字

为什么 `List<Cat>` 不能放在需要 `List<Animal>` 的位置，以及解决它的两个小关键字

重點摘要

说明 Kotlin 中泛型类型为何不能随意互换。

介绍 `in` 和 `out` 作为变型的核心工具。

展示变型如何让 API 在保持类型安全时更灵活。

本文讲解 Kotlin 的变型（variance）以及 `in`、`out` 关键字在泛型类型安全中的作用。文章从一个常见问题入手：即使 Cat 是 Animal 的子类型，`List<Cat>` 也不能直接用在需要 `List<Animal>` 的地方。随后说明 Kotlin 通过声明处变型来表达类型参数的角色：`out` 更像生产者，`in` 更像消费者。借助这套机制，Kotlin 可以在不牺牲类型安全的前提下，让泛型 API 更加灵活。

Kotlin 變異：深入淺出 in 與 out 關鍵字

為什麼 `List<Cat>` 不能放在需要 `List<Animal>` 的地方，以及解決它的兩個小關鍵字

重點摘要

說明 Kotlin 中泛型型別為何不能任意互換。

介紹 `in` 與 `out` 作為變異的核心工具。

展示變異如何讓 API 在保持型別安全下更彈性。

本文說明 Kotlin 的變異（variance）概念，以及 `in`、`out` 兩個關鍵字在泛型型別安全中的作用。文章從常見情境切入：即使 Cat 是 Animal 的子型別，`List<Cat>` 仍不能直接當成 `List<Animal>` 使用。接著介紹 Kotlin 以宣告處變異來表達型別參數的角色：`out` 偏向產出者，`in` 偏向消費者。透過這套機制，Kotlin 能在不犧牲型別安全的前提下，讓泛型 API 更具彈性。

05

Engineering Geofencing: The Battery-Accuracy Tradeoff in Android

Dev.to Kotlin 作者：Haseeb 發布：08-27 23:16

Engineering Geofencing: The Battery-Accuracy Tradeoff in Android

Building geofencing on Android is a masterclass in compromise.

重點摘要

High-accuracy location requests can drain battery and still delay triggers.

A geofencing setup with PendingIntent and BroadcastReceiver keeps the app mostly dormant.

Debouncing state changes and using a ForegroundService improved reliability across devices.

The article describes building Muffle, an Android automation app designed to silence a phone based on context instead of manual toggles or rigid schedules. The author explains the central geofencing challenge: Android’s location APIs force a tradeoff between accuracy and battery life, and even official GeofencingClient behavior can be delayed or suppressed by power-saving modes. To reduce battery drain, the app uses GeofencingClient with a PendingIntent and BroadcastReceiver, plus custom debounce logic to ignore rapid enter/exit jitter. The author also found that some devices aggressively kill background work, so a ForegroundService and better diagnostic logging became necessary. The main lesson is to work with Android’s constraints, prioritize reliability over perfection, and build resilient, battery-conscious background automation.

Android 地理围栏工程：电量与精度的权衡

在 Android 上构建地理围栏，是一堂关于取舍的工程课。

重點摘要

高精度定位会显著耗电，触发也未必更及时。

GeofencingClient 配合 PendingIntent 与 BroadcastReceiver，可让应用保持低活跃状态。

通过时间门限、ForegroundService 和日志系统提升可靠性。

这篇文章讲述作者为 Muffle 开发 Android 自动静音自动化功能的过程，重点在于地理围栏场景下精度与电量之间的权衡。作者指出，Android 官方的 GeofencingClient 虽然能监控位置，但在省电模式或设备长时间静止时，系统可能延迟触发；若改用更高频率的位置更新，则会带来难以接受的耗电。最终方案是使用 GeofencingClient 结合 PendingIntent 与 BroadcastReceiver，并通过 60 秒时间门限过滤边界抖动，避免状态频繁切换。文章还提到，部分设备会因为 Doze 等机制杀死后台任务，因此需要 ForegroundService、持续通知和更完善的诊断日志。作者总结，开发者应顺应平台限制，而不是试图对抗它。

Android 地理圍欄工程：電量與精準度的取捨

在 Android 上打造地理圍欄，是一場充滿取捨的工程。

重點摘要

高精準度定位可能耗電，且不一定能即時觸發。

以 GeofencingClient 搭配 PendingIntent 與 BroadcastReceiver，可降低背景耗能。

加入狀態緩衝與 ForegroundService，能提升跨裝置穩定性。

這篇文章分享作者為 Muffle 打造 Android 自動化靜音功能的經驗，核心難題是地理圍欄在精準度與電量之間的取捨。作者發現，Android 的 GeofencingClient 雖然是官方方案，但在省電模式或裝置靜止時，觸發可能延遲，甚至被系統抑制。若改用高頻率定位雖然更準，卻會造成嚴重耗電，因此最後採用 GeofencingClient 搭配 PendingIntent 與 BroadcastReceiver，並用時間門檻過濾進出邊界的抖動。面對部分裝置會終止背景程序，作者改以 ForegroundService 與持續通知提高優先權，也強調應建立完善日誌，並接受平台限制，才能做出穩定可靠的背景自動化。

06

How I built a floating dictation orb on Android, and why the accessibility service is the whole app

Dev.to Kotlin 作者：Ayanda Phaketsi 發布：08-28 03:57

How I built a floating dictation orb on Android, and why the accessibility service is the whole app

The interesting part turned out not to be the transcription. It was knowing when to appear.

重點摘要

An AccessibilityService is used to detect when a text field has focus.

The overlay must stay unfocused so it does not steal the caret.

Dictation is streamed in chunks to reduce perceived latency and keep audio as fallback.

The author built RMBLR, an Android floating dictation orb designed for code-mixed speech that other dictation tools mishandled. The core challenge was not transcription quality but knowing when the orb should appear: Android’s AccessibilityService is used to detect whether a cursor is currently in an editable field. The overlay is kept non-focusable so it does not steal the caret, and text is inserted by paste first, then by set-text fallback if needed. The article also details the orb’s touch gestures, streaming dictation to reduce perceived latency, and keeping full audio locally so failed streams can fall back to batch transcription. The app is open source, MIT licensed, and uses the user’s own API key.

我如何在 Android 上构建悬浮听写球，以及为什么无障碍服务就是整个 App

真正有趣的部分不是转写，而是它何时出现。

重點摘要

借助 AccessibilityService 判断当前是否有可编辑输入框获得焦点。

悬浮层必须保持不抢焦点，否则光标会丢失。

通过流式传输与保留完整音频，降低体感延迟并防止丢字。

作者开发了 RMBLR 这款 Android 悬浮听写球，目标是解决英语与母语混杂说话时，现有听写工具往往强行选定单一语言、导致结果失真的问题。文章强调，真正的难点不是转写质量，而是判断何时显示：Android 只能通过 AccessibilityService 知道外部应用里是否有输入光标。为了不抢走焦点，悬浮层必须设置为不可聚焦，并优先通过粘贴把文字送回目标输入框，失败时再改用 setText。作者还采用流式上传音频以降低感知延迟，同时保留完整 WAV，便于网络不稳时回退到批量转写。

我如何在 Android 上打造浮動聽寫球，以及為何無障礙服務就是整個 App

真正有趣的部分不是轉錄，而是要知道它何時該出現。

重點摘要

用 AccessibilityService 判斷目前是否有可編輯輸入欄位取得焦點。

浮動覆蓋層必須保持不搶焦點，否則游標會消失。

採串流聽寫與完整音檔備援，降低體感延遲並避免資料遺失。

作者打造了 RMBLR 這款 Android 浮動聽寫球，目的是處理英語與母語混雜的口說內容，因為多數聽寫工具會先選定單一語言而導致結果需要重打。文章指出，關鍵不在轉錄本身，而在於何時顯示：Android 只能靠 AccessibilityService 判斷外部 App 的輸入欄位是否取得焦點。為避免覆蓋層搶走游標，介面必須維持不可聚焦，並以貼上優先、失敗才改用設定文字。作者也透過串流上傳音訊降低體感延遲，並保留完整 WAV 作為網路不穩時的備援。

07

20/28: What Actually Happens When You Call requestPermissions()

Medium Kotlin 作者：Pramod Patel 發布：08-28 00:31

20/28: What Actually Happens When You Call requestPermissions()

PermissionController, grants, and AppOps

重點摘要

Explains the internal flow behind calling requestPermissions().

Covers how PermissionController handles permission grants.

Touches on the role of AppOps in permission management.

This article appears to explain what happens inside Android when an app calls requestPermissions(). Based on the available text, it focuses on the PermissionController, how permissions are granted, and how AppOps fits into the permission-checking and enforcement flow. The piece is part of a series and likely aims to demystify the system-level steps that occur behind a seemingly simple API call.

20/28：调用 requestPermissions() 时究竟会发生什么

PermissionController、授权与 AppOps

重點摘要

说明 requestPermissions() 背后的内部流程。

介绍 PermissionController 如何处理权限授予。

提及 AppOps 在权限管理中的作用。

这篇文章看起来是在解释 Android 中应用调用 requestPermissions() 时，系统内部实际会经历哪些步骤。根据目前可获得的内容，重点围绕 PermissionController、权限授予机制，以及 AppOps 在权限检查与执行流程中的作用。该文属于一个系列，旨在拆解这一看似简单的 API 调用背后的系统层细节。

20/28：呼叫 requestPermissions() 時實際會發生什麼事

PermissionController、授權與 AppOps

重點摘要

說明 requestPermissions() 背後的內部流程。

介紹 PermissionController 如何處理權限授予。

提及 AppOps 在權限管理中的角色。

這篇文章看起來是在說明 Android 中應用程式呼叫 requestPermissions() 時，系統內部實際會發生的流程。依據目前可取得的內容，重點放在 PermissionController、權限授予機制，以及 AppOps 在權限檢查與執行中的作用。這是系列文章的一部分，目的在於拆解這個看似簡單的 API 呼叫背後的系統層步驟。

08

Mastering Jetpack Compose Side Effect States

Medium Kotlin 作者：Arun Gohil 發布：08-28 04:31

Mastering Jetpack Compose Side Effect States

In the previous part of this series, we covered Side-Effect Handlers such as LaunchedEffect, rememberCoroutineScope, and DisposableEffect.

重點摘要

Continues a Jetpack Compose series focused on side effects

Recaps earlier coverage of key side-effect handlers

Introduces the next topic: side-effect states

This article is the next installment in a Jetpack Compose series. It references the previous part, which covered side-effect handlers including LaunchedEffect, rememberCoroutineScope, and DisposableEffect. Based on the provided text, the post is setting up a discussion of side-effect states and continuing a broader exploration of Compose side effects.

掌握 Jetpack Compose 的 Side Effect 状态

在本系列的前一部分中，我们介绍了 LaunchedEffect、rememberCoroutineScope 和 DisposableEffect 等 Side-Effect 处理器。

重點摘要

延续 Jetpack Compose side effect 系列内容

回顾前文提到的几个关键处理器

引出下一主题：side effect 状态

这篇文章是 Jetpack Compose 系列的延续，承接前一部分对 Side-Effect Handlers 的介绍，包含 LaunchedEffect、rememberCoroutineScope 和 DisposableEffect。根据目前提供的内容，本文将进一步讨论 side-effect states，并继续展开对 Compose 副作用机制的说明。

掌握 Jetpack Compose 的 Side Effect 狀態

在本系列的前一部分中，我們介紹了 LaunchedEffect、rememberCoroutineScope 與 DisposableEffect 等 Side-Effect 處理器。

重點摘要

延續 Jetpack Compose side effect 系列內容

回顧前文提到的幾個關鍵處理器

引出下一個主題：side effect 狀態

這篇文章是 Jetpack Compose 系列的延續，承接前一部分對 Side-Effect Handlers 的介紹，包含 LaunchedEffect、rememberCoroutineScope 與 DisposableEffect。從目前提供的內容可知，本文將進一步談論 side-effect states，並延伸前文對 Compose 副作用機制的討論。