4.6Looper深度解析

目录介绍

• 01.Activity如何自动绑定Looper
• 02.Looper.prepare()方法源码分析
• 03.Looper.prepare()能否调用多次
• 04.Looper.loop()方法源码分析
• 06.Activity生命周期依赖Looper
• 07.Looper死循环为何不阻塞应用卡死
• 08.Looper停止App就退出吗

01.Activity如何自动绑定Looper

• 主线程如何自动调用Looper.prepare()
• ActivityThread，并且在main方法中我们会看到主线程也是通过Looper方式来维持一个消息循环。那么这个死循环会不会导致应用卡死，即使不会的话，它会慢慢的消耗越来越多的资源吗？
  • 对于线程即是一段可执行的代码，当可执行代码执行完成后，线程生命周期便该终止了，线程退出。而对于主线程，我们是绝不希望会被运行一段时间，自己就退出，那么如何保证能一直存活呢？简单做法就是可执行代码是能一直执行下去的，死循环便能保证不会被退出。
  • 例如，binder线程也是采用死循环的方法，通过循环方式不同与Binder驱动进行读写操作，当然并非简单地死循环，无消息时会休眠。但这里可能又引发了另一个问题，既然是死循环又如何去处理其他事务呢？通过创建新线程的方式。真正会卡死主线程的操作是在回调方法onCreate/onStart/onResume等操作时间过长，会导致掉帧，甚至发生ANR，looper.loop本身不会导致应用卡死。
• 可以看到Looper.prepare()方法在这里调用，所以在主线程中可以直接初始化Handler了。

  //ActivityThread类中的main方法中重点代码
  //注意：这里省略了许多代码
  public static void main(String[] args) {
      ……
      //创建Looper和MessageQueue对象，用于处理主线程的消息
      Looper.prepareMainLooper();
      //创建ActivityThread对象
      ActivityThread thread = new ActivityThread();
      //建立Binder通道 (创建新线程)
      thread.attach(false);
      ……
      //消息循环运行
      Looper.loop();
      //如果能执行下面方法，说明应用崩溃或者是退出了...
      throw new RuntimeException("Main thread loop unexpectedly exited");
  }

• 并且可以看到还调用了：Looper.loop()方法，可以知道一个Handler的标准写法其实是这样的

  Looper.prepare();
  Handler mHandler = new Handler() {
     @Override
     public void handleMessage(Message msg) {
        if (msg.what == 101) {
           Log.i(TAG, "在子线程中定义Handler，并接收到消息");
         }
     }
  };
  Looper.loop();

02.Looper.prepare()方法源码分析

• 源码如下所示
  • sThreadLocal 对象又是通过 prepare(boolean) 来进行赋值的，且该方法只允许调用一次，一个线程只能创建一个 Looper 对象，否则将抛出异常。
  • 熟悉JDK的同学应该知道，当使用ThreadLocal维护变量时，ThreadLocal为每个使用该变量的线程提供独立的变量副本，所以每一个线程都可以独立地改变自己的副本，而不会影响其它线程所对应的副本。博客

  public static void prepare() {
      prepare(true);
  }
  
  private static void prepare(boolean quitAllowed) {
      if (sThreadLocal.get() != null) {
          throw new RuntimeException("Only one Looper may be created per thread");
      }
      sThreadLocal.set(new Looper(quitAllowed));
  }

03.Looper.prepare()能否调用多次

• 思考：Looper.prepare()能否调用两次或者多次
  • 如果运行，则会报错，并提示prepare中的Excetion信息。由此可以得出在每个线程中Looper.prepare()能且只能调用一次

  //这里Looper.prepare()方法调用了两次
  Looper.prepare();
  Looper.prepare();
  Handler mHandler = new Handler() {
     @Override
     public void handleMessage(Message msg) {
         if (msg.what == 1) {
            Log.i(TAG, "在子线程中定义Handler，并接收到消息。。。");
         }
     }
  };
  Looper.loop();

• Looper 类的构造函数也是私有的，且在构造函数中还初始化了一个线程常量 mThread，这都说明了 Looper 只能关联到一个线程，且关联之后不能改变。

05.Looper.loop()方法源码分析

• 看看里面得源码，如下所示
  • 看到Looper.loop()方法里起了一个死循环，不断的判断MessageQueue中的消息是否为空，如果为空则直接return掉，然后执行queue.next()方法。博客

  public static void loop() {
      final Looper me = myLooper();
      if (me == null) {
          throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
      }
      final MessageQueue queue = me.mQueue;
      Binder.clearCallingIdentity();
      final long ident = Binder.clearCallingIdentity();
      for (;;) {
          Message msg = queue.next(); // might block
          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);
          }
          final long slowDispatchThresholdMs = me.mSlowDispatchThresholdMs;
          final long traceTag = me.mTraceTag;
          if (traceTag != 0 && Trace.isTagEnabled(traceTag)) {
              Trace.traceBegin(traceTag, msg.target.getTraceName(msg));
          }
          final long start = (slowDispatchThresholdMs == 0) ? 0 : SystemClock.uptimeMillis();
          final long end;
          try {
              msg.target.dispatchMessage(msg);
              end = (slowDispatchThresholdMs == 0) ? 0 : SystemClock.uptimeMillis();
          } finally {
              if (traceTag != 0) {
                  Trace.traceEnd(traceTag);
              }
          }
          if (slowDispatchThresholdMs > 0) {
              final long time = end - start;
              if (time > slowDispatchThresholdMs) {
                  Slog.w(TAG, "Dispatch took " + time + "ms on "
                          + Thread.currentThread().getName() + ", h=" +
                          msg.target + " cb=" + msg.callback + " msg=" + msg.what);
              }
          }
          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();
      }
  }

• 看queue.next()方法源码
  • 大概的实现逻辑就是Message的出栈操作，里面可能对线程，并发控制做了一些限制等。
  • 获取到栈顶的Message对象之后开始执行：msg.target.dispatchMessage(msg)

  Message next() {
      // Return here if the message loop has already quit and been disposed.
      // This can happen if the application tries to restart a looper after quit
      // which is not supported.
      final long ptr = mPtr;
      if (ptr == 0) {
          return null;
      }
  
      int pendingIdleHandlerCount = -1; // -1 only during first iteration
      int nextPollTimeoutMillis = 0;
      for (;;) {
          if (nextPollTimeoutMillis != 0) {
              Binder.flushPendingCommands();
          }
  
          nativePollOnce(ptr, nextPollTimeoutMillis);
  
          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 (now < msg.when) {
                      // Next message is not ready.  Set a timeout to wake up when it is ready.
                      nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
                  } else {
                      // Got a message.
                      mBlocked = false;
                      if (prevMsg != null) {
                          prevMsg.next = msg.next;
                      } else {
                          mMessages = msg.next;
                      }
                      msg.next = null;
                      if (DEBUG) Log.v(TAG, "Returning message: " + msg);
                      msg.markInUse();
                      return msg;
                  }
              } else {
                  // No more messages.
                  nextPollTimeoutMillis = -1;
              }
  
              // Process the quit message now that all pending messages have been handled.
              if (mQuitting) {
                  dispose();
                  return null;
              }
  
              // If first time idle, then get the number of idlers to run.
              // Idle handles only run if the queue is empty or if the first message
              // in the queue (possibly a barrier) is due to be handled in the future.
              if (pendingIdleHandlerCount < 0
                      && (mMessages == null || now < mMessages.when)) {
                  pendingIdleHandlerCount = mIdleHandlers.size();
              }
              if (pendingIdleHandlerCount <= 0) {
                  // No idle handlers to run.  Loop and wait some more.
                  mBlocked = true;
                  continue;
              }
  
              if (mPendingIdleHandlers == null) {
                  mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
              }
              mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
          }
  
          // Run the idle handlers.
          // We only ever reach this code block during the first iteration.
          for (int i = 0; i < pendingIdleHandlerCount; i++) {
              final IdleHandler idler = mPendingIdleHandlers[i];
              mPendingIdleHandlers[i] = null; // release the reference to the handler
  
              boolean keep = false;
              try {
                  keep = idler.queueIdle();
              } catch (Throwable t) {
                  Log.wtf(TAG, "IdleHandler threw exception", t);
              }
  
              if (!keep) {
                  synchronized (this) {
                      mIdleHandlers.remove(idler);
                  }
              }
          }
  
          // Reset the idle handler count to 0 so we do not run them again.
          pendingIdleHandlerCount = 0;
  
          // While calling an idle handler, a new message could have been delivered
          // so go back and look again for a pending message without waiting.
          nextPollTimeoutMillis = 0;
      }
  }

• 那么msg.target是什么呢？通过追踪可以知道就是定义的Handler对象，然后查看一下Handler类的dispatchMessage方法：
  • 可以看到，如果我们设置了callback（Runnable对象）的话，则会直接调用handleCallback方法
  • 在初始化Handler的时候设置了callback（Runnable）对象，则直接调用run方法。

  public void dispatchMessage(Message msg) {
      if (msg.callback != null) {
          handleCallback(msg);
      } else {
          if (mCallback != null) {
              if (mCallback.handleMessage(msg)) {
                  return;
              }
          }
          handleMessage(msg);
      }
  }
  
  private static void handleCallback(Message message) {
      message.callback.run();
  }

06.Activity生命周期依赖Looper

• Activity的生命周期都是依靠主线程的Looper.loop
  • 当收到不同Message时则采用相应措施：一旦退出消息循环，那么你的程序也就可以退出呢。从消息队列中取消息可能会阻塞，取到消息会做出相应的处理。如果某个消息处理时间过长，就可能会影响UI线程的刷新速率，造成卡顿的现象。

  
  //在FragmentActivity中
  @Override
  protected void onPause() {
      super.onPause();
      if (mHandler.hasMessages(MSG_RESUME_PENDING)) {
          mHandler.removeMessages(MSG_RESUME_PENDING);
      }
  }
  
  
  @Override
  protected void onResume() {
      super.onResume();
      mHandler.sendEmptyMessage(MSG_RESUME_PENDING);
  }
  
  @Override
  protected void onStart() {
      super.onStart();
      mHandler.removeMessages(MSG_REALLY_STOPPED);
  }
  
  @Override
  protected void onStop() {
      super.onStop();
      mHandler.sendEmptyMessage(MSG_REALLY_STOPPED);
  }

• ActivityThread的动力是什么
  • 进程
    • 每个app运行时前首先创建一个进程，该进程是由Zygote fork出来的，用于承载App上运行的各种Activity/Service等组件。进程对于上层应用来说是完全透明的，这也是google有意为之，让App程序都是运行在Android Runtime。大多数情况一个App就运行在一个进程中，除非在AndroidManifest.xml中配置Android:process属性，或通过native代码fork进程。博客
  • 线程
    • 线程对应用来说非常常见，比如每次new Thread().start都会创建一个新的线程。该线程与App所在进程之间资源共享，从Linux角度来说进程与线程除了是否共享资源外，并没有本质的区别，都是一个task_struct结构体，在CPU看来进程或线程无非就是一段可执行的代码，CPU采用CFS调度算法，保证每个task都尽可能公平的享有CPU时间片。
  • 其实承载ActivityThread的主线程就是由Zygote fork而创建的进程。

07.Looper死循环为何不阻塞应用卡死

• 问题描述
  • 在处理消息的时候使用了Looper.loop()方法，并且在该方法中进入了一个死循环，同时Looper.loop()方法是在主线程中调用的，那么为什么没有造成阻塞呢？
• Looper死循环为什么不会导致应用卡死，会消耗大量资源吗？
  • 线程默认没有Looper的，如果需要使用Handler就必须为线程创建Looper。我们经常提到的主线程，也叫UI线程，它就是ActivityThread，ActivityThread被创建时就会初始化Looper，这也是在主线程中默认可以使用Handler的原因。
• 创建一个子线程，并且死循环，然后做更新UI操作，看看会不会卡死应用
  • 先看看代码

  new Thread(new Runnable() {
      @Override
      public void run() {
          Log.e("yc", "yc 0 ");
          Looper.prepare();
          Toast.makeText(MainActivity.this, "run on Thread", Toast.LENGTH_SHORT).show();
          Log.e("yc", "yc 1 ");
          Looper.loop();
          Log.e("yc", "yc 2 ");
      }
  }).start();

  • 然后再来看看Looper.loop()源代码，可以直接参考前面分析，Looper.loop();里面维护了一个死循环方法，所以按照理论，上述代码执行的应该是yc 0 –>yc 1也就是说循环在Looper.prepare();与Looper.loop();之间。所以不会卡死应用。
  • 在子线程中，如果手动为其创建了Looper，那么在所有的事情完成以后应该调用quit方法来终止消息循环，否则这个子线程就会一直处于等待（阻塞）状态，而如果退出Looper以后，这个线程就会立刻（执行所有方法并）终止，因此建议不需要的时候终止Looper。
• 主线程的死循环一直运行是不是特别消耗CPU资源呢？ 博客
  • 其实不然，这里就涉及到Linux pipe/epoll机制，简单说就是在主线程的MessageQueue没有消息时，便阻塞在loop的queue.next()中的nativePollOnce()方法里，此时主线程会释放CPU资源进入休眠状态，直到下个消息到达或者有事务发生，通过往pipe管道写端写入数据来唤醒主线程工作。
  • 这里采用的epoll机制，是一种IO多路复用机制，可以同时监控多个描述符，当某个描述符就绪(读或写就绪)，则立刻通知相应程序进行读或写操作，本质同步I/O，即读写是阻塞的。所以说，主线程大多数时候都是处于休眠状态，并不会消耗大量CPU资源。

08.一个Looper只有一个MessageQueue

• 为什么一个线程只有一个Looper、只有一个MessageQueue，可以有多个Handler？
• 注意：一个Thread只能有一个Looper，可以有多个Handler
  • Looper有一个MessageQueue，可以处理来自多个Handler的Message；MessageQueue有一组待处理的Message，这些Message可来自不同的Handler；Message中记录了负责发送和处理消息的Handler；Handler中有Looper和MessageQueue。
• 为什么一个线程只有一个Looper？技术博客大总结
  • 需使用Looper的prepare方法，Looper.prepare()。可以看下源代码，Android中一个线程最多仅仅能有一个Looper，若在已有Looper的线程中调用Looper.prepare()会抛出RuntimeException(“Only one Looper may be created per thread”)。
  • 所以一个线程只有一个Looper，不知道这样解释是否合理！更多可以查看我的博客汇总：https://github.com/yangchong211/YCBlogs

  public static void prepare() {
      prepare(true);
  }
  
  private static void prepare(boolean quitAllowed) {
      if (sThreadLocal.get() != null) {
          throw new RuntimeException("Only one Looper may be created per thread");
      }
      sThreadLocal.set(new Looper(quitAllowed));
  }

08.Looper停止App就退出吗

• looper如果停止了，那么app会退出吗，先做个实验看一下。代码如下所示
  • 可以发现调用这句话，是会让app退出的。会报错崩溃日志是：java.lang.IllegalStateException: Main thread not allowed to quit.

  Looper.getMainLooper().quit();
  
  //下面这种是安全退出
  if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN_MR2) {
      Looper.getMainLooper().quitSafely();
  }

• 然后看一下Looper中quit方法源码
  • Looper的quit方法源码如下：

  public void quit() {
      mQueue.quit(false);
  }

  • Looper的quitSafely方法源码如下：

  public void quitSafely() {
      mQueue.quit(true);
  }

• 以上两个方法中mQueue是MessageQueue类型的对象，二者都调用了MessageQueue中的quit方法，MessageQueue的quit方法源码如下:
  • 可以发现上面调用了quit方法，即会出现出现崩溃，主要原因是因为调用prepare()-->new Looper(true)--->new MessageQueue(true)--->mQuitAllowed设置为true

  void quit(boolean safe) {
      if (!mQuitAllowed) {
          throw new IllegalStateException("Main thread not allowed to quit.");
      }
  
      synchronized (this) {
          if (mQuitting) {
              return;
          }
          mQuitting = true;
  
          if (safe) {
              removeAllFutureMessagesLocked();
          } else {
              removeAllMessagesLocked();
          }
  
          // We can assume mPtr != 0 because mQuitting was previously false.
          nativeWake(mPtr);
      }
  }

• 通过观察以上源码我们可以发现:
  • 当我们调用Looper的quit方法时，实际上执行了MessageQueue中的removeAllMessagesLocked方法，该方法的作用是把MessageQueue消息池中所有的消息全部清空，无论是延迟消息（延迟消息是指通过sendMessageDelayed或通过postDelayed等方法发送的需要延迟执行的消息）还是非延迟消息。
  • 当我们调用Looper的quitSafely方法时，实际上执行了MessageQueue中的removeAllFutureMessagesLocked方法，通过名字就可以看出，该方法只会清空MessageQueue消息池中所有的延迟消息，并将消息池中所有的非延迟消息派发出去让Handler去处理，quitSafely相比于quit方法安全之处在于清空消息之前会派发所有的非延迟消息。
  • 无论是调用了quit方法还是quitSafely方法只会，Looper就不再接收新的消息。即在调用了Looper的quit或quitSafely方法之后，消息循环就终结了，这时候再通过Handler调用sendMessage或post等方法发送消息时均返回false，表示消息没有成功放入消息队列MessageQueue中，因为消息队列已经退出了。
  • 需要注意的是Looper的quit方法从API Level 1就存在了，但是Looper的quitSafely方法从API Level 18才添加进来。

其他介绍

01.关于博客汇总链接

• 1.技术博客汇总
• 2.开源项目汇总
• 3.生活博客汇总
• 4.喜马拉雅音频汇总
• 5.其他汇总

02.关于我的博客

• github：https://github.com/yangchong211
• 知乎：https://www.zhihu.com/people/yczbj/activities
• 简书：http://www.jianshu.com/u/b7b2c6ed9284
• csdn：http://my.csdn.net/m0_37700275
• 喜马拉雅听书：http://www.ximalaya.com/zhubo/71989305/
• 开源中国：https://my.oschina.net/zbj1618/blog
• 泡在网上的日子：http://www.jcodecraeer.com/member/content_list.php?channelid=1
• 邮箱：yangchong211@163.com
• 阿里云博客：https://yq.aliyun.com/users/article?spm=5176.100- 239.headeruserinfo.3.dT4bcV
• segmentfault头条：https://segmentfault.com/u/xiangjianyu/articles
• 掘金：https://juejin.im/user/5939433efe88c2006afa0c6e