主线程阻塞之源：耗时操作、同步锁与 I/O

好，咱们来聊聊主线程到底是怎么被“卡死”的。很多人遇到 ANR 第一反应就是“代码跑太慢”，但慢的原因其实就那么几类。我带的团队在过去几年里修过的 ANR 问题，九成以上都逃不过这三个坑：耗时操作、同步锁、I/O。说白了，主线程就像一个单车道，只要有一辆车抛锚，后面全堵死。

耗时操作——UI 卡顿的头号杀手

耗时操作，顾名思义，就是需要很长时间才能完成的任务。在主线程上做这类事情，就像你一边开车一边数街边的广告牌——你数完十块，车已经撞树上了。

举个例子：

• 计算密集任务：图片压缩、大数组排序、复杂数学运算。我有个项目是把一张 4K 图片在解码时直接在主线程做滤镜处理，结果用户一拍照就 ANR。后来改成子线程处理，问题消失。
• 循环次数过多：比如 for 循环里嵌套网络请求，每次循环都等几十毫秒，几十次下来就是几秒。你想想看，用户点击后等两三秒没反应，系统就会判定 ANR。
• 大对象创建与销毁：在列表滑动时频繁 new 大对象，GC 被频繁触发，主线程时不时停一下做内存回收。

我个人习惯是：凡是超过 10ms 的操作，都问问自己“这能放到子线程吗？” 10ms 看起来短，但用户在 5 秒内滑动列表，累积几十次 10ms 就是 500ms 以上的卡顿。

同步锁——优雅的毒药

“锁”这个东西，本质是为了保护共享数据。但要是用错了地方，它就是 ANR 的温床。我遇到过最典型的场景：主线程需要拿一个锁，而子线程正拿着这个锁在做 I/O——主线程就死等。

常见的锁陷阱：

• 主线程等待子线程的锁：子线程持锁做耗时操作，主线程同时请求同一把锁。解决方法很简单：主线程里尽量别拿锁，或者用 tryLock 加超时。
• 死锁：两个线程互相等待对方的锁。我记得有一次 debug，发现线程 A 持有锁 L1 请求 L2，线程 B 持有锁 L2 请求 L1——两边都卡死了。解决方案是统一锁的获取顺序，或者用更高层次的锁（如 ReentrantLock 的 tryLock）。
• 锁粒度过大：把一个本质只需保护几行代码的锁，包住了整个方法甚至循环。我见过有人直接在 RecyclerView 的 onBindViewHolder 里加 synchronized——滑动时主线程和子线程疯狂竞争，ANR 频发。

我曾经犯过一个错：为了快速实现缓存同步，在 getSharedPreferences 的读写操作外面加了个全局锁。结果用户每次保存设置都会卡一下。后来改用 apply 异步写，再也不用锁了——你看，有时候去掉锁反而是最好的解。

I/O 操作——看不见的慢

I/O 最坑的地方是它的延迟不可控。你以为读写一个文件只要 1ms，但遇到 SD 卡老化、网络拥堵、数据库事务回滚，就可能变成 500ms 甚至更长。而在主线程上，500ms 就足够让系统报警了。

常见 I/O 阻塞点：

• 文件读写：SharedPreferences 的 commit() 是同步写磁盘的，千万不能用。用 apply() 异步写入，或者换 MMKV 这种更快的方案。我在早期项目里习惯用 commit 保存用户设置，后来被用户投诉“保存后返回首页要卡 2 秒”。
• 网络请求：所有网络请求（包括 DNS 解析、SSL 握手）都必须在子线程。如果在主线程调用 URLConnection 的 connect()，系统直接弹 ANR。这里有个易忽略的点：HostnameVerifier 的回调也可能在主线程，要小心。
• 数据库操作：Room 的流式查询（LiveData 或 Flow）如果返回大量数据，或者查询没有索引，都可能耗时。我建议所有数据库写操作都用异步，读操作尽量加上 limit 和使用索引。

记住一条铁律：主线程里不要出现任何可能触发磁盘或网络的动作。连 getExternalFilesDir 都可能走 I/O（虽然一般很快），但保险起见也在子线程调用。

三大阻塞原因速查表

原因	典型场景	解决方案	影响程度
耗时操作	大循环、复杂计算、GC 频繁	子线程执行、优化算法、减少对象创建	高（直接卡死 UI）
同步锁	主线程持锁等待子线程释放、死锁	避免主线程加锁、使用 tryLock、统一锁顺序	中到高（阻塞不可预测）
I/O 操作	同步文件读写、网络请求、数据库事务	异步 I/O、使用线程池、Room 异步查询	高（延迟不稳定）