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 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.
 * 
 * 
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));
}

01.关于博客汇总链接

1.技术博客汇总

2.开源项目汇总

3.生活博客汇总

4.喜马拉雅音频汇总

5.其他汇总

02.关于我的博客

我的个人站点：www.yczbj.org， www.ycbjie.cn

github：github.com/yangchong21…

知乎：www.zhihu.com/people/yczb…

简书：www.jianshu.com/u/b7b2c6ed9…

csdn：my.csdn.net/m0_37700275

喜马拉雅听书：www.ximalaya.com/zhubo/71989…

开源中国：my.oschina.net/zbj1618/blo…

泡在网上的日子：www.jcodecraeer.com/member/cont…

邮箱：yangchong211@163.com

阿里云博客：yq.aliyun.com/users/artic… 239.headeruserinfo.3.dT4bcV

segmentfault头条：segmentfault.com/u/xiangjian…

掘金：juejin.im/user/593943…