Android之消息机制问题

• 6.0.0.1 谈谈消息机制Hander作用？有哪些要素？流程是怎样的？简单说一下你的看法！
• 6.0.0.2 为什么一个线程只有一个Looper、只有一个MessageQueue，可以有多个Handler？
• 6.0.0.3 可以在子线程直接new一个Handler吗？会出现什么问题，如何在子线程中使用handler？
• 6.0.0.4 说一下Handler内存泄漏有哪些？造成造成内存泄漏原因是什么？如何解决handler造成的内存泄漏？
• 6.0.0.5 Activity如何自动绑定Looper？主线程中的Looper死循环和binder线程中的死循环有哪些区别？
• 6.0.0.6 为什么系统不建议在子线程访问UI，不对UI控件的访问加上锁机制的原因？
• 6.0.0.7 Looper.loop是一个死循环，拿不到需要处理的Message就会阻塞，那在UI线程中为什么不会导致ANR？
• 6.0.0.8 Handler.sendMessageDelayed()怎么实现延迟的？结合Looper.loop()循环中，Message=messageQueue.next()和MessageQueue.enqueueMessage()分析。
• 6.0.0.9 Message可以如何创建？哪种效果更好，为什么？
• 6.0.1.0 MessageQueue作用是干什么的？MessageQueue的定义是什么？MessageQueue主要工作原理是怎样的？
• 6.0.1.1 子线程更新UI有哪些方式？runOnUiThread如何实现子线程更新UI？View.post(Runnable r)更新UI？
• 6.0.1.3 使用Hanlder的postDealy()后消息队列会发生什么变化？
• 6.0.1.4 ThreadLocal有什么作用？如何避免UI线程尽量只做跟UI相关的工作?
• 6.0.1.5 为什么一个线程只有一个Looper、只有一个MessageQueue，可以有多个Handler？

好消息

• 博客笔记大汇总【16年3月到至今】，包括 Java 基础及深入知识点，Android技术博客，Python学习笔记等等，还包括平时开发中遇到的bug汇总，当然也在工作之余收集了大量的面试题，长期更新维护并且修正，持续完善……开源的文件是markdown格式的！同时也开源了生活博客，从12年起，积累共计N篇[近100万字，陆续搬到网上]，转载请注明出处，谢谢！
• 链接地址： github.com/yangchong21…
• 如果觉得好，可以star一下，谢谢！当然也欢迎提出建议，万事起于忽微，量变引起质变！

6.0.0.1 谈谈消息机制Hander作用？有哪些要素？流程是怎样的？简单说一下你的看法！

• 作用：
  • 跨线程通信。当子线程中进行耗时操作后需要更新UI时，通过Handler将有关UI的操作切换到主线程中执行。
• 四要素：
  • Message（消息）：需要被传递的消息，其中包含了消息ID，消息处理对象以及处理的数据等，由MessageQueue统一列队，最终由Handler处理。 技术博客大总结
  • MessageQueue（消息队列）：用来存放Handler发送过来的消息，内部通过单链表的数据结构来维护消息列表，等待Looper的抽取。
  • Handler（处理者）：负责Message的发送及处理。通过 Handler.sendMessage() 向消息池发送各种消息事件；通过 Handler.handleMessage() 处理相应的消息事件。
  • Looper（消息泵）：通过Looper.loop()不断地从MessageQueue中抽取Message，按分发机制将消息分发给目标处理者。
• 具体流程
  • Handler.sendMessage()发送消息时，会通过MessageQueue.enqueueMessage()向MessageQueue中添加一条消息；
  • 通过Looper.loop()开启循环后，不断轮询调用MessageQueue.next()；
  • 调用目标Handler.dispatchMessage()去传递消息，目标Handler收到消息后调用Handler.handlerMessage()处理消息。

  • 

6.0.0.2 Handler的post方法和view的post方法有什么区别？为什么说要避免在子线程中手动创建looper？

• Handler的post方法实现很简单，如下所示

  mHandler.post(new Runnable() {
      @Override
      public void run() {
  
      }
  });
  
  public final boolean post(Runnable r){
     return  sendMessageDelayed(getPostMessage(r), 0);
  }
  复制代码

• view的post方法也很简单，如下所示
  • 可以发现其调用的就是activity中默认保存的handler对象的post方法

  public boolean post(Runnable action) {
      final AttachInfo attachInfo = mAttachInfo;
      if (attachInfo != null) {
          return attachInfo.mHandler.post(action);
      }
      ViewRootImpl.getRunQueue().post(action);
      return true;
  }
  
  public void post(Runnable action) {
      postDelayed(action, 0);
  }
  
  public void postDelayed(Runnable action, long delayMillis) {
      final HandlerAction handlerAction = new HandlerAction(action, delayMillis);
  
      synchronized (this) {
          if (mActions == null) {
              mActions = new HandlerAction[4];
          }
          mActions = GrowingArrayUtils.append(mActions, mCount, handlerAction);
          mCount++;
      }
  }
  复制代码

• 为什么说要避免在子线程中手动创建looper？
  • 下面这种使用方式，是非常危险的一种做法
  • 在子线程中，如果手动为其创建Looper，那么在所有的事情完成以后应该调用quit方法来终止消息循环，否则这个子线程就会一直处于等待的状态，而如果退出Looper以后，这个线程就会立刻终止，因此建议不需要的时候终止Looper。(【 Looper.myLooper().quit(); 】)

  new Thread(new Runnable() {
      @Override
      public void run() {
          Looper.prepare();
          Toast.makeText(MainActivity.this, "run on Thread", Toast.LENGTH_SHORT).show();
          Looper.loop();
      }
  }).start();
  复制代码

6.0.0.3 可以在子线程直接new一个Handler吗？会出现什么问题，那该怎么做？

• 直接在子线程中创建handler，看看会出现什么情况？ 博客
  • 运行后可以得出在子线程中定义Handler对象出错，难道Handler对象的定义或者是初始化只能在主线程中？其实不是这样的，错误信息中提示的已经很明显了，在初始化Handler对象之前需要调用Looper.prepare()方法。
  • Handler的工作是依赖于Looper的，而Looper（与消息队列）又是属于某一个线程（ThreadLocal是线程内部的数据存储类，通过它可以在指定线程中存储数据，其他线程则无法获取到），其他线程不能访问。因此Handler就是间接跟线程是绑定在一起了。因此要使用Handler必须要保证Handler所创建的线程中有Looper对象并且启动循环。因为子线程中默认是没有Looper的，所以会报错。

  tv.setOnClickListener(new View.OnClickListener() {
      @Override
      public void onClick(View v) {
          new Thread() {
              @Override
              public void run() {
                  Handler mHandler = new Handler() {
                      @Override
                      public void handleMessage(Message msg) {
                          if (msg.what == 1) {
                              Log.i(TAG, "在子线程中定义Handler，接收并处理消息");
                          }
                      }
                  };
              }
          }.start();
      }
  });
  复制代码

• 如何正确运行。在这里问一个问题，在子线程中可以吐司吗？答案是可以的，只不过又条件，详细可以看这篇文章 02.Toast源码深度分析
  • 这样程序已经不会报错，那么这说明初始化Handler对象的时候我们是需要调用Looper.prepare()的，那么主线程中为什么可以直接初始化Handler呢？难道是主线程创建handler对象的时候，会自动调用Looper.prepare()方法的吗？ 博客

  tv.setOnClickListener(new View.OnClickListener() {
      @Override
      public void onClick(View v) {
          new Thread() {
              @Override
              public void run() {
                  Looper.prepare();
                  Handler mHandler = new Handler() {
                      @Override
                      public void handleMessage(Message msg) {
                          if (msg.what == 1) {
                              Log.i(TAG, "在子线程中定义Handler，接收并处理消息");
                          }
                      }
                  };
                  //获取Looper对象
                  mLooper = Looper.myLooper();
                  Looper.loop();
                  //在适当的时候退出Looper的消息循环，防止内存泄漏
                  mLooper.quit();
              }
          }.start();
      }
  });
  复制代码

6.0.0.4 说一下Handler内存泄漏有哪些？造成造成内存泄漏原因是什么？如何解决handler造成的内存泄漏？

• 解决Handler内存泄露主要2点
  • 有延时消息，要在Activity销毁的时候移除Messages
  • 匿名内部类导致的泄露改为匿名静态内部类，并且对上下文或者Activity使用弱引用。 博客
• 问题代码

  public class MainActivity extends AppCompatActivity {
      private Handler mHandler = new Handler();
      private TextView mTextView;
      @Override
      protected void onCreate(Bundle savedInstanceState) {
          super.onCreate(savedInstanceState);
          setContentView(R.layout.activity_main);
          mTextView = (TextView) findViewById(R.id.text);        //模拟内存泄露
          mHandler.postDelayed(new Runnable() {
              @Override
              public void run() {
                  mTextView.setText("yangchong");
              }
          }, 2000);
      }
  }
  复制代码

• 造成内存泄漏原因分析
  • 上述代码通过内部类的方式创建mHandler对象,此时mHandler会隐式地持有一个外部类对象引用这里就是MainActivity，当执行postDelayed方法时，该方法会将你的Handler装入一个Message，并把这条Message推到MessageQueue中，MessageQueue是在一个Looper线程中不断轮询处理消息，那么当这个Activity退出时消息队列中还有未处理的消息或者正在处理消息，而消息队列中的Message持有mHandler实例的引用，mHandler又持有Activity的引用，所以导致该Activity的内存资源无法及时回收，引发内存泄漏。
• 如何解决handler造成的内存泄漏
  • 第一种解决办法
    • 要想避免Handler引起内存泄漏问题，需要我们在Activity关闭退出的时候的移除消息队列中所有消息和所有的Runnable。
    • 上述代码只需在onDestroy()函数中调用mHandler.removeCallbacksAndMessages(null);就行了。

    @Override
    protected void onDestroy() {
        super.onDestroy();
        if(handler!=null){
            handler.removeCallbacksAndMessages(null);
            handler = null;
        }
    }
    复制代码

  • 第二种解决方案
    • 使用弱引用解决handler内存泄漏问题，关于代码案例，可以参考我的开源项目： github.com/yangchong21…

    //自定义handler
    public static class HandlerHolder extends Handler {
        WeakReference<OnReceiveMessageListener> mListenerWeakReference;
        /**
         * @param listener 收到消息回调接口
         */
        HandlerHolder(OnReceiveMessageListener listener) {
            mListenerWeakReference = new WeakReference<>(listener);
        }
    
        @Override
        public void handleMessage(Message msg) {
            if (mListenerWeakReference!=null && mListenerWeakReference.get()!=null){
                mListenerWeakReference.get().handlerMessage(msg);
            }
        }
    }
    
    //创建handler对象
    private HandlerHolder handler = new HandlerHolder(new OnReceiveMessageListener() {
        @Override
        public void handlerMessage(Message msg) {
            switch (msg.what){
                case 1:
                    TextView textView1 = (TextView) msg.obj;
                    showBottomInAnimation(textView1);
                    break;
                case 2:
                    TextView textView2 = (TextView) msg.obj;
                    showBottomOutAnimation(textView2);
                    break;
            }
        }
    });
    
    //发送消息
    Message message = new Message();
    message.what = 1;
    message.obj = textView;
    handler.sendMessageDelayed(message,time);
    
    
    即推荐使用静态内部类 + WeakReference 这种方式。每次使用前注意判空。
    复制代码

6.0.0.5 Activity如何自动绑定Looper？主线程中的Looper死循环和binder线程中的死循环有哪些区别？

• 主线程如何自动调用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();
  复制代码

6.0.0.6 Looper.prepare()能否调用多次？调用多次会出现什么情况？Looper中用什么存储消息？

• 思考：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中用什么存储消息
  • 先看一下下面得源代码
  • 可以看到Looper中有一个ThreadLocal成员变量，熟悉JDK的同学应该知道，当使用ThreadLocal维护变量时，ThreadLocal为每个使用该变量的线程提供独立的变量副本，所以每一个线程都可以独立地改变自己的副本，而不会影响其它线程所对应的副本。
  • 看Looper对象的构造方法，可以看到在其构造方法中初始化了一个MessageQueue对象。MessageQueue也称之为消息队列，特点是先进先出，底层实现是单链表数据结构。

  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));
  }
  
  private Looper(boolean quitAllowed) {
      mQueue = new MessageQueue(quitAllowed);
      mThread = Thread.currentThread();
  }
  复制代码

6.0.0.6 为什么系统不建议在子线程访问UI，不对UI控件的访问加上锁机制的原因？

• 出自《Android艺术探索》
• 这是因为Android的UI控件不是线程安全的，如果在多线程中并发访问可能会导致UI控件处于不可预期的状态，那么为什么系统不对UI控件的访问加上锁机制呢？缺点有两个：
  • ①首先加上锁机制会让UI访问的逻辑变得复杂
  • ②锁机制会降低UI访问的效率，因为锁机制会阻塞某些线程的执行。
  • 所以最简单且高效的方法就是采用单线程模型来处理UI操作。
• 为什么说子线程不能更新UI？
  • 子线程是不能直接更新UI的。Android实现View更新有两组方法，分别是invalidate和postInvalidate。前者在UI线程中使用，后者在非UI线程即子线程中使用。换句话说，在子线程调用 invalidate 方法会导致线程不安全。熟悉View工作原理的人都知道，invalidate 方法会通知 view 立即重绘，刷新界面。作一个假设，现在用 invalidate 在子线程中刷新界面，同时UI线程也在用 invalidate 刷新界面，这样会不会导致界面的刷新不能同步？这就是invalidate不能在子线程中使用的原因。 博客

6.0.0.7 Looper.loop是一个死循环，拿不到需要处理的Message就会阻塞，那在UI线程中为什么不会导致ANR？

• 问题描述
  • 在处理消息的时候使用了Looper.loop()方法，并且在该方法中进入了一个死循环，同时Looper.loop()方法是在主线程中调用的，那么为什么没有造成阻塞呢？
• ActivityThread中main方法
  • ActivityThread类的注释上可以知道这个类管理着我们平常所说的主线程(UI线程)
    • 首先 ActivityThread 并不是一个 Thread，就只是一个 final 类而已。我们常说的主线程就是从这个类的 main 方法开始，main 方法很简短

    public static final void main(String[] args) {
        ...
        //创建Looper和MessageQueue
        Looper.prepareMainLooper();
        ...
        //轮询器开始轮询
        Looper.loop();
        ...
    }
    复制代码

• Looper.loop()方法无限循环
  • 看看Looper.loop()方法无限循环部分的代码

    while (true) {
       //取出消息队列的消息，可能会阻塞
       Message msg = queue.next(); // might block
       ...
       //解析消息，分发消息
       msg.target.dispatchMessage(msg);
       ...
    }
    复制代码

• 为什么这个死循环不会造成ANR异常呢？
  • 因为Android 的是由事件驱动的，looper.loop() 不断地接收事件、处理事件，每一个点击触摸或者说Activity的生命周期都是运行在 Looper.loop() 的控制之下，如果它停止了，应用也就停止了。只能是某一个消息或者说对消息的处理阻塞了 Looper.loop()，而不是 Looper.loop() 阻塞它。 技术博客大总结
• 处理消息handleMessage方法
  • 如下所示
    • 可以看见Activity的生命周期都是依靠主线程的Looper.loop，当收到不同Message时则采用相应措施。
    • 如果某个消息处理时间过长，比如你在onCreate(),onResume()里面处理耗时操作，那么下一次的消息比如用户的点击事件不能处理了，整个循环就会产生卡顿，时间一长就成了ANR。

    public void handleMessage(Message msg) {
        if (DEBUG_MESSAGES) Slog.v(TAG, ">>> handling: " + codeToString(msg.what));
        switch (msg.what) {
            case LAUNCH_ACTIVITY: {
                Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityStart");
                final ActivityClientRecord r = (ActivityClientRecord) msg.obj;
                r.packageInfo = getPackageInfoNoCheck(r.activityInfo.applicationInfo, r.compatInfo);
                handleLaunchActivity(r, null);
                Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
            }
            break;
            case RELAUNCH_ACTIVITY: {
                Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityRestart");
                ActivityClientRecord r = (ActivityClientRecord) msg.obj;
                handleRelaunchActivity(r);
                Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
            }
            break;
            case PAUSE_ACTIVITY:
                Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityPause");
                handlePauseActivity((IBinder) msg.obj, false, (msg.arg1 & 1) != 0, msg.arg2, (msg.arg1 & 2) != 0);
                maybeSnapshot();
                Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
                break;
            case PAUSE_ACTIVITY_FINISHING:
                Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityPause");
                handlePauseActivity((IBinder) msg.obj, true, (msg.arg1 & 1) != 0, msg.arg2, (msg.arg1 & 1) != 0);
                Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
                break;
            ...........
        }
    }
    复制代码

• loop的循环消耗性能吗？
  • 主线程Looper从消息队列读取消息，当读完所有消息时，主线程阻塞。子线程往消息队列发送消息，并且往管道文件写数据，主线程即被唤醒，从管道文件读取数据，主线程被唤醒只是为了读取消息，当消息读取完毕，再次睡眠。因此loop的循环并不会对CPU性能有过多的消耗。
  • 简单的来说：ActivityThread的main方法主要就是做消息循环，一旦退出消息循环，那么你的程序也就可以退出了。

6.0.0.9 Message可以如何创建？哪种效果更好，为什么？runOnUiThread如何实现子线程更新UI？

• 创建Message对象的几种方式： 技术博客大总结
  • Message msg = new Message();
  • Message msg = Message.obtain();
  • Message msg = handler1.obtainMessage();
• 后两种方法都是从整个Messge池中返回一个新的Message实例，能有效避免重复Message创建对象，因此更鼓励这种方式创建Message
• runOnUiThread如何实现子线程更新UI
  • 看看源码，如下所示
  • 如果msg.callback为空的话，会直接调用我们的mCallback.handleMessage(msg)，即handler的handlerMessage方法。由于Handler对象是在主线程中创建的，所以handler的handlerMessage方法的执行也会在主线程中。
  • 在runOnUiThread程序首先会判断当前线程是否是UI线程，如果是就直接运行，如果不是则post，这时其实质还是使用的Handler机制来处理线程与UI通讯。

  public void dispatchMessage(Message msg) {
      if (msg.callback != null) {
          handleCallback(msg);
      } else {
          if (mCallback != null) {
              if (mCallback.handleMessage(msg)) {
                  return;
              }
          }
          handleMessage(msg);
      }
  }
  
  @Override
  public final void runOnUiThread(Runnable action) {
      if (Thread.currentThread() != mUiThread) {
          mHandler.post(action);
      } else {
          action.run();
      }
  }
  复制代码

6.0.1.0 MessageQueue作用是干什么的？MessageQueue的定义是什么？MessageQueue主要工作原理是怎样的？

• MessageQueue作用是干什么的
  • MessageQueue，主要包含2个操作：插入和读取。
    • 读取操作会伴随着删除操作，插入和读取对应的方法分别为enqueueMessage和next，其中enqueueMessage的作用是往消息队列中插入一条消息，而next的作用是从消息队列中取出一条消息并将其从消息队列中移除。
  • 虽然MessageQueue叫消息队列，但是它的内部实现并不是用的队列。
    • 实际上它是通过一个单链表的数据结构来维护消息列表，单链表在插入和删除上比较有优势。
• MessageQueue的定义是什么
  • 通过源码我们可以知道，MessageQueue维护了一个消息列表。Messgae并不是直接添加到MessageQueue中，而是通过和Looper相关联的Handler来添加的。在当前线程中可以通过调用Looper.myQueue()方法来获取当前线程的MessageQueue。 博客

  /**
   * Low-level class holding the list of messages to be dispatched by a
   * {@link Looper}.  Messages are not added directly to a MessageQueue,
   * but rather through {@link Handler} objects associated with the Looper.
   * 
   * <p>You can retrieve the MessageQueue for the current thread with
   * {@link Looper#myQueue() Looper.myQueue()}.
   */
  public final class MessageQueue
  复制代码

• MessageQueue主要工作原理是怎样的？
  • 源码如下所示
    • 在Message的源码中定义了一个成员属性target，其类型为Handler。由上面enqueuMessage的源码，我们可以看到，当Message没有处理其的Handler或该Message正在被处理的时候，都不能正常进入MessageQueue，这一点也是很容易理解的。当线程处于死亡状态的时候，Message会被回收掉，而不再进入该线程对应的MessageQueue中。否则，一切正常，enqueMessage就执行单链表的插入操作，将Message插入到MessageQueue中。

    boolean enqueueMessage(Message msg, long when) {
        if (msg.target == null) {
            throw new IllegalArgumentException("Message must have a target.");
        }
        if (msg.isInUse()) {
            throw new IllegalStateException(msg + " This message is already in use.");
        }
    
        synchronized (this) {
            if (mQuitting) {
                IllegalStateException e = new IllegalStateException(
                        msg.target + " sending message to a Handler on a dead thread");
                Log.w(TAG, e.getMessage(), e);
                msg.recycle();
                return false;
            }
    
            msg.markInUse();
            msg.when = when;
            Message p = mMessages;
            boolean needWake;
            if (p == null || when == 0 || when < p.when) {
                // New head, wake up the event queue if blocked.
                msg.next = p;
                mMessages = msg;
                needWake = mBlocked;
            } else {
                // Inserted within the middle of the queue.  Usually we don't have to wake
                // up the event queue unless there is a barrier at the head of the queue
                // and the message is the earliest asynchronous message in the queue.
                needWake = mBlocked && p.target == null && msg.isAsynchronous();
                Message prev;
                for (;;) {
                    prev = p;
                    p = p.next;
                    if (p == null || when < p.when) {
                        break;
                    }
                    if (needWake && p.isAsynchronous()) {
                        needWake = false;
                    }
                }
                msg.next = p; // invariant: p == prev.next
                prev.next = msg;
            }
    
            // We can assume mPtr != 0 because mQuitting is false.
            if (needWake) {
                nativeWake(mPtr);
            }
        }
        return true;
    }
    复制代码

  • next()方法源码分析
    • 在 MessageQueue 中消息的读取其实是通过内部的 next() 方法进行的， next() 方法是一个无限循环的方法。 博客
    • 如果消息队列中没有消息，则该方法会一直阻塞，
    • 当有新消息来的时候 next() 方法会返回这条消息并将其从单链表中删除。

    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;
        }
    }
    复制代码

6.0.1.1 子线程更新UI有哪些方式？runOnUiThread如何实现子线程更新UI？View.post(Runnable r)更新UI？

• 子线程更新UI有哪些方式
  • 主线程中定义Handler，子线程通过mHandler发送消息，主线程Handler的handleMessage更新UI
  • 用Activity对象的runOnUiThread方法
  • 创建Handler，传入getMainLooper
  • View.post(Runnable r)
• runOnUiThread如何实现子线程更新UI
  • 如何使用代码如下所示

  new Thread(new Runnable() {
      @Override
      public void run() {
          runOnUiThread(new Runnable() {
              @Override
              public void run() {
                  tv_0.setText("滚犊子++++");
              }
          });
      }
  }).start();
  复制代码

  • 看看源码，如下所示
  • 如果msg.callback为空的话，会直接调用我们的mCallback.handleMessage(msg)，即handler的handlerMessage方法。由于Handler对象是在主线程中创建的，所以handler的handlerMessage方法的执行也会在主线程中。
  • 在runOnUiThread程序首先会判断当前线程是否是UI线程，如果是就直接运行，如果不是则post，这时其实质还是使用的Handler机制来处理线程与UI通讯。 博客

  public void dispatchMessage(Message msg) {
      if (msg.callback != null) {
          handleCallback(msg);
      } else {
          if (mCallback != null) {
              if (mCallback.handleMessage(msg)) {
                  return;
              }
          }
          handleMessage(msg);
      }
  }
  
  @Override
  public final void runOnUiThread(Runnable action) {
      if (Thread.currentThread() != mUiThread) {
          mHandler.post(action);
      } else {
          action.run();
      }
  }
  复制代码

• View.post(Runnable r)更新UI
  • 代码如下所示

  tv_0.post(new Runnable() {
      @Override
      public void run() {
          tv_0.setText("滚犊子");
      }
  });
  复制代码

  • 源码原理如下所示

  public boolean post(Runnable action) {
      final AttachInfo attachInfo = mAttachInfo;
      if (attachInfo != null) {
          return attachInfo.mHandler.post(action);
      }
  
      // Postpone the runnable until we know on which thread it needs to run.
      // Assume that the runnable will be successfully placed after attach.
      getRunQueue().post(action);
      return true;
  }
  
  private HandlerActionQueue getRunQueue() {
      if (mRunQueue == null) {
          mRunQueue = new HandlerActionQueue();
      }
      return mRunQueue;
  }
  复制代码

  • View.post(Runnable r)使用注意事项
  • 看源码的注释可知：如果view已经attached，则调用ViewRootImpl中的ViewRootHandler，放入主线程Lopper等待执行。如果detach，则将其暂存在RunQueue当中，等待其它线程取出执行。
  • View.post(Runnable r)很多时候在子线程调用，用于进行子线程无法完成的操作，或者在该方法中通过getMeasuredWidth()获取view的宽高。需要注意的是，在子线程调用该函数，可能不会被执行，原因是该view不是attached状态。 博客
• 子线程更新UI总结概括
  • handler.post(Runnable r)、 view.post(Runnable r)、activity.runOnUIThread(Runnable r)等方法。跟进去看源码，发现其实它们的实现原理都还是一样，最终都是通过Handler发送消息来实现的。

6.0.1.3 使用Hanlder的postDealy()后消息队列会发生什么变化？

• post delay的Message并不是先等待一定时间再放入到MessageQueue中，而是直接进入并阻塞当前线程，然后将其delay的时间和队头的进行比较，按照触发时间进行排序，如果触发时间更近则放入队头，保证队头的时间最小、队尾的时间最大。此时，如果队头的Message正是被delay的，则将当前线程堵塞一段时间，直到等待足够时间再唤醒执行该Message，否则唤醒后直接执行。

6.0.1.4 ThreadLocal有什么作用？如何避免UI线程尽量只做跟UI相关的工作?

• 线程本地存储的功能
  • ThreadLocal类可实现线程本地存储的功能，把共享数据的可见范围限制在同一个线程之内，无须同步就能保证线程之间不出现数据争用的问题，这里可理解为ThreadLocal帮助Handler找到本线程的Looper。
  • 技术博客大总结
• 怎么存储呢？底层数据结构是啥？
  • 每个线程的Thread对象中都有一个ThreadLocalMap对象，它存储了一组以ThreadLocal.threadLocalHashCode为key、以本地线程变量为value的键值对，而ThreadLocal对象就是当前线程的ThreadLocalMap的访问入口，也就包含了一个独一无二的threadLocalHashCode值，通过这个值就可以在线程键值值对中找回对应的本地线程变量。
• 如何避免UI线程尽量只做跟UI相关的工作?
  • 耗时的操作(比如数据库操作，I/O,连接网络或者别的有可能阻塞UI线程的操作)把它放在单独的线程处理尽量用Handler来处理UIthread和别的thread之间的交互.使用Thread或者HandlerThread时，调用Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND)设置优先级，否则仍然会降低程序响应，因为默认Thread的优先级和主线程相同。使用Handler处理工作线程结果，而不是使用Thread.wait()或者Thread.sleep()来阻塞主线程。

6.0.1.5 为什么一个线程只有一个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，不知道这样解释是否合理！更多可以查看我的博客汇总： github.com/yangchong21…

  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));
  }
  复制代码