Android消息机制浅析

Posted on | Edited on | In | Comments:

Android消息机制可以说是Android系统的核心也不为过，所有与UI相关的操作基本都需要依赖消息机制，而Handler就是消息机制的上层开放的接口。一般我们不论是更新UI还是异步传递消息都只需要通过Handler即可。

使用消息机制的原因

  • android4.0以后不允许主线程进行网络请求

    现在几乎每个app都需要访问网络，而在android4.0以前，访问网络操作是可以在UI线程中进行的，但在4.0以后，Android默认禁止在UI线程中进行网络请求和相关操作（会报NetworkOnMainThreadException的异常，但其实可以强制在主线程里进行）。另外我们知道，Android的UI线程的等待时间，也就是Activity的等待时间为5秒，Service（服务也是运行于UI线程下的）的为20秒，所以比较耗时的操作也不能放在主线程里运行。

  • 子线程不能操作主线程UI

    子线程完成了耗时操作，按照业务逻辑一般需要在UI中做出反馈，但是却不能直接修改主线程UI，因为android规定只有创建了View的线程才能操作这个view。所以反过来主线程也不能操作子线程创建的View。

  • 多线程消息传递

    子线程执行完毕，需要返回执行结果或取得的数据，就得借助于消息机制来传递。

而以上问题，借助消息机制，通过Handler就全部都能搞定。

消息机制的框架

android中的消息机制由Handler，MessageQueue，Looper，Message组成，其架构如图：

Handler: 线程之间通信的桥梁，通过Handler可以发送消息(sendMessage)和处理消息(handleMessage)；
Message: 被发送的消息，可以存放一些关键性的指信息，如文本，对象等，另外可以指定消息的标志，表明该消息应该如何处理；
MessageQueue: 存放消息的队列，所有由子线程发送给主线程的消息都暂存在这里，等待Looper来取；
Looper: 通过loop()无限循环不断从MessageQueue取消息并将消息提交至Handler；每个线程只能存在一个Looper的实例，但一个Looper实例可以被多个线程引用；

消息的处理过程（代码）

  • 在主线程中创建一个Handler的实例并重写handleMessage方法：
1
2
3
4
5
6
7
8
private Handler handler=new Handler(){
    @Override
    public void handleMessage(Message msg) {
        switch (msg.what){
            // TODO: 操作UI 
        }
    }
};
  • 在子线程向主线程发送信息
1
2
3
4
5
6
7
8
9
new Thread(){
    @Override
    public void run() {
        ...
        Message msg=new Message();
        msg.what=LOAD_IMAGE;
        handler.sendMessage(msg);
    }
}.start();

其实需要我们写的代码就这么多，系统在后台自动帮们实时获取到队列中的Message并提交到了Handler，但是我们还是需要了解其背后的一些原理。

为什么主线程可以更新UI

事实上所有的线程本身都不具有消息循环能力，而是通过Looper.prepare()方法可以将一个线程转换为Looper线程，同时也就具备了消息循环能力。
当主线程被创建的时候，系统会自动调用Looper.prepare()将当前线程转换为Looper线程，然后在创建Handler的时候系统会自动调用Looper.loop()进行轮询。
所以其实我们在子线程中也是可以更新UI的，只要将操作UI对象的代码写在Looper.prepare()和Looper.loop()之间，当然大前提还是操作的UI对象必须得是子线程自己创建的。
因此即使子线程可以操作自己的UI对象，比如弹出一个Toast(使用getApplicationContext)，但是子线程仍然不能直接操作主线程的UI。
同理主线程也不能操作子线程创建的UI对象，想要操作也必须引用子线程中的Handler发送消息来更新。

消息的处理过程（原理）

通过上面的解释，接着来深入分析消息机制的实现流程：

  • 当我们创建Handler的实例：

    • 与该线程唯一的Looper进行绑定
    • 与Looper下的MessageQueue进行绑定

  • 当我们发送一个消息的时候

    • 调用过程：sendMessage() -> sendMessageDelayed() -> sendMessageAtTime() -> enqueueMessage()
    • 在sendMessageAtTime()方法中会将Message与MessageQueue进行关联，然后在enqueueMessage()中实际将消息加入消息队列；
    • 在enqueueMessage()方法中，会将Message与发送消息的Handler通过target属性进行绑定，确保最后调用正确的Handler来处理消息，也就是确保消息处理的唯一性；

  • MessageQueue建立完成

    • Looper.loop() 以无限循环遍历Looper内部的MessageQueue，通过msg.target.dispatchMessage(msg)调用Handler的事件分发实现消息回调处理。
    • handleMessage()方法被调用

看似神奇的post()方法

或许你见过有的人直接调用对象的post()或者postXXX()方法可以直接在子线程中进行UI操作，但是如果深入去看这些方法的源码，就会发现其实他们也是依赖于消息机制，例如post()的流程：
post() -> attachInfo.mHandler.post(action) -> sendMessageDelayed() -> sendMessageAtTime() -> enqueueMessage()

所以post()类型的方法底层也是使用消息机制进行UI操作，只是Android官方帮我们做了封装而已。

强制在主线程请求网络

虽然Android官方禁止在4.0以后的版本中在主线程中进行网络请求，但是仍然可以通过特殊的方法强制在主线程中进行：
在UI线程的onCreate()方法中setContentView()之后添加如同下代码：

1
2
3
4
if (android.os.Build.VERSION.SDK_INT > 9) {
    StrictMode.ThreadPolicy policy = new StrictMode.ThreadPolicy.Builder().permitAll().build();
    StrictMode.setThreadPolicy(policy);
}

这几行代码的作用是修改当前线程的限制策略，表示允许所有行为，即所有不规范的的操作都是被允许的。

这几行代码其实是相当危险的，这以后的所有的不规范操作都不会被编译器识别并提醒，或许你当时没有发现什么错误，但是以后会有很多的坑等着你往里跳呢。所以最好不要使用这种方法，按照Android官方的规范，把所有与网络请求的操作放入子线程运行。