企业官网建设流程全解析

做 Android 开发这些年，面试也好、技术评审也好，“多线程”这三个字几乎是绕不开的必考题。但真正让我警觉的，是前阵子帮一个朋友排查线上卡顿问题：一个看起来人畜无害的图片加载逻辑，硬生生在主线程里同步跑了网络请求，用户滑动列表时整页掉帧，ANR 日志堆了一屏。翻代码的时候我发现，写这段逻辑的同学并不是不会用线程，而是对“Android 到底有几种开线程的方式、每种方式该在什么场景下用、各自的坑在哪”没有形成体系化的认知。这其实很普遍——很多人能背出 Thread、HandlerThread、AsyncTask、线程池、协程这几个名词，但一问到“为什么 AsyncTask 被废弃了”“HandlerThread 的 Looper 到底怎么转起来的”“线程池的核心线程数怎么定”，就开始含糊其辞。

这篇内容我想把 Android 实现多线程的几种方式从头到尾捋一遍，不是罗列 API，而是把每种方式的设计意图、底层原理、适用边界和踩坑经验讲透。适合刚入行、正在准备面试的 Android 开发者，也适合工作几年但一直靠“抄模板”写并发代码、想补上底层认知的朋友。读完之后，你应该能对着一个具体需求，快速判断该用哪种线程方案，并且知道为什么这么选，而不是凭感觉。

1. 先搞清楚：Android 多线程到底在解决什么问题

1.1 主线程模型与 ANR 的因果链

Android 应用启动时，系统会为每个进程创建一个主线程，也叫 UI 线程。这个线程身上挂着一个 Looper，负责不断从消息队列里取消息、分发、执行。所有跟界面相关的操作——View 的测量、布局、绘制，触摸事件的回调，Activity 生命周期的分发——全部跑在这个线程上。系统这么设计的原因很直接：UI 组件不是线程安全的，如果允许多个线程同时改 View 的属性，那状态就彻底乱套了，加锁的成本又高得离谱。所以干脆规定，UI 操作只能在主线程做。

问题在于，主线程只有一个，而它要干的活却越来越多。一次网络请求、一次数据库查询、一次大文件的解析，如果都塞进主线程，消息队列就会被堵住，后续的触摸事件、绘制指令全部排队等待。用户感知到的就是界面卡住不动。当主线程被阻塞超过一定时间（输入事件通常 5 秒、广播 10 秒左右），系统就会弹出 ANR 对话框。这就是为什么耗时的、不确定何时返回的操作必须挪到子线程去。

但挪到子线程只是第一步。子线程算完结果，往往还要更新 UI，而 UI 又只能在主线程改，于是又引出线程间通信的问题。所以“Android 多线程”这件事，本质上包含两个层面：一是把耗时任务从主线程剥离出去，二是把子线程的结果安全地送回主线程。后面讲的每一种方式，其实都是在这两个层面做不同的权衡。

1.2 并发不等于并行，别被名词绕晕

很多人把并发和并行混着用，但在实际写代码时这个区分很重要。并行指的是同一时刻真的有多个任务在多个 CPU 核心上同时执行；并发指的是多个任务在时间片上交替推进，宏观上看像是同时在跑。Android 设备的核心数有限，你开十个线程，操作系统也不可能让十个线程真正同时跑，更多是快速切换。

理解这一点，对后面选型有直接影响。比如你开一堆 Thread 去做 CPU 密集型计算，线程数超过核心数之后，切换开销反而会拖慢整体速度；而如果是 IO 密集型任务（网络、磁盘），线程大部分时间在等待，多开一些线程反而能提高吞吐。这也是为什么线程池要区分核心线程数、最大线程数，以及为什么要针对不同任务类型配置不同的队列策略。把这些底层逻辑想清楚，比记住几个 API 签名有用得多。

2. 方式一：Thread 与 Runnable，最原始也最灵活

2.1 基本用法与两种写法差异

最朴素的起线程方式就是new Thread()。它有两种常见写法：继承 Thread 重写run()，或者实现 Runnable 接口再交给 Thread 执行。从功能上看两者都能跑，但实际项目里我更推荐 Runnable 的写法。原因在于 Java 单继承的限制——你继承了 Thread 就没法再继承别的类，而实现接口则灵活得多。另外 Runnable 把“任务”和“执行机制”解耦了，同一个 Runnable 可以交给 Thread 跑，也可以丢进线程池跑，复用性更好。

// 写法一：实现 Runnable Runnable task = new Runnable() { @Override public void run() { // 耗时逻辑 doHeavyWork(); } }; new Thread(task).start(); // 写法二：继承 Thread class MyThread extends Thread { @Override public void run() { doHeavyWork(); } } new MyThread().start();

这里有个新手常犯的错误：调用run()而不是start()。直接调run()只是在当前线程里同步执行了一遍方法体，根本没有开新线程，主线程照样被阻塞。这个坑我见过不止一次，尤其是在代码重构时不小心把start()改成了run()，表面看逻辑没变，实际并发语义完全丢了。

2.2 Thread 的适用边界与致命短板

Thread 最大的优点是简单直接，没有任何框架封装，你想怎么控制就怎么控制。它适合那种一次性、低频、生命周期短的任务，比如应用启动时上报一次设备信息、某个按钮点击后触发一次独立的后台计算。这种场景下用线程池反而是杀鸡用牛刀。

但它的短板同样明显。第一，线程的创建和销毁是有成本的，每个线程都要占用栈空间（默认 1MB 左右），频繁 new Thread 会造成明显的内存和性能压力。第二，Thread 没有任务管理能力，你开出去的线程无法统一调度、无法复用、无法控制并发数量，任务一多就容易失控。第三，异常处理很麻烦，子线程里抛出的未捕获异常会直接导致线程终止，如果没设置UncaughtExceptionHandler，崩溃信息可能悄无声息地丢掉。第四，Thread 没有内置的结果返回机制，你要拿子线程的计算结果，得自己搞共享变量加等待通知，非常别扭。

所以我的经验是：Thread 只用来做“一次性、无返回值、不需要管理”的简单任务。一旦涉及批量任务、需要复用、需要拿结果，立刻换线程池或者更上层的方案。把它当成最底层的原语看待，而不是日常主力工具。

3. 方式二：Handler 与 HandlerThread，Android 特有的消息驱动模型

3.1 Handler 机制的本质：跨线程投递消息

Handler 是 Android 里最核心的线程通信机制，理解它是理解后面很多方案的基础。它的工作模型可以拆成三个角色：Looper、MessageQueue、Handler。Looper 负责在一个线程里开启消息循环，不断从 MessageQueue 里取消息；MessageQueue 是消息队列，按时间顺序存放待处理的消息；Handler 则是消息的发送者和最终处理者，你通过 Handler 往队列里塞消息，Looper 取出来后交回给 Handler 的handleMessage执行。

关键在于，一个线程只能有一个 Looper，一个 Looper 对应一个 MessageQueue。主线程之所以能处理 UI 事件，就是因为系统在启动时已经给它准备好了 Looper 并让它进入循环。而普通子线程默认是没有 Looper 的，你在子线程里直接 new Handler 会抛异常，提示“Can't create handler inside thread that has not called Looper.prepare()”。

// 子线程里手动准备 Looper new Thread(new Runnable() { @Override public void run() { Looper.prepare(); // 创建当前线程的 Looper Handler handler = new Handler(Looper.myLooper()) { @Override public void handleMessage(Message msg) { // 在这个子线程里处理消息 } }; Looper.loop(); // 开启循环，阻塞在这里 } }).start();

这套机制的精妙之处在于，它把“线程间通信”抽象成了“往队列里投消息”。发送方不需要知道接收方在哪个线程、什么时候处理，只管把消息扔进去；接收方的 Looper 在自己的线程里按顺序取出执行。这就天然实现了线程隔离和顺序性。主线程更新 UI 的标准姿势——handler.post()或者runOnUiThread()——底层走的就是这条路。

3.2 HandlerThread：把 Looper 循环封装成线程

上面那段手动Looper.prepare()加Looper.loop()的代码，其实就是 HandlerThread 干的事。HandlerThread 是 Android 提供的一个封装类，它继承自 Thread，在run()方法里帮你把 Looper 准备好并开启循环，你只需要拿到它的 Looper 构造 Handler 就能用了。

HandlerThread handlerThread = new HandlerThread("worker"); handlerThread.start(); Handler workerHandler = new Handler(handlerThread.getLooper()); workerHandler.post(() -> { // 这个任务会在 handlerThread 这个子线程里串行执行 });

它最大的价值是串行化。所有投递到这个 Handler 的任务，都会在同一个后台线程里按顺序一个接一个执行，不会并发。这个特性在什么场景下特别香？典型的就是需要保证顺序的异步任务，比如日志的按序写入、本地缓存的顺序更新、某些需要串行处理的状态机。你不用担心并发冲突，因为压根就只有一个线程在跑。

但要注意，HandlerThread 的串行特性也是双刃剑。如果某个任务特别耗时，后面排队的任务全得等着，吞吐量上不去。所以它适合“任务量不大但要求顺序”的场景，不适合高并发批量处理。另外，HandlerThread 用完一定要调quit()或quitSafely()释放，否则线程会一直挂着，Looper 循环不退出，造成资源泄漏。quitSafely()会处理完队列里已有的消息再退出，quit()则直接清空，一般推荐前者。

3.3 一个容易忽略的细节：内存泄漏

用 Handler 时最常见的坑就是内存泄漏。非静态内部类或匿名内部类创建的 Handler 会隐式持有外部类（通常是 Activity）的引用，如果此时队列里还有延迟消息没执行完，Activity 已经销毁了，这个引用链就会让 Activity 无法被回收。解决办法有两个：一是把 Handler 声明为静态内部类并配合 WeakReference 持有外部引用；二是在onDestroy里调用handler.removeCallbacksAndMessages(null)清空所有待处理消息。后者更简单直接，我一般优先用它。

4. 方式三：AsyncTask，一个已经退场但值得复盘的老兵

4.1 它的设计初衷与四步回调

AsyncTask 曾经是 Android 官方推荐的异步方案，它的设计目标很明确：帮开发者屏蔽掉线程切换的细节，让你专注在“后台干活 + 前台更新”这个流程上。它定义了四个回调方法，对应任务生命周期的四个阶段：onPreExecute()在后台任务开始前于主线程执行，用来做准备工作；doInBackground()在子线程执行，是真正干活的入口；onProgressUpdate()在主线程执行，用来响应进度更新；onPostExecute()在任务完成后于主线程执行，用来处理结果。

class DownloadTask extends AsyncTask<String, Integer, String> { @Override protected void onPreExecute() { // 主线程：显示进度条 } @Override protected String doInBackground(String... urls) { // 子线程：下载文件，期间可调用 publishProgress 更新进度 return "result"; } @Override protected void onProgressUpdate(Integer... values) { // 主线程：更新进度条 } @Override protected void onPostExecute(String result) { // 主线程：处理结果 } } new DownloadTask().execute("url");

这套回调模型在当年确实降低了异步编程的门槛，很多老项目里到处是 AsyncTask 的身影。但它的缺陷随着 Android 版本演进越来越突出。

4.2 为什么它被废弃：几个绕不过去的硬伤

第一个硬伤是生命周期管理。AsyncTask 跟 Activity 的生命周期没有绑定关系，Activity 旋转屏幕重建或者被销毁时，后台任务还在跑，任务完成回调onPostExecute时可能操作的是一个已经失效的 Activity，轻则无效，重则崩溃。开发者得自己写一堆标志位来判断，代码很快就变得臃肿。

第二个硬伤是版本行为不一致。早期 AsyncTask 是并行执行的，后来为了规避并发问题改成了串行（API 11 之后默认串行），想并行还得显式传线程池参数。这种历史包袱让很多老代码的行为难以预测，同一个 AsyncTask 在不同版本上表现可能不同。

第三个硬伤是异常处理不友好。doInBackground里抛出的异常不会自动传递到主线程，得自己 try-catch 再想办法往外传，很容易漏掉。第四个是内存泄漏风险，跟 Handler 类似，非静态内部类持有外部引用的问题同样存在。

综合下来，官方在 API 30 正式把它标记为废弃，推荐用协程或者线程池替代。我的建议很明确：新项目绝对不要再用 AsyncTask，老项目里遇到就顺手重构掉。它现在唯一的价值是帮你读懂遗留代码，以及面试时能讲清楚它为什么被淘汰。

5. 方式四：线程池，工程化并发的主力方案

5.1 为什么线程池是绕不开的

前面几种方式各有各的局限，而线程池解决的是一组更根本的问题：线程复用、并发控制、任务排队、统一管理。它的核心思想是预先创建一批线程放在池子里，任务来了就交给空闲线程执行，执行完线程不销毁而是回到池子里等下一个任务。这样就避免了频繁创建销毁线程的开销，同时通过队列和最大线程数把并发量控制在可控范围内。

Android 里最常用的线程池入口是Executors工厂类，它提供了几个预设配置。newFixedThreadPool(n)创建固定数量线程的池子，适合负载稳定、需要控制并发的场景；newCachedThreadPool()线程数按需增长、空闲回收，适合大量短小的异步任务；newSingleThreadExecutor()只有一个线程，保证任务严格串行；newScheduledThreadPool(n)支持定时和周期性任务。

// 固定 4 个线程的池子 ExecutorService pool = Executors.newFixedThreadPool(4); pool.execute(() -> { // 后台任务 }); // 需要结果时用 submit 拿 Future Future<String> future = pool.submit(() -> "result"); String result = future.get(); // 注意：get 会阻塞当前线程

5.2 核心参数怎么定：一次算给你看

真正体现功底的不是会用Executors，而是能自己new ThreadPoolExecutor并合理配置参数。它的完整构造参数有七个：核心线程数、最大线程数、空闲线程存活时间、时间单位、任务队列、线程工厂、拒绝策略。任务提交时的处理逻辑是这样的：当前线程数小于核心线程数，直接新建线程执行；核心线程满了，任务进队列排队；队列也满了，线程数还没到最大值，新建线程执行；线程数到最大值且队列满，触发拒绝策略。

核心线程数怎么定，取决于任务类型。业界有个经验公式：CPU 密集型任务，线程数设为 CPU 核心数加一，多出来的一个用于在某个线程偶发阻塞时顶上；IO 密集型任务，线程数设为 CPU 核心数的两倍左右，因为 IO 线程大部分时间在等待，多开一些能提高利用率。假设一台设备是 8 核，做图片压缩这种 CPU 密集任务，核心线程数设 9 左右比较合适；做网络请求这种 IO 密集任务，设 16 左右更合理。当然这只是起点，实际还要结合压测结果微调。

队列的选择也有讲究。ArrayBlockingQueue是有界队列，能防止任务无限堆积导致内存溢出，生产环境我更推荐用它；LinkedBlockingQueue默认容量接近无限，用不好就是内存炸弹；SynchronousQueue不存储任务，来一个就必须有线程接，配合较大的最大线程数适合短任务高吞吐场景。

5.3 拒绝策略与监控，生产环境的必修课

线程池满了之后怎么办，由拒绝策略决定。默认的AbortPolicy直接抛异常，简单粗暴但容易让调用方措手不及；CallerRunsPolicy让提交任务的线程自己执行，相当于给上游施加背压，能起到限流作用；DiscardPolicy和DiscardOldestPolicy都是静默丢弃，除非你明确知道丢任务无所谓，否则不建议用。我一般会根据业务重要性选CallerRunsPolicy或者自定义策略，至少保证任务不丢、问题可见。

还有一个容易被忽视的点是线程池的监控。线上环境里线程池打满、任务堆积是很常见的故障源，如果不做监控，出了问题只能靠猜。建议在创建线程池时重写beforeExecute、afterExecute记录任务耗时，定期打印活跃线程数、队列长度这些指标。另外线程工厂里给线程起个有意义的名字，排查问题时看线程栈能一眼定位是哪个池子出的问题，这个习惯能省下大量排查时间。

6. 方式五：Kotlin 协程，现代 Android 并发的主流选择

6.1 协程解决的核心痛点：回调地狱与线程切换

如果说线程池解决的是“怎么高效地跑任务”，那协程解决的是“怎么优雅地写异步代码”。传统异步写法里，多个有依赖的异步操作会层层嵌套，形成所谓的回调地狱，代码横向展开、可读性极差，错误处理也散落各处。协程用挂起函数把异步逻辑写成了看起来像同步的顺序代码，编译器在背后帮你做了状态保存和恢复。

// 传统回调嵌套 api.getUser(userId, user -> { api.getOrders(user, orders -> { api.getDetail(orders, detail -> { // 层层嵌套 }); }); }); // 协程写法 lifecycleScope.launch { val user = api.getUser(userId) // 挂起，不阻塞线程 val orders = api.getOrders(user) val detail = api.getDetail(orders) // 顺序清晰 }

关键在于“挂起”这个词。挂起不等于阻塞，协程挂起时它所在的线程会被释放出来去干别的事，等结果回来了再恢复执行。这意味着用很少的线程就能支撑大量的并发任务，资源利用率比传统线程模型高得多。

6.2 作用域与调度器：协程落地的两个关键概念

协程不是随便launch就完事，它必须跑在一个 CoroutineScope 里，作用域决定了协程的生命周期。Android 里常用的几个作用域：lifecycleScope跟随 Activity/Fragment 生命周期，销毁时自动取消；viewModelScope跟随 ViewModel；GlobalScope是全局的，但因为它不跟任何生命周期绑定，容易造成泄漏，我基本不用。选对作用域，很多生命周期相关的崩溃就自动消失了。

调度器决定协程跑在哪个线程。Dispatchers.Main是主线程，用于更新 UI；Dispatchers.IO是 IO 优化过的线程池，适合网络和磁盘操作；Dispatchers.Default是 CPU 密集型任务的线程池；Dispatchers.Unconfined不切换线程，一般只在特殊场景用。实际写法通常是withContext(Dispatchers.IO) { ... }把耗时块切到 IO 线程，执行完自动切回来。

viewModelScope.launch { val data = withContext(Dispatchers.IO) { repository.loadData() // 在 IO 线程执行 } updateUi(data) // 自动回到主线程 }

6.3 协程不是银弹：几个必须知道的坑

协程写起来爽，但坑也不少。第一，挂起函数必须在协程或另一个挂起函数里调用，初学者经常在普通函数里直接调挂起函数然后编译报错，得理解这个约束的本质是“挂起需要上下文”。第二，异常处理机制和传统 try-catch 不完全一样，launch里未捕获的异常会直接抛给父作用域导致崩溃，而async的异常要等await()时才抛出，用错容易漏掉异常。第三，取消是协作式的，协程被取消后不会立刻停止，得在代码里检查isActive或者调用挂起函数才能响应取消，纯计算循环里不检查的话取消是无效的。第四，别在协程里做阻塞调用，比如在Dispatchers.Default里调Thread.sleep，那会占着线程不放，失去了协程的意义。

7. 几种方式的横向对比与选型建议

7.1 一张表看清各自定位

7.2 我的实际选型逻辑

面对一个具体需求，我通常按这个顺序判断：如果是新项目、用 Kotlin，优先协程，配合作用域和调度器，代码最简洁、生命周期最安全；如果是 Java 项目或者需要精细控制并发参数，用线程池，自己配核心参数和拒绝策略；如果任务要求严格串行且量不大，HandlerThread 或者单线程池都行；如果只是一次性的、跑完就完的简单任务，直接 new Thread 也无妨，没必要为了“规范”硬套线程池。

有一点要强调：不要为了用而用。我见过有人为了一个只执行一次的后台任务专门建了个线程池，纯属增加复杂度。选型的核心是匹配场景，而不是追求技术上的“高级感”。

8. 实操中踩过的坑与排查经验

8.1 子线程更新 UI 的隐蔽崩溃

最经典的坑就是在子线程直接操作 View。有些情况下它不崩，比如你改的是还没 attach 到窗口的 View，或者改的属性不触发重绘，于是有人误以为“子线程也能改 UI”。但只要触发了requestLayout或者invalidate，就会抛CalledFromWrongThreadException。我的做法是养成肌肉记忆：任何涉及 View 的代码，先问自己“这行在哪个线程跑”。用协程的话，Dispatchers.Main明确切回来；用线程池的话，结果通过 Handler 或者runOnUiThread送回主线程。

8.2 线程池打满导致的连锁超时

有一次线上出现大面积接口超时，排查发现是一个公共线程池被某个批量任务占满了，其他模块的任务全在队列里排队。根因是那个批量任务用了newFixedThreadPool但任务量远超预期，队列无限增长，线程全被长任务占着。后来我们做了两件事：一是给线程池换成有界队列并配置合理的拒绝策略，二是把不同业务拆到独立线程池，避免互相影响。这个教训让我明白，线程池隔离和有界队列在生产环境几乎是必须的。

8.3 常见问题速查表

8.4 几个提升稳定性的小习惯

给线程起名字，排查问题时线程栈里一眼能认出来；线程池的submit返回的 Future 如果不需要结果，记得处理异常，否则异常会被吞掉；HandlerThread 用完及时quitSafely；协程里做资源操作记得用try-finally或者use保证释放。这些都是小事，但线上出问题时，往往就是这些小事决定了你排查的速度。

最后分享一个我自己的体会：多线程的难点从来不是“怎么开一个线程”，而是“怎么让多个线程安全、高效、可维护地协作”。把每种方式的边界想清楚，把生命周期和异常处理这两件事盯死，大部分并发问题都能提前规避掉。真正写代码时，能少开线程就少开，能复用就复用，能交给成熟框架就别自己造轮子——这条原则我用了很多年，至今没让我失望过。