每日新聞摘要

Cobrainer describes how it built production AI features on the JVM with Kotlin rather than adding a separate Python stack. The company uses one Kotlin monorepo with shared types, Koog for agent and prompt orchestration, Exposed for SQL, coroutines for non-blocking I/O, and kotlinx.serialization for structured contracts. Koog stood out because it stays close to Kotlin, making control flow, sealed types, and provider capabilities explicit. In production, structured output powers job-architecture generation, while fallback chains, circuit breakers, and LLM observability handle provider throttling and failures. The team also reports a 5× throughput gain after removing blocking code from coroutine paths and emphasizes contract tests and careful security integration for its agentic platform.

Cobrainer 介绍了他们如何在 JVM 上用 Kotlin 构建生产级 AI，而不是再引入一套 Python 技术栈。团队采用单一 Kotlin monorepo，实现端到端类型共享，并用 Koog 负责 agent 与 prompt 编排、Exposed 处理 SQL、coroutines 支持非阻塞 I/O、kotlinx.serialization 定义结构化契约。Koog 的价值在于贴近 Kotlin 本身，让控制流、sealed types 和 provider 能力差异都保持清晰可见。生产中，结构化输出支撑 Job Architecture 生成；当 provider 限流或失效时，则依赖 fallback chain、circuit breaker 和 LLM 观测来保持稳定。团队还指出，清理 coroutine 路径中的 blocking code 后，吞吐量提升了 5×。

This article describes the design of an Android camera app that guides the user to move the phone until a tapped visual detail aligns with a composition guide. Rather than use object detection, the app tracks the exact patch the user tapped, using normalized cross-correlation on small grayscale frames and rejecting weak or ambiguous matches. A gyroscope-based rotation history helps bridge fast turns when matching fails, but estimates are strictly treated as “maybe” and never allowed to become green, auto-capture, or feedback. The post also details freshness rules for sensor, camera, and focus data, a shared normalized coordinate system across preview and overlay, performance notes from emulator runs, and a testing strategy built around JVM tests and scene replays.

这篇文章介绍一个 Android 相机 App 的设计：用户点选画面中的细节后，App 会持续追踪那一小块图像，并引导用户移动手机，直到该细节对齐构图辅助线。作者没有采用对象检测，而是以归一化互相关在小型灰度帧上追踪被点击的区域，并排除低方差、模糊或歧义过高的匹配。当快速转动导致图像匹配失败时，系统会用陀螺仪旋转历史来预测位置，但这些估计只能算“可能”，不能变成绿色、不能触发自动拍摄或反馈。文章还说明了传感器和相机数据的新鲜度规则、共享的归一化坐标系、模拟器上的性能观察，以及以 JVM 测试和场景重放为主的测试方法。

This article shows how to build a Kotlin AI agent that cannot issue refunds without human approval. Using Telar, it introduces a tool-based agent, then adds an interrupt before tool execution so risky calls can be reviewed, approved, or declined. The pause can be checkpointed to survive restarts, and the same flow can be tested without any model by using a scripted ChatModel. Finally, the article shows how to enforce hard business rules in graph structure instead of prompts, so old orders never reach the model at all. The result is ordinary, typed, testable Kotlin around an unpredictable model.

本文演示如何用 Kotlin 构建一个在退款前必须获得人工批准的 AI agent。作者以 Telar 为例，先搭建基于工具调用的 agent，再在工具执行前设置中断点，让高风险操作可以被审核、批准或拒绝。这个暂停状态可以通过 checkpoint 持久化，服务重启后还能继续处理；同时也能用 scripted ChatModel 在没有模型和网络的情况下进行单元测试。最后，文章说明如何把超过 30 天的订单等硬性规则放进图结构里，而不是交给 prompt，从而让模型根本接触不到这些请求。

Onetap is an Android app that converts payment notifications from user-selected banking or wallet apps into expense entries, without using a bank login or bank API. The post explains the design choices behind its notification listener, including filtering by package name before reading content, dropping OTPs on device, and masking sensitive identifiers before sending text to a language model. It also covers how the app handles ambiguous currency data, avoids duplicate records, writes to disk before network calls, retries with WorkManager, and recovers missed notifications after reconnecting. The author notes Android-specific listener issues, including Xiaomi/HyperOS behavior, and describes debug testing with shell-posted notifications.

Onetap 是一款 Android 应用，可以把用户选定的银行或钱包 App 发出的付款通知转换为支出记录，而且不需要银行登录或银行 API。文章介绍了它的通知监听设计：先按 package name 过滤，再在设备端丢弃 OTP，并在送入语言模型前遮罩卡号、账号等敏感信息。作者还处理了币种歧义、避免重复记录、先写入加密 inbox、用 WorkManager 重试，以及监听器断开或重连后的补抓逻辑，并提到 Xiaomi/HyperOS 的特殊问题和通过 shell 发布通知进行测试的方法。

The author, an iOS developer shipping a Kotlin Multiplatform app, asks what would happen if shared logic were written in Swift and run on Android instead of Kotlin running on iPhone. The article explains that Swift 6.3 marks the first official Swift SDK for Android from the open-source Swift project, not Apple, and that it is a cross-compilation kit rather than a full Android UI stack. It covers what ships, what is missing, how swift-java bridges Swift and Kotlin through JNI, and how the approach mirrors KMP from the opposite direction. The piece closes with practical guidance on when the SDK makes sense and when KMP still fits better.

作者是一名正在用 Kotlin Multiplatform 交付应用的 iOS 工程师，他从自己的项目出发提出一个问题：如果共享逻辑改用 Swift 在 Android 上运行，而不是 Kotlin 在 iPhone 上运行，会怎样。文章说明，Swift 6.3 起开源 Swift 项目提供了 Android 的官方 SDK，但这不是 Apple 直接为 Android 发布 Swift，也不是完整的 UI 方案。正文介绍了 SDK 的工作方式、已包含与缺失的部分，以及 swift-java 如何通过 JNI 实现 Swift 与 Kotlin 的双向桥接，并逐项对比 KMP。最后也给出哪些团队现在适合尝试、哪些场景暂时还不适合。

React Native allows teams to use one JavaScript codebase for both iOS and Android, but the article points out that experienced mobile engineers eventually run into limitations with that approach. The piece focuses on bridging React Native with native iOS and Android screens, suggesting a practical need to combine cross-platform code with platform-specific UI where necessary. The excerpt itself does not provide implementation details or outcomes, only the article’s framing and problem statement.

React Native 允许团队用一套 JavaScript 代码库同时面向 iOS 和 Android，但文章指出，经验丰富的移动工程师最终都会碰到这种方案的边界。本文重点讨论如何将 React Native 与原生 iOS、Android 界面衔接起来，暗示在某些场景下仍需要把跨平台代码与平台专属 UI 结合使用。当前摘录并未给出具体实现细节或结果，只呈现了文章的切入点与问题背景。

This article centers on Kotlin object declarations and companion objects, framing them as key tools for implementing thread-safe singletons, companion factories, and anonymous object expressions. It positions the topic in the context of Kotlin Multiplatform and emphasizes mastering these patterns rather than introducing unrelated APIs or claims. The available text is brief, but it clearly signals a practical discussion of how Kotlin’s object-related features are used in real code across platforms.

本文主题是 Kotlin 的对象声明与 companion object，重点介绍如何利用这些机制实现线程安全的单例、companion factory，以及匿名对象表达式。结合标题和正文可见，文章放在 Kotlin Multiplatform 的语境下，强调对这些对象相关模式的理解与运用，而不是引入其他 API 或未给出的性能结论。

This article describes a problem in a Compose Multiplatform iOS flow where leaving a photo review screen can cause an upload to be cancelled when the screen is disposed. The premise is simple: closing the screen should not interrupt the rest of the app experience. The piece focuses on this upload interruption issue and the need to keep the transfer going even after the UI leaves the screen.

本文说明在 Compose Multiplatform 的 iOS 流程中，用户离开照片审阅界面时，界面被销毁可能导致上传被取消。作者强调，关闭页面不应中断应用的后续操作，重点是处理这种上传中断问题，使传输在 UI 离开该页后仍能继续进行。

The article points out a small but important difference across four switch branches in the app: three branches return false when configuration reading fails, while one returns null. That single distinction is presented as the core of the safety design, showing how a return value can communicate different failure semantics. Rather than treating all failures the same, the code uses the return type and branch behavior to express intent and constraints more precisely.

本文指出，应用中的四个 switch 分支表面相似，却有一个关键区别：当配置读取失败时，三个分支返回 false，只有一个分支返回 null。作者强调，正是这一点返回值差异构成了整体的安全设计，使失败语义能够被更精确地表达，而不是把所有错误都当作同一种情况处理。

The article argues that Android projects may already have a meaningful, double-digit percentage improvement in cold start time available through Baseline Profiles, without requiring new code paths or major changes. It focuses on the practical workflow: generating profiles, verifying that they are correct, and keeping the process honest so the results remain trustworthy as the project evolves. The piece frames Baseline Profiles as an opportunity to reduce startup latency while avoiding claims that are not backed by real verification.

文章指出，Android 项目中可能已经存在一项可观的冷启动时间改进机会，幅度可达两位数百分比，而且不需要新增新的代码路径或大幅改动。文章重点放在实践流程：如何生成 Baseline Profiles、如何验证其正确性，以及如何在项目演进过程中保持结果可信，避免只依赖未经验证的说法。

This article points out that Jetpack Compose screens may redraw much more often than developers expect, and that instability in UI state can be a major cause. Based on the title and teaser, it centers on 12 common stability mistakes that lead to unnecessary recomposition and make the UI draw twice. The piece appears to be aimed at helping developers understand and avoid those pitfalls when working with Jetpack Compose.

本文指出，Jetpack Compose 的界面重绘次数可能远超开发者预期，而 UI 状态不稳定是导致重组过于频繁的重要原因之一。根据标题和简介可知，文章聚焦 12 个常见的稳定性错误，这些问题会带来不必要的重组，甚至让 UI 重绘两次。文章意在帮助开发者在使用 Jetpack Compose 时识别并避开这些陷阱。

This article discusses the challenge of test recording in Android applications that are built primarily with Jetpack Compose but still include XML Views. The author focuses on the gap in tooling for capturing user interactions across both UI systems and describes the effort to build an interaction recorder that can work in a mixed Compose-and-Views environment. The piece frames this as a practical tooling problem rather than a broader change to Compose itself.

这篇文章讨论了以 Jetpack Compose 为主、但仍包含 XML Views 的 Android 应用在测试录制方面存在的工具缺口。作者指出，现有工具难以同时捕捉两种 UI 系统中的用户交互，因此尝试构建一个可在混合式 Compose 与 Views 环境中工作的交互录制器。文章强调的是一个实际的工具问题，而不是对 Compose 本身提出更广泛的改动。

The article explains how the author built Muffle, an offline Android geofencing system that automatically adjusts phone sound settings based on location. Rather than polling location every few minutes, the app uses GeofencingClient so the system handles boundary detection more efficiently and conserves battery. To keep geofences active under background limits, the implementation relies on a foreground service and a lightweight PendingIntent receiver that reads routine data from a local Room database. The author also describes practical issues such as coarse network-based location in dense cities, unreliable triggers with overly small radii, and geofences being cleared after device reboot. To address these, the app adds a visual radius editor, warning messages, and BOOT_COMPLETED re-registration. The main lesson is to work with Android’s constraints, keep logic local, and avoid heavy cloud dependencies when building location-based features.

本文分享作者为 Muffle 构建离线 Android 地理围栏系统的过程，让手机能根据位置自动切换静音与音量设置。作者最初尝试每隔几分钟轮询一次定位，但很快发现这会频繁唤醒 GPS、非常耗电，因此改用 GeofencingClient，让系统负责边界检测。为了应对后台限制，方案加入前台服务和常驻通知，并通过轻量的 PendingIntent receiver 从本地 Room 数据库读取规则。作者还提到，基于网络的定位在高密度城市里可能不够精确，半径过小又会导致触发不稳定；另外，设备重启后 geofence 也可能被清除，因此需要用 BOOT_COMPLETED 重新注册。核心结论是：顺着 Android 的系统约束来设计，把逻辑尽量留在本地，才能做出省电且稳定的定位功能。

Most duplicate-dispatch bugs in AI agents are not caused by missing retry guards or broken idempotency keys, but by treating two independent questions as one field: whether dispatch evidence exists, and whether that evidence satisfies the intended outcome. The article proposes a two-axis model with DeliveryState and AcceptanceState, enforced by state-machine rules so acceptance cannot be evaluated before delivery is confirmed. This separation lets systems distinguish unresolved delivery from real failure, preventing premature retries that create duplicates. Instead, unresolved cases go to reconciliation, confirmed mismatches are fixed and re-run, and each dispatch keeps its own artifact binding across retries and restarts.

本文指出，AI agent 的多数重复派发问题，并不是缺少 retry guard 或 idempotency key，而是把两个独立问题错误地合并成了一个状态字段：是否已有派发证据，以及该证据是否满足预期结果。作者提出由 DeliveryState 和 AcceptanceState 组成的双轴模型，并用状态机规则保证先确认投递、再评估接受，避免在未确认时就进入重试。这样可以区分“尚未确认”和“真正失败”，未解析状态先进入 reconciliation，语义不匹配则修正后再派发，同时保留每次 dispatch 的独立绑定。

This case study describes how an Android project hit dependency conflicts after updating to the Compose BOM 2024.12.01 in a Bazel-based build. The author explains that Bazel’s Bzlmod uses Minimal Version Selection, unlike Gradle’s default newest-version-wins behavior, so conflicts can surface when no single version satisfies every request. Simply setting version_conflict_policy = "pinned" was not enough. The actual workaround was to run the Maven pinning flow, inspect the generated maven_pin.txt log for conflicting libraries, and then use maven.artifact overrides in MODULE.bazel to force compatible versions. After iterating through several libraries, the build succeeded again. The post ends by noting that Bazel’s deterministic model is useful, but rule updates such as rules_android and rules_kotlin can be more difficult to manage, especially as newer Compose BOM versions raise Kotlin requirements.

作者在一个使用 Bazel 构建的 Android 项目中更新 Compose BOM 2024.12.01 后，遭遇了依赖冲突。文章解释了 Bazel 的 Bzlmod 采用 Minimal Version Selection，与 Gradle 默认的“选择最新版本”策略不同，因此当多个依赖要求不同版本时，冲突更容易暴露。仅添加 version_conflict_policy = "pinned" 并不能消除错误；正确流程是先运行 Maven pinning，导出完整日志到 maven_pin.txt，再从日志中定位冲突库，最后在 MODULE.bazel 中使用 maven.artifact 手动覆盖版本。经过多轮排查与调整后，构建恢复成功。作者同时指出，Bazel 的确定性和可重现性很有价值，但 rules_android、rules_kotlin 等规则更新本身也可能带来额外的配置复杂度。

The article explains why Kotlin companion objects have long been used for class-level constants and factory methods, while also noting their singleton nature and Java interop friction. It introduces Kotlin 2.5’s experimental companion blocks and companion extensions, which compile to native static-like members on the JVM. Companion blocks drop the object keyword and cannot implement interfaces, while companion extensions allow adding static-like properties and functions to classes from outside, including external or SDK types. The post also shows the required preview repository setup and compiler flags for trying the feature in 2.5.0-Beta1.

文章回顾了 Kotlin 长期使用 companion object 来组织类级常量和工厂方法，但它在底层其实是单例对象，因此可能带来内存开销，并在与 Java 互操作时需要处理 @JvmStatic 等细节。Kotlin 2.5 以实验性形式引入 companion block 和 companion extension：前者去掉 object 关键字，直接编译为 JVM 上的原生 static 成员；后者允许从类外为现有类添加静态风格的属性和函数，甚至可用于外部依赖或 Java SDK 类型。文中还说明了在 2.5.0-Beta1 中启用预览仓库和编译器标志的方法。

This article traces how Flow collection in Jetpack Compose evolved from simple state conversion to lifecycle-aware UI updates. It starts with collectAsState(), which is easy to use but does not stop collecting when the Android lifecycle drops below STARTED. It then explains Lifecycle 2.4.0 APIs such as launchWhenStarted(), repeatOnLifecycle(), and flowWithLifecycle(), which improved safety but still required more boilerplate. Finally, it introduces collectAsStateWithLifecycle(), the recommended default for most Compose screens. The article also clarifies an important distinction: stopping collection in the UI does not always stop upstream work or data refreshes, since that behavior depends on how the Flow is built.

本文梳理了 Jetpack Compose 中 Flow 收集方式的演进：从最初易用的 collectAsState()，到具备生命周期感知的 UI 更新。collectAsState() 虽然可以直接把 Flow 转成 Compose State，但当 Android 生命周期低于 STARTED 时不会自动停止收集，应用退到后台后仍可能继续执行。随后文章介绍 Lifecycle 2.4.0 的 launchWhenStarted()、repeatOnLifecycle() 和 flowWithLifecycle()，它们提升了安全性，却依然需要更多样板代码。最终，collectAsStateWithLifecycle() 把常见模式整合为单一 API，成为多数 Compose 屏幕更清晰的默认选择；同时文章强调，停止 UI 收集并不等于停止上游工作或数据刷新。