android

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

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

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

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

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

在 Android 早期开发中，Handler 几乎是“线程切换”的代名词。 更新 UI？ 用 Handler。 延迟执行？ 用 Handler。 子线程和主线程通信？ 还是 Handler。

很多 Android 开发者在学习 Kotlin 和协程时，都会下意识地打开 Android Studio。 但实践证明：这是一个效率很低、挫败感很强的起点。

Data 层往往最容易出现隐性风险：阻塞、错误的并发模型、接口不一致、伪异步等问题会在后期演变成性能瓶颈、线程死锁、不可控的异常，甚至影响业务稳定性。

在协程成为主流之后，我越来越坚定一个观点： 包括： ReentrantLock CountDownLatch Semaphore FutureTask synchronized 不是因为它们不好。

🧭 协程中的三大反模式：真正的问题不在 ViewModel 在 Android 项目中，协程早已成为默认选择。 但很多协程代码的问题，并不体现在“能不能跑”，而是体现在职责边界是否清晰。

为什么我选择不在 ViewModel 里处理异常 在使用 Android MVVM 架构时，ViewModel 应该不要处理异常？ 更准确地说：ViewModel 不应该“深入地”处理异常，

从混乱到清晰：在 Android 项目中实践 Clean Architecture 前言：为什么你的代码越来越难维护？

ReentrantLock 的世界观是： ❌ 锁的 owner 必须是同一个线程 而协程是： ✅ 只要是“同一个协程”，逻辑就是连续的 当线程锁遇到可迁移执行的协程时， 两套宇宙法则发生了冲突。

想象你经营一家外卖公司，公司里有三种角色： 老板（你）：制定送餐规则，关心利润 餐厅经理：准备食物，保证质量 外卖员：把食物送到客户手中 现在，如果你是老板，你不需要知道每个外卖员开什么车

在很多项目里，UseCase 被引入是为了“承载业务逻辑”。 但随着时间推移，它常常变成： Repository 的转发器 ViewModel 的工具类 协程调度中心 线程切换器 甚至是“万能胶水层”

在 Kotlin 协程的世界里，Repository 是否应该启动协程，是一个常见但危险的误区,也是一种典型的反模式。