AsyncTask 已死多年：协程到底赢在哪里？

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

一、先聊聊这位"老朋友"：AsyncTask

做 Android 超十年的同学，应该都写过这段代码：

2010 年前后，这东西刚出来的时候，确实让人眼前一亮：

不用自己管 Thread 了
自动帮你切回主线程
比 Handler + Thread 那套优雅多了

当时觉得，Google 这个工具不错。

但用了几年之后，你会发现：

AsyncTask 关注的是线程切换本身，而不是异步逻辑的表达与组织。
它提供的是局部能力，而不是完整的异步解决方案

二、AsyncTask 的三个设计硬伤

很多人以为 AsyncTask 只是"老了"、"API 设计过时了"。

不，它的问题是结构性的。

硬伤一：强制割裂控制流

你的业务逻辑，被这个 API 强行切成两段。

业务简单的时候还好。一旦复杂起来------A 接口的结果决定是否调用 B，B 的结果又要传给 C...

恭喜你，喜提经典的"回调地狱"：

改一行逻辑，要在三个回调之间跳来跳去。

代码 review 的时候，眼睛比脑子先累。

硬伤二：生命周期管理是你的事

这是老 Android 开发的经典噩梦：

后果：

内存泄漏（AsyncTask 隐式持有外部类引用）
空指针（Activity 没了还想 setText）
用户看到 ANR 对话框

你得在 onDestroy() 里手动 cancel()，还得在每个回调里判断 isFinishing()...

本来是想省心的，结果心更累。

硬伤三：线程成了你的思考负担

写 AsyncTask 的时候，你满脑子都是：

这段代码跑在哪个线程？
怎么安全地切回主线程？
默认线程池是串行还是并行？

但你真正想做的事情其实很简单：

请求数据 → 拿到结果 → 更新界面

线程是实现细节，不应该成为业务代码的主角。

公平地说：这不是 AsyncTask 的错

上面说的三个"硬伤"，说实话，不是 AsyncTask 设计者的锅，而是 Java 语言的时代局限。

2010 年前后，Java 没有协程，没有 async/await，甚至连 Lambda 都没有（Java 8 才有，那是 2014 年）。

在那个时代，你想做异步，只有几条路：

方案	问题
`new Thread()`	太原始，线程切换全靠手动
`ExecutorService`	线程池有了，但回调还得自己处理
`AsyncTask`	已经是当时最优雅的封装了
`RxJava`（后来）	学习曲线陡峭，"回调地狱"变成了"操作符地狱"

AsyncTask 在它的时代，已经是一个不错的解决方案了。

问题在于------

它只能在"语言不支持"的前提下，用设计模式去"模拟"异步流程。

这就像在没有高铁的年代，你把绿皮火车优化到极致，它还是跑不过高铁。

协程的出现，是语言层面的升级。 它不是"更好的 AsyncTask"，而是直接改变了游戏规则：

Java 只能用回调 → Kotlin 支持挂起函数
Java 只能切线程 → 协程可以挂起不阻塞
Java 靠约定管理生命周期 → 协程有结构化并发

所以，与其说"AsyncTask 设计得不好"，不如说：

协程解决的是 Java 时代根本无法解决的问题。

三、协程：换了一套思维模型

来看 Kotlin 协程怎么写同样的逻辑：

第一眼看：不就是换了个写法吗？

仔细看：代码是线性的。

请求数据 → 拿到结果 → 更新 UI 没有回调，没有嵌套，读起来就像同步代码。

这才是协程真正的价值------

它让异步代码恢复了"顺序表达"的能力。

四、协程的四个结构性优势

优势一：控制流回归线性

AsyncTask 时代：

协程时代：

逻辑是连贯的，阅读代码不需要在函数间跳来跳去。

优势二：挂起而非阻塞

AsyncTask： 线程在等 I/O 的时候，整个线程干等着，资源浪费。

协程： 遇到 I/O 就挂起，把线程让出来执行其他任务。

打个比方：

AsyncTask 像在银行柜台排队------轮到你之前只能干等。

协程像取号等叫------等待期间你可以去办别的事。

优势三：结构化并发，生命周期自动管理

这一行背后，框架帮你做了：

Activity/Fragment 销毁时，协程自动取消
父协程取消，子协程全部取消
无需手动维护，不会有"野协程"泄漏

十年前我们手写的那些 cancel 逻辑，现在一行代码解决。

优势四：异常处理回归常识

AsyncTask： 异常容易在回调链中丢失，定位问题像开盲盒。

协程：

跟写同步代码一样，符合直觉，符合常识。

五、本质区别

AsyncTask 解决的是"线程怎么切"

协程解决的是"异步逻辑怎么写"

这是两个层次的问题。

打个比方：

AsyncTask 是教你手动挡怎么换
协程是直接给你一辆自动挡

六、真正拉开差距的场景：并发任务组合

单个异步任务，AsyncTask 凑合能用。

但一旦需要"多个任务并行执行，然后汇总结果"------它就力不从心了。

场景：首页需要同时请求三个接口

用户信息
订单列表
推荐内容
全部返回后，才能渲染页面

用 AsyncTask 怎么实现？

方案一：串行嵌套

java 复制代码

请求用户 → 完成后请求订单 → 完成后请求推荐

问题：本来 1 秒能搞定的事，硬是要 3 秒。

方案二：手动协调并发

java 复制代码

AtomicInteger counter = new AtomicInteger(0);

// 三个 AsyncTask 各自执行
// 每个完成后 counter++
// 当 counter == 3 时更新 UI

问题：

代码冗长且脆弱
错误处理逻辑混乱
扩展性差，改需求就是重写

AsyncTask 缺乏任务组合的抽象能力。

就像给你三块积木，但不告诉你怎么拼接。

用协程怎么实现？

简洁、清晰、可扩展。

特性	说明
天然并发	`async { }` 启动即并发
自动同步	`await()` 等待所有结果
错误传播	任一失败，整个 scope 感知
易于扩展	3 个改 30 个，逻辑不变

七、能力对比总结

维度	AsyncTask	协程
单任务异步	✅ 可用	✅ 更优雅
多任务并发	❌ 手动拼凑	✅ 原生支持
任务组合	❌ 无抽象	✅ async/await
异常处理	❌ 容易丢失	✅ try-catch
生命周期	❌ 手动管理	✅ 自动绑定
代码结构	😵 回调嵌套	😊 线性表达

八、最后

协程是线性的，AsyncTask 不是。

这不是修辞，是结构性差异。

AsyncTask 的执行流：

阅读代码时，你的视线需要在多个函数之间来回跳跃。

协程的执行流：

从上到下，逐行阅读，就是执行顺序。

这是协程真正的胜利：

它把分散的异步逻辑，重新组织成线性的代码结构。

线性意味着：

✅ 阅读时无需跳转
✅ 编写时无需思考回调
✅ 维护时无需翻多个文件
✅ 调试时执行路径清晰可循

总结成一句话：

AsyncTask 看起来是断裂的，协程让你看起来是线性的。（虽然他们都是异步的）

写了十年 Android，看着 AsyncTask 从"最佳实践"变成"deprecated"，感慨颇多。技术在进步，思维也要跟着迭代。笔者上次写 AsyncTask 还是十年前的事。。。。。。。。。当前面试 AsyncTask也已无必要。

全文完。