每日新聞摘要

Todorant’s Android app was rebuilt in native Kotlin and Jetpack Compose and reached Google Play in four days, but the path to release exposed issues that test builds missed. The team fixed Google sign-in by replacing a deleted Google Cloud project and adding both upload and Play signing fingerprints, removed broken Google Calendar sync, and patched an R8-related QR login crash found by Play’s pre-launch report. A later release removed Apple-only SF Pro fonts, shrinking the APK by 4.5 MB. The post also notes a separate F-Droid flavor, permission cleanup, and several fixes for real users after launch.

Todorant 将 Android App 重写为原生 Kotlin 和 Jetpack Compose 后，在四天内完成了 Google Play 上架，但正式发布过程暴露出测试版不会出现的问题。团队先是因为原来的 Google Cloud 项目被删除而重建登录配置，并补上上传密钥和 Play 签名密钥的指纹；随后移除已失效的 Google Calendar 同步，再修复由 R8 引发的二维码登录崩溃。之后删除仅适用于 Apple 平台的 SF Pro 字体，使 APK 再减少 4.5 MB。文章还提到 F-Droid 版本、权限精简，以及上线后针对真实用户的后续修复。

This article explains how Kotlin Flow conflation can quietly turn UI events into data loss bugs. StateFlow is designed to keep only the latest value, which is ideal for screen state but wrong for one-off effects like navigation or showing a receipt. The post shows how nullable state fields, misused SharedFlow settings, collectLatest, and conflated buffers can drop events or cancel handlers unexpectedly. It then compares fixes: a buffered SharedFlow for always-present collectors, a Channel for single-consumer UI effects, or explicit queued state with IDs when effects must live in state. The key rule is to distinguish values from occurrences and choose delivery semantics accordingly.

这篇文章说明 Kotlin Flow 的 conflation 如何悄悄把 UI 事件变成数据丢失问题。StateFlow 设计上只保留最新值，适合界面状态，却不适合导航、展示收据这类一次性效果。文中指出，用可空字段表示事件、误用 SharedFlow 配置、collectLatest，以及带有合并语义的 buffer，都可能让事件丢失或在处理中被取消。随后比较几种修复方式：对始终有收集者的场景可用 buffered SharedFlow；单消费者 UI effect 更适合 Channel；若必须放进 state，则应使用带标识符的队列保存。核心原则是先区分值与事件，再选择匹配的传递语义。

FinLedger treats transaction deletion as a coordinated reconciliation workflow rather than a simple SQL DELETE. Before removing a record, it inspects linked accounts and attachments, then reverses the original postings inside an atomic SQLite transaction so balances remain correct. If the transaction is tied to lending or split-expense features, companion records are updated to preserve relational truth. After the database commit, local receipt files are deleted and any cloud-sync queue is updated. Because filesystem cleanup is outside SQLite’s ACID boundary, the app also runs a startup sweep to remove orphaned attachment files left behind by unexpected crashes.

FinLedger 将删除交易视为一套协同的对账流程，而不是简单执行 SQL DELETE。系统会先查询交易及其关联账户、附件，然后在 SQLite 的原子事务中反转原始记账分录，使余额恢复正确。若交易关联借贷或拆分费用功能，也会同步更新伴随记录，保持关系一致。数据库提交后，再删除本地收据文件并处理云端同步标记。由于文件系统不属于 SQLite 的 ACID 范围，应用还会在启动时扫描并清理残留的孤儿附件。

A chat app can duplicate messages after a network drop because a WebSocket reconnect is not a true resume: it is a fresh connection with no shared state. If the server replays messages around the disconnect window, or if multiple reconnect attempts succeed, the same message may be delivered more than once. The article shows that the client should resume from a durable server-assigned message ID stored in local persistence, not in memory, and that the database should ignore duplicate inserts using an idempotent key such as serverId. The core lesson is that reliable chat design needs both resume semantics and duplicate-tolerant storage.

聊天应用在网络掉线后出现重复消息，通常不是 UI 代码出错，而是重连流程没有正确处理。WebSocket 重连并不是续传，而是一次全新的连接，因此服务器可能在断线窗口内重播消息；如果 onFailure 在短时间内触发多次，还可能产生多次成功重连与重复回补。文章建议客户端从本地数据库读取最后收到的 server-assigned ID，通过 resumeFrom 明确告知服务器已经拥有的进度，同时在数据库层用唯一键配合 IGNORE 把重复消息变成无害的幂等写入。

This article explains why emitting from inside withContext, launch, or async within a plain flow { } triggers “Flow invariant is violated.” Kotlin enforces that emit runs in the same coroutine context as collect so downstream operators can remain sequential, context-predictable, and unsynchronized. The preferred fix is to move dispatcher switching into suspend functions and keep the flow builder simple. For long-running upstream work, flowOn shifts the producer side, while channelFlow is the right tool when multiple coroutines or contexts must produce values concurrently. The post also covers callbackFlow for listener APIs, the hidden buffering behavior introduced by flowOn, common failure modes, and a test strategy to lock the invariant in place.

本文解释了为什么在普通的 flow { } 中把 emit 放进 withContext、launch 或 async，会触发“Flow invariant is violated”。Kotlin 强制 emit 必须与 collect 处于相同的 coroutine context，这样下游运算符才能保持顺序执行、可预测的执行环境以及无需同步的状态。作者建议，大多数情况下应把 dispatcher 切换下放到 suspend 函数中，让 flow 本身保持简单；如果是长时间运行的上游工作，可以使用 flowOn 迁移整段上游；当多个 coroutine 或不同 context 需要并发产出值时，则应使用 channelFlow。文章还补充了 callbackFlow、flowOn 的隐藏缓冲、常见失败模式，以及用于锁定该不变式的测试方法。

This article traces one Kotlin line through the entire Android release pipeline, from Gradle configuration and task execution to AAPT2, manifest merging, compilation, shrinking, packaging, signing, Play delivery, and ART at runtime. It explains common failure modes such as configuration-time work that slows every build, resource shrinking that removes dynamically referenced assets, R8 stripping or renaming classes reached by reflection, and missing library desugaring on older devices. It also covers distribution details like AAB language splits and signing schemes, then shows how Baseline Profiles help ART compile startup-critical code before first launch. The main point is that release problems usually come from a specific link in the chain, not from magic.

本文沿着 Android 发布流水线追踪一行 Kotlin 代码，从 Gradle 的初始化与配置、AAPT2 资源处理、Manifest 合并、Kotlin/Java 编译，到 R8 的缩减、优化与混淆、打包签名、Play 分发，最后到设备上的 ART。作者用多个常见故障说明问题所在：configuration-time 工作会拖慢所有 Gradle 调用，动态引用的资源可能被 shrinker 删除，通过反射或字符串访问的类可能被 R8 移除或改名，而旧设备如果没有启用 library desugaring 也会在运行时出错。文章还说明了 AAB 的语言拆分、签名方案，以及 Baseline Profiles 如何帮助首次启动。

fold() and reduce() may look similar, but the starting accumulator changes their type rules, empty-input behavior, and failure modes. The article shows why fold is the better choice when you need to build a different result type, handle possibly empty collections, or define a replayable state transition. reduce is appropriate when the first element is a valid start and all values share the same shape, but it can throw on empty inputs and can accidentally mutate the first element if the accumulator is modified in place. The post also warns about shared mutable seeds, quadratic copying, integer overflow from using 0 as an Int seed, and semantic changes when swapping reduce for fold without checking whether the seed is a true identity.

fold() 和 reduce() 看起来很像，但起始累加值不同，会直接影响类型规则、空输入行为和潜在故障模式。本文说明了为什么在需要构造不同结果类型、处理可能为空的集合，或重建可回放状态时，fold 通常更合适；而当第一个元素本身就是合理起点，且所有值形状相同时，reduce 才更自然。不过 reduce 在空集合上会抛出异常，如果在原地修改累加值，还可能意外改写第一个元素。文章也提醒要避免共享可变种子、每一步都复制导致 O(n²)、用 Int 种子引发整数溢出，以及在没有确认种子是否为幺元之前就把 reduce 换成 fold。

This article explains how Android Studio previews work under Layoutlib, tracing the rendering pipeline from XML inflation or compiled composables through measurement, layout, drawing, and final image output. It distinguishes the View-based path, which builds an Android View hierarchy, from the Compose path, where Compose runs inside a View host while keeping its own internal UI tree. The piece also shows why Layoutlib relies on framework delegates, why previews can fail for dependency or runtime reasons, and why a rendered preview is useful but not a substitute for testing on a real device or emulator.

本文解释 Android Studio 预览在 Layoutlib 下如何工作，从 XML inflate 或已编译的 composable 开始，经过测量、布局、绘制，最终生成预览图像。文章区分了以 View 为主的路径：构建 Android View 层级；以及 Compose 路径：在 View 宿主中执行 Compose，但由 Compose 自己维护内部 UI 树。作者还说明了 Layoutlib 为何需要 framework delegate、预览失败可能发生在依赖或运行时边界，以及为什么预览只能说明某种渲染结果，并不能替代在模拟器或真机上的测试。

This installment of the migration series explains what moved into Kotlin Multiplatform with little effort and what became painful. Koin, Ktor, and SQLDelight largely shifted cleanly because the original architecture already favored shared code, but the real difficulty came from the app’s own coupling to Android and other platform APIs. The author highlights how dependency injection reduced the need for expect/actual, why dates based on java.time were especially disruptive, and why file handling and local storage required different implementations across Android, web, and iOS. The main lesson is to audit platform coupling early, keep DI responsible for platform differences, and build a second target in CI from the beginning.

这一篇继续记录迁移过程，重点讲哪些内容几乎可以直接搬到 Kotlin Multiplatform，哪些地方最费时间。作者指出，Koin、Ktor 和 SQLDelight 之所以迁移顺利，是因为原本架构就较偏共享代码；真正拖慢进度的是代码本身对 Android 及其他平台 API 的耦合。文中比较了 expect/actual 与 DI 的取舍，并说明日期处理、文件上传和本地存储为何在 Android、Web 和 iOS 之间差异很大。结论是：先审视平台耦合、让 DI 承担平台差异，并尽早在 CI 中加入第二个目标平台。

The provided text uses a tongue-in-cheek analogy to frame a comparison between frameworks, likening it to the controversial topic of pineapple on pizza. It suggests that, much like that food debate, the native versus cross-platform discussion is something nobody explicitly asked for. No further technical arguments, platform details, or conclusions are included in the excerpt.

这段文字用带有戏谑意味的比喻，将框架比较类比为“菠萝披萨”这一颇具争议的话题，暗示原生与跨平台之争并不是人人都真正想讨论的内容。摘录中没有进一步给出技术论点、平台细节或结论，因此只能确认作者是在以幽默方式引出这场辩论，而不是展开具体分析。

The article questions whether a separate domain layer is truly necessary in every Kotlin app. It argues that placing a UseCase in front of every repository function is not automatically architecture; sometimes it only adds more folders and indirection. The author then points toward a simpler alternative, asking whether the ViewModel could call into the data layer directly instead of routing everything through tiny three-line UseCases. The piece is framed as a practical challenge to over-layering, not as a claim that domain separation is always wrong.

本文质疑在 Kotlin 应用中，Domain Layer 是否真的每次都必不可少。作者认为，给每个 repository 函数前都加一个 UseCase，并不一定意味着更好的架构；有时只是增加了层次和更多文件夹而已。文章进一步提出更简化的可能性，追问是否可以让 ViewModel 直接调用数据层，而不必经过那些只有三行代码的 UseCase。整体重点是反思过度分层，而不是否定 Domain 分层本身的价值。

This article introduces MVVM for Android development with Kotlin in a beginner-friendly way. It explains how Model, View, and ViewModel work together and frames the pattern as a way to build cleaner, more maintainable Android applications. The piece is presented as a guide for readers who want to understand the basic role of each component and how the architecture fits into Android app design.

本文以适合初学者的方式介绍 Android 开发中的 MVVM 和 Kotlin。内容说明 Model、View 与 ViewModel 如何协同工作，并将这种架构作为构建更干净、易维护的 Android 应用的一种方式。文章定位为入门指南，帮助读者理解各组件的基本职责，以及它们在 Android 应用架构中的作用。

This article focuses on Kotlin Multiplatform project organization, especially the relationship between commonMain and platform-specific source sets. It highlights the core building blocks involved in KMP architecture, including source sets, compilation targets, hierarchy templates, and dependency sharing. The piece is framed as a practical guide for understanding how multiplatform code is structured across shared and platform-specific layers.

本文聚焦于 Kotlin Multiplatform 项目的架构与结构，尤其是 commonMain 与各平台 source sets 的关系。内容提到多平台开发中的几个核心概念，包括 source sets、编译目标、层级模板，以及依赖共享。整体旨在帮助读者理解共享代码与平台专属代码在 KMP 中如何分层和组织。

This article points Android developers to Kotlin 2.4.20’s Swift export improvements, which are presented as a reason to pay attention if you share code across platforms. The provided text is brief and does not include technical details, benchmarks, or implementation specifics, so the safest takeaway is simply that the piece highlights iOS interoperability in this Kotlin release.

这篇文章提到 Kotlin 2.4.20 的 Swift export 改进，主题集中在提升与 iOS 的互操作性，对需要跨平台共享代码的 Android 开发者尤其相关。不过，原文内容非常简短，没有提供具体技术细节、实现方式或性能数据，因此可以确认的只有这次版本更新与 iOS 互操作性的关联。

The author says they were preparing to upgrade a side project to the latest version of Compose and expected to run into many errors, but the update did not break anything. The post is a brief Medium note rather than a technical deep dive, and it mainly conveys relief that the migration was smooth. No specific fixes, APIs, or compatibility issues are described in the provided text.

作者表示，他在准备把自己的 side project 升级到最新版本的 Compose 时，原本预期会遇到很多错误，但实际并没有任何内容损坏。本文只是 Medium 上的一则简短感想，核心信息是升级过程出乎意料地顺利，让人松了一口气；给出的正文并未说明具体修复项、API 变化或兼容性问题。

The article points out two common patterns in large Gradle builds: a root-level allprojects block and cross-module reach-ins. It frames the discussion around Gradle Isolated Projects, focusing on what these patterns break and what alternatives may replace them. The content is limited in the provided excerpt, so it does not claim specific implementations or results beyond the article’s stated topic.

文章指出，大型 Gradle 构建里常见两种做法：在根目录使用 allprojects 区块，以及让某个模块直接跨模块访问其他模块。作者以 Gradle Isolated Projects 为主题，讨论这些习惯会在哪些地方出问题，以及可能的替代方向。由于目前提供的内容只有文章开头，无法推断更细的实现细节或结果。

The article is framed as a personal take on Android’s next release cycle. The author says that a few years ago they would have promised themselves not to get overly excited about another Android version, but that feeling changes when the previews begin rolling out. The excerpt does not list the features yet; it only sets up an upcoming discussion of what the author hopes to see in a future Android version, with the rest of the piece continuing on Medium.

这篇文章以作者对 Android 新版本的个人期待开篇。作者说，几年前自己还会提醒自己不要对另一个 Android 版本太兴奋，但当 preview 开始陆续推出时，这种感觉又回来了。截取内容并未列出具体功能，只表明作者接下来会谈他希望未来 Android 版本具备哪些特性，完整内容需要前往 Medium 继续阅读。

Jetpack Compose 1.12 has been released, and work on 1.13 is already underway. The article frames the update around three practical angles: what is new in the current release, what is coming in beta for the next version, and what developers should review before upgrading. It does not provide the full technical details in the excerpt, but it clearly signals a transition from one stable release to the next and encourages readers to check compatibility and upgrade considerations before moving forward.

Jetpack Compose 1.12 已经发布，而 1.13 也已经开始推进。文章围绕三个重点展开：当前版本带来了什么新内容、下一版在 Beta 阶段会有哪些变化，以及升级前需要先确认哪些事项。虽然摘录没有给出完整技术细节，但核心意思很清楚：开发者在从稳定版过渡到下一版本时，应先关注兼容性和升级检查，避免直接切换带来问题。

This is the second part of a series about migrating a real Android app to Kotlin Multiplatform. The article centers on two sides of the transition: the pieces that moved over with little effort and the areas that caused pain during migration. Based on the available text, it frames the discussion as a practical follow-up in the author’s ongoing series, rather than a broad tutorial or a claim of universal success. The piece continues on ProAndroidDev and is positioned as part 2 of 4.

这是关于将一个真实 Android App 迁移到 Kotlin Multiplatform 的系列第二篇。文章聚焦迁移过程中的两个方面：哪些内容几乎可以直接迁移，以及哪些地方在实现上带来了阻碍与困扰。根据现有文本可知，这篇文章是作者延续前文的实战分享，属于系列中的第 2 部分，而不是通用教程或对迁移结果的全面结论。内容发布在 ProAndroidDev，主题明确指向真实项目的迁移经验。

This article compares Java virtual threads and Kotlin coroutines through the lens of suspension mechanics rather than basic usage. Virtual threads are stackful: the runtime saves and restores the whole stack, so suspension stays invisible in code. Coroutines are stackless: the compiler rewrites suspend functions to return and later resume via a Continuation, which makes suspension explicit. The author argues that both approaches only reduce the cost of waiting, not the total demand for resources. As thread limits disappear, the bottleneck shifts to connection pools, external APIs, or disks. The post also contrasts their impact on ThreadLocal, pinning, blocking I/O, observability, and version choices, concluding that the right model depends on whether you want transparent compatibility or explicit asynchronous structure.

本文从挂起机制出发比较 Java virtual threads 和 Kotlin coroutines。虚拟线程属于 stackful，由运行时保存并恢复整个栈，因此挂起点对代码几乎不可见；协程属于 stackless，由编译器改写 suspend 函数，通过 Continuation 返回并再次调用，使挂起点显式暴露。作者强调，两者都只是降低等待成本，并不会增加资源总量，因此当线程限制被放开后，瓶颈会转移到数据库连接池、外部 API 配额或磁盘等下游资源。文章还讨论了 ThreadLocal、pinning、阻塞 I/O、JFR 监控和版本选择，指出选型应围绕真实的等待资源来评估。

The article explains that many Compose screenshot test suites only render at the default fontScale 1.0, which leaves a blind spot for accessibility text scaling. A layout that looks fine in snapshots can break when users increase system font size to 1.3x or beyond, especially when a weighted text element sits beside a fixed-width sibling such as a price label. The author shows how a value like $1,249.00 can be silently truncated by TextOverflow.Ellipsis with no crash and no failing test. The recommended fix is to add a fontScale 1.3f render path by parameterizing Paparazzi DeviceConfig or overriding LocalDensity in Compose UI tests.

文章指出，许多 Compose 截图测试套件默认只在 fontScale 1.0 下渲染，这会留下一个重要盲点：用户开启无障碍字体缩放后，界面可能在真实设备上溢出或被截断。作者以一个 Row 布局为例说明，当左侧文本可伸缩、右侧价格使用固定宽度时，像 $1,249.00 这样的内容在 1.3 倍字体下会被 TextOverflow.Ellipsis 悄悄截短。整个测试套件仍然可能是绿色的，因为从未在该缩放级别渲染。解决方式是为 Paparazzi 的 DeviceConfig 或 Compose UI 测试中的 LocalDensity 显式加入 fontScale 1.3f。

This part introduces AgentContext, a session-local working model that helps an Android AI agent anticipate what the user is doing before they ask for help. It stores the active and previous packages, recent app switches, the current screen snapshot, pending tasks, last known intent, and a confidence level. The builder infers confidence from recent accessibility events: frequent app switching in the last minute suggests HIGH confidence, while sparse or absent activity lowers it. The context is serialized into a compact prompt for the LLM, using only the most recent app switches and the current screen state. The agent then adapts its initial prompt behavior based on confidence, auto-filling context at HIGH, suggesting and confirming at MEDIUM, and asking directly only at LOW. Context is never persisted across sessions and becomes stale after five minutes.

本篇引入 AgentContext：一种仅在当前会话内有效的上下文模型，用来帮助 Android AI agent 在用户发问前推断其正在做什么。它保存当前和上一个包名、最近的 App 切换、当前屏幕截图、待处理任务、最后一次已知意图以及置信度。构建器会根据最近 60 秒内的切换次数推断置信度：频繁切换表示 HIGH，只有少量信号为 MEDIUM，没有近期活动则为 LOW。随后，这些信息会被压缩成适合 LLM 的提示内容，只保留最近几次切换和当前屏幕，以减少噪声。系统再依据置信度决定初始交互方式：HIGH 直接带入上下文，MEDIUM 先建议并确认，LOW 才会主动询问；另外，超过五分钟的上下文会被视为过期。

The article explains why personal finance apps cannot treat transaction edits like ordinary CRUD updates. Changing a transaction in place can break account balances because the original economic effects have already been recorded elsewhere in the ledger. FinLedger instead uses a two-phase reconciliation approach: it first reverses the original postings, then validates and applies the updated transaction, all inside a single SQLite transaction via Room's withTransaction. This preserves balance integrity even when edits change the amount, account, transaction type, or date across billing boundaries. The post also notes that atomic rollback protects the ledger if any error or interruption occurs during the edit.

本文解释了为什么个人财务应用不能像普通 CRUD 那样直接原地更新交易记录。交易一旦被记入账本，就已经影响账户余额、预算和报表，若只改数据库字段而不重算这些影响，账本就会失衡。FinLedger 采用两阶段对账：先把原交易的过账反向撤销，再验证并应用新交易，并把整个过程放在 Room 的 withTransaction 和 SQLite 事务中执行，以确保原子性。这样即使金额、账户、交易类型或跨账单边界的日期发生变化，账本也能保持严格一致。

QuickTube is an open-source Android app built in Jetpack Compose for searching, watching, and saving videos and music without ads or accounts. It supports YouTube search and playback with live suggestions, trending and music feeds, comments, and an inline player. The app can download from YouTube and more than 1,800 other sites in multiple qualities, or as audio only. It also integrates with Android share sheets, includes a built-in browser that detects videos on a page, and supports playlists, channels, background playback, a downloads gallery, and themes. The author highlights technical work such as on-device merging without re-encoding, HLS to MP4 conversion, and extracting player data from WebView pages.

QuickTube 是一款使用 Jetpack Compose 开发的开源 Android 应用，目标是在没有广告或账号的情况下搜索、观看并保存视频和音乐。它支持 YouTube 的搜索与播放、实时建议、热门和音乐信息流、评论，以及内嵌播放器；同时也能从 YouTube 和 1,800 多个网站下载，提供多种画质或仅音频下载。应用还集成了分享即下载、内置浏览器自动识别页面中的视频、批量处理播放列表和频道，并支持后台播放、下载库与主题。作者也提到其技术重点包括在设备端合并流媒体、将 HLS 转为 MP4，以及从 WebView 读取播放器数据。

This guide explains how to build an Android MVI architecture using Jetpack Compose, Kotlin Coroutines/Flow, and a centralized MviStateStore. It focuses on unidirectional data flow, a single immutable UiState as the source of truth, and pure reducer functions for synchronous, thread-safe state transitions. It also covers handling one-time side effects such as navigation, toasts, and snackbars with Coroutine Channels to avoid re-firing issues after screen rotation, and includes a side-by-side comparison of MVI and MVVM with full Kotlin code examples.

本指南介绍如何在 Android 中结合 Jetpack Compose、Kotlin Coroutines/Flow 和集中式 MviStateStore 构建 MVI 架构。重点包括单向数据流、用单一不可变 UiState 管理整个屏幕状态，以及通过纯 reducer 函数实现同步且线程安全的状态转换。文章还说明如何使用 Coroutine Channels 处理导航、Toast 和 Snackbar 等一次性副作用，避免屏幕旋转后重复触发，并以完整的 Kotlin 示例对比 MVI 和 MVVM。

This entry is Day 10 of a 12-day Android interview preparation plan and centers on performance optimization and Android internals. The provided content is very brief, so it mainly indicates the topic rather than offering detailed explanations or examples. It continues the interview-prep series and points readers to the full article on Medium.

这篇文章是 12 天 Android 面试准备计划的第 10 天，主题聚焦在性能优化与 Android 内部机制。由于正文非常简短，内容主要只是点出本篇主题，没有展开细节或实现说明。整体来看，它是该系列面试准备内容中的一篇，并引导读者前往 Medium 阅读完整文章。

This article examines how flatMapMerge, flatMapConcat, and flatMapLatest behave when applied to the same input in Kotlin Flow. Rather than treating them as interchangeable, it frames the choice as a tradeoff between racing, queuing, and canceling upstream work. The piece also points out that each operator can mask different failure modes in production, making it important to understand their semantics before choosing one for an application.

这篇文章讲解在 Kotlin Flow 中，flatMapMerge、flatMapConcat 和 flatMapLatest 作用于相同输入时会表现出怎样的差异。作者并不把它们当作可互换的选择，而是从竞速、排队和取消上游工作三个角度来分析取舍。文章还指出，这些 operator 可能分别掩盖不同的生产环境故障模式，因此在应用中选择之前，理解它们的语义很重要。

This article presents a practical guide to mutation testing in Kotlin using PIT. It frames the topic around a familiar concern for engineers: green tests do not always mean the tests are effective at catching bugs. The piece promises to walk through mutation testing from the first execution to CI integration, and it also references a real-world scenario plus interview questions. Based on the provided text, the article is an introduction to the approach rather than a claim of results or performance gains.

本文提供了一份使用 PIT 在 Kotlin 中进行 mutation testing 的实用指南，核心问题是：测试全绿，并不一定代表测试真的能发现缺陷。文章将从第一次运行讲到 CI 集成，并配合一个真实场景以及面试题展开说明。根据目前给出的文字，这篇文章主要是方法介绍与实践入口，没有额外声称效果、性能数据或任何已验证的比较结果。

This post argues that Android ViewModels should favor composition over inheritance instead of relying on large shared base classes. It points to Kotlin interface delegation and Lifecycle 2.11 scoping as the mechanisms that can replace bloated BaseViewModel designs. The article’s emphasis is on reducing the need for massive 500-line base classes and structuring ViewModels through smaller, more focused components.

本文主张 Android ViewModel 应采用组合优于继承，而不是依赖庞大的共享基类。作者指出，可以通过 Kotlin 接口委托和 Lifecycle 2.11 的作用域来替代臃肿的 BaseViewModel 设计，减少对大型父类的依赖。重点是不要再用动辄 500 行的 base class，而应以更小、更聚焦的组件来组织 ViewModel。