📚 课程目录第4章主线程阻塞原理

主线程阻塞原理：为什么不能做耗时操作

说实话，这个问题我面试别人时经常问。很多人背得出“主线程不能做耗时操作”，但问为什么，就卡住了。其实核心原因就一句话：Android的UI系统是单线程模型。

主线程也叫UI线程，它要干的事情太多了——处理触摸事件、执行布局测量、绘制界面、分发广播、处理输入法回调……这些东西全串在一个消息队列里排队执行。一旦某个任务卡住超过5秒，系统就会判定ANR。

我在项目里碰到过最离谱的一个ANR，是同事直接在onClick里写了个Thread.sleep(7000)，说是“等服务器响应”。结果可想而知，用户点了个按钮，整个界面卡死7秒，直接弹ANR对话框。用户当场卸载。

主线程的“时间红线”

场景	超时阈值	常见触发点
输入事件（触摸、按键）	5秒	`onClick`、`onTouchEvent`耗时
广播接收	10秒	`onReceive`里做IO
Service前台执行	20秒	`onStartCommand`搞计算
ContentProvider	10秒	查询数据库大量数据

说白了，这5秒不是瞎定的。用户对操作响应有一个心理阈值：超过100毫秒就觉得“不跟手”；超过1秒就觉得“卡”；超过5秒就直接崩溃了。Google定的这个阈值，其实是在用户体验和硬件能力之间取的平衡。

四大阻塞源头

核心观点：所有导致主线程卡住的原因，归根到底只有四类——IO、网络、计算、锁。我们一个一个拆。

1. IO阻塞

读写文件、SharedPreferences提交、数据库操作……这些都会产生磁盘IO。磁盘速度比内存慢几个数量级，一次随机读写可能要几十毫秒甚至上百毫秒。别小看几十毫秒，如果连续做几次，5秒很快就被吃光了。

我自己就踩过坑：之前做个图片缓存应用，在onCreate里直接调了SharedPreferences.getAll()，那个文件有200多K，解析出来花了400多毫秒。页面启动就慢半拍，用户反馈“点开App黑屏一下”。后来改成异步加载，启动时间降到了100毫秒以内。

// ❌ 错误示范：主线程同步读文件
String content = readFromFile("/data/data/.../big_config.json");
parseConfig(content); // 假设解析耗时800ms

// ✅ 正确做法：协程或线程池异步
lifecycleScope.launch(Dispatchers.IO) {
    val content = readFromFile(...)
    withContext(Dispatchers.Main) { parseConfig(content) }
}

⚠️ 特别提醒：SQLite事务提交，apply()虽然是异步，但是commit()是同步写磁盘，千万不要在主线程调。

2. 网络阻塞

这个应该是最常见的ANR原因了。网络请求从毫秒到几十秒不等，取决于信号、服务器处理时间、数据包大小。你在主线程调HttpURLConnection.connect()，就等于让UI线程干等——期间不能刷新，不能响应触摸。

我记得有个版本上线前，QA反馈“点击登录按钮后整个App卡死”。追查发现网络层用了同步OkHttp调用，而且没有设置超时时间。那段时间公司网络刚好有点波动，每次请求都要等TCP重试三次，整整30秒。用户直接看到ANR，体验极差。

// ❌ 主线程做网络请求
private fun login() {
    val response = httpClient.newCall(request).execute() // 阻塞！可能等30秒
    handleResponse(response)
}

// ✅ 使用协程或回调
private fun login() {
    lifecycleScope.launch {
        val response = withContext(Dispatchers.IO) {
            httpClient.newCall(request).execute()
        }
        handleResponse(response)
    }
}

3. 密集计算

复杂算法、图片处理、JSON解析、正则匹配……这些任务如果数据量大，CPU跑满几秒钟很正常。尤其JSON解析，我曾优化过一个列表页，因为后端返回了3000条数据，Gson.fromJson()在主线程跑了2.3秒，滑动列表直接掉帧。

你想想看，主线程的Looper里每个消息执行时间通常只有几毫秒。突然插进来一个2秒的任务，后面的所有触摸事件、绘制请求都得排队。用户以为手机死机了，其实只是你的计算把线程堵死了。

💡 我的做法：凡是大循环超过100次的、字符串拼接超过1MB的、图片解码尺寸超过1080p的，都扔到子线程去。主线程只做内存状态判断和界面更新。

4. 锁竞争与死锁

这个最隐蔽，也最难排查。主线程跟子线程同时抢一把锁，子线程持有锁去做IO，主线程等着锁继续执行——这就形成了阻塞。更严重的是死锁：线程A持有锁1等锁2，线程B持有锁2等锁1，主线程刚好是其中一个线程，直接ANR。

我之前接手过一个历史项目，里面有个全局的synchronized方法，子线程网络回调里调这个方法，主线程的onBindViewHolder也调。有一次网络特别慢，子线程在同步方法里等网络返回，主线程就卡在列表刷新上，整个界面僵住了。后来改成ReentrantReadWriteLock，或者干脆把共享数据做成不可变对象，才根除问题。

// ❌ 主线程和子线程竞争同一把锁
private val lock = Any()
fun updateUI() {
    synchronized(lock) { // 主线程等锁，子线程可能持有锁做IO
        // 更新界面
    }
}

// ✅ 避免主线程参与锁竞争
fun updateUI() {
    // 用Handler或其他原子操作，不要让主线程等锁
    runOnUiThread { updateView() }
}

主线程阻塞的核心逻辑图

下面这张图概括了整节的脉络，我建议你保存下来，排查ANR时对着看，思路会清晰很多。

排查阻塞源的核心思路

其实说来说去，遇到ANR不要慌。先拿到/data/anr/traces.txt，找到主线程的调用栈，看它停在哪个方法上。停在哪里，阻塞源就在哪里。

停在FileInputStream.read()或SharedPreferencesImpl → IO阻塞，检查是否有主线程读写大文件或commit()
停在SocketInputStream或OkHttp → 网络阻塞，将请求移到子线程
停在for循环或Gson.fromJson → 计算阻塞，异步处理
停在Object.wait()或LockSupport.park → 锁竞争，检查死锁或长时间持有锁

💡 个人习惯：每次上线前，我会在CI流程里加一个静态检查规则：禁止在主线程调用的方法列表。比如Thread.sleep()、InputStream.read()、SQLiteDatabase.execSQL()（非WAL模式）都直接报error。从源头堵住，比事后查日志省心多了。

嗯，以上就是主线程阻塞的全部秘密了。你想想看，其实并不复杂——记住一句话就行：主线程只做UI相关的事，其他一切靠边站。哪天真出了ANR，对照着这篇内容去查，八成能找到根因。