1、基础概念：什么是后台线程？UI线程与后台线程的区别

线程，说白了就是一个执行流

我刚开始做客户端开发时，对“线程”的理解就是“代码跑在一条路上”。后来踩过不少坑才真正意识到——线程不是抽象概念，它是实实在在影响你 App 体验的东西。

一个进程里可以有好几个线程。每个线程都有自己的执行栈，能独立跑你的代码。CPU 在它们之间快速切换，造成“同时做多件事”的假象。

UI线程 — 你 App 的“面子工程”

UI 线程也叫主线程。它负责绘制界面、处理触摸事件、响应用户交互。你想想看，如果主线程被堵住了，屏幕就卡住了，用户马上就能感觉到。

我记得有一次线上反馈说某个页面打开时白屏 2 秒，查了半天发现是一个网络请求直接写在 Activity 的 onCreate 里。哎，主线程去等网络，界面当然出不来。

后台线程 — 干苦力的“隐形人”

后台线程就是除了主线程以外的线程。它们用来做耗时操作：网络请求、文件读写、数据库查询、图片解码、复杂计算……

说白了，所有会让 UI 卡顿的事情，都应该丢到后台线程去做。

两者对比，一目了然

对比维度	UI线程（主线程）	后台线程
职责	渲染界面、接收用户输入	执行耗时计算、IO 操作
能否操作 UI	可以	通常不允许（会抛异常）
响应速度要求	16ms 内必须完成一帧	没有严格时间约束
阻塞后果	掉帧、ANR（应用无响应）	只会影响自身任务
生命周期	与进程共存亡	可创建可销毁
常见示例	onCreate、onClick、动画回调	网络请求线程、Worker 线程

为什么有这条“红线”？

很多初学者会问：“为什么 UI 操作必须放在主线程？”其实原因很实际——UI 框架内部大多数状态都不是线程安全的。操作系统希望简化设计，就约定所有界面更新都串行到主线程处理。

反过来想：如果允许任意线程改 UI，那就得给每个控件加锁。加锁多了性能下降，还容易死锁。所以干脆一刀切——主线程独占 UI 访问权。我觉得这是非常合理的权衡。

什么时候用后台线程？

1. 网络请求：API 调用、图片下载，必须丢到后台。
2. 本地大文件读写：几百 KB 以上的文件读写不要在主线程做。
3. 数据库操作（SQLite、CoreData、Room）：查询 100 条以上数据就可能卡。
4. 图片/视频处理：解码、缩略图生成、滤镜。
5. 复杂数学运算：排序、加密、数据解析。

后台线程到 UI 的桥梁 — 消息队列

后台线程做完任务，怎么把结果送回 UI 线程？靠的就是消息队列机制。主线程内部维护一个 Loop，不断从队列取消息并执行。后台线程把更新 UI 的任务“包装”成一个 Runnable/Method，扔进主线程的消息队列，主线程处理完，界面就变了。

我个人习惯把这比喻成“后台线程写信扔进邮筒，主线程定时开邮筒看信”。这封信就是我们的 UI 更新代码。

// Android 示例：后台线程执行完成后更新 UI
new Thread(() -> {
    // 1. 后台执行耗时操作
    String result = fetchDataFromNetwork();

    // 2. 切回主线程
    runOnUiThread(() -> {
        // 3. 安全更新 UI
        textView.setText(result);
    });
}).start();

常见误区扫雷

• 误区：以为“后台线程越多越快”。事实：线程切换有开销，通常和 CPU 核数匹配即可。
• 误区：在后台线程直接 new Handler()。容易造成内存泄漏，最好使用弱引用或 Lifecycle 感知。
• 误区：所有耗时操作都开新线程，不考虑线程池复用。频繁创建线程很费资源。