Android中为什么主线程不会因为Looper.loop里的无限循环ANR?

通过前面的知识Android Handler消息机制我们知道了Handler的工作原理，同时也产生了一些问题，比如Looper.loop()开启了死循环，不会阻塞线程么？不会被卡死么？

导读

移动开发知识体系总章（Java基础、Android、Flutter）
Android中为什么主线程不会因为Looper.loop里的无限循环ANR?
Looper.loop和MessageQueue.next分析
ANR

Android中为什么主线程不会因为Looper.loop里的无限循环ANR?

先看看进程和线程：

进程：每个app运行前会先创建一个进程，该进程是由Zygote fork出来的，用于承载App上运行的各种Activity/Service等组件。进程对于上层应用来说是完全透明的，App程序都是运行在Android Runtime。大多数情况一个App就运行在一个进程中（在AndroidManifest.xml中配置Android:process属性，或通过native代码fork进程）。并且至少有一个线程。

线程：依附于进程，是分配和调度CPU的最小单元，由于依附关系，线程之间是可以资源共享的，但进程不行，从Linux角度来说进程与线程除了是否共享资源外，并没有本质的区别，都是一个task_struct结构体，在CPU看来进程、线程无非就是一段可执行的代码，CPU采用CFS调度算法，保证每个task都尽可能公平的享有CPU时间片。

对于进程和线程的区别，我看到过这样一个比喻：把系统比作一个公司，公司会分配一个办公场所（拥有独立的用户空间）给某个部门的部门（部门或部门经理相当于进程了），会有核心项目需要执行（可执行程序代码），部门至少有一个或多个员工（即线程），而员工归属于部门（或部门经理）（线程依附于进程），在这个部门下员工之间非常好沟通（零食啥的随便分享），但部门与部门间有啥事就得通过沟通了（不能直接共享，需要通信）

对于主线程，若应用运行一下就自己就结束了，肯定不行的，那么如何保证能一直存活呢？简单做法就是可执行代码是能一直执行下去的，无限循环便能保证不会被退出，而ActivityThread的main方法主要就是做消息循环，主角就是Looper。

再看看程序无响应（ANR）和线程阻塞、结束

程序无响应：主线程执行事件的时间过长，导致其他需要立刻在主线程处理的事件无法得到处理。
线程阻塞：线程处于等待状态。
线程结束：一般线程执行完run方法之后,线程就正常结束了。

1.阻塞和程序无响应没有必然的关系，虽然主线程在没有消息可处理的时候是阻塞的，但是只要保证有消息的时候能够立即处理，程序是不会无响应的。

2.阻塞和线程退出也没有必然的关系，线程完全可以在不阻塞的情况下死循环，同样达到不退出的效果。阻塞考虑到节约系统而做的处理，和线程退出没有关系。

3.ActivityThread的main方法主要就是做消息循环，一旦退出消息循环，那么应用就退出了，Looper.loop方法可能会引起主线程阻塞，但只要消息循环没有被阻塞，就一直能处理事件就不会产生ANR异常。

4.消息队列是一个无限循环，为什么无限循环不会ANR?因为应用的整个生命周期就是运行在这个消息循环中的，Android是由事件驱动的,Looper.loop方法不断的接受处理事件，每个点击触摸或者Activity每个生命周期都是在Looper.loop方法的控制之下，Looper.loop方法一旦结束，应用程序的生命周期也就结束了。

5.什么情况下会发生ANR？
第一，事件没有得到处理；
第二，事件正在处理，但是没有及时完成。

结论：
所以只能说事件的处理如果阻塞导致ANR，而不能说是Looper.loop的无限循环会ANR。

这就是说为什么在Activity生命周期onCreate/onStart/onResume等方法进行耗时的操作会ANR了。
这也是以下情况容易ANR的根本原因
Activity响应时间超过5s无响应
Broadcast在处理时间超过10s无响应
Service处理时间超过20s无响应

笔者新建了一个demo，创建了页面一（有一个跳转页面二的按钮）、页面二（在子线程中开启了一个无限循环），运行后，页面二果然没有ANR。（代码很简单就不贴了）。

页面一	页面二（子线程无限循环的）

页面一、二CPU\内存对比结果：
1、页面一无CPU消耗，页面二CPU平均消耗25%。
2、页面一内存消耗约10M，页面二内存消耗约12M。
3、在页面一直接新增无限循环，直接ANR。
4、在页面二无限循环新增Thread.sleep(200000);进行休眠，发现程序并没有ANR,而且CPU没有消耗，内存多消耗约1M。
（说明：只有主线程中执行任务事件过长，导致其他需要立刻在主线程处理的事件无法得到处理，才有可能会ANR）.
5、在页面二无限循环新增简单处理逻辑，CPU和内存消耗会小幅波动。
6、在页面二无限循环新增了读取drawable为Bitmap并用list一直add，此时的CPU波动非常平稳保持22%，而内存消耗则逐步提升，很快又会被降低，在约23分钟后后由于OutOfMemory而停止运行。

Looper.loop和MessageQueue.next分析

先查看loop()的源码：

public static void loop() {
        ...
        for (;;) {
            Message msg = queue.next(); // might block
            if (msg == null) {
                // No message indicates that the message queue is quitting.
                return;
            }
        }
    }

在for循环里，queue.next(); 写着注释might block，说可能会阻塞！查看next关键代码：


    Message next() {
        ...
        for (;;) {
            ...
            synchronized (this) {
                // Try to retrieve the next message.  Return if found.
                final long now = SystemClock.uptimeMillis();
                Message prevMsg = null;
                Message msg = mMessages;
                if (msg != null && msg.target == null) {
                    // Stalled by a barrier.  Find the next asynchronous message in the queue.
                    do {
                        prevMsg = msg;
                        msg = msg.next;
                    } while (msg != null && !msg.isAsynchronous());
                }
                if (msg != null) {
                       ...
                       if (prevMsg != null) {
                            prevMsg.next = msg.next;
                        } else {
                            mMessages = msg.next;
                            ...
                            return msg;
                        }
                } 
           }
        }
    }

1、MessageQueue.next内部也是一个for (;;)无限循环。
2、正常情况下，有消息，直接return msg，继续执行loop()中的方法。
2、msg为空或者msg指向的Handler为空（target）时，，则会执行dowhile，去取队列中的下一个消息，值得取出来为止，反之会无限循环着！
3、Looper中有无限循环，MessageQueue中也有无限循环，我们都知道新建一个项目跑起来是没有任何问题的，也就是说，Looper、MessageQueue中的无限循环不会ANR，
（还不知道msg.target为什么是Handler?Hanlder源码中明确写着Message.target == this）