1. 多线程这件事为什么值得反复聊Android 开发干到一定年头你会发现一个规律UI 卡顿、ANR、数据错乱、内存泄漏追到根上十有八九都跟线程调度脱不了干系。我刚入行那会儿觉得new Thread().start()就能解决一切结果项目里线程越开越多最后连崩溃日志都看不出是谁闯的祸。后来才明白Android 的多线程不是“会不会开线程”的问题而是“在什么场景下选什么工具、怎么管住它们”的问题。这篇内容想聊的就是 Android 实现多线程的几种主流方式从最原始的Thread到HandlerThread、ExecutorService、AsyncTask虽然已废弃但老项目里还大量存在、IntentService、Kotlin协程再到WorkManager这类偏调度的方案。每一种我都会说清楚它解决什么问题、适合什么场景、坑在哪里。适合谁看刚接触 Android 不久、对线程切换还犯迷糊的新人以及写过一些代码但总觉得线程管理“差点意思”的中级开发者。读完你至少能做到拿到一个需求能快速判断该用哪种线程方案而不是条件反射地new Thread。需要先明确一个前提Android 的主线程UI 线程负责处理用户交互和界面刷新任何耗时操作放在主线程超过 5 秒左右就会触发 ANR。所以多线程的核心诉求其实就两条——把耗时任务挪出主线程以及把结果安全地送回主线程。所有的方案本质上都是围绕这两件事在做文章区别只在于封装程度、调度能力和生命周期管理。2. 先搞清楚线程模型这块地基2.1 主线程与工作线程的分工边界Android 应用启动时会自动创建一个主线程也叫 UI 线程它内部维护着一个Looper不断从MessageQueue里取消息来执行。你在onCreate里写的代码、按钮点击回调、View的绘制全都跑在这个线程上。工作线程则是我们手动创建的它默认没有Looper执行完run()方法就结束不能直接更新 UI。这里有个新手常踩的坑在工作线程里直接调用TextView.setText()运气好没崩运气差直接抛CalledFromWrongThreadException。原因是 Android 的 View 体系不是线程安全的系统干脆用检查机制把这个口子堵死。所以“切回主线程”这件事是每种多线程方案都必须回答的问题。2.2 线程切换的本质是消息传递很多人把线程切换想得很玄乎其实底层就是HandlerLooperMessageQueue这套机制。工作线程把结果封装成Message或Runnable通过Handler投递到主线程的MessageQueue主线程的Looper循环取出并执行。理解了这一点你再看runOnUiThread、View.post、Handler.post会发现它们只是同一套机制的不同马甲。我习惯用一个类比MessageQueue是传送带Handler是往传送带上放包裹的人Looper是那个不停从传送带上取包裹拆开看的工人。工作线程想跟主线程说话就得通过Handler这个“放包裹的人”把话递过去。这个模型想通了后面所有方案的理解都会顺很多。2.3 线程安全问题的根源在哪多线程带来的不只是切换问题还有共享数据的竞争。两个线程同时对一个int变量做自增结果可能少加了一次因为i不是原子操作它包含读取、计算、写回三步。Android 里常见的场景是网络请求回来后更新一个列表同时用户又在滑动列表触发读取如果没做同步就可能抛ConcurrentModificationException。解决手段无非几种加锁synchronized、ReentrantLock、使用线程安全容器ConcurrentHashMap、CopyOnWriteArrayList、或者干脆用消息机制把并发变成串行HandlerThread就是这个思路。选哪种取决于你的数据访问频率和冲突概率这个后面会结合具体方案展开。3. 几种主流实现方式逐个拆解3.1 最原始的 Thread简单但不好管Thread是 Java 层面的基础能力Android 完全继承了过来。写法很直接new Thread(new Runnable() { Override public void run() { // 耗时操作比如读文件、解析数据 String result doSomethingHeavy(); // 切回主线程更新 UI runOnUiThread(() - textView.setText(result)); } }).start();它的优点是零依赖、上手快适合一次性、短生命周期的任务。但问题也很明显每次任务都新建线程线程创建和销毁本身有开销线程数量不受控开多了会拖垮系统没有统一的取消机制任务跑到一半想停都停不下来异常也没人兜底run()里抛出的异常会直接导致线程终止日志里还不一定看得清楚。我的经验是Thread只适合写 Demo 或者极其简单的场景。真实项目里如果到处new Thread后期维护会非常痛苦。曾经接手过一个项目光搜索new Thread就出来上百处排查一个偶现的并发问题时几乎无从下手。3.2 HandlerThread给线程配一个消息队列HandlerThread的本质是一个自带Looper的Thread。普通Thread执行完就没了而HandlerThread启动后会进入Looper.loop()的无限循环不断从自己的MessageQueue里取任务执行直到你调用quit()。HandlerThread handlerThread new HandlerThread(worker); handlerThread.start(); Handler workerHandler new Handler(handlerThread.getLooper()); workerHandler.post(() - { // 这里的任务会串行执行 processTask(); });它最大的价值是把并发变成了串行。所有投递到这个Handler的任务都排在同一队列里一个执行完再执行下一个天然避免了多线程竞争。适合什么场景比如本地数据库的连续写入、日志的按序落盘、需要保证执行顺序的串行任务链。坑在于它是串行的如果你投了一个耗时很长的任务进去后面的任务全得等着。另外用完必须调用quitSafely()释放否则线程一直挂着在Activity销毁后还持有引用就会泄漏。我一般会在onDestroy里显式清理别指望 GC 帮你兜底。3.3 ExecutorService线程池才是正经干活的主力线程池是我在项目里用得最多的方案没有之一。它的核心思想是复用线程、控制并发数量、统一管理任务队列。Android 里常用的创建方式有几种// 固定数量线程池适合任务量稳定、需要控制并发的场景 ExecutorService fixedPool Executors.newFixedThreadPool(4); // 缓存线程池适合大量短小任务线程数按需增长 ExecutorService cachedPool Executors.newCachedThreadPool(); // 单线程池保证任务按提交顺序串行执行 ExecutorService singlePool Executors.newSingleThreadExecutor(); // 定时/周期任务 ScheduledExecutorService scheduledPool Executors.newScheduledThreadPool(2);不过在实际项目里我更推荐直接用ThreadPoolExecutor手动配置参数因为Executors的几个工厂方法藏着坑。比如newCachedThreadPool的最大线程数是Integer.MAX_VALUE任务暴涨时可能创建海量线程直接把内存撑爆newFixedThreadPool和newSingleThreadExecutor用的是无界队列任务堆积过多会 OOM。手动配置长这样ThreadPoolExecutor executor new ThreadPoolExecutor( 4, // 核心线程数 8, // 最大线程数 60L, TimeUnit.SECONDS, // 空闲线程存活时间 new ArrayBlockingQueue(64), // 有界任务队列 new ThreadFactory() { // 自定义线程名方便排查 private final AtomicInteger count new AtomicInteger(1); Override public Thread newThread(Runnable r) { return new Thread(r, biz-pool- count.getAndIncrement()); } }, new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略 );参数怎么定核心线程数一般参考 CPU 核数计算密集型任务设为CPU 核数 1IO 密集型可以设大一些比如CPU 核数 * 2。队列容量要结合任务产生速度和消费速度来估宁可设小一点配合合理的拒绝策略也别用无界队列把问题藏起来。拒绝策略里CallerRunsPolicy比较温和队列满了就让提交任务的线程自己跑起到一个天然的降速作用。线程工厂里给线程起名字这个细节很多人忽略但排查问题时特别有用。崩溃日志里看到biz-pool-3和看到pool-1-thread-3定位效率完全不一样。3.4 AsyncTask曾经的宠儿如今的遗产AsyncTask在早期 Android 开发里几乎是标配它把“后台执行 进度更新 结果回调”封装成了一个模板方法。写法上继承AsyncTask重写doInBackground、onPostExecute、onProgressUpdate等方法。但它在 Android 11API 30已经被正式标记为废弃。原因有几条一是它内部默认用串行执行器多个AsyncTask实例之间容易互相阻塞二是不处理生命周期Activity销毁后回调还可能触发导致崩溃或泄漏三是异常处理很别扭doInBackground里抛的异常不会自动传到onPostExecute。老项目里如果还在用我的建议是逐步替换成协程或线程池 Handler的组合别在新代码里继续引入。如果只是维护至少注意两点不要在Activity销毁后还持有AsyncTask引用以及cancel()要配合isCancelled()检查使用否则取消不生效。3.5 IntentService后台串行任务的旧方案IntentService继承自Service内部用HandlerThread实现所有通过startService传进来的Intent会排队串行处理处理完自动停止。它适合“触发一次、后台做完就结束”的任务比如上传日志、同步数据。public class UploadService extends IntentService { public UploadService() { super(UploadService); } Override protected void onHandleIntent(Intent intent) { // 在后台线程执行处理完自动 stopSelf uploadData(intent.getStringExtra(path)); } }它在 Android 8.0 之后受后台执行限制影响很大加上本身在 API 30 也被废弃现在基本被WorkManager取代。了解它的存在主要是为了读懂老代码新项目不建议再用。3.6 Kotlin 协程现代 Android 的首选如果项目已经上了 Kotlin协程基本是当前多线程方案的最优解。它最大的优势是用同步的写法表达异步的逻辑把回调地狱拍平了。lifecycleScope.launch { val data withContext(Dispatchers.IO) { // 自动切到 IO 线程池执行 repository.fetchData() } // 自动切回主线程 textView.text data }Dispatchers.IO适合网络和磁盘操作Dispatchers.Default适合 CPU 密集型计算Dispatchers.Main就是主线程。withContext会自动处理线程切换和结果返回代码读起来跟同步调用一样顺。协程还有两个杀手锏结构化并发和取消传播。lifecycleScope绑定生命周期Activity销毁时协程自动取消不用手动管理父协程取消时子协程跟着取消不会出现任务跑飞的情况。异常处理也统一try-catch直接包住withContext就行。需要注意的是协程不是“没有线程”它底层还是跑在线程池上只是调度更聪明。另外别在GlobalScope里随便launch那样就失去了结构化并发的意义跟裸开线程区别不大。3.7 WorkManager需要保证执行的任务交给它WorkManager严格来说不是“多线程方案”而是“可延迟、可保证执行的后台任务调度框架”。它适合那些“不要求立即执行但要求最终一定执行”的任务比如数据同步、日志上报、定期清理缓存。val request OneTimeWorkRequestBuilderSyncWorker() .setConstraints( Constraints.Builder() .setRequiredNetworkType(NetworkType.CONNECTED) .build() ) .build() WorkManager.getInstance(context).enqueue(request)它内部会根据系统版本和任务条件选择合适的执行方式可能用线程池也可能用JobScheduler。约束条件网络、电量、充电状态和设备重启后的恢复能力是它的核心价值。但如果你需要立即拿到结果或者任务跟 UI 强相关那它就不合适老老实实用协程或线程池。4. 方案选型的判断逻辑与对比4.1 按场景对号入座选型这件事我总结了一个简单的判断路径任务要不要立即执行要就看是不是跟 UI 生命周期绑定绑定就用协程的lifecycleScope不绑定就用线程池不要立即执行、但要保证最终执行用WorkManager需要严格串行且带消息循环用HandlerThread只是写个临时脚本或极简 DemoThread也不是不能用。下面这张表是我平时给团队新人做参考的对比参数和结论都来自实际项目经验方案线程复用生命周期感知任务取消适用场景现状建议Thread否否困难极简一次性任务仅限 DemoHandlerThread是单线程否需手动 quit串行消息处理特定场景可用ExecutorService是否通过 Future通用并发任务主力方案之一AsyncTask是否有但不可靠老项目遗留逐步替换IntentService是单线程否有限老项目后台任务已被取代Kotlin 协程是是自动传播现代 Android 开发首选WorkManager是部分支持可延迟保证执行后台调度首选4.2 线程数量到底开多少合适这个问题没有标准答案但有个估算思路。假设你的任务以网络请求为主属于 IO 密集型线程大部分时间在等网络返回CPU 是闲着的那线程数可以适当多一些比如 8 到 16 个如果是图片压缩、数据加密这类 CPU 密集型任务线程开多了反而因为上下文切换变慢一般控制在 CPU 核数附近。我通常的做法是先按经验值配一个初始参数然后在测试环境用ThreadPoolExecutor的getActiveCount()、getQueue().size()观察实际负载再微调。别一上来就追求“最优参数”先跑起来看数据比拍脑袋靠谱。4.3 生命周期管理是绕不开的坎不管用哪种方案只要任务跟Activity或Fragment绑定就必须考虑生命周期。工作线程持有Activity引用Activity销毁后线程还在跑轻则回调空指针重则内存泄漏。协程的lifecycleScope和viewModelScope之所以好用就是因为把这件事自动化了。用线程池的话我一般会在onDestroy里取消所有未完成的任务或者用弱引用包装回调。Handler的话记得removeCallbacksAndMessages(null)。这些清理动作写起来琐碎但不写迟早出事。5. 实操中的坑与排查实录5.1 常见问题速查下面这些是我和团队在实际项目里反复遇到的整理成表格方便对照现象可能原因排查方向解决思路偶发 ANR主线程有耗时操作看 ANR 日志的主线程堆栈把耗时逻辑挪到工作线程更新 UI 崩溃在非主线程操作 View检查回调所在线程用 Handler 或协程切回主线程数据错乱共享变量无同步检查多线程读写点加锁或用线程安全容器内存泄漏线程持有 Activity 引用用内存分析工具看引用链弱引用或及时取消任务任务不执行线程池队列满或已 shutdown看拒绝策略和池状态调整队列容量或拒绝策略回调不触发任务被取消或线程已退出检查 cancel 和 quit 调用确认生命周期与取消时机5.2 一个真实的排查案例之前有个页面偶尔卡死日志里没有明显异常。后来用主线程堆栈抓了几次发现卡在一个synchronized块上。原因是工作线程持锁做网络请求主线程等这把锁去读缓存网络一慢主线程就跟着卡。这种问题的根子在于锁的粒度太大把不该保护的耗时操作也包进去了。改法是把网络请求挪到锁外面锁只保护内存数据的读写并且换成读写锁ReentrantReadWriteLock读多写少的场景下并发度明显提升。这个案例说明多线程问题很多时候不是“线程开错了”而是“共享数据的访问方式设计得不对”。5.3 几条踩出来的经验第一给线程起名字。不管是线程池的ThreadFactory还是HandlerThread的构造参数都别偷懒。排查问题时日志里一个有意义的名字能省半小时。第二别在循环里创建线程。见过有人在for循环里new Thread一千条数据开一千个线程手机直接卡成幻灯片。正确做法是交给线程池或者用协程的async并发处理再awaitAll。第三异常一定要兜住。工作线程里抛出的未捕获异常默认行为是终止线程而且不一定打到你能看到的日志里。线程池可以设置UncaughtExceptionHandler协程用CoroutineExceptionHandler别让异常悄悄溜走。第四测试并发问题要有耐心。并发 bug 往往在低概率下才出现本地跑十次没事不代表没问题。我习惯在关键路径上加一些日志埋点配合压力测试多跑几轮比单纯靠肉眼 review 靠谱。6. 我个人的选型习惯干到现在我自己的默认选择很明确新项目一律 Kotlin 协程打底跟 UI 相关的用lifecycleScope或viewModelScope纯后台计算用Dispatchers.Default网络和磁盘用Dispatchers.IO需要保证最终执行的后台任务交给WorkManager只有在维护老 Java 代码或者需要极精细控制线程池参数时才手动配置ThreadPoolExecutor。Thread、AsyncTask、IntentService这些基本只在读老代码时才会碰。协程虽好但也别神化它。它解决的是调度和生命周期的麻烦不解决你代码本身的逻辑问题。该加锁的地方还得加锁该注意的线程安全一样跑不掉。工具是工具思路才是根本。
1. 多线程这件事为什么值得反复聊Android 开发干到一定年头你会发现一个规律UI 卡顿、ANR、数据错乱、内存泄漏追到根上十有八九都跟线程调度脱不了干系。我刚入行那会儿觉得new Thread().start()就能解决一切结果项目里线程越开越多最后连崩溃日志都看不出是谁闯的祸。后来才明白Android 的多线程不是“会不会开线程”的问题而是“在什么场景下选什么工具、怎么管住它们”的问题。这篇内容想聊的就是 Android 实现多线程的几种主流方式从最原始的Thread到HandlerThread、ExecutorService、AsyncTask虽然已废弃但老项目里还大量存在、IntentService、Kotlin协程再到WorkManager这类偏调度的方案。每一种我都会说清楚它解决什么问题、适合什么场景、坑在哪里。适合谁看刚接触 Android 不久、对线程切换还犯迷糊的新人以及写过一些代码但总觉得线程管理“差点意思”的中级开发者。读完你至少能做到拿到一个需求能快速判断该用哪种线程方案而不是条件反射地new Thread。需要先明确一个前提Android 的主线程UI 线程负责处理用户交互和界面刷新任何耗时操作放在主线程超过 5 秒左右就会触发 ANR。所以多线程的核心诉求其实就两条——把耗时任务挪出主线程以及把结果安全地送回主线程。所有的方案本质上都是围绕这两件事在做文章区别只在于封装程度、调度能力和生命周期管理。2. 先搞清楚线程模型这块地基2.1 主线程与工作线程的分工边界Android 应用启动时会自动创建一个主线程也叫 UI 线程它内部维护着一个Looper不断从MessageQueue里取消息来执行。你在onCreate里写的代码、按钮点击回调、View的绘制全都跑在这个线程上。工作线程则是我们手动创建的它默认没有Looper执行完run()方法就结束不能直接更新 UI。这里有个新手常踩的坑在工作线程里直接调用TextView.setText()运气好没崩运气差直接抛CalledFromWrongThreadException。原因是 Android 的 View 体系不是线程安全的系统干脆用检查机制把这个口子堵死。所以“切回主线程”这件事是每种多线程方案都必须回答的问题。2.2 线程切换的本质是消息传递很多人把线程切换想得很玄乎其实底层就是HandlerLooperMessageQueue这套机制。工作线程把结果封装成Message或Runnable通过Handler投递到主线程的MessageQueue主线程的Looper循环取出并执行。理解了这一点你再看runOnUiThread、View.post、Handler.post会发现它们只是同一套机制的不同马甲。我习惯用一个类比MessageQueue是传送带Handler是往传送带上放包裹的人Looper是那个不停从传送带上取包裹拆开看的工人。工作线程想跟主线程说话就得通过Handler这个“放包裹的人”把话递过去。这个模型想通了后面所有方案的理解都会顺很多。2.3 线程安全问题的根源在哪多线程带来的不只是切换问题还有共享数据的竞争。两个线程同时对一个int变量做自增结果可能少加了一次因为i不是原子操作它包含读取、计算、写回三步。Android 里常见的场景是网络请求回来后更新一个列表同时用户又在滑动列表触发读取如果没做同步就可能抛ConcurrentModificationException。解决手段无非几种加锁synchronized、ReentrantLock、使用线程安全容器ConcurrentHashMap、CopyOnWriteArrayList、或者干脆用消息机制把并发变成串行HandlerThread就是这个思路。选哪种取决于你的数据访问频率和冲突概率这个后面会结合具体方案展开。3. 几种主流实现方式逐个拆解3.1 最原始的 Thread简单但不好管Thread是 Java 层面的基础能力Android 完全继承了过来。写法很直接new Thread(new Runnable() { Override public void run() { // 耗时操作比如读文件、解析数据 String result doSomethingHeavy(); // 切回主线程更新 UI runOnUiThread(() - textView.setText(result)); } }).start();它的优点是零依赖、上手快适合一次性、短生命周期的任务。但问题也很明显每次任务都新建线程线程创建和销毁本身有开销线程数量不受控开多了会拖垮系统没有统一的取消机制任务跑到一半想停都停不下来异常也没人兜底run()里抛出的异常会直接导致线程终止日志里还不一定看得清楚。我的经验是Thread只适合写 Demo 或者极其简单的场景。真实项目里如果到处new Thread后期维护会非常痛苦。曾经接手过一个项目光搜索new Thread就出来上百处排查一个偶现的并发问题时几乎无从下手。3.2 HandlerThread给线程配一个消息队列HandlerThread的本质是一个自带Looper的Thread。普通Thread执行完就没了而HandlerThread启动后会进入Looper.loop()的无限循环不断从自己的MessageQueue里取任务执行直到你调用quit()。HandlerThread handlerThread new HandlerThread(worker); handlerThread.start(); Handler workerHandler new Handler(handlerThread.getLooper()); workerHandler.post(() - { // 这里的任务会串行执行 processTask(); });它最大的价值是把并发变成了串行。所有投递到这个Handler的任务都排在同一队列里一个执行完再执行下一个天然避免了多线程竞争。适合什么场景比如本地数据库的连续写入、日志的按序落盘、需要保证执行顺序的串行任务链。坑在于它是串行的如果你投了一个耗时很长的任务进去后面的任务全得等着。另外用完必须调用quitSafely()释放否则线程一直挂着在Activity销毁后还持有引用就会泄漏。我一般会在onDestroy里显式清理别指望 GC 帮你兜底。3.3 ExecutorService线程池才是正经干活的主力线程池是我在项目里用得最多的方案没有之一。它的核心思想是复用线程、控制并发数量、统一管理任务队列。Android 里常用的创建方式有几种// 固定数量线程池适合任务量稳定、需要控制并发的场景 ExecutorService fixedPool Executors.newFixedThreadPool(4); // 缓存线程池适合大量短小任务线程数按需增长 ExecutorService cachedPool Executors.newCachedThreadPool(); // 单线程池保证任务按提交顺序串行执行 ExecutorService singlePool Executors.newSingleThreadExecutor(); // 定时/周期任务 ScheduledExecutorService scheduledPool Executors.newScheduledThreadPool(2);不过在实际项目里我更推荐直接用ThreadPoolExecutor手动配置参数因为Executors的几个工厂方法藏着坑。比如newCachedThreadPool的最大线程数是Integer.MAX_VALUE任务暴涨时可能创建海量线程直接把内存撑爆newFixedThreadPool和newSingleThreadExecutor用的是无界队列任务堆积过多会 OOM。手动配置长这样ThreadPoolExecutor executor new ThreadPoolExecutor( 4, // 核心线程数 8, // 最大线程数 60L, TimeUnit.SECONDS, // 空闲线程存活时间 new ArrayBlockingQueue(64), // 有界任务队列 new ThreadFactory() { // 自定义线程名方便排查 private final AtomicInteger count new AtomicInteger(1); Override public Thread newThread(Runnable r) { return new Thread(r, biz-pool- count.getAndIncrement()); } }, new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略 );参数怎么定核心线程数一般参考 CPU 核数计算密集型任务设为CPU 核数 1IO 密集型可以设大一些比如CPU 核数 * 2。队列容量要结合任务产生速度和消费速度来估宁可设小一点配合合理的拒绝策略也别用无界队列把问题藏起来。拒绝策略里CallerRunsPolicy比较温和队列满了就让提交任务的线程自己跑起到一个天然的降速作用。线程工厂里给线程起名字这个细节很多人忽略但排查问题时特别有用。崩溃日志里看到biz-pool-3和看到pool-1-thread-3定位效率完全不一样。3.4 AsyncTask曾经的宠儿如今的遗产AsyncTask在早期 Android 开发里几乎是标配它把“后台执行 进度更新 结果回调”封装成了一个模板方法。写法上继承AsyncTask重写doInBackground、onPostExecute、onProgressUpdate等方法。但它在 Android 11API 30已经被正式标记为废弃。原因有几条一是它内部默认用串行执行器多个AsyncTask实例之间容易互相阻塞二是不处理生命周期Activity销毁后回调还可能触发导致崩溃或泄漏三是异常处理很别扭doInBackground里抛的异常不会自动传到onPostExecute。老项目里如果还在用我的建议是逐步替换成协程或线程池 Handler的组合别在新代码里继续引入。如果只是维护至少注意两点不要在Activity销毁后还持有AsyncTask引用以及cancel()要配合isCancelled()检查使用否则取消不生效。3.5 IntentService后台串行任务的旧方案IntentService继承自Service内部用HandlerThread实现所有通过startService传进来的Intent会排队串行处理处理完自动停止。它适合“触发一次、后台做完就结束”的任务比如上传日志、同步数据。public class UploadService extends IntentService { public UploadService() { super(UploadService); } Override protected void onHandleIntent(Intent intent) { // 在后台线程执行处理完自动 stopSelf uploadData(intent.getStringExtra(path)); } }它在 Android 8.0 之后受后台执行限制影响很大加上本身在 API 30 也被废弃现在基本被WorkManager取代。了解它的存在主要是为了读懂老代码新项目不建议再用。3.6 Kotlin 协程现代 Android 的首选如果项目已经上了 Kotlin协程基本是当前多线程方案的最优解。它最大的优势是用同步的写法表达异步的逻辑把回调地狱拍平了。lifecycleScope.launch { val data withContext(Dispatchers.IO) { // 自动切到 IO 线程池执行 repository.fetchData() } // 自动切回主线程 textView.text data }Dispatchers.IO适合网络和磁盘操作Dispatchers.Default适合 CPU 密集型计算Dispatchers.Main就是主线程。withContext会自动处理线程切换和结果返回代码读起来跟同步调用一样顺。协程还有两个杀手锏结构化并发和取消传播。lifecycleScope绑定生命周期Activity销毁时协程自动取消不用手动管理父协程取消时子协程跟着取消不会出现任务跑飞的情况。异常处理也统一try-catch直接包住withContext就行。需要注意的是协程不是“没有线程”它底层还是跑在线程池上只是调度更聪明。另外别在GlobalScope里随便launch那样就失去了结构化并发的意义跟裸开线程区别不大。3.7 WorkManager需要保证执行的任务交给它WorkManager严格来说不是“多线程方案”而是“可延迟、可保证执行的后台任务调度框架”。它适合那些“不要求立即执行但要求最终一定执行”的任务比如数据同步、日志上报、定期清理缓存。val request OneTimeWorkRequestBuilderSyncWorker() .setConstraints( Constraints.Builder() .setRequiredNetworkType(NetworkType.CONNECTED) .build() ) .build() WorkManager.getInstance(context).enqueue(request)它内部会根据系统版本和任务条件选择合适的执行方式可能用线程池也可能用JobScheduler。约束条件网络、电量、充电状态和设备重启后的恢复能力是它的核心价值。但如果你需要立即拿到结果或者任务跟 UI 强相关那它就不合适老老实实用协程或线程池。4. 方案选型的判断逻辑与对比4.1 按场景对号入座选型这件事我总结了一个简单的判断路径任务要不要立即执行要就看是不是跟 UI 生命周期绑定绑定就用协程的lifecycleScope不绑定就用线程池不要立即执行、但要保证最终执行用WorkManager需要严格串行且带消息循环用HandlerThread只是写个临时脚本或极简 DemoThread也不是不能用。下面这张表是我平时给团队新人做参考的对比参数和结论都来自实际项目经验方案线程复用生命周期感知任务取消适用场景现状建议Thread否否困难极简一次性任务仅限 DemoHandlerThread是单线程否需手动 quit串行消息处理特定场景可用ExecutorService是否通过 Future通用并发任务主力方案之一AsyncTask是否有但不可靠老项目遗留逐步替换IntentService是单线程否有限老项目后台任务已被取代Kotlin 协程是是自动传播现代 Android 开发首选WorkManager是部分支持可延迟保证执行后台调度首选4.2 线程数量到底开多少合适这个问题没有标准答案但有个估算思路。假设你的任务以网络请求为主属于 IO 密集型线程大部分时间在等网络返回CPU 是闲着的那线程数可以适当多一些比如 8 到 16 个如果是图片压缩、数据加密这类 CPU 密集型任务线程开多了反而因为上下文切换变慢一般控制在 CPU 核数附近。我通常的做法是先按经验值配一个初始参数然后在测试环境用ThreadPoolExecutor的getActiveCount()、getQueue().size()观察实际负载再微调。别一上来就追求“最优参数”先跑起来看数据比拍脑袋靠谱。4.3 生命周期管理是绕不开的坎不管用哪种方案只要任务跟Activity或Fragment绑定就必须考虑生命周期。工作线程持有Activity引用Activity销毁后线程还在跑轻则回调空指针重则内存泄漏。协程的lifecycleScope和viewModelScope之所以好用就是因为把这件事自动化了。用线程池的话我一般会在onDestroy里取消所有未完成的任务或者用弱引用包装回调。Handler的话记得removeCallbacksAndMessages(null)。这些清理动作写起来琐碎但不写迟早出事。5. 实操中的坑与排查实录5.1 常见问题速查下面这些是我和团队在实际项目里反复遇到的整理成表格方便对照现象可能原因排查方向解决思路偶发 ANR主线程有耗时操作看 ANR 日志的主线程堆栈把耗时逻辑挪到工作线程更新 UI 崩溃在非主线程操作 View检查回调所在线程用 Handler 或协程切回主线程数据错乱共享变量无同步检查多线程读写点加锁或用线程安全容器内存泄漏线程持有 Activity 引用用内存分析工具看引用链弱引用或及时取消任务任务不执行线程池队列满或已 shutdown看拒绝策略和池状态调整队列容量或拒绝策略回调不触发任务被取消或线程已退出检查 cancel 和 quit 调用确认生命周期与取消时机5.2 一个真实的排查案例之前有个页面偶尔卡死日志里没有明显异常。后来用主线程堆栈抓了几次发现卡在一个synchronized块上。原因是工作线程持锁做网络请求主线程等这把锁去读缓存网络一慢主线程就跟着卡。这种问题的根子在于锁的粒度太大把不该保护的耗时操作也包进去了。改法是把网络请求挪到锁外面锁只保护内存数据的读写并且换成读写锁ReentrantReadWriteLock读多写少的场景下并发度明显提升。这个案例说明多线程问题很多时候不是“线程开错了”而是“共享数据的访问方式设计得不对”。5.3 几条踩出来的经验第一给线程起名字。不管是线程池的ThreadFactory还是HandlerThread的构造参数都别偷懒。排查问题时日志里一个有意义的名字能省半小时。第二别在循环里创建线程。见过有人在for循环里new Thread一千条数据开一千个线程手机直接卡成幻灯片。正确做法是交给线程池或者用协程的async并发处理再awaitAll。第三异常一定要兜住。工作线程里抛出的未捕获异常默认行为是终止线程而且不一定打到你能看到的日志里。线程池可以设置UncaughtExceptionHandler协程用CoroutineExceptionHandler别让异常悄悄溜走。第四测试并发问题要有耐心。并发 bug 往往在低概率下才出现本地跑十次没事不代表没问题。我习惯在关键路径上加一些日志埋点配合压力测试多跑几轮比单纯靠肉眼 review 靠谱。6. 我个人的选型习惯干到现在我自己的默认选择很明确新项目一律 Kotlin 协程打底跟 UI 相关的用lifecycleScope或viewModelScope纯后台计算用Dispatchers.Default网络和磁盘用Dispatchers.IO需要保证最终执行的后台任务交给WorkManager只有在维护老 Java 代码或者需要极精细控制线程池参数时才手动配置ThreadPoolExecutor。Thread、AsyncTask、IntentService这些基本只在读老代码时才会碰。协程虽好但也别神化它。它解决的是调度和生命周期的麻烦不解决你代码本身的逻辑问题。该加锁的地方还得加锁该注意的线程安全一样跑不掉。工具是工具思路才是根本。
