面试题-为什么主线程不会因为Looper.loop()死循环卡死

文章参考：https://www.zhihu.com/question/34652589

如果看过源码的人都知道，在处理消息的时候使用了Looper.loop()方法，并且在该方法中进入了一个死循环，同时Looper.loop()方法是在主线程中调用的，那么为什么没有造成阻塞呢？

首先我们需要从Android程序启动的入口开始来看：

  public static void main(String[] args) {
      Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "ActivityThreadMain");
// ......

      Process.setArgV0("<pre-initialized>");
      // 初始化主线程的looper对象
      Looper.prepareMainLooper();

      // Find the value for {@link #PROC_START_SEQ_IDENT} if provided on the command line.
      // It will be in the format "seq=114"
      long startSeq = 0;
      if (args != null) {
          for (int i = args.length - 1; i >= 0; --i) {
              if (args[i] != null && args[i].startsWith(PROC_START_SEQ_IDENT)) {
                  startSeq = Long.parseLong(
                          args[i].substring(PROC_START_SEQ_IDENT.length()));
              }
          }
      }
      ActivityThread thread = new ActivityThread();
      thread.attach(false, startSeq);
      if (sMainThreadHandler == null) {
          sMainThreadHandler = thread.getHandler();
      }
      if (false) {
          Looper.myLooper().setMessageLogging(new
                  LogPrinter(Log.DEBUG, "ActivityThread"));
      }
      // End of event ActivityThreadMain.
      Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
      // 执行Looper的loop方法
      Looper.loop();

      throw new RuntimeException("Main thread loop unexpectedly exited");
  }

然后再看看Looper.loop()方法：

/**
    * Run the message queue in this thread. Be sure to call
    * {@link #quit()} to end the loop.
    * 这个方法主要是进行当前线程里面的message queue队列的遍历，来遍历消息，进行消息的分发
    */
   public static void loop() {
       // 这个方法就是从TreadLocal里面取得当前的Looper对象。
       // 也就是我们每个线程实例化的ThreadLocal对象
       final Looper me = myLooper();
       // 毫无疑问，me为null 表示这个线程里面没有进行Looper对象的Looper.prepare()初始化。
       if (me == null) {
           throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
       }
       // 这个queue就是构造函数中实例化的mQueue
       final MessageQueue queue = me.mQueue;

       // Make sure the identity of this thread is that of the local process,
       // and keep track of what that identity token actually is.
       Binder.clearCallingIdentity();
       final long ident = Binder.clearCallingIdentity();
       
       /// 省略部分代码
       
       // Looper的loop方法执行死循环。
       // 我们可以看到这个地方，是执行了一个死循环，在这个死循环中依次遍历queue里面的所有消息
       for (;;) {
           // 从Looper的queue中依次取出消息实体
           // 拿到下一个Message.如果没有消息这个地方就会阻塞掉
           Message msg = queue.next(); // might block

           // 如果为null,表明这个额消息队列正在停止，这个时候就跳出循环。
           if (msg == null) {
               // No message indicates that the message queue is quitting.
               return;
           }

           // This must be in a local variable, in case a UI event sets the logger
           final Printer logging = me.mLogging;
           if (logging != null) {
               logging.println(">>>>> Dispatching to " + msg.target + " " +
                       msg.callback + ": " + msg.what);
           }
           // Make sure the observer won't change while processing a transaction.
           final Observer observer = sObserver;
           
		// ......
           
           if (traceTag != 0 && Trace.isTagEnabled(traceTag)) {
               Trace.traceBegin(traceTag, msg.target.getTraceName(msg));
           }

           final long dispatchStart = needStartTime ? SystemClock.uptimeMillis() : 0;
           final long dispatchEnd;
           Object token = null;
           if (observer != null) {
               token = observer.messageDispatchStarting();
           }
           long origWorkSource = ThreadLocalWorkSource.setUid(msg.workSourceUid);
           // 我们从这个地方调用 msg.target的dispatchMessage()方法
           // 那么 msg.target对象是什么？
           // 其实就是Handler对象
           try {
               msg.target.dispatchMessage(msg);
               if (observer != null) {
                   observer.messageDispatched(token, msg);
               }
               dispatchEnd = needEndTime ? SystemClock.uptimeMillis() : 0;
           } catch (Exception exception) {
               if (observer != null) {
                   observer.dispatchingThrewException(token, msg, exception);
               }
               throw exception;
           } finally {
               ThreadLocalWorkSource.restore(origWorkSource);
               if (traceTag != 0) {
                   Trace.traceEnd(traceTag);
               }
           }
           if (logSlowDelivery) {
               if (slowDeliveryDetected) {
                   if ((dispatchStart - msg.when) <= 10) {
                       Slog.w(TAG, "Drained");
                       slowDeliveryDetected = false;
                   }
               } else {
                   if (showSlowLog(slowDeliveryThresholdMs, msg.when, dispatchStart, "delivery",
                           msg)) {
                       // Once we write a slow delivery log, suppress until the queue drains.
                       slowDeliveryDetected = true;
                   }
               }
           }
           if (logSlowDispatch) {
               showSlowLog(slowDispatchThresholdMs, dispatchStart, dispatchEnd, "dispatch", msg);
           }

           if (logging != null) {
               logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
           }

           // Make sure that during the course of dispatching the
           // identity of the thread wasn't corrupted.
           final long newIdent = Binder.clearCallingIdentity();
           if (ident != newIdent) {
               Log.wtf(TAG, "Thread identity changed from 0x"
                       + Long.toHexString(ident) + " to 0x"
                       + Long.toHexString(newIdent) + " while dispatching to "
                       + msg.target.getClass().getName() + " "
                       + msg.callback + " what=" + msg.what);
           }

           msg.recycleUnchecked();
       }
   }

这么一看，似乎真的是在主线程中有一个死循环，而且没有造成阻塞？

那么我们先从入口ActivityThread 类开始看：首先 ActivityThread 并不是一个 Thread，就只是一个 final 类而已。我们常说的主线程就是从这个类的 main 方法开始，main 方法很简短，一眼就能看全（如上），我们看到里面有 Looper 了，那么接下来就找找 ActivityThread 对应的 Handler 啊，就是内部类 H，其继承 Handler，贴出 handleMessage 的小部分：

public void handleMessage(Message msg) {
            if (DEBUG_MESSAGES) Slog.v(TAG, ">>> handling: " + codeToString(msg.what));
            switch (msg.what) {
                    
                // ....
                    
                case RUN_ISOLATED_ENTRY_POINT:
                    handleRunIsolatedEntryPoint((String) ((SomeArgs) msg.obj).arg1,
                            (String[]) ((SomeArgs) msg.obj).arg2);
                    break;
                case EXECUTE_TRANSACTION:
                    final ClientTransaction transaction = (ClientTransaction) msg.obj;
                    mTransactionExecutor.execute(transaction);
                    if (isSystem()) {
                        // Client transactions inside system process are recycled on the client side
                        // instead of ClientLifecycleManager to avoid being cleared before this
                        // message is handled.
                        transaction.recycle();
                    }
                    // TODO(lifecycler): Recycle locally scheduled transactions.
                    break;
                case RELAUNCH_ACTIVITY:
                    handleRelaunchActivityLocally((IBinder) msg.obj);
                    break;
            }
            Object obj = msg.obj;
            if (obj instanceof SomeArgs) {
                ((SomeArgs) obj).recycle();
            }
            if (DEBUG_MESSAGES) Slog.v(TAG, "<<< done: " + codeToString(msg.what));
        }

看完这 Handler 里处理消息的内容应该明白了吧， Activity 的生命周期都有对应的 case 条件了，ActivityThread 有个 getHandler 方法，得到这个 handler 就可以发送消息，然后 loop 里就分发消息，然后就发给 handler, 然后就执行到 H（Handler ）里的对应代码。所以这些代码就不会卡死～，有消息过来就能执行。举个例子，在 ActivityThread 里的内部类 ApplicationThread 中就有很多 sendMessage 的方法。

简单的来说：ActivityThread的main方法主要就是做消息循环，一旦退出消息循环，那么你的程序也就可以退出了。
从消息队列中取消息可能会阻塞，取到消息会做出相应的处理。如果某个消息处理时间过长，就可能会影响UI线程的刷新速率，造成卡顿的现象。

如果你了解下linux的epoll你就知道为什么不会被卡住了，先说结论：阻塞是有的，但是不会卡住。

主要原因有2个

• epoll模型

当没有消息的时候会epoll.wait，等待句柄写的时候再唤醒，这个时候其实是阻塞的。

主线程的死循环一直运行是不是特别消耗CPU资源呢？ 其实不然，这里就涉及到Linux pipe/epoll机制，简单说就是在主线程的MessageQueue没有消息时，便阻塞在loop的queue.next()中的nativePollOnce()方法里

此时主线程会释放CPU资源进入休眠状态，直到下个消息到达或者有事务发生，通过往pipe管道写端写入数据来唤醒主线程工作。这里采用的epoll机制，是一种IO多路复用机制，可以同时监控多个描述符，当某个描述符就绪(读或写就绪)，则立刻通知相应程序进行读或写操作，本质同步I/O，即读写是阻塞的。 所以说，主线程大多数时候都是处于休眠状态，并不会消耗大量CPU资源。

比如屏幕刷新16ms一个消息，你的各种点击事件，所以就会有句柄写操作，唤醒上文的wait操作，所以不会被卡死了。

• 所有的ui操作都通过handler来发消息操作。