Kotlin

前言 在做 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 前言：为什么你的代码越来越难维护？

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

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

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

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

如果说前几年我是在“捡 API、抄 Demo、补锅”，那 2025 就是我开始“写自己的框架”的一年。 我不追热点、不卷新概念。 我更像是在给自己搭一个“能复用、能解释、能传给别人”的技术体系。

在 Kotlin 协程的响应式编程中，SharedFlow 作为热流（Hot Flow）的核心组件，被广泛应用于状态管理、事件总线等场景。

在 Kotlin 协程友好的 API 中，常见两类函数： suspend functions：返回单一结果 普通函数返回 Flow：返回一个结果流 这两类函数在 Room DAO 等库中都有体现。

Retrofit 是一款广受欢迎的 HTTP 客户端库，以其优雅的声明式 API 设计深受开发者喜爱。本文将通过模拟实现，逐步解析 Retrofit 的核心机制。

异常处理是保障应用稳健性的基石，在不同开发环境中，异常的表现与处理方式大相径庭。本文将带您解码Java、Android与Kotlin协程中的异常行为差异，剖析常见陷阱。

Kotlin 协程提供了一种简洁而强大的方式来处理异步编程。runBlocking 是协程库中的一个重要构造器，它允许我们在协程中运行代码并阻塞当前线程，直到协程完成。

在并发编程中，队列是一个非常重要的数据结构，尤其是在生产者-消费者模式中。Java的阻塞队列（如ArrayBlockingQueue和PriorityBlockingQueue）提供了强大的并发支持，