每日新聞摘要

This post looks at life after RevenueCat’s Shipaton for BoatBrawl and its supporting library, Joyframe. Joyframe was tested by building two unrelated games, Island Panic and SkyFall, both created in about an hour with Claude Code, showing that the library can handle non-boat games too. The article also describes how BoatBrawl was brought to Amazon Fire TV Stick by adding a low-power profile that lowers render resolution, limits effects, moves simulation work, and fixes remote-input handling. Along the way, it explains Joyframe’s Kotlin-first approach: data-driven scenes, generated models and sound, off-screen rendering for verification, and phones as controllers.

这篇文章回顾了 RevenueCat Shipaton 结束后，BoatBrawl 与其底层库 Joyframe 的后续进展。作者先用 Joyframe 验证它是否适合非船战游戏，结果是两款全新的 3D 游戏 Island Panic 和 SkyFall 都在大约一小时内完成，并借助 Claude Code 生成。随后，BoatBrawl 也移植到 Amazon Fire TV Stick，通过低功耗配置文件降低分辨率、关闭部分效果、调整模拟与输入处理。文章还说明了 Joyframe 以 Kotlin 为核心、以数据驱动场景和生成式资源运行的设计。

Over several months shipping Coinly, an Android expense tracker built with Kotlin, MVVM, coroutines, Flow, Room, Gson, and R8, the author hit five production bugs that tests never caught. They included Gson fields broken by R8 renaming, StateFlow values stuck at their initial state because nothing collected them, and a splash screen that could hang forever when a one-shot navigation event was dropped. Other issues came from Android App Bundle language splitting and a Crashlytics report caused by Google Play’s pre-launch robot. The post argues that debug tests and screen-only smoke checks are not enough, and recommends testing minified release builds, installing from Play, exercising background/foreground transitions, and paying attention to device names in crash reports.

作者在开发并发布 Android 记账应用 Coinly 的过程中，遇到 5 个测试没有发现的问题：Gson 字段在 release 版被 R8 重命名后，反序列化会静默失效；StateFlow 只读 .value 而未被收集时，值一直停在初始状态；使用 replay = 0 的 SharedFlow 发送一次性导航事件，在应用不在前台时会被丢掉。另有 App Bundle 语言拆分导致语言切换异常，以及 Google Play pre-launch 机器人带来的 Crashlytics 崩溃报告。文章强调，只测 debug 版和界面显示远远不够，应该测试 minified release、从 Play 安装、验证后台/前台切换，并留意崩溃报告中的设备名称。

This article describes Punish, an Android app that turns screen-time limits into financial penalties for causes users dislike. Because an inaccurate count could wrongly send money or weaken the deterrent, the app’s guiding rule is to under-count when unsure and report unknown when measurement fails. The author explains several Android pitfalls: UsageStatsManager overcounts foreground time, STOPPED events arrive late, midnight boundaries and device shutdowns need special handling, and missing permissions can look like zero usage. For web tracking, the app reads browser address bars through an AccessibilityService, throttles content events, and treats browser detection and URL parsing carefully. Since accessibility services can die silently, the app records coverage windows so missed time is treated as unmeasured, not used.

这篇文章介绍了作者独自开发的 Android 应用 Punish：用户先设定屏幕使用时间目标并押上金额，若超标，就把钱付给自己最不愿资助的组织。因为计时一旦出错，可能会把钱错误转出，或削弱威慑效果，所以原生层遵循的原则是“拿不准就低估，完全测不到就明确说明”。作者详细列举了 Android 的多个问题，包括 UsageStatsManager 会高估前台时间、STOPPED 事件会延后到达、跨午夜与关机场景需要特殊处理，以及无权限时查询会静默返回空结果。网页追踪则依赖 AccessibilityService 读取浏览器地址栏，并通过记录覆盖窗口避免服务死亡时被误判为正常使用。

This post describes a long-running personal Kotlin project built deliberately beyond what it strictly needed. The author wanted to explore a real backend, Android app, CI, and infrastructure on something personally owned, rather than inside systems constrained by work. Over about 22 months, the project grew in stages: backend first, then Android with Jetpack Compose, CI with Dagger.io, infrastructure with Pulumi and KinD, and finally a small k3s cluster on a Hetzner VPS. Some choices were intentional overkill, while others were course corrections, such as dropping Karate E2E tests, moving from multiple repos to a monorepo, and replacing Elasticsearch with Meilisearch. The result is a live app with a small first user base and a public codebase split across several repositories.

这篇文章回顾了作者耗时约 22 个月的 Kotlin 个人项目。起初只是想在不受工作约束的情况下，亲手搭出一个真实可运行的后端、Android App、CI 和基础设施。项目按阶段推进：先做后端，再加入 Android 与 Jetpack Compose，随后是 Dagger.io CI、Pulumi 与 KinD 测试环境，最后部署到 Hetzner VPS 上的 k3s 集群。作者承认其中很多设计是有意为之的“过度工程”，也有一些是根据现实反馈不断修正的结果，例如移除 Karate E2E、从多仓库迁移到 monorepo，以及把 Elasticsearch 换成 Meilisearch。如今应用已经上线，并有少量真实用户在使用。

The article argues that in Android interviews, a technically correct answer may still not perform well if it misses what the interview loop is actually assessing. Using two correct responses to the same question that were scored very differently, it suggests that senior-level interviews often measure more than factual accuracy alone. The piece points readers to a broader explanation of what those loops are looking for once basic correctness is established.

文章指出，在 Android 面试里，技术上正确的答案并不一定会得到好结果，关键还在于它是否符合面试流程真正考察的重点。作者以同一道题的两个正确回答却被打出截然不同分数为例，说明资深面试往往不只看事实是否正确，也会关注候选人的思路与表达方式。本文目前只是导读，完整文章可在 Medium 上继续阅读。

JCOReflector brings a real CLR into a JVM process and exposes the .NET API surface as Java APIs, which can then be used by Scala, Kotlin, and Clojure as well. The article highlights that the project now includes experimental generics support. No further implementation details, limitations, or performance claims are provided in the source text.

JCOReflector 让真正的 CLR 进入 JVM 进程，并把 .NET API 接口以 Java API 的形式暴露出来，因此也能供 Scala、Kotlin 和 Clojure 使用。文章同时提到，这个项目现在加入了实验性泛型支持。原文只包含这些信息，没有给出更多实现细节、限制或性能数据。

The article centers on a launch-time crash associated with the error “Window couldn’t find content container view,” and connects it to the behavior of Google’s consent form, which must wait until a window is available. The author frames the discussion around a prior incident in August, then notes that a subsequent app crashed in the same way nine times within 15 attempts. The piece focuses on understanding the timing and window-related conditions behind the crash rather than claiming a broader fix or unsupported cause.

这篇文章围绕启动时出现的“Window couldn’t find content container view”错误展开，并说明它与 Google 同意表单的显示时机有关：必须等到窗口可用后才能继续。作者先回顾自己在 8 月曾把一次启动崩溃归咎于手机，随后指出自己的另一个 app 也以同样方式在 15 次尝试中崩溃了 9 次。文章重点在于梳理这种与窗口建立时序相关的问题，而不是声称已有通用修复或额外原因。

The article compares MVI and MVVM in the context of Jetpack Compose, with an emphasis on long-term trade-offs rather than abstract ideology. The author says they have shipped apps using both approaches and explains how they prefer to think about the decision during real Android app development. Based on the available text, the piece appears to focus on which architecture is less likely to create problems in the future, instead of claiming that one pattern is universally superior.

这篇文章在 Jetpack Compose 的场景下比较 MVI 和 MVVM，重点放在长期取舍，而不是抽象的架构之争。作者表示自己两种做法都已经实际交付过产品，并说明在真实 Android App 开发中如何思考这个选择。从目前可见内容来看，文章主要关注哪一种模式更不容易在未来引发问题，而不是主张某一种模式绝对优于另一种。

This article introduces Kotlin function features that Android developers should understand. It emphasizes that Kotlin provides several powerful capabilities that make functions more expressive, concise, and flexible. The post is presented as a guide for readers who want to work more effectively with Kotlin functions in Android development.

这篇文章介绍了 Android 开发者应该理解的 Kotlin 函数特性，指出 Kotlin 提供多项强大能力，能让函数更具表达力、更简洁，也更灵活。文章作为一篇入门导读，帮助读者更有效地在 Android 开发中使用 Kotlin 函数。

Kotlin 2.4 is out, but the article’s focus is on what may matter next. It highlights stable context parameters, explicit backing fields, and the Kotlin 2.4.20 changes the author is betting on. The piece is presented as a forward-looking note rather than a detailed feature roundup, emphasizing the upcoming direction of the language and the specific shifts the author expects to be important.

Kotlin 2.4 已发布，但文章重点不在这次版本本身，而在接下来可能出现的变化。文中提到 stable context parameters、explicit backing fields，以及作者看好的 Kotlin 2.4.20 走向。整体来看，这更像是一则前瞻性观察，强调语言未来的发展方向，而不是对新功能的完整盘点。

The author reflects on a growing tension in software engineering: code can now be produced in seconds, yet understanding may feel weaker. The piece argues that writing code was never the hardest part, and asks what the real difficulty in software engineering actually has been. As presented here, it is a short introductory post that directs readers to continue on Medium rather than offering a full argument in the excerpt.

作者反思软件工程中的一个矛盾：如今几秒钟就能生成代码，但对系统的理解却可能变得更弱。文章认为，写代码从来不是最难的部分，并进一步追问软件工程真正困难的到底是什么。就目前提供的内容来看，这只是 Medium 上的一段简短开头，主要作用是引导读者到原文继续阅读。

This article explains how gRPC is built on HTTP/2 and Protocol Buffers, and why it can be a strong choice for internal services compared with REST. It also points readers toward the practical side by discussing how to build a Kotlin server. The piece frames gRPC as an implementation and architecture topic rather than a general API design overview.

本文说明 gRPC 如何运行在 HTTP/2 与 Protocol Buffers 之上，并指出它在内部服务场景中，可能比 REST 更合适。内容也涉及实践层面，提到如何构建 Kotlin 服务器。整体重点放在 gRPC 的架构与实际使用，而不是泛泛的 API 设计比较。

This article explains how gRPC is built on top of HTTP/2 and Protocol Buffers, and what that means in practice. It contrasts gRPC with REST, highlighting the architectural differences rather than claiming any universal advantage. The post also covers how to assemble a server and client in Kotlin using Gradle, making it a practical introduction for developers who want to understand the communication model and basic project setup.

本文说明 gRPC 如何建立在 HTTP/2 与 Protocol Buffers 之上，以及这会带来怎样的实际运行方式。文章还将 gRPC 与 REST 进行对比，重点放在架构差异，而不是宣称任何普遍优势。最后，作者介绍如何使用 Kotlin 和 Gradle 组装服务器与客户端，适合作为希望理解通信模型和基础项目设置的工程师入门阅读。

The article highlights the KISS principle in Android development: keep code simple. It argues that simpler code is easier for developers to understand, test, debug, and maintain. The main takeaway is that avoiding unnecessary complexity helps make Android code more practical and manageable.

本文介绍了 Android 开发中的 KISS 原则，即让代码保持简单。作者指出，简单的代码更容易被理解、测试、调试和维护。核心观点是避免不必要的复杂度，能让 Android 代码更实用，也更容易管理。

This article describes the building of Muffle, an Android app that automates sound profiles based on location and time without draining the battery. The author first tried continuous location polling, but moved to GeofencingClient so the OS could handle location monitoring more efficiently. Reliability also required JobIntentService, careful AudioManager and Do Not Disturb handling, and a WakeLock only for trigger events. The piece highlights how OEM power management can kill background work even when standard Android guidance is followed, and recommends using native APIs, testing on aggressive devices, and keeping background automation simple.

本文讲述作者开发 Android 应用 Muffle 的过程：根据位置和时间自动切换手机音效配置，同时尽量避免电量损耗。作者最初使用持续定位轮询，后来改为 GeofencingClient，把位置监控交给系统底层处理；为了提升可靠性，又结合 JobIntentService、AudioManager，以及仅在触发时启用的 WakeLock。文章强调，不同 OEM 的后台限制和省电机制常导致触发失败，因此应优先使用系统原生 API、简化触发架构，并在激进省电的设备上充分测试。

This article introduces TBEG (Template Based Excel Generator), a JVM library for generating Excel reports by binding data to predesigned Excel templates. Instead of writing spreadsheets cell by cell with Apache POI, developers place markers such as ${variableName} in an Excel file and pass data from code. TBEG handles variable substitution, repeated data expansion, image insertion, automatic cell merging, formula range updates, conditional formatting duplication, and chart data reflection. The post also outlines performance claims, shows common Excel download API usage in Spring Boot, and provides Kotlin and Java quick-start examples. It is intended for report generation only, not Excel file reading or parsing.

本文介绍了 TBEG（Template Based Excel Generator），这是一个 JVM 库，通过把数据绑定到预先设计好的 Excel 模板来生成报表。相比使用 Apache POI 逐格创建报表，开发者只需在模板中放入 ${variableName} 之类的标记，并在代码中提供数据。TBEG 会自动处理变量替换、列表数据展开、图片插入、单元格自动合并、公式范围调整、条件格式复制以及图表数据反映。文章还展示了性能说明、Spring Boot 导出 API 的常见用法，以及 Kotlin 和 Java 的快速开始示例；该工具仅用于生成 Excel，不支持读取或解析文件。

The article introduces Nepali Date Picker, a Kotlin Multiplatform library created to address a specific need: providing Android and iOS apps with a Bikram Sambat date picker that feels like Material 3. From the available excerpt, the focus is on the motivation behind the project and the fact that the library is being published in multiple places, including Maven Central, SPM, and pub.dev. The text does not provide implementation details or broader comparisons, so the main takeaway is the project’s cross-platform publishing goal and its user-facing date-picker use case.

这篇文章介绍了 Nepali Date Picker 这一 Kotlin Multiplatform 库，作者的初衷是解决一个明确需求：为 Android 和 iOS 提供一个体验上接近 Material 3 的 Bikram Sambat 日期选择器。就现有内容来看，重点在于该库将发布到多个位置，包括 Maven Central、SPM 和 pub.dev。原文摘录没有提供实现细节或更多技术对比，因此能够确认的核心是跨平台发布目标，以及这个日期选择器的应用场景。

The post is a brief teaser introducing the author’s debugging routine: before working on a ticket each sprint, Chucker is already open on the device to inspect all network requests and responses made by the app. The headline contrasts a staging environment that never produced a 500 error for the author’s Kotlin project with an AI agent that does, but the excerpt itself only provides the setup and points readers to continue on Stackademic. No further technical details or root cause are included in the provided text.

这篇文章目前只给出一段简短导语：作者在每个 sprint 处理 ticket 之前，都会先在设备上打开 Chucker，用来查看应用发出的所有 request 以及收到的 response。标题对比了 staging 从未让 Kotlin 项目出现 500 错误，却是 AI agent 会带来问题；但所提供的内文没有进一步说明原因、过程或解决方案，只提示读者前往 Stackademic 继续阅读。