潜龙勿用之化骨龙

前言 在做 Android 架构评审时，我经常看到这样的代码： ViewModel 在关心什么？它在关心缓存策略、缓存 key 的格式、是否要强制刷新。这些本不该是它的事。 这就是复杂度泄露——一层不

前言 EventBus、Otto，这些曾经风靡 Android 社区的事件总线框架确实在某个时代解决了组件间通信的难题。但随着 Kotlin 协程、Flow、ViewModel 的成熟，事件总线的种种

2026 已经过去三分之一了。 我回头翻了一下这三个月写下的东西，总结总结。 一、先看一眼这些“产出” 三个月，10+ 篇文章，大致分布在四个方向： Clean Architecture 落地实践

在很多 Android 项目中，我们经常能看到各种 Manager： 这些类似乎什么都能做： 管理数据 协调业务 调用网络 操作数据库 维护状态 于是一个 Manager 很容易变成这样： 看起来似乎

前言 在 Android 开发中，我们每天都在和异步打交道——网络请求、数据库查询、磁盘读写。这个问题一直困扰开发者：耗时操作应该谁来负责异步化？ 长久以来，答案默认是：调用方。

在 Android 开发里，大家最常听到的架构模式，基本绕不开两个：MVVM 和 MVI。 很多人会有一个直觉印象： 这句话有点抽象，但放到实际 Android 项目里，会变得非常具体。

在大多数 Android 项目中，UI（Activity / Fragment / ViewMod

SharedPreferences 是「锁模型」，DataStore 是「无锁消息模型」 ，这是思想上的转变。

前言 内存泄露是 Android 面试的必考题，但很多候选人的回答还停留在「用静态内部类 + WeakReference 解决 Handler 泄露」这个层面。 这个答案在 2018 年是正确的