每日新聞摘要

In Kotlin Coroutines, error handling differs between launch and async because of their return behavior. launch is fire-and-forget: it doesn't return a value, so exceptions thrown inside it are not stored and propagate immediately, causing the exception to cancel the parent scope (fail-fast). async returns a Deferred (like a promise/future) that encapsulates either a successful result or an exception; exceptions raised inside async are captured and do not throw immediately. They are only rethrown when the caller invokes await() (or awaitAll()), which unwraps the Deferred and will propagate any stored exception at that point. Therefore, use launch for tasks where immediate failure should cancel the scope, and use async when you need a deferred result and want to control when exceptions surface by awaiting.

在 Kotlin Coroutine 中，launch 与 async 的错误处理有所不同：launch 属于 fire-and-forget，不返回值，内部抛出的异常没有保存位置，会立即抛出并取消父 scope（fail-fast）。async 返回 Deferred（类似 promise/future），内部的成功结果或异常会被封装，异常会被捕获而不会立即抛出，只有在调用 await() 或 awaitAll() 解包 Deferred 时才会重新抛出。因此，若需立即失败并取消范围可用 launch；若需延后获取结果并控制异常何时显现，则使用 async。

This article guides Android developers on why Firebase App Check matters and how to set it up. It notes the convenience of connecting Firestore, Realtime Database, and Storage, but warns that without App Check those services can be accessed or abused by unauthorized clients. The piece covers App Check’s purpose—attesting app authenticity and preventing misuse—and presents a practical setup workflow: enable App Check in the Firebase console, integrate the App Check SDK into your Android project, choose an attestation provider or use debug tokens for development, test thoroughly, and then enable enforcement. It also emphasizes monitoring and cautious rollout to avoid disrupting legitimate users while adding a protective layer to Firebase-powered apps.

本文面向使用 Firebase 的 Android 开发者，说明为何应启用 App Check 以及基本的设置方式。文章指出 Firebase（如 Firestore、Realtime Database、Storage）串接很方便，但若不验证客户端，后端服务可能遭到未授权访问或滥用；因此建议使用 App Check 来证明应用来源并防止滥用。文章概述了典型流程：在 Firebase 控制台启用 App Check、在 Android 项目中整合 App Check SDK、选择合适的 attestation 提供者或使用开发调试 token、在充分测试后再开启强制执行，同时建议监控与渐进式部署以避免影响合法用户。

This article (Part 4) explains how to master the low-level Animatable API in Jetpack Compose to implement sequential, gesture-driven, and highly precise animations by leveraging Kotlin Coroutines. It emphasizes using coroutine suspension to gain deterministic control over animation flows, enabling developers to pause, resume, and coordinate multiple animations programmatically. Working at the Animatable layer allows finer timing and interruptibility compared with higher-level primitives, making it suitable for scenarios that require explicit sequencing or tight gesture integration. The piece outlines practical patterns for suspending animation execution and integrating coroutine-based control with Compose, helping developers build smoother, more responsive UI motion with explicit, coroutine-friendly animation logic.

本文为系列第4篇，介绍如何在 Jetpack Compose 中掌握低级 Animatable API，并结合 Kotlin Coroutines 实现顺序化、手势驱动和高精度的动画控制。文章强调利用协程的可挂起机制，使动画流程可被明确暂停与恢复，从而以编程方式协调多个动画并提升可中断性与时序精度。与高级动画抽象相比，操作 Animatable 能取得更细致的时序与控制，适合需要明确序列或紧密集成手势的场景，并提供了与 Compose 结合的实用模式，帮助开发者构建更流畅、响应更灵敏的界面动效。

Manually entering one-time passwords (OTPs) is a common pain point in mobile onboarding, and requesting SMS permissions exacerbates user friction and privacy concerns. This article introduces Google's SMS Retriever API as a solution that can automatically capture OTPs sent via SMS without requiring the app to request SMS read permissions from the user. By using the API, developers can streamline verification flows, improve conversion rates, and reduce perceived intrusion. The post outlines the concept, benefits, and practical considerations for integrating SMS Retriever into Android apps, highlighting how it preserves user privacy while simplifying authentication. Developers looking to minimize permission prompts and improve onboarding UX will find this approach valuable.

手动输入一次性密码（OTP）是移动端入门流程中最令人沮丧的环节之一，而请求短信权限会进一步增加用户流失与隐私顾虑。本文介绍了 Google 的 SMS Retriever API，能在不向用户申请短信读取权限的情况下，自动获取短信中的 OTP，从而简化验证流程、提高转化率并减少干扰。文章说明该方案的概念与优势，并指出整合时需要注意的实践问题，帮助开发者在不获取完整短信访问权限的前提下，优化认证体验并保护用户隐私。

The author recounts diagnosing an app that suffered from excessive main-thread work and poor responsiveness. By profiling the application to locate hotspots, they discovered a single UI component that generated a disproportionate amount of main-thread activity. Swapping that component for a lighter alternative reduced main-thread work by roughly 30%, lowering CPU pressure and UI blocking without a large-scale rewrite. The account highlights the value of measurement: identifying the specific cause, evaluating alternatives, and making a focused change that delivered meaningful performance improvement. The article advocates using profiling tools to find dominant contributors to main-thread load and considering component-level replacements as a practical optimization strategy.

作者描述了在诊断应用性能问题时，发现主线程工作量过大导致界面卡顿。通过使用性能分析工具定位关键热区，确认是一个单独的 UI 组件占用了大量主线程资源。将其替换为更轻量的替代组件后，主线程工作量约减少 30%，降低了 CPU 压力与 UI 阻塞，而且不需要大规模重写代码。文章强调以测量为基础，识别主要负担来源并进行有针对性的调整，说明小范围的组件替换也能带来显著的性能提升。

This article addresses the problem of user interfaces being overlapped or obscured by system bars when building apps with Jetpack Compose. It explains why this issue matters—particularly as Android 15 enforces edge-to-edge layouts—and frames the implications for Compose layouts. The author outlines the need to account for system insets so content remains readable and interactable, and discusses considerations developers should keep in mind when designing Compose UIs that run on devices with varying system bar behaviors. The piece highlights the increased importance of proper inset handling under Android 15 and encourages adopting layout practices that respect system bars to ensure consistent visual and interaction quality across devices.

本文讨论在使用 Jetpack Compose 构建界面时，因系统栏（如状态栏或导航栏）导致界面元素被覆盖或遮挡的问题，并解释这一问题为何重要，尤其是在 Android 15 强制推行 edge-to-edge 布局的背景下。文章指出开发者需重视系统 inset 的处理，以确保内容在不同设备与系统栏行为下仍能正确显示与交互，建议采用能尊重系统栏的布局实践，从而在 Android 15 及其他版本间维持一致的视觉和交互体验。

This Medium post by Kamaldeep Kakkar is presented as a coroutine interview question focused on the difference between supervisorScope and SupervisorJob in Kotlin coroutines. The short excerpt indicates the piece is intended to prompt or answer an interview-style question and directs readers to continue reading on Medium for the full content. While the provided fragment does not include technical details, the title implies a comparative treatment of two coroutine constructs; the full article likely clarifies their roles, failure-handling behavior, and typical use cases for interview preparation. Readers interested in concrete examples or deeper explanation are advised to follow the link to the complete Medium article for the author’s full discussion.

本文为 Kamaldeep Kakkar 在 Medium 发布的一则短文，标题为 supervisorScope vs SupervisorJob in Kotlin Coroutines，以“Coroutine Interview Question”呈现并引导读者继续在 Medium 阅读完整内容。摘要中并未包含具体技术细节，但标题表明文章聚焦于比较两种协程构造。文章似乎旨在帮助面试准备或澄清两者在失败处理与使用场景上的差别；欲获得完整解析、示例与实现细节，请访问 Medium 上的完整文章。

Kotlin was created by JetBrains in 2011 and has become especially popular in the Android ecosystem. This article examines why, despite its technical strengths and rising visibility, Kotlin is not yet universally known among developers. It reviews possible contributing factors such as entrenched Java codebases and corporate inertia that slow migration, differences in education and community awareness, the learning curve for teams, uneven tooling or platform support outside Android, and the gradual nature of technology adoption in industry. The piece argues that popularity does not immediately translate into universal familiarity: languages can be widely respected yet remain unfamiliar to many developers because of legacy systems, hiring patterns, and ecosystem fragmentation. Ultimately the article frames Kotlin’s situation as one of growing but uneven adoption rather than a failure of the language itself.

Kotlin 由 JetBrains 在 2011 年开发，在 Android 生态中迅速走红。本文探讨为何即便具备技术优势和日益可见度，Kotlin 仍未被所有开发者熟知。文章提出若干可能因素：既有 Java 代码库和项目阻碍迁移、企业与团队的惯性、教育与社区的能见度不足、团队学习曲线，以及 Android 之外平台或工具支持的不均衡。作者指出，流行度上升不等于立即普及——受制于遗留系统、招聘与生态碎片化，采用通常是渐进且不均匀的，因此 Kotlin 虽受认可但仍有很多开发者尚未接触。

This article explains how to use Temporal's Workflow Engine with the Spring Boot integration of the Java SDK. It outlines the integration features—automatic registration of workflows and activities via dependency injection, declarative worker queue configuration, and an auto-configured WorkflowClient bean—and shows the minimal Maven dependency and spring.temporal properties needed to run locally or switch environments. Using an Order processing example, it walks through defining workflow, signal, and query interfaces, activity interfaces and implementations, and a workflow implementation that demonstrates parallel branches with Async.function() and coordination with Workflow.await(). The piece also describes a REST API layer that hides Temporal details, how to create and start workflows via WorkflowClient, and approaches to testing using the in-memory test server with the ability to fast-forward time for timeout scenarios. Code examples and testing patterns are provided for practical implementation.

文章介绍了如何将 Temporal 工作流引擎与 Spring Boot 集成，说明该模块带来的便捷：通过标准依赖注入自动注册工作流和活动，声明式配置 worker 队列，并将 WorkflowClient 自动作为 Bean 提供。以订单处理为例，展示了 workflow、signal 与 query 接口的定义，activities 接口与具体实现，以及如何用 Async.function() 实现并行分支与用 Workflow.await() 等待异步结果或超时条件。还介绍了用 REST API 隐藏 Temporal 细节、利用 WorkflowClient 启动 workflow 的方式，以及在内存测试服务器中使用 sleep() 快进时间来测试超时与补偿逻辑的实用测试方法。示例代码可供参考。

RestTestClient is a concise, builder-style HTTP test client introduced in Spring Framework 7.0 that simplifies integration testing in Spring Boot projects. It supports multiple binding modes — MockMvc, live server, WebApplicationContext, RouterFunction(s), or controllers — and offers a configurable builder for base URL, default headers and cookies. Practical examples show GET/POST requests, status and body assertions, JSONPath checks, and custom assertions via consumeWith. RestTestClient instances are immutable and thread-safe once built, while builders are mutable and not thread-safe. Common pitfalls include choosing the wrong binding (yielding false negatives) and subtle behavioral differences from WebTestClient (e.g., null vs empty body handling). Best practices: pick the appropriate binding, create fresh builders or reuse built clients, and explicitly assert empty bodies for robust tests.

RestTestClient 是 Spring Framework 7.0 新增的简洁构建式 HTTP 测试客户端，可在 Spring Boot 项目中以轻量方式执行集成测试。它支持多种绑定模式（MockMvc、实际服务器、WebApplicationContext、RouterFunction 或 Controller），並提供可配置的 builder，例如 baseUrl、默认 header 与 cookie。文章示例展示了基本請求、狀態與主體断言、JSONPath 校验，以及使用 consumeWith 的自定义断言。已构建的 RestTestClient 实例不可变且线程安全；builder 则是可变且非线程安全。常见陷阱包括选择错误的绑定导致假阴性，以及与 WebTestClient 在空响应处理上的细微差别。建议选择合适的绑定、为每个测试创建 builder 或重用已构建实例，并对空响应进行显式断言以确保测试可靠。

This article highlights the importance of Content Providers in Android and frames them as a powerful but often overlooked component. Centered on Kotlin, it presents a real-world example that demonstrates how multiple apps can synchronize login state using a Content Provider-based approach. The piece aims to clarify when and why to use Content Providers for cross-app data sharing, discuss practical considerations for implementing a multi-app login sync, and help Android developers better understand integration patterns for app interoperability. Overall, the article serves as a focused introduction and applied example to make Content Providers more accessible to developers building multi-application ecosystems.

本文强调 Content Providers 在 Android 生态中的重要性，并指出它们常被低估。文章以 Kotlin 为主，展示一个真实世界的示例，说明如何通过 Content Provider 的方式在多个应用之间同步登录状态。内容旨在阐明何时以及为何使用 Content Providers 来共享跨应用数据，讨论实现多应用登录同步时的考虑要点，并帮助 Android 开发者理解应用间集成的常见模式和应用情境，使这一组件对开发者更具可用性与可理解性。