为何runOnUIThread比runBlocking(Dispatchers.Main)引发更多ANR？

先看你的代码变化：
旧代码（触发ANR）：

methodOnWorkerThread(){
    ..some calls...
    runOnUIThread{
        ..some more calls...
        callThatRequiresTheUIThreadAndGivesANRs()
    }
}

新代码（解决ANR）：

methodOnWorkerThread(){
    ..some calls...
    ..some more calls...
    runBlocking(Dispatchers.Main) {
        callThatRequiresTheUIThreadAndGivesANRs()
    }
}

核心差异和ANR的关联点如下：

1. 任务执行范围与UI线程占用 #

• runOnUIThread：你传入的整个Runnable都会被加入UI线程的消息队列，等待UI线程依次执行。旧代码中..some more calls...这部分本属于工作线程的任务，却被放到了UI线程执行——如果这部分包含耗时操作（比如IO、复杂计算、同步锁等待），会直接占用UI线程，导致UI线程无法及时响应用户输入或系统消息，最终触发ANR。
• runBlocking(Dispatchers.Main)：仅Lambda内部的代码会被提交到UI线程执行，..some more calls...被移回工作线程执行，UI线程只需要处理callThatRequiresTheUIThreadAndGivesANRs()这一段必要的UI相关逻辑，不会被额外的耗时任务占用，自然不会触发ANR。

2. 堆栈跟踪的误导性 #

ANR的堆栈会抓取UI线程当前正在执行的方法，旧代码中..some more calls...已经占用了UI线程大量时间，等到执行callThatRequiresTheUIThreadAndGivesANRs()时，UI线程的响应超时阈值（通常5秒）已经被触发，所以堆栈会指向这个方法，但实际根源是前面的非UI耗时逻辑挤占了UI线程资源。

3. 线程阻塞的差异 #

• runOnUIThread：不会阻塞调用它的工作线程，工作线程会继续执行后续代码，但UI线程的消息队列如果堆积耗时任务，会持续处于繁忙状态。
• runBlocking(Dispatchers.Main)：会阻塞当前的工作线程，直到UI线程执行完Lambda内的代码。但这种阻塞只会影响工作线程，不会占用UI线程额外时间——只要Lambda内的代码是真正必要的UI操作，就不会导致UI线程超时。

总结：你遇到的ANR本质是错误地将非UI耗时逻辑放到了UI线程执行，修改代码后把这部分逻辑移回工作线程，才是解决ANR的关键。runOnUIThread和runBlocking(Dispatchers.Main)的核心差异在于你如何划分UI线程和工作线程的任务范围，而非API本身的调度机制差异。

内容的提问来源于stack exchange，提问作者casolorz