android

很多人第一次接触 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（嵌套回调） 实现代

基于 Android 17 AOSP 真实源码分析。 这不是简单优化，而是： 一、为什么必须重构？ 旧版 MessageQueue 的问题不在于"写得不好"，而在于它生于单核时代，

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

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

前言 在做 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 年是正确的