Daily Digest

每日新聞摘要

2026年09月05日

今日總結

內容會跟隨語言切換。

📝 今日焦點：Compose Multiplatform 改造 tvOS fork、API 37 支援、以及 data class 基礎與隱含行為同時成為關注焦點。 🔧 效能最佳化：Muffle 以 GeofencingClient 取代持續 GPS 輪詢，並用二次驗證、去彈跳與重註冊降低耗電與誤判。 🏗 架構設計：tvOS 移植依賴順序推進，重點落在 compose:ui:ui；lint 變慢多半是重複執行，應先減少冗餘流程。 ✅ 測試與品質：Asmaul Husna 以卡片式主動回想、清楚字卡與深色模式提升長期記憶與可讀性，適合各年齡層反覆練習。

📝 Today’s focus: Compose Multiplatform tvOS support, Android API 37 readiness, and Kotlin data classes drew the main attention. 🔧 Performance: Muffle replaced constant GPS polling with GeofencingClient, then added validation, debouncing, and reboot re-registration to reduce battery cost and false triggers. 🏗 Architecture: The tvOS port advanced in dependency order, with compose:ui:ui as the hardest module; slow lint often comes from repeated runs, not the tool itself. ✅ Quality: Asmaul Husna uses card-based active recall, clear typography, and dark mode to improve accessibility and long-term retention.

My Journey Making Compose Multiplatform Work on tvOS, and What I Learned

Dev.to Kotlin 作者：Sajid Ali 發布：09-05 07:43

My Journey Making Compose Multiplatform Work on tvOS, and What I Learned

This series is about how that requirement ended with me maintaining a fork of Compose Multiplatform with tvOS support, and what I learned along the way.

重點摘要

Skiko already supported tvOS, making the port feasible.

The work required changes in both the Gradle plugin and Compose runtime.

The hardest problems were input handling, focus, and ongoing upstream maintenance.

This high-level overview explains how an Android and Android TV developer at Devolic ended up maintaining a fork of Compose Multiplatform with tvOS support. The team first moved from Android Views to Jetpack Compose, then added desktop, iOS and tvOS to the roadmap. Native SwiftUI on tvOS was rejected because focus handling could not match Android TV behavior. After confirming that tvOS is close enough to iOS and that Skiko already had tvOS targets, the author enabled tvOS in the Gradle plugin and runtime, then ported modules in dependency order. The largest effort was compose:ui:ui, especially rendering, Siri Remote input, focus, density and text input. The article closes with lessons on dependency-first checks, sharing code between iOS and tvOS, and expecting frequent upstream rebases.

我如何让 Compose Multiplatform 在 tvOS 上运行，以及从中学到什么

这个系列讲的是，这一需求最终如何让我维护一个支持 tvOS 的 Compose Multiplatform 分支，以及我一路学到的经验。

重點摘要

Skiko 已支持 tvOS，使移植变得可行。

需要同时修改 Gradle 插件和 Compose runtime。

最难的是输入、焦点处理以及持续跟进上游变更。

这篇概览文章讲述了一名拥有十年 Android 和 Android TV 经验的开发者，如何因为流媒体应用需要覆盖多平台，而开始维护一个支持 tvOS 的 Compose Multiplatform 分支。团队先从 Android Views 迁移到 Jetpack Compose，随后把 desktop、iOS 和 tvOS 纳入路线图，但在 tvOS 上尝试原生 SwiftUI 后，因焦点管理无法达到 Android TV 的行为而放弃。确认 tvOS 与 iOS 架构相近、且 Skiko 已提供 tvOS 目标后，作者先修改 Gradle 插件和 runtime，再按依赖顺序逐步移植模块。工作量最大的部分是 compose:ui:ui，涉及渲染、Siri Remote 输入、焦点、屏幕密度和文本输入。

我如何讓 Compose Multiplatform 在 tvOS 上運作，以及一路學到的事

這個系列講的是，這項需求最後如何讓我維護一個支援 tvOS 的 Compose Multiplatform 分支，以及我在過程中的收穫。

重點摘要

Skiko 已支援 tvOS，讓移植具備可行性。

需要同時修改 Gradle 外掛與 Compose runtime。

最難的是輸入、焦點處理與持續跟進上游變更。

這篇總覽文章說明，一位有十年 Android 與 Android TV 經驗的開發者，如何因為串流 App 需要支援多平台，而開始維護一個帶有 tvOS 支援的 Compose Multiplatform fork。團隊先從 Android Views 轉到 Jetpack Compose，再把 desktop、iOS 與 tvOS 納入規劃，但在 tvOS 上採用 SwiftUI 後，因焦點管理無法達到 Android TV 的行為而作罷。確認 tvOS 與 iOS 架構相近、且 Skiko 已有 tvOS 目標後，作者先改 Gradle 外掛與 runtime，再依賴關係順序逐步移植模組。最費工的是 compose:ui:ui，涵蓋渲染、Siri Remote 輸入、焦點、密度與文字輸入。

My Journey Making Compose Multiplatform Work on tvOS, and What I Learned

Medium Kotlin 作者：Sajid Ali 發布：09-05 07:43

My Journey Making Compose Multiplatform Work on tvOS, and What I Learned

This post is a high-level overview of the journey; the next posts will dive into each module in detail.

重點摘要

Part 1 of a series

High-level overview of the project and journey

Later posts will cover each module in detail

This article is the first part of a series about the author’s effort to make Compose Multiplatform work on tvOS. It serves as a high-level overview rather than a technical deep dive. The post explains that the upcoming entries will examine each module in detail, giving readers a roadmap for the rest of the series and framing the project as an incremental learning journey.

我让 Compose Multiplatform 在 tvOS 上运行的旅程，以及我的收获

这篇文章是整个旅程的高层概览；后续文章将逐一深入各个模块的细节。

重點摘要

系列文章的第 1 部分

以高层次介绍项目与开发历程

后续篇章将详解各个模块

本文是系列文章的第一篇，讲述作者如何尝试让 Compose Multiplatform 在 tvOS 上运行。这篇文章主要提供高层概览，并非深入技术实现细节。作者也表示，后续文章会分别展开介绍各个模块，为整篇系列建立清晰路线图，同时呈现这是一段逐步探索与学习的过程。

我將 Compose Multiplatform 帶上 tvOS 的旅程，以及我學到的事

這篇文章是整個旅程的高層概覽；後續文章將逐一深入各個模組細節。

重點摘要

系列文章的第 1 部分

以高層次介紹專案與開發旅程

後續篇章將詳解各個模組

本文是系列文章的第一篇，主題是作者如何嘗試讓 Compose Multiplatform 在 tvOS 上運作。這篇先提供高層次概覽，並非逐步拆解技術細節。作者也說明後續文章會針對每個模組分別深入介紹，為整個系列建立清楚脈絡，也呈現這是一段逐步探索與學習的旅程。

Android upgrade API 37 Android 17

Medium Kotlin 作者：Coolzero 發布：09-05 07:59

Android Upgrade to API 37 and Android 17

I have a nice GitHub set up for changes with API 37.

重點摘要

The post mentions a GitHub setup for API 37-related changes.

It is tied to an Android 17 upgrade context.

The source text does not provide further technical details.

This short post is about upgrading Android to API 37, associated with Android 17. The author says they have a well-organized GitHub setup for handling the changes, but the excerpt does not include the specific modifications, migration steps, or technical issues involved. As provided, the main takeaway is simply that supporting API 37 has been prepared in code on GitHub.

Android 升级到 API 37 与 Android 17

我已经在 GitHub 上为 API 37 的变更做好了完善的设置。

重點摘要

文章提到已为 API 37 相关变更建立 GitHub 配置。

内容与 Android 17 升级情境有关。

摘录未提供更多具体技术细节。

这篇短文主题是 Android 升级到 API 37，并与 Android 17 相关。作者表示自己已在 GitHub 上整理好可支持这些变更的设置，但摘录内容没有列出实际修改项、迁移步骤或技术问题。就目前提供的文字来看，重点仅在于相关支持已先在 GitHub 代码中准备完成。

Android 升級至 API 37 與 Android 17

我已經在 GitHub 上為 API 37 的變更做好了完善的設定。

重點摘要

文章提到已為 API 37 相關變更建立 GitHub 設定。

內容與 Android 17 升級情境有關。

摘錄未提供更多具體技術細節。

這篇短文主題是 Android 升級到 API 37，並與 Android 17 相關。作者表示自己已在 GitHub 上整理好可支援這些變更的設定，但摘錄內容沒有列出實際修改項目、遷移步驟或技術問題。就目前提供的文字來看，重點僅在於相關支援已先在 GitHub 程式碼中準備完成。

Asmaul Husna: Memory Practice

Dev.to Kotlin 作者：Henri Susanto 發布：09-05 01:41

Asmaul Husna: Memory Practice

Enhance your memorization of the 99 Names of Allah with an interactive, sequential active recall system designed for all ages.

重點摘要

Sequential active recall helps practice the names in order.

Each card shows Arabic calligraphy, transliteration, and English meaning.

Clean UI and dark mode support make it accessible for all ages.

Asmaul Husna: Memory Practice is an interactive app for memorizing the 99 Names of Allah through sequential active recall. Instead of passively reading a list, users tap through cards in order to test and strengthen memory. Each card presents Arabic calligraphy, English transliteration, and clear meanings, while the clean, high-contrast interface is designed for kids, adults, and seniors. The app also supports dark mode based on system settings, making it suitable for self-practice, daily review, and long-term retention.

Asmaul Husna：记忆练习

通过互动式、按顺序进行的主动回忆系统，加强对真主 99 个尊名的记忆，适合所有年龄层。

重點摘要

以按顺序的主动回忆方式练习尊名。

每张卡片包含阿拉伯书法、英文音译和英文释义。

界面简洁易读，并支持深色模式。

Asmaul Husna：Memory Practice 是一款帮助记忆真主 99 个尊名的互动应用，采用按顺序进行的主动回忆练习方式。它不是让用户被动浏览名单，而是通过逐张卡片测试记忆，强化对顺序与内容的掌握。每张卡片都展示阿拉伯书法、英文音译和清晰的英文含义，配合高可读性、高对比度的界面，适合儿童、成人和老年人使用；同时支持根据系统设置切换深色模式，便于自我练习、日常复习和长期记忆。

Asmaul Husna：記憶練習

透過互動式、依序進行的主動回想系統，加強對真主 99 個尊名的記憶，適合各年齡層使用。

重點摘要

以依序主動回想的方式練習尊名順序。

每張卡片提供阿拉伯書法、英文音譯與英文含義。

介面簡潔高可讀，並支援深色模式。

Asmaul Husna：Memory Practice 是一款用來記憶真主 99 個尊名的互動式應用程式，採用依序主動回想的練習方式。使用者不只是被動閱讀清單，而是透過逐張卡片依序測驗自己，加強對順序與內容的記憶。每張卡片都顯示阿拉伯書法、英文音譯與清楚的英文含義，搭配高對比、易閱讀的介面，適合兒童、成人與長者；同時也支援依系統設定切換深色模式，方便日常複習與長期記憶。

Architecting a Low-Power Geofencing Engine: Lessons from the Android Location API

Dev.to Kotlin 作者：Haseeb 發布：09-05 02:14

Architecting a Low-Power Geofencing Engine: Lessons from the Android Location API

The most successful features are the ones the user forgets exist because they just work.

重點摘要

Use GeofencingClient for battery-efficient background triggers.

Add secondary validation to reduce noisy or false geofence events.

Account for OEM battery optimizations, reboot re-registration, and GPS drift.

This article recounts the building of Muffle, an Android app designed to automatically switch audio profiles based on location while preserving battery life. The author explains why continuous GPS polling is too costly and why low-accuracy network locations are unreliable, then describes using GeofencingClient as a battery-efficient middle ground. Because tight radiuses and noisy signals can delay or misfire transitions, the app adds a second validation layer in a BroadcastReceiver, plus debouncing to confirm real entries. The piece also highlights practical challenges such as PendingIntent handling, BOOT_COMPLETED re-registration after reboot, manufacturer-specific background-kill behavior, and the need to request Battery Optimization exemptions.

构建低功耗地理围栏引擎：来自 Android Location API 的经验

最成功的功能，是用户几乎忘了它存在，却总能正常工作。

重點摘要

用 GeofencingClient 作为省电的后台触发核心。

在 BroadcastReceiver 中加入二次校验，减少误触发。

需处理厂商省电策略、重启后重注册与 GPS 漂移。

本文讲述作者为 Muffle 开发自动音频情境切换功能的过程，目标是在不显著耗电的前提下，让手机能根据所在位置自动调整声音模式。作者指出，持续轮询 GPS 会快速耗尽电量，而低精度的网络定位又不够可靠，因此选择 GeofencingClient 作为系统级、低功耗的背景触发方案。由于小半径围栏、信号噪声和不同厂商的后台限制都会带来延迟或误判，作者进一步在 BroadcastReceiver 中加入二次验证与去抖动逻辑，并处理 BOOT_COMPLETED 重注册、PendingIntent 可靠性和电池优化白名单等实际问题。

打造低耗電地理圍欄引擎：從 Android Location API 學到的經驗

最成功的功能，是使用者幾乎忘了它存在，卻始終運作順暢的功能。

重點摘要

以 GeofencingClient 作為省電的背景觸發核心。

在廣播接收器中加入二次驗證，降低誤觸發。

需面對 OEM 省電策略、重開機重註冊與 GPS 漂移問題。

本文分享作者為 Muffle 開發自動音效情境切換功能的經驗，目標是在不耗電的前提下，讓手機能依據所在位置自動調整音訊設定。作者指出連續輪詢 GPS 會嚴重耗電，純靠低精度網路定位又不夠可靠，因此改採 GeofencingClient 做為背景觸發機制。由於小半徑圍欄、訊號雜訊與製造商差異都會造成延遲或誤判，作者再加入廣播接收器二次驗證、觸發去彈跳，以及 BOOT_COMPLETED 重註冊流程，並提醒開發者需正視 GPS 漂移與電池最佳化限制。

# Kotlin Data Classes Deep Dive: Everything You Need to Know

Medium Kotlin 作者：Apoorv Rathore 發布：09-05 05:59

Kotlin Data Classes Deep Dive: Everything You Need to Know

One annotation. Five auto-generated functions. And a lot of hidden behavior most developers never fully explore.

重點摘要

Explains what Kotlin data classes generate automatically.

Highlights that data classes include more hidden behavior than many developers realize.

Introduces the topic as a deep dive into everything you need to know.

This article introduces Kotlin data classes by emphasizing how much functionality is created from a single annotation. It points out that data classes automatically generate five functions and include hidden behavior that many developers never fully investigate. Although the provided excerpt is brief, it clearly frames the post as a deep dive intended to explain the core mechanics and lesser-known details of Kotlin data classes.

Kotlin 数据类深度解析：你需要知道的一切

一个注解、五个自动生成的函数，以及许多大多数开发者从未彻底探索的隐藏行为。

重點摘要

说明 Kotlin 数据类会自动生成多个函数。

指出数据类还包含许多开发者不易注意的隐藏行为。

文章定位为对数据类的全面深度解析。

这篇文章以 Kotlin 数据类为核心，强调只需要一个注解，就会自动生成五个函数，并伴随许多开发者往往不会深入了解的隐藏行为。虽然当前公开内容有限，但已明确表明文章将以深度解析的方式，帮助读者理解 Kotlin data class 的基础机制、常见用途以及较少被注意的细节。

Kotlin 資料類別深入解析：你需要知道的一切

一個註解，五個自動生成的函式，還有許多多數開發者從未完全探索的隱藏行為。

重點摘要

說明 Kotlin 資料類別會自動生成多個函式。

指出資料類別還包含許多不易察覺的隱藏行為。

文章定位為資料類別的完整深入解析。

本文以 Kotlin 資料類別為主題，強調只需一個註解，就能自動產生五個函式，並帶來許多開發者常忽略的隱含行為。雖然目前可見內容很短，但已清楚表明這篇文章將從基礎機制到較少被探討的細節，帶讀者完整理解 Kotlin data class 的特性與用途。

Your Lint Task Isn’t Slow. It’s Just Running Too Many Times

Medium Kotlin 作者：AMAR PAL SINGH 發布：09-05 06:19

Your Lint Task Isn’t Slow. It’s Just Running Too Many Times

Your lint task isn’t slow; it’s simply being triggered too often.

重點摘要

The article points to repeated execution as the real issue.

Lint performance can appear worse when the task runs unnecessarily.

The piece focuses on diagnosing over-invocation rather than raw speed.

The article argues that a slow lint task is often not a performance problem in the task itself, but a workflow problem caused by running it too many times. Rather than assuming linting is inherently sluggish, the key takeaway is to check how often the task is triggered and whether it is being invoked unnecessarily. The central message is that reducing redundant executions can improve the overall experience more effectively than trying to optimize the lint process alone.

你的 Lint 任务并不慢，只是运行次数太多

你的 lint 任务看起来不慢，真正的问题是它被触发得太频繁。

重點摘要

文章指出，真正的问题在于重复执行。

Lint 性能看似不佳，可能是因为任务被不必要地触发。

重点在于排查过度调用，而不是单纯追求加速。

文章认为，lint 任务看起来很慢，往往不是工具本身性能不足，而是因为它被执行了太多次。作者提醒读者，与其直接把问题归因于 lint，不如先检查任务是否被重复触发、是否存在不必要的运行流程。核心观点是：减少冗余调用，通常比单纯优化 lint 本身，更能有效改善整体体验。

你的 Lint 任務不是很慢，只是執行次數太多

你的 lint 任務看起來不慢，真正的問題是它被觸發得太頻繁。

重點摘要

文章指出，真正的問題在於重複執行。

Lint 效能看似不佳，可能是因為任務被不必要地觸發。

重點放在排查過度呼叫，而非單純追求加速。

文章主張，lint 任務看起來很慢，往往不是因為工具本身效能差，而是因為它被執行了太多次。作者提醒讀者，與其直接把問題歸咎於 lint，不如先檢查任務是否被重複觸發、是否存在不必要的執行流程。核心觀點是：減少冗餘呼叫，通常比單純優化 lint 本身，更能有效改善整體體驗。