Kotlin

前言 在 Android 开发里，MVVM 和 MVI 几乎是绕不开的两个词。 很多人刚开始接触架构时，都会冒出同一个疑问： 有人说算，因为项目里确实是"按 MVVM 写的"；有人说不算，因为它们只管

很多人第一次接触 Clean Architecture 时，会产生一个非常典型的误解： 尤其在 Android + Kotlin 的语境下，这种印象会被进一步强化： 调用时： 看起来既优雅又"标准"。

一、一个 iOS 开发者，把我问住了 上周，一个刚从 iOS 转过来的同事问我： 我下意识想回答：“因为生命周期不稳定”。 但话到嘴边，我停住了。 这个答案——是对的，但不够本质。 于是我们从 Act

一、早期的说法：协程 = 轻量级线程 Kotlin 1.1 刚推出协程时，官方文档里直接写着： Kotlin 1.1 Coroutines 官方文档 当时这样宣传完全合理。那几年大家还在被 Threa

在 Android Clean Architecture 或常见分层设计中，很多人都会遇到一个问题： 不少教程默认给出这样的结构： 看起来很“标准”，但在实际项目中，如果不加思考地套用，很容易导致过度

在现代开发中，我们越来越多地写出这样的代码： ![image.png](https://p0-

> **AsyncTask 的退场，不是一个 API 的废弃，而是一种编程思维的终结。** #

> 📌 本文面向有 Android 基础、了解协程基本用法，但尚未接触 Clean Archit

📌 场景定义 这个"3并1串"的模式在真实业务中极为常见，比如：首页同时拉取轮播图、文章列表、置顶文章，全部就绪后再根据结果请求个性化推荐。 方案一：Java Callbacks（嵌套回调） 实现代

大家都见过这样的代码： 看起来很优雅，对吧？ 但当你点进 BaseActivity： 👉 2000 行 👉 十几个功能混在一起 👉 没人敢改 很多 Android 项目，都是这样“慢慢烂掉”的。

> **摘要**： ANR 从来不是突然出现的意外，而是主线程长期带病运行的结果。本文从"幽门螺

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

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

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

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

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

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

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

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

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