每日新聞摘要

This article shows how to model theme selection in Compose Multiplatform without misrepresenting the user’s choice. Instead of a single boolean, it uses three states: System, Light, and Dark, so the app can distinguish between a system-driven theme and an explicit user selection. The implementation stores settings as one JSON blob with multiplatform-settings and kotlinx.serialization, exposes a single source of truth through StateFlow, and protects read-modify-write updates with a mutex. It also keeps display labels in the UI layer for localization, and includes tests for missing, corrupted, and unknown stored values. The result is a small settings foundation that is safer to evolve and easier to extend to future preferences.

本文展示了如何在 Compose Multiplatform 中正确表达主题选择，避免把用户设置误写成单一布尔值。作者改用 System、Light、Dark 三种状态，区分系统主题与用户明确选择。数据层使用 multiplatform-settings 配合 kotlinx.serialization 将设置保存为一个 JSON Blob，并通过 StateFlow 提供唯一数据来源，更新时再用 mutex 保证读写一致性。展示文案留在 UI 层处理，便于本地化，也避免直接暴露 enum 名称；同时加入测试，覆盖缺失、损坏 JSON 和未知存值的安全回退。

The author investigated why Qwen2.5-1.5B-Instruct ran far slower than expected on a Google Pixel 4. Theoretical estimates suggested 30–60 tok/s, but measured generation was only 0.5 tok/s. After ruling out thread count and page eviction, the key issue turned out to be missing ARM optimization flags during Android cross-compilation: ggml fell back to baseline ARMv8-A without dotprod or fp16, slowing quantized matrix multiplication. Even after confirming the optimized instructions were generated, performance remained poor, so the project was shipped with the limitation clearly documented. The post closes with practical lessons for debugging on-device inference and avoiding API drift in llama.cpp.

作者在 Google Pixel 4 上离线运行 Qwen2.5-1.5B-Instruct 时，发现生成速度远低于理论预期。按内存带宽和算力估算，这台设备理论上应达到 30–60 tok/s，但实测只有 0.5 tok/s。排除线程数和 mmap 页面被回收后，关键问题出在 Android cross-compiling 时缺少 ARM 优化参数，导致 ggml 退回到基础 ARMv8-A，没有启用 dotprod 和 fp16。即使确认优化指令已生成，性能依旧没有根本改善，因此项目最后选择如实记录限制并继续发布。

This article compares Kotlin coroutines and Java virtual threads as two modern JVM approaches to concurrency. It explains why traditional OS-thread-based models hit scalability limits, then outlines how coroutines use suspension, dispatchers, and structured concurrency, while virtual threads rely on JVM-managed scheduling to make blocking I/O cheap. The article also contrasts their ergonomics, debugging, error handling, and ecosystem fit, noting that coroutines suit Kotlin and high-concurrency reactive workloads, whereas virtual threads are a natural fit for Java projects and traditional server patterns. It concludes that both are valuable and can coexist in modern backend systems.

本文对比了 Kotlin 协程与 Java 虚拟线程这两种现代 JVM 并发方案。文章先说明传统基于 OS 线程的模型在可扩展性上的瓶颈，再介绍协程如何借助挂起、dispatcher 和结构化并发工作，以及虚拟线程如何通过 JVM 管理调度，让阻塞式 I/O 也能保持良好扩展性。文中还比较了两者在语法、调试、异常处理和生态整合方面的差异，并指出协程更适合 Kotlin 与高并发响应式场景，而虚拟线程更适合 Java 项目和传统服务器模式。最后强调，两者都具有价值，并且可以在现代后端系统中并存。

This article is presented as a practical guide for Android developers interested in using AI more effectively. It points to AI Skills, Copilot, Navigation 3, and better context as part of a more efficient AI-assisted development workflow. The piece frames Android expertise as a way to change how people interact with AI, rather than relying on oversized prompts.

本文从 Android 开发者的实践角度出发，讨论如何更有效地使用 AI。内容提到 AI Skills、Copilot、Navigation 3 以及更好的上下文，作为提升 AI 辅助开发效率的方向。文章主旨是：与其依赖冗长提示词，不如利用 Android 技能和上下文，改变与 AI 协作的方式。

The provided input does not include the article body, only the title, author, link, and a brief line inviting readers to continue on MobileByteSensei. Because the substantive content is missing, no faithful technical summary or article-specific highlights can be derived without risking invention. The only verifiable information is the title, which suggests a discussion about Kotlin `expect` declarations and the implications of defining them across platforms, but the input itself does not state any details, arguments, examples, or conclusions.

这份输入没有提供文章正文，只有标题、作者、链接，以及一行引导读者前往 MobileByteSensei 继续阅读的文字。由于缺少实质内容，无法在不臆测的情况下生成忠实的技术摘要或要点。唯一可以确认的是标题所指向的主题，似乎与 Kotlin 的 `expect` 声明有关，但输入本身并未说明文章的论点、示例或结论，因此不宜进一步推断。

The article argues for a deliberately unexciting Android stack for new projects in 2026: Kotlin 2.4, Compose, Flow, and Room. Rather than chasing novelty, the author presents this combination as the setup they would choose if starting a new app tomorrow. The emphasis is on practicality and a modern architecture that is simple, familiar, and workable, without claiming any extra features or performance advantages beyond that recommendation.

文章主张 2026 年的新 Android 项目可以采用一套刻意朴素、但实际可行的技术栈：Kotlin 2.4、Compose、Flow 和 Room。作者强调，如果明天要从零开始做一个新应用，自己会选择这套配置。全文重点不在追逐新奇，而在于把它视为一种务实、熟悉且可落地的现代架构选择，并没有宣称额外优势或性能数据。

Nav3 is now stable, and Google recommends migrating to it. In this short post, the author frames the question around back stack ownership and says they’ll share their opinion on when it makes sense to use Navigation 3 versus Navigation Compose. The piece does not provide detailed implementation guidance in the excerpt, but it clearly positions Nav3 as the recommended direction while acknowledging that the right choice may depend on the case.

Nav3 已经稳定，Google 也建议开发者迁移。本篇围绕 back stack 的归属展开，作者表示会分享自己对 Navigation 3 与 Navigation Compose 在哪些场景下更合适的看法。截文没有展开具体实现细节，但已经清楚表明 Nav3 是推荐方向，同时也暗示具体选型仍要结合实际情况判断。

The article points to a coming shift in Android development: as opting out of large screens goes away, apps need to be designed to adapt rather than assume a phone-shaped display. It uses the Pixel Fold as a reminder that an app can look correct on a folded device but still break or feel incomplete when unfolded. The central message is that Android developers should prepare for larger, adaptive layouts and make sure their apps behave well across form factors.

本文指出 Android 开发正在迎来变化：随着“退出大屏幕适配”的选项逐渐消失，应用不能再默认只面对手机尺寸的界面，而必须具备自适应能力。作者以 Pixel Fold 为例说明，应用在折叠状态下可能看起来正常，但展开后就可能暴露出布局或体验问题。文章的核心信息是，Android 开发者需要尽早为更大的屏幕和不同形态的设备做好准备。

This article introduces the first part of a series on how a Kotlin Android app works. Based on the provided excerpt, it points readers toward Kotlin basics, the Android lifecycle, MVVM, and coroutines as the main topics. The post appears to be an entry point for Android developers who want a structured overview of these core concepts.

这篇文章是系列的第一部分，主题是 Kotlin Android 应用如何运作。根据提供的内文摘录，文章聚焦于 Kotlin 基础、Android 生命周期、MVVM 与 coroutines 等核心概念，作为 Android 开发者理解这些主题的入门导览。

The article describes a mismatch between a commit message and what the author saw in a build file. Three apps were pinned to version 1.7.8 because of a single sentence in that message, which suggested the Compose BoM had dropped material-icons-extended. The author later tested that claim eight weeks after the fact and found the situation did not match the build file’s implication. The piece centers on this confusion and the need to verify dependency changes carefully before assuming a removal happened.

这篇文章讲的是提交信息与构建文件之间的误解。作者因为提交信息里的那一句话，把三个应用锁定在 1.7.8，并据此以为 Compose BoM 已经移除了 material-icons-extended。直到八周后作者才实际测试这条说法，发现情况并不像构建文件所暗示的那样。文章强调，在判断依赖变更时，不能只凭一句提交说明就认定某个功能或模块已经被移除。

This article continues the series on designing Compose components by examining receiver scopes in practice. It explains how these scopes actually behave and why @DslMarker cannot be treated as optional when building DSL-like APIs in Compose. The piece is aimed at helping developers design component APIs that are clearer and less error-prone by understanding how receivers interact. It is a focused technical discussion about Compose component design rather than a general overview.

本文延续 Compose 组件设计系列，聚焦接收者作用域在实际中的运作方式，并说明在构建类 DSL 的 Compose API 时，@DslMarker 不能被视为可有可无。文章以组件 API 设计为重点，帮助开发者理解不同 receiver 之间的交互，从而打造更清晰、较不易误用的接口。这是一篇关于 Compose 组件设计的技术讨论，而不是概览性介绍。

This article explores builder DSL design in Compose components, using LazyColumn’s item {} as the central example. It explains how the item builder works under the hood and examines the trade-offs between registering content and composing it directly. The piece is aimed at helping Kotlin and Compose developers understand the mechanics behind declarative APIs and how builder-style structures shape component design. The article is a continuation of the “Designing Compose Components” series and stays focused on the relationship between API design and implementation behavior.

本文探讨 Compose 组件中的 builder DSL 设计，并以 LazyColumn 的 item {} 作为核心示例，说明这个 builder 在底层如何运作，以及注册内容和直接组合内容之间的取舍。文章主要帮助 Kotlin 与 Compose 开发者理解声明式 API 背后的机制，并看到 builder 风格的结构如何影响组件设计。这篇内容延续 “Designing Compose Components” 系列，重点放在 API 设计与实现行为之间的关系。

The article introduces the Open/Closed Principle (OCP) in Android: software should be open for extension but closed for modification. In practice, this means adding new functionality without repeatedly changing code that already works, helping keep existing behavior stable. The piece positions OCP as a design guideline for building maintainable Android code, emphasizing extension through new code rather than edits to proven implementations.

本文介绍 Android 中的开闭原则（OCP）：软件应当对扩展开放、对修改封闭。实践中，这意味着在不反复改动已有且已经能正常工作的代码的前提下添加新功能，从而保持既有行为稳定。文章将 OCP 视为 Android 可维护性设计准则，强调通过新增代码来扩展功能，而不是修改已验证可用的实现。

Muffle was built to solve a simple annoyance: manually changing sound settings based on where the user is. The article explains why Android geofencing is a better fit than polling location frequently, because GeofencingClient lets Google Play Services handle the heavy work and wake the app only on enter or exit events. It also describes practical constraints, including 30 to 120 seconds of trigger latency, false positives in dense urban areas, Doze mode restrictions, and the need for a ForegroundService, confidence radius, and hysteresis. The main lesson is to work with Android’s power model, not against it, and to prioritize reliability over millisecond-level precision.

Muffle 的目标是解决用户在不同场景下手动切换声音设置的烦恼。文章指出，在 Android 上使用 GeofencingClient 比持续轮询定位更合适，因为它把重活交给 Google Play Services 和系统，只在进入或离开预设范围时唤醒应用，因此更省电。但这也带来限制：触发通常会有 30 到 120 秒延迟，密集城市环境可能因基站信号而误判，还要面对 Doze mode、ForegroundService、confidence radius 和 hysteresis 等实现问题。作者强调，背景任务开发应顺应系统电量管理，把可靠性放在毫秒级精度之前。

Getting an AI agent to act is easy; knowing whether the action truly worked is harder. The article argues that an agent’s self-report of success is unreliable because completed steps do not guarantee the intended outcome. Instead, systems should verify state after dispatch using explicit thresholds such as state changes, timestamps, and expected artifacts. It introduces three statuses—CONFIRMED, FAILED, and DENIED_UNRESOLVED—and emphasizes that unverifiable outcomes should not silently degrade into success. Using messaging as an example, the piece shows how to confirm delivery by checking sent records and timestamps, then explains why this matters even more for on-device agents, where failures are visible to users immediately.

让 AI agent 执行动作并不难，真正困难的是判断它是否真的做对了。文章指出，agent 的自我报告不能当作事实依据，因为步骤跑完不代表目标已达成。正确做法是在派发前定义成功条件，派发后再根据系统状态、时间戳与预期产物进行验证，并以 CONFIRMED、FAILED、DENIED_UNRESOLVED 区分结果。以消息发送为例，应检查已发送记录与时间是否符合要求；若无法验证，就必须明确标记为 DENIED_UNRESOLVED。对于设备端 agent 来说，透明地失败比自信地搞错更重要。

The provided text is only a brief pointer to the full Medium article, titled "Daily Kotlin: Null Safety, Safe Calls, and the Elvis Operator." It identifies the topic but does not include the article’s technical content, examples, or explanations. As a result, the supplied text confirms only that the piece is about Kotlin null safety and related language features, while the actual discussion must be read on Medium.

当前提供的内容只是指向 Medium 完整文章的提示，标题为「Daily Kotlin: Null Safety, Safe Calls, and the Elvis Operator」。正文仅说明主题和阅读入口，没有包含具体的技术讲解、示例或分析。因此，从这段文字里只能确认文章聚焦于 Kotlin 的空安全及相关语法，完整内容仍需到 Medium 查看。

The provided content is only a brief teaser for a Medium article titled “fun interface and SAM Conversion: When a Lambda Becomes an Interface” by Ahmed Elkrrai. It does not include the actual article body, so there are no technical explanations, examples, or conclusions available to summarize. The only visible line suggests the topic is something readers may have written many times before, but the rest of the discussion is behind the Medium continuation link.

目前提供的内容只是 Medium 文章《fun interface and SAM Conversion: When a Lambda Becomes an Interface》的开头引言，作者为 Ahmed Elkrrai。正文没有展开任何技术说明、示例或结论，因此无法从这段文本提炼出更多具体信息。可见的唯一一句话只是提示读者，这个场景可能是大家经常写到的代码片段，其余内容需要通过 Medium 链接继续阅读。