每日新聞摘要

This article shows how to build an Excel download API with Spring Boot and TBEG after adding a single dependency. It explains that TbegAutoConfiguration registers ExcelGenerator automatically and binds tbeg.* settings from application.yml, so no extra @Bean or @EnableXxx setup is needed. The post then demonstrates service-layer generation with generate() and generateToFile(), controller-based downloads using ResponseEntity<Resource>, streaming responses with generateToStream() and StreamingResponseBody, and asynchronous report generation with submitToFile() plus ExcelGenerationListener callbacks. It also covers JPA Stream integration, noting that @Transactional is required to keep the stream open during generation, and finishes with service and controller tests using XSSFWorkbook and MockMvc.

本文介绍如何在 Spring Boot 中结合 TBEG 构建 Excel 下载 API，只需添加一个依赖即可自动获得 ExcelGenerator，且 application.yml 中的 tbeg.* 配置会自动绑定，无需额外声明 @Bean 或 @EnableXxx。文章随后展示了服务层使用 generate()、generateToFile() 生成报表，控制器通过 ResponseEntity<Resource> 进行文件下载，以及使用 generateToStream() 和 StreamingResponseBody 直接向响应流输出；同时也说明了 submitToFile() 的异步生成与 ExcelGenerationListener 回调机制。最后补充了 JPA Stream 集成和测试示例，并强调使用 Stream 时必须保持事务开启直到生成结束。

A C# backend developer describes moving into native Android development through Kotlin and finding the experience surprisingly familiar. The article highlights five benefits that stood out: built-in null safety, coroutines that feel intuitive to developers used to async/await and channels, concise data classes, extension functions, and modern declarative UI with Jetpack Compose. It also lists key official references for developers coming from .NET. The main takeaway is that Kotlin bridges backend engineering habits and mobile app development well, making the transition to native Android feel productive rather than foreign.

作者从 C# 后端和企业开发模式转向原生移动开发，分享第一次使用 Kotlin 开发 Android 应用的感受。文章重点介绍了五个对 C# 开发者很有吸引力的特性：内置空安全、与 async/await 和 channels 思路接近的 coroutines、能显著压缩代码的数据类、扩展函数，以及配合 Jetpack Compose 的声明式 UI。文末还列出 .NET 开发者值得收藏的官方参考资料。文章的结论是，Kotlin 能很好地连接后端工程经验与移动开发，让构建原生 Android 应用变得高效且自然。

A solo developer building a Kotlin Multiplatform notes app recounts a 36-hour struggle to make payments work across Stripe and RevenueCat. Test environments masked real issues, including a blank Android API key, while real-money testing exposed them. The post warns that webhooks can arrive out of order and retry, so blindly trusting payloads can create “Zombie Pro Users.” It also describes a Mac paywall bug that trapped users inside the app. The main lesson is that payment infrastructure needs real-world testing, direct verification of subscription state, and careful UI handling before a side project can feel like a real business.

作者是一名白天做项目经理、晚上做独立开发者的人，他为 Kotlin Multiplatform 笔记应用 EpicNotes 接入 Stripe 和 RevenueCat，结果在支付基础设施上耗费了整整 36 小时。测试环境掩盖了 Android 端空白 API key 等问题，直到真实付款才暴露出来。文章强调，Webhook 可能乱序到达并触发重试，若直接信任 payload，可能把已取消订阅误判为 Pro 用户。作者还分享了 Mac 端支付页无法关闭的 bug，提醒开发者在上线前必须做真实测试并直接校验订阅状态。

The article opens with a filter-screen scenario in Compose: a user searches for products, applies several filters, and scrolls down. It uses this setup to introduce the question of what happens to the view when an if block closes. The piece focuses on the anatomy of disappearing state in Compose and sets up a discussion about why UI state can appear to be lost when compositional branches are removed.

文章从 Compose 的筛选页面切入：用户先搜索商品、选择多个筛选条件，再向下滚动。作者借此提出一个核心问题：当 if 关闭时，界面会发生什么变化。内容聚焦于 Compose 中“消失的 state”是如何出现的，并为后续讨论组合分支被移除后，UI 状态为何看起来像是丢失做铺垫。

The provided content contains only the article metadata and a brief byline, with no substantive body text to summarize. The title indicates that the piece is about ANR, the misconception of chasing the wrong causes, and how to address thread starvation, but the excerpt itself does not provide any claims, examples, or technical guidance beyond that. As a result, only the topic can be identified, not the article’s actual arguments or conclusions.

当前提供的内容只有文章标题和作者信息，正文几乎为空，因此无法依据原文整理出具体观点或做法。从标题可以看出，文章主题是 ANR 与线程饥饿，并试图说明如何停止追逐错误线索，但摘录并未给出任何示例、分析或结论。基于这段资料，只能确认文章主题，不能补充未出现的技术细节。

This article centers on Kotlin data classes and their role in modeling immutable state, extracting components through destructuring, and using copy() for creating updated instances. It frames these features as practical tools for writing cleaner Kotlin code, including in Kotlin Multiplatform contexts. The provided text is brief, so the key takeaway is the combination of automatic utility behavior and concise component access that data classes offer.

本文围绕 Kotlin data classes 展开，说明它们如何用于不可变状态建模，以及如何通过 destructuring 清晰提取组件，并借助 copy() 创建更新后的实例。原文还提到这些能力适用于 Kotlin Multiplatform 场景，帮助编写更简洁的 Kotlin 代码。由于可用内容较少，核心信息在于 data classes 提供的自动辅助能力和简洁的组件访问方式。

The article examines what changed in Room 3.0, focusing on the impact to existing DAOs and the tradeoffs developers may face when upgrading. It frames the discussion around three practical questions: what changed, what the migration could cost, and whether an Android app should move now or wait. The post is presented as guidance for developers evaluating the transition rather than as a full technical reference.

这篇文章聚焦 Room 3.0 的变化，以及这些调整对现有 DAO 会带来什么影响。内容主要围绕三个实际问题展开：Room 3 改了哪些地方、升级可能付出哪些代价，以及 Android 应用现在是否该迁移或先观望。文章定位为帮助开发者评估升级时机的导读，而不是完整的技术参考。

Kotlin 2.4.20’s StackTraceRecoverable addresses a problem where custom exceptions can lose their trail when they cross coroutine boundaries. The article’s core point is that crashes can now better indicate who rethrew them, helping preserve debugging context across coroutine hops. It focuses on this specific fix and does not claim broader changes beyond the exception-tracing behavior described.

Kotlin 2.4.20 的 StackTraceRecoverable 修复了自定义异常在跨越 coroutine 边界时可能丢失追踪脉络的问题。文章重点在于，crash 被重新抛出后，现在可以更清楚地看出相关来源，从而让调试信息不会在 coroutine 之间中断。正文只说明了这一项针对异常追踪的修复，没有声称还有其他范围的改动。

The provided input contains only the article title, author, link, and a brief teaser that directs readers to continue on MobileByteSensei. Because no substantive body text is included, there is no article content to summarize without guessing. The only verifiable information is the title, “The corpus your generator reads is production code,” which suggests a focus on how generator input or training material should be treated in a production context. Any deeper interpretation would go beyond the supplied text.

当前提供的只有文章标题、作者、链接，以及一段引导读者前往 MobileByteSensei 继续阅读的提示，没有实际正文可供整理。因此，若不进行猜测，无法写出更完整的内容摘要。就可验证的信息来看，标题表明文章关注的是“生成器所读取的语料就是生产代码”，暗示讨论生成器输入或训练材料在生产场景中的含义；除此之外，无法从原文片段推导更多事实。

The article argues that Kotlin Multiplatform can be introduced gradually rather than through a full rewrite. It emphasizes that teams do not need to rebuild their app from scratch, share the UI layer, or first persuade an iOS team to change its approach. Instead, KMP can be adopted one module at a time, allowing engineering teams to start incrementally and fit the migration to their existing codebase and workflow.

本文主张 Kotlin Multiplatform 不必通过一次性重构来落地，而是可以循序渐进地引入。作者指出，团队无需重写整个应用，也不必共享 UI，甚至不需要先说服 iOS 团队接受某种做法。KMP 可以从单个模块开始，让工程团队结合现有代码库与工作流程，逐步推进采用。

The article highlights a classic Android problem: code that works in debug but crashes in release, even though the source is identical. It frames this as a consequence of production shrinking and obfuscation, where R8 and keep rules determine which classes, methods, and members remain available. The title points to a large 600-module app and the challenge of reducing app size without breaking reflection-based code. The excerpt itself does not provide implementation details, but it clearly signals that understanding and controlling keep rules is essential when shipping optimized release builds.

这篇文章提出一个经典的 Android 问题：同样的代码在 debug 能运行，到 release 却会崩溃。作者将原因指向生产环境中的压缩与混淆流程，尤其是 R8 和 keep rules 如何决定哪些类、方法和成员会被保留。标题提到一个 600 模块的大型应用，核心挑战是在缩小 App 体积的同时不破坏依赖反射的代码。尽管节选内容没有给出具体实现细节，但已经清楚表明：正确理解并控制 keep rules，对于发布优化后的版本至关重要。

This article introduces the Interface Segregation Principle (ISP) in the context of Android development. Its central message is simple: do not force a class to implement functions it does not need. The title frames the idea around small, focused interfaces, but the provided content contains only this single guiding statement rather than a full discussion or implementation details.

本文介绍了 Android 开发中的接口隔离原则（ISP），核心观点很明确：不要强迫一个类去实现它不需要的函数。标题强调“小而聚焦的接口”，但当前提供的正文只有这一句原则性表述，没有展开更多实现细节或具体示例。

This article describes a side-by-side measurement of AlphaKids, a children’s reading app, implemented in Kotlin Multiplatform and in native code. The comparison was run on one phone over the course of one day and focused on practical metrics rather than theory. The author reports on memory usage, build times, app size, and startup behavior, framing the post as a measurement-based look at the trade-offs between the two implementations. The source excerpt does not provide the actual results, so the piece should be read as an overview of what was measured rather than a conclusion about which approach is better.

这篇文章介绍了儿童阅读应用 AlphaKids 分别采用 Kotlin Multiplatform 和原生代码实现后的对比测量。测试在同一部手机上进行，持续一天，重点关注的是实际指标而不是理论讨论，包括内存占用、构建时间、应用大小和启动表现。摘录中没有给出具体结果，因此文章更适合作为一次测量范围的说明，而不是对两种方案优劣的最终判断。

On-device AI agents can pass testing yet fail after a few minutes of real use because the device heats up, the CPU downclocks, and latency spikes. What looks like a model issue is often thermal throttling. The article recommends checking PowerManager.getThermalHeadroom() on Android to forecast available thermal headroom and throttle proactively instead of waiting for the system to do it. When headroom falls, apps should switch to a lighter model, reduce inference frequency, or skip non-critical work. The author also notes that emulators and even newer flagship phones may not expose the problem, so sustained inference testing on older mid-range devices and Firebase Test Lab device matrices is important.

设备端 AI 代理在测试中可能表现正常，但真实连续运行几分钟后，设备升温、CPU 降频，延迟就会明显上升，问题看起来像模型故障，其实往往是热节流。文章建议在 Android 上使用 PowerManager.getThermalHeadroom() 预测可用热余量，不要等系统先限制性能再处理。当余量下降时，可以切换更轻量的模型、降低推理频率，或延后非必要调用。作者还指出，模拟器和新款旗舰机未必能复现这一问题，必须在较旧的中端设备上做长时间测试，并借助 Firebase Test Lab 找出受影响机型。

The article explains a lifecycle bug in a KMP Flow bridge: when Swift code calls observe() again, it overwrites the stored cancellation token without canceling the previous Job. That leaves the old collector running, potentially emitting into stale closures and keeping resources alive even after the view changes. [weak self] prevents the view model from being retained by the closure, but it does not stop the orphaned coroutine. The practical fix is to cancel before resubscribing on the Swift side, and, for stronger defense, have the Kotlin wrapper cancel any active Job before starting a new watch() on the same instance. The broader lesson is to treat cross-boundary Flow bridges as resources that require explicit teardown, especially because Swift has no structured-concurrency equivalent to Kotlin’s CoroutineScope ownership.

文章说明了 KMP 的 Flow bridge 中一种生命周期漏洞：Swift 端每次重新调用 observe() 时，如果只是覆盖掉旧的 cancellation，却没有先取消先前的 Job，就会留下仍在运行的 collector。旧 collector 可能继续向过时的 closure 发值，导致界面状态错乱或资源持续占用。[weak self] 只能避免 view model 被 closure 强引用，并不能终止那个被遗弃的 coroutine。作者建议在 Swift 端重新订阅前先取消，并在 Kotlin 包装层中主动取消同一实例上已有的 Job，让重复 watch() 不会悄悄叠出多个活跃 collector。

Dhvani Music is an open source Android music player built with Kotlin, Jetpack Compose, and AndroidX Media3. Its core idea is to combine ad-free YouTube Music playback with higher-quality sources such as JioSaavn, while also including built-in audio utilities. The app offers dual-source streaming with live quality switching, a 10-band graphic equalizer, bass boost, Dolby Atmos integration, a ringtone trimmer, alternative song versions, synced lyrics, offline playback and downloading with metadata embedding, plus Android Auto, Listen Together rooms, and Discord Rich Presence support. The project is free, tracker-free, and licensed under GNU GPL v3.

Dhvani Music 是一款使用 Kotlin、Jetpack Compose 和 AndroidX Media3 开发的开源 Android 音乐播放器。它的核心思路是将无广告的 YouTube Music 播放与更高音质的来源（例如 JioSaavn）结合，同时提供一系列内置音频工具。功能包括双来源流媒体与实时音质切换、10 段图形均衡器、低音增强、Dolby Atmos 集成、铃声剪辑器、替代歌曲版本、同步歌词、离线播放和下载并嵌入完整元数据，以及 Android Auto、Listen Together 房间和 Discord Rich Presence。该项目完全免费、没有追踪器，并采用 GNU GPL v3 许可。

Android development in 2026 is no longer just about shipping screens and API calls. Apps must adapt to Android 17 behavior changes, large-screen and resizable layouts, stricter Play target API requirements, tighter privacy and security expectations, background execution limits, and AI features with real failure modes. The article recommends testing on current SDKs, keeping platform-specific code isolated, building responsive Compose layouts, minimizing permissions, using the right background-work APIs, validating AI output, and profiling real workloads. It also stresses device fragmentation, release engineering, and staged rollouts as essential practices for reliable Android apps.

2026 年的 Android 开发不再只是完成页面和 API 对接。应用必须适应 Android 17 的行为变化、大屏和可调整窗口、Google Play 的目标 API 要求、更严格的隐私与安全预期、后台执行限制，以及具有真实失败模式的 AI 功能。文章建议先在当前 SDK 上测试、将平台相关代码集中隔离、使用响应式 Compose 布局、尽量减少权限、选对后台任务 API、验证 AI 输出，并基于真实负载做性能分析。设备碎片化、发布工程与分阶段发布同样是可靠性的重要组成部分。

The excerpt is a brief introduction to a longer Stackademic article. It says that around 2018, the author’s last Dicoding Android submission was a Movie DB app, and notes that this project stayed relevant for years. The title indicates the full piece compares Codex and Opus on the same Android take-home test, but the supplied text does not include the review details or any results. Based only on the excerpt, the safe takeaway is that the article begins from the author’s earlier Android submission and uses it as the setup for a later comparison.

这段摘录只是 Stackademic 长文的开头。文中提到，作者在 2018 年左右最后一次提交 Dicoding Android 作业时做的是一个 Movie DB app，而这个项目后来还持续陪伴了几年。标题显示全文会比较 Codex 和 Opus 在同一份 Android take-home test 上的表现，但所给内容并未包含具体评测过程或结论。就当前文本来看，唯一能确认的是作者早期的 Android 作品，以及它如何成为后续比较的背景。

Companion objects have been Kotlin’s answer to static members since version 1.0. This article notes that Kotlin 2.5.0 brings KEEP-0449, which introduces two new experimental features related to companion extensions and blocks. The excerpt does not describe the features in detail, but it clearly frames them as experimental additions rather than stable, fully supported APIs.

Companion object 自 Kotlin 1.0 起一直是静态成员的替代方案。本文指出，Kotlin 2.5.0 通过 KEEP-0449 引入了与 companion extensions 和 blocks 相关的两项新的实验性功能。摘录没有进一步说明这些功能的细节，但明确表明它们仍属于实验性新增，而不是稳定、正式支持的 API。

Over the past few months, the author’s team has been migrating an Android app from MVP to MVVM while following Google’s official app architecture guidance. The piece sets up a discussion about a common rendering issue: how changing a single boolean state can cause an entire screen to re-render. Based on the available excerpt, the article focuses on the migration context and the architectural implications of state-driven UI updates.

过去几个月里，作者的团队一直按照 Google 官方应用架构指南，将 Android 项目从 MVP 迁移到 MVVM。文章借此引出一个常见的渲染问题：当某个布尔状态发生变化时，为什么整个屏幕可能会重新渲染。根据目前提供的摘要，重点在于迁移背景，以及状态驱动 UI 更新所带来的架构影响。