Looper 死循环阻塞没有 ANR 的原因在于 ANR (Application Not Responding) 的检测机制依赖于特定线程的事件处理超时。以下是详细解释：
1. ANR 的触发机制：
- 主线程 (UI 线程) 阻塞： ANR 最常见的情况是主线程阻塞。Android 系统会监控主线程的事件处理时间。如果主线程在一定时间内（通常是 5 秒）没有响应输入事件（例如触摸、按键）或广播接收器没有在 10 秒内完成执行，系统就会认为应用程序无响应，从而触发 ANR。
- BroadcastReceiver 超时： 如果一个 BroadcastReceiver 的
onReceive()方法执行时间超过 10 秒，也会触发 ANR。 - Service 超时： 如果一个 Service 在前台运行，并且在一定时间内（例如 20 秒）没有完成
onCreate()、onStartCommand()或onBind()方法的执行，也会触发 ANR。
2. Looper 的作用：
- 消息循环： Looper 是 Android 消息处理机制的核心。它负责从 MessageQueue 中取出消息，并将消息分发给相应的 Handler 进行处理。
- 线程保活： Looper 运行在一个线程中，并且会一直循环，只要 MessageQueue 中有消息，Looper 就会不断地处理。 这使得线程能够保持活动状态，等待和处理消息。
3. 为什么 Looper 死循环阻塞不一定导致 ANR：
- 非主线程： 如果 Looper 运行在非主线程中，即使它进入死循环阻塞，也不会直接导致 ANR。因为 ANR 的主要监控对象是主线程。 非主线程的阻塞只会导致该线程无法执行其他任务，但不会影响主线程的响应。
- 主线程，但没有阻塞事件处理： 即使 Looper 运行在主线程中，如果死循环发生在
Looper.loop()之外，并且没有阻塞主线程处理输入事件或广播接收器，那么也不会触发 ANR。 例如，如果在onCreate()方法中启动了一个死循环的线程，并且该线程没有与主线程进行任何交互，那么应用程序仍然可以响应用户输入，不会出现 ANR。 - 死循环发生在 Handler 的
handleMessage()中，但时间足够短： 如果死循环发生在 Handler 的handleMessage()方法中，并且每次循环的时间很短，使得主线程仍然能够在 5 秒内响应输入事件，那么也不会触发 ANR。 但是，这种情况仍然会导致应用程序性能下降，因为主线程的大部分时间都在执行死循环，无法处理其他任务。 - 死循环发生在 Handler 的
handleMessage()中，但有Thread.sleep()或类似操作： 如果死循环中包含Thread.sleep()或类似的操作，使得主线程在每次循环中都有机会响应输入事件，那么也不会触发 ANR。 但是，这种做法非常不推荐，因为它会导致应用程序性能下降，并且可能会导致其他问题。