Android Handler 消息机制

【Android Handler 消息机制】

前言

在Android开发中,我们都知道不能在主线程中执行耗时的任务避免ANR

Android中主线程也叫UI线程,那么从名字上我们也知道主线程主要是用来创建、更新UI的,而其他耗时操作,比如网络访问,或者文件处理,多媒体处理等都需要在子线程中操作。
之所以在子线程中操作是为了保证UI的流畅程度,手机显示的刷新频率是60Hz,也就是一秒钟刷新60次,每16.67毫秒刷新一次,为了不丢帧,那么主线程处理代码最好不要超过16毫秒。

当子线程处理完数据后,为了防止UI处理逻辑的混乱,Android只允许主线程修改UI,那么这时候就需要Handler来充当子线程和主线程之间的桥梁了。Handler机制在Android多线程编程中可以说是不可或缺的角色。

消息机制概述

Android系统在设计的初期就已经考虑到了UI的更新问题,由于Android中的View是线程不安全的,然而程序中异步处理任务结束后更新UI元素也是必须的。这就造成了一个矛盾,最简单的解决方法肯定是给View加同步锁使其变成线程安全的。这样做不是不可以,只是会有两点坏处:

  1. 加锁会有导致效率底下
  2. 由于可以在多个地方更新UI,开发就必须很小心操作,开发起来就很麻烦,一不小心就出错了。

基于以上两个缺点,谷歌设置一个线程专门处理UI控件的更新,如果其他线程也需要对UI进行更新,必须把想做的告诉那个专门处理UI线程的家伙,让它帮你做。大家各有各的任务,井水不犯河水,各司其职。

消息机制简单概括:其他线程通过给特定线程发送消息,将某项专职的工作,交给这个特定的线程去做。比如说其他线程都把处理UI显示的工作通过发送消息交给UI线程去做。

实现原理呢,我是这么理解的,现在要做的主要工作就是切换线程去操作,怎么切换呢?把两条线程看作是两条并行的公路,如果要从一条公路转到另一条公路上,要怎么做呢?是不是只要找到两条公路交叉或者共用某个资源的地方,如果说交叉路口,比如说加油站。当然了,线程是不存在交叉的地方的,那么可以考虑他们公用资源的地方,不同的进程享用不同的内存空间,但是同一个进程的不同线程享用的是同一片内存空间,那让其他线程把要处理的消息放到这个特定的内存空间上,处理消息的线程来这个内存空间上来取消息去处理不就可以了吗。事实正是如此,在Android的消息机制中,扮演这个特定内存空间的对象就是MessageQueue对象,发送和处理的消息就是Message对象。其他的HandlerLooper都是为了配合线程切换用的。
其实不仅仅是线程之间,不同进程之间进行消息传递(IPC机制),也是这个思路,找到公用的一个资源点,文件系统啊,共享内存啊等等。

Handler

Handler的主要用途

  1. 推送未来某个时间点将要执行的Message或者Runnable到消息队列。
  2. 在子线程把需要在另一个线程执行的操作加入到消息队列中去。

废话不多说,通过举例来说明Handler的两个主要用途。

1. 推送未来某个时间点将要执行的Message或者Runnable到消息队列

实例:通过Handler配合Message或者Runnable实现倒计时

  • 首先看一下效果图

Android Handler 消息机制_第1张图片

  • 方法一,通过Handler + Message的方式实现倒计时。代码如下:
public class MainActivity extends AppCompatActivity {
    private ActivityMainBinding mBinding;
    private Handler mHandler ;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        mBinding = DataBindingUtil.setContentView(this, R.layout.activity_main);
        //设置监听事件
        mBinding.clickBtn.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                //通过Handler + Message的方式实现倒计时
                for (int i = 1; i <= 10; i++) {
                    Message message = Message.obtain(mHandler);
                    message.what = 10 - i;
                    mHandler.sendMessageDelayed(message, 1000 * i); //通过延迟发送消息,每隔一秒发送一条消息
                }
            }
        });
        mHandler = new Handler() {
            @Override
            public void handleMessage(Message msg) {
                super.handleMessage(msg);
                mBinding.time.setText(msg.what + "");   //在handleMessage中处理消息队列中的消息
            }
        };
    }
}

通过这个小程序,大家可以了解到Handler的一个作用就是:在主线程中,可以通过Handler来处理一些有顺序的操作,让它们在固定的时间点被执行。

  • 方法二,通过Handler + Runnable的方式实现倒计时。代码如下:
public class MainActivity extends AppCompatActivity {
    private ActivityMainBinding mBinding;
    private Handler mHandler = new Handler();
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        mBinding = DataBindingUtil.setContentView(this, R.layout.activity_main);
        //设置监听事件
        mBinding.clickBtn.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                for (int i = 1; i <= 10; i++) {
                    final int fadedSecond = i;
                    //每延迟一秒,发送一个Runnable对象
                    mHandler.postDelayed(new Runnable() {
                        @Override
                        public void run() {
                            mBinding.time.setText((10 - fadedSecond) + "");
                        }
                    }, 1000 * i);
                }
            }
        });
    }
}

方法二也是通过代码让大家加深Handler处理有序事件的用途,之所以分开Runnable和Message两种方法来实现,是因为很多人都搞不清楚为什么Handler可以推送Runnable和Message两种对象。
其实,无论Handler将Runnable还是Message加入MessageQueue,最终都只是将Message加入到MessageQueue。Handler的post Runnable对象这个方法只是对post Message进行了一层封装,所以最终我们都是通过Handler推送了一个Message罢了。

2. 在子线程把需要在另一个线程执行的操作加入到消息队列中去

实例:通过Handler + Message来实现子线程加载图片,在UI线程显示图片

  • 效果图如下

Android Handler 消息机制_第2张图片

  • 代码如下(布局代码也不放出来了)
public class ThreadActivity extends AppCompatActivity implements View.OnClickListener {
    private ActivityThreadBinding mBinding = null;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        mBinding = DataBindingUtil.setContentView(this, R.layout.activity_thread);
        // 设置点击事件
        mBinding.clickBtn.setOnClickListener(this);
        mBinding.resetBtn.setOnClickListener(this);
    }
    @Override
    public void onClick(View v) {
        switch (v.getId()) {
            // 响应load按钮
            case R.id.clickBtn:
                // 开启一个线程
                new Thread(new Runnable() {
                    @Override
                    public void run() {
                        // 在Runnable中进行网络读取操作,返回bitmap
                        final Bitmap bitmap = loadPicFromInternet();
                        // 在子线程中实例化Handler同样是可以的,只要在构造函数的参数中传入主线程的Looper即可
                        Handler handler = new Handler(Looper.getMainLooper());
                        // 通过Handler的post Runnable到UI线程的MessageQueue中去即可
                        handler.post(new Runnable() {
                            @Override
                            public void run() {
                                // 在MessageQueue出队该Runnable时进行的操作
                                mBinding.photo.setImageBitmap(bitmap);
                            }
                        });
                    }
                }).start();
                break;
            case R.id.resetBtn:
                mBinding.photo.setImageBitmap(BitmapFactory.decodeResource(getResources(), R.mipmap.default_pic));
                break;
        }
    }

    /* HttpUrlConnection加载图片 */
    public Bitmap loadPicFromInternet() {
        Bitmap bitmap = null;
        int respondCode = 0;
        InputStream is = null;
        try {
            URL url = new URL("https://ss2.bdstatic.com/70cFvnSh_Q1YnxGkpoWK1HF6hhy/it/u=1421494343,3838991329&fm=23&gp=0.jpg");
            HttpURLConnection connection = (HttpURLConnection) url.openConnection();
            connection.setRequestMethod("GET");
            connection.setConnectTimeout(10 * 1000);
            connection.setReadTimeout(5 * 1000);
            connection.connect();
            respondCode = connection.getResponseCode();
            if (respondCode == 200) {
                is = connection.getInputStream();
                bitmap = BitmapFactory.decodeStream(is);
            }
        } catch (MalformedURLException e) {
            e.printStackTrace();
            Toast.makeText(getApplicationContext(), "访问失败", Toast.LENGTH_SHORT).show();
        } catch (IOException e) {
            e.printStackTrace();
        } finally {
            if (is != null) {
                try {
                    is.close();
                } catch (IOException e) {
                    e.printStackTrace();
                }
            }
        }
        return bitmap;
    }
}

Handler推送Message和Runnable的区别

首先我们看看post方法和sendMessage方法的源码:

    public final boolean post(Runnable r){
       return  sendMessageDelayed(getPostMessage(r), 0);
    }
    public final boolean sendMessage(Message msg) {
        return sendMessageDelayed(msg, 0);
    }

可见,两个方法都是通过调用sendMessageDelayed方法实现的,所以可以知道它们的底层逻辑是一致的。

但是,post方法的底层调用sendMessageDelayed的时候,却是通过getPostMessage(r)来将Runnable对象来转为Message,我们点进方getPostMessage()法可以看到:

    private static Message getPostMessage(Runnable r) {
        Message m = Message.obtain();
        m.callback = r;
        return m;
    }

其实,最终runnable最终也是转化为一个Message,而这个Message只有一个被赋值的成员变量,就是Runnable的回调函数,也就是说,这个Message在进入MessageQueue之后,它只是一个“动作”,即我们Runnbale的run方法里面的操作。

要知道,我们的Message类可是有很多参数的,所以你可以理解为它是一个非常丰富的JavaBean,可以看看它的成员变量:

  • public int what;
  • public int arg1;
  • public int arg2;
  • public Object obj;
  • ...

那么讲到这里,大家也应该有所理解为什么Google工程师为什么会封装这两种方法,我总结如为:为了更方便开发者根据不同需要进行调用
当我们需要传输很多数据时,我们可以使用sendMessage来实现,因为通过给Message的不同成员变量赋值可以封装成数据非常丰富的对象,从而进行传输;
当我们只需要进行一个动作时,直接使用Runnable,在run方法中实现动作内容即可。当然我们也可以通过Message.obtain(Handler h, Runnable callback)来传入callback接口,但这样看起来就没有post(Ruannable callback)那么直观。

API

API是我们学习最好的文档

构造函数

  • Handler()
  • Handler(Handler.Callback callback):传入一个实现的Handler.Callback接口,接口只需要实现handleMessage方法。
  • Handler(Looper looper):将Handler关联到任意一个线程的Looper,在实现子线程之间通信可以用到。
  • Handler(Looper looper, Handler.Callback callback)

主要方法

  • void dispatchMessage (Message msg)
    一般情况下不会使用,因为它的底层实现其实是作为处理系统消息的一个方法,如果真要用,效果和sendMessage(Message m)效果一样。

    public void dispatchMessage(Message msg) {
        if (msg.callback != null) {
            // 如果有Runnbale,则直接执行它的run方法
            handleCallback(msg);
        } else {
            //如果有实现自己的callback接口
            if (mCallback != null) {
                //执行callback的handleMessage方法
                if (mCallback.handleMessage(msg)) {
                    return;
                }
            }
            //否则执行自身的handleMessage方法
            handleMessage(msg);
        }
    }
    private static void handleCallback(Message message) {
        message.callback.run();
    }
    
  • void dump (Printer pw, String prefix)
    主要Debug时使用的一个方法,dump函数只是使用了Printer对象进行了打印,打印出Handler以及Looper和Queue中的一些信息,源码如下:

    public final void dump(Printer pw, String prefix) {
        pw.println(prefix + this + " @ " + SystemClock.uptimeMillis());
        // 如果Looper为空,输出Looper没有初始化
        if (mLooper == null) {
            pw.println(prefix + "looper uninitialized");
        } else {
            // 否则调用Looper的dump方法,Looper的dump方法也是
            mLooper.dump(pw, prefix + "  ");
        }
    }
    

    通过测试用例大家会了解得更清晰:

          //测试代码
          Printer pw = new LogPrinter(Log.ERROR, "MyTag");
          mHandler.dump(pw, "prefix");
    

    结果:

  • Looper getLooper ()
    拿到Handler相关联的Looper

  • String getMessageName (Message message)
    获取Message的名字,默认名字为message.what的值。

  • void handleMessage (Message msg)
    处理消息。

  • boolean hasMessages (int what)
    判断是否有Message的what值为参数what。

  • boolean hasMessages (int what, Object object)
    判断是否有Message的what值为参数what,obj值为参数object。

  • Message obtainMessage (int what, Object obj)
    从消息池中拿到一个消息并赋值what和obj,其他重载函数同理。

  • boolean post (Runnable r)
    将Runnable对象加入MessageQueue。

  • boolean post (Runnable r)
    将Runnbale加入到消息队列的队首。但是官方不推荐这么做,因为很容易打乱队列顺序。

  • boolean postAtTime (Runnable r, Object token, long uptimeMillis)
    在某个时间点执行Runnable r。

  • boolean postDelayed (Runnable r, long delayMillis)
    当前时间延迟delayMillis个毫秒后执行Runnable r。

  • void removeCallbacks (Runnable r, Object token)
    移除MessageQueue中的所有Runnable对象。

  • void removeCallbacksAndMessages (Object token)
    移除MessageQueue中的所有Runnable和Message对象。

  • void removeMessages (int what)
    移除所有what值得Message对象。

  • boolean sendEmptyMessage (int what)
    直接拿到一个空的消息,并赋值what,然后发送到MessageQueue。

  • boolean sendMessageDelayed (Message msg, long delayMillis)
    在延迟delayMillis毫秒之后发送一个Message到MessageQueue。

Handler内存泄漏问题

在上面的例子中,为了展示方便,我都没有考虑内存泄漏的情况,但是在实际开发中,如果不考虑代码的安全性的话,尤其当一个项目到达了一定的规模之后,那么对于代码的维护和系统的调试都是非常困难的。而Handler的内存泄漏在Android中也是一个非常经典的案例。

详细可以参考:How to Leak a Context: Handlers & Inner Classes

或参考翻译文:Android中Handler引起的内存泄露

典型错误的使用示例

public class LeakActivity extends AppCompatActivity {
    private int a = 10;
    //也是匿名内部类,也会引用外部
    private Handler mHandler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
            switch (msg.what) {
            case 0:
                a = 20;
                break;
            }
        }
    };
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_leak);
        mHandler.sendEmptyMessageDelayed(0, 5000);
        mHandler.postDelayed(new Runnable() {
            @Override
            public void run() {
                ...
            }
        }, 1000000);
    }
}

分析问题:

  1. 外部类Activity中定义了一个非静态内部类Handler非静态内部类默认持有对外部类的引用
    如果外部Activity突然关闭了,MessageQueue中的消息还没处理完,那么Handler就会一直持有对外部Activty的引用,垃圾回收器无法回收Activity,从而导致内存泄漏
    Handler的生命周期有可能与Activity的生命周期不一致,比如栗子中的sendEmptyMessageDelayed,在5000毫秒之后才发送消息,但是很有可能这时候Activity被返回了,这样会造成Handler比Activity还要长寿,这样会导致Activity发生暂时性的内存泄漏
  2. 如上代码,在postDelayed中,我们在参数中传入一个非静态内部类Runnable,这同样会造成内存泄漏
    假如此时关闭了Activity,那么垃圾回收器在接下来的1000000ms内都无法回收Activity,造成内存泄漏。

问题一:

为了解决这个问题,我们可以把Handler改为static的, 改成静态内部类后,对外部类的引用设为弱引用,因为在垃圾回收时,会自动将弱引用的对象回收。
但是这样会造成Handler无法访问Activity的非静态变量a。

private static Handler mHandler = new Handler() {
    @Override
    public void handleMessage(Message msg) {
        switch (msg.what) {
        case 0:
            //a = 20;   //不能访问得到
            break;
        }
    }
};

问题二:

通过把Activity作为Handler成员变量,在Handler构造的时候传进来即可。这时候我们不能使用匿名内部类了,要把Handler单独抽取成一个类,这样就可以访问Activity的非静态变量了。但是我们的问题又回来了,这时候Handler持有了Activity的强引用了,这样不就是回到我们的原点了吗?(内存泄漏问题依然没有解决

private static class MyHandler extends Handler {
    private LeakActivity mActivity;//外部类的强引用
    public MyHandler(LeakActivity activity) {
        mActivity = activity;
    }
    @Override
    public void handleMessage(Message msg) {
        super.handleMessage(msg);
        mActivity.a = 20;
    }
}

解决方案1:

Activity通过弱引用来作为成员变量。虽然我们把Activity作为弱引用,但是Activity不一定就是会在GC的时候被回收,因为可能还有其他对象引用了Activity。在处理消息的时候就要注意了,当Activity回收或者正在finish的时候,就不能继续处理消息了。

public class LeakActivity extends AppCompatActivity {
    private int a = 10;
    private final MyHandler mHandler = new MyHandler(this);
    private static final Runnable mRunnable = new Runnable() {
        @Override
        public void run() {
            // 操作
        }
    };

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_fourth);
        mHandler.postDelayed(mRunnable, 1000*10);
        finish();   
    }

    private static class MyHandler extends Handler {
        WeakReference mWeakActivity;
        public MyHandler(HandlerActivity activity) {
            this.mWeakActivity = new WeakReference(activity);
        }

        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            //当使用弱引用的时候,会回收Activity吗?
            //虽然用的是弱引用,但是并不代表不存在其他的对象没有引用Activity,因此不一定会被回收
            LeakActivity activity = mActivityRef.get();//获取Activity
            if (activity == null || activity.isFinishing()) {//当Activity回收或者正在finish的时候,不能继续处理消息
                return;
            }
            mActivityRef.get().a = 20;
        }
    }
}

HandlerThread

思考一下,假如我们需要同时下载A和B,下载A需要6s,下载B需要5s,在它们下载完成后Toast信息出来即可,此时HandlerThread便是一种解决方式之一。那么HandlerThread到底是什么?

  • HandlerThread就是一种线程。
  • HandlerThread和普通的Thread之间的区别就是HandlerThread在创建的时候会提供自己该线程的Looper对象

我们在Actvity创建时系统会自动帮我们初始化好主线程的Looper,然后这个Looper就会管理主线程的消息队列。但是在我们创建子线程时,系统并不会帮我们创建子线程的Looper,需要我们自己手动创建,如下:

    new Thread(){
        @Override
        public void run() {
            super.run();
            Looper.prepare();
            Handler mHandler = new Handler(Looper.myLooper());
            Looper.loop();
        }
    }.start();

所以HandlerThread就在内部帮我们封装了Looper的创建过程,从源码可以看到,HandlerThread集成于Thread,然后覆写run方法,进行Looper的创建,从而通过getLooper方法暴露出该线程的Looper对象

/* HandlerThread 源码 */
public class HandlerThread extends Thread {
    int mPriority;
    int mTid = -1;
    Looper mLooper;
    ...
    public HandlerThread(String name) {
        super(name);
        mPriority = Process.THREAD_PRIORITY_DEFAULT;//默认优先级
    }
    public HandlerThread(String name, int priority) {
        super(name);
        mPriority = priority;
    }
    @Override
    public void run() {
        mTid = Process.myTid(); //获取线程的tid
        Looper.prepare();// 创建Looper对象
        synchronized (this) {
            mLooper = Looper.myLooper();//获取looper对象
            notifyAll();//唤醒等待线程
        }
        Process.setThreadPriority(mPriority);
        onLooperPrepared();// 该方法可通过覆写,实现自己的逻辑
        Looper.loop();//进入循环模式
        mTid = -1;
    }
    public Looper getLooper() {//获取HandlerThread线程中的Looper对象
        if (!isAlive()) {// 当线程没有启动或者已经结束时,则返回null
            return null;
        }
        // If the thread has been started, wait until the looper has been created.
        //当线程已经启动,则等待直到looper创建完成
        synchronized (this) {
            while (isAlive() && mLooper == null) {
                try {
                    wait();//休眠等待
                } catch (InterruptedException e) {
                }
            }
        }
        return mLooper;
    }
    //退出 
    //quit()与quitSafely()的区别,仅仅在于是否移除当前正在处理的消息。移除当前正在处理的消息可能会出现不安全的行为。
    public boolean quit() {
        Looper looper = getLooper();
        if (looper != null) {
            looper.quit(); //普通退出
            return true;
        }
        return false;
    }   
    public boolean quitSafely() {
        Looper looper = getLooper();
        if (looper != null) {
            looper.quitSafely(); //安全退出
            return true;
        }
        return false;
    }
    ...
}    

应用

很多时候,在HandlerThread线程中运行Loop()方法,在其他线程中通过Handler发送消息到HandlerThread线程。通过wait/notifyAll的方式,有效地解决了多线程的同步问题。

示例代码:

// Step 1: 创建并启动HandlerThread线程,内部包含Looper
HandlerThread handlerThread = new HandlerThread("gityuan.com");
handlerThread.start();

// Step 2: 创建Handler
Handler handler = new Handler(handlerThread.getLooper());

// Step 3: 发送消息
handler.post(new Runnable() {
        @Override
        public void run() {
            System.out.println("thread id="+Thread.currentThread().getId());
        }
    });

或者 handler.postDelayed(Runnable r, long delayMillis)用于延迟执行。

实例:使用HandlerThread同时下载A和B

Android Handler 消息机制_第3张图片
image

代码:

public class HandlerThreadActivity extends AppCompatActivity {
    private TextView tv_A, tv_B;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_handler_thread);
        tv_A = (TextView) findViewById(R.id.txt_dlA);
        tv_B = (TextView) findViewById(R.id.txt_dlB);
        
        final Handler mainHandler = new Handler();

        final HandlerThread downloadAThread = new HandlerThread("downloadAThread");
        downloadAThread.start();
        Handler downloadAHandler = new Handler(downloadAThread.getLooper());

        // 通过postDelayed模拟耗时操作
        downloadAHandler.postDelayed(new Runnable() {
            @Override
            public void run() {
                Toast.makeText(getApplicationContext(), "下载A完成", Toast.LENGTH_SHORT).show();
                mainHandler.post(new Runnable() {
                    @Override
                    public void run() {
                        tv_A.setText("A任务已经下载完成");
                    }
                });
            }
        }, 1000 * 5);

        final HandlerThread downloadBThread = new HandlerThread("downloadBThread");
        downloadBThread.start();
        Handler downloadBHandler = new Handler(downloadBThread.getLooper());

        // 通过postDelayed模拟耗时操作
        downloadBHandler.postDelayed(new Runnable() {
            @Override
            public void run() {
                Toast.makeText(getApplicationContext(), "下载B完成", Toast.LENGTH_SHORT).show();
                mainHandler.post(new Runnable() {
                    @Override
                    public void run() {
                        tv_B.setText("B任务已经下载完成");
                    }
                });

            }
        }, 1000 * 7);
    }
}

总结

由于Android的UI更新只能在主线程,所以Handler是Android中一套非常重要的更新UI线程机制,虽然在很多框架的帮助下我们可以减少了很多Handler的代码编写,但实际上很多框架的底层实现都是通过Handler来更新UI的,所以可见掌握好Handler对我们来说是多么重要,所以这也是很多面试官在面试中的高频考点之一。虽然Handler对开发者来说是一个非常方便的存在,但是我们也不能否认它也是存在缺点的,如处理不当,Handler所造成的的内存泄漏对开发者来说也是一个非常头疼的难题。

消息机制

MessageQueue

每个线程最多只有一个MessageQueue
MessageQueue通常都是由Looper来管理,而主线程创建时,会创建一个默认的Looper对象,而Looper对象的创建,将自动创建一个MessageQueue。其他非主线程,不会自动创建Looper。

消息队列,用来保存handler.sendMessage(msg)或者handler.post(r,delayTime)时的产生消息,虽然名字叫做队列,但是在实现中,这只是一个单链表的结构,学过数据结构的朋友都知道,链表用于插入和删除很方便。
要注意的是,MessageQueue 只负责保存消息,并处理消息。

MessageQueue只包含两个主要操作

enqueueMessage

插入一条消息

boolean enqueueMessage(Message msg, long when)

next

取出一条消息并且把这条消息从消息队列中移除

Message next()
/* MessageQueue源码 */
Message next() {
    ...
    for (;;) {
        ...
    }
}

可以看出,next函数是一个无限循环的函数,如果消息队列中没有消息,那么next函数会一直阻塞在这里,直到有消息过来。

Looper

每一个线程只有一个Looper,每个线程在初始化Looper之后,然后Looper会维护好该线程的消息队列,用来存放Handler发送的Message,并处理消息队列出队的Message。
它的特点是它跟它的线程是绑定的,处理消息也是在Looper所在的线程去处理,所以当我们在主线程创建Handler时,它就会跟主线程唯一的Looper绑定,从而我们使用Handler 在子线程发消息时,最终也是在主线程处理,达到了异步的效果。

为什么我们使用Handler的时候从来都不需要创建Looper呢?这是因为在主线程中,ActivityThread默认会把Looper初始化好,prepare以后,当前线程就会变成一个Looper线程。

子线程创建Handler

//如下代码会报异常:java.lang.RuntimeException: Can't create handler inside thread that has not called Looper.prepare()
new Thread(new Runnable() {    
    @Override
    public void run() {        
        Handler handler = new Handler();
        handler.sendEmptyMessageDelayed(0,1000);
    }
}).start();

我们在主线程中使用Handler并没有问题,但如上代码在子线程里面创建了一个handler,使用这个handler去处理事情,就会出现异常java.lang.RuntimeException: Can't create handler inside thread that has not called Looper.prepare()。因为Handler的消息是由Looper进行处理的,但是你并没有创建Looper对象,所以会产生这个异常。
在主线程中使用了Handler没问题,是因为在主线程中,系统默认为我们创建一个Looper对象

上面的代码如何解决呢?我们创建一个Looper并调用loop即可。

//子线程中创建Handler正确方式
new Thread(new Runnable() {    
    @Override
    public void run() {        
        Looper.prepare();//创建Looper
        Handler handler = new Handler();
        handler.sendEmptyMessageDelayed(0,1000);
        Looper.loop();//一定要调用loop()方法,否则我们只是单单创建了一个Looper
    }
}).start();

parpare

创建looper对象并不是使用Looper loop = new Looper(),而是直接调用函数Looper.parpare()即可。我们跟踪这个函数看看:

/* Looper.parpare() */
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));
}
private Looper(boolean quitAllowed) {    
    //在这里创建了一个消息队列
    mQueue = new MessageQueue(quitAllowed);
    mThread = Thread.currentThread();
}

Looper构造函数里面Looper会创建一个MessageQueue对象。

loop

Looper类中的函数loop()不断的调用MessageQueuenext()函数来查看是否有新消息,如果马上去处理这个消息
既然MessageQueue的next()函数有可能堵塞,所以这就导致了loop()函数堵塞

/* Looper.parpare() */
public static void loop() {
    ...
    for (;;) {
        Message msg = queue.next(); // might block
        if (msg == null) {
            // No message indicates that the message queue is quitting.
            return;
        }
        ...
            msg.target.dispatchMessage(msg);//处理消息
        ...
    }
}

看loop函数的源码可知,当MessageQueue的next返回新消息,Looper就会处理这条消息 : msg.target.dispatchMessage(msg);
这里的msg.target就是发送这条消息的Handler,这样子Handler发送的消息最终又要交给它的dispatchMessage函数来处理。

接下来我们就分析一下Handler的内部原理。

Handler

一般,我们通过Handler的post或者send的一系列函数来发送消息,但是其实不管是send还是post,最终都是通过send函数来实现的。
send系列函数有很多个,但是最终都是调用sendMessageAtTime(Message msg, long uptimeMillis)

/* Handler源码 */
//post最终都是调用send
public final boolean post(Runnable r){
   return  sendMessageDelayed(getPostMessage(r), 0);
}
public final boolean postAtTime(Runnable r, long uptimeMillis){
    return sendMessageAtTime(getPostMessage(r), uptimeMillis);
}
public final boolean postAtTime(Runnable r, Object token, long uptimeMillis){
    return sendMessageAtTime(getPostMessage(r, token), uptimeMillis);
}

public final boolean postDelayed(Runnable r, long delayMillis){
    return sendMessageDelayed(getPostMessage(r), delayMillis);
}
public final boolean sendMessage(Message msg){
    return sendMessageDelayed(msg, 0);
}
public final boolean sendEmptyMessage(int what){
    return sendEmptyMessageDelayed(what, 0);
}
public final boolean sendEmptyMessageDelayed(int what, long delayMillis) {
    Message msg = Message.obtain();
    msg.what = what;
    return sendMessageDelayed(msg, delayMillis);
}
public final boolean sendEmptyMessageAtTime(int what, long uptimeMillis) {
    Message msg = Message.obtain();
    msg.what = what;
    return sendMessageAtTime(msg, uptimeMillis);
}
public final boolean sendMessageDelayed(Message msg, long delayMillis){
    if (delayMillis < 0) { delayMillis = 0; }
    return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
}
//最终都是调用这个方法
public boolean sendMessageAtTime(Message msg, long uptimeMillis) {
    ...
}

sendMessageAtTime

/* Handler源码 */
public boolean sendMessageAtTime(Message msg, long uptimeMillis) {
    MessageQueue queue = mQueue;
    if (queue == null) {
        RuntimeException e = new RuntimeException(
                this + " sendMessageAtTime() called with no mQueue");
        Log.w("Looper", e.getMessage(), e);
        return false;
    }
    //关键在这里
    return enqueueMessage(queue, msg, uptimeMillis);
}
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
    msg.target = this;//证实了msg.target就是发送条消息的Handler
    if (mAsynchronous) {
        msg.setAsynchronous(true);
    }
    return queue.enqueueMessage(msg, uptimeMillis);//往消息队列里面插入一条消息
}

如上源码可知,send函数其实就是往消息队列里面插入一条消息

同时Looper的loop函数又会调用MessageQueue的next函数去获取消息最后在交给Handler的dispatchMessage函数处理
这样子我们就把Handler, MessageQueue, Looper三者串起来了。

那么接下来我们赶紧来看看dispatchMessage是什么样子的。

dispatchMessage

/* Handler源码 */
public void dispatchMessage(Message msg) {    
    if (msg.callback != null) {//msg.callback
        handleCallback(msg);//①
    } else {        
        if (mCallback != null) {//mCallback
            if (mCallback.handleMessage(msg)) {//②
                return;
            }
        }
        handleMessage(msg);//③
    }
}

这里有两个callBack,我们一一来分析一下是什么意思。

① msg.callback

msg.callback是你在调用Handler.post....()函数时候创建出来的, msg.callback就是这里的runnbale匿名类:

handler.postDelayed(new Runnable() {//postDelayed具体实现见下面源码
    @Override
    public void run() {      
        //.....
    }
}, 1000);
/* Handler源码 */
public final boolean postDelayed(Runnable r, long delayMillis){
    return sendMessageDelayed(getPostMessage(r), delayMillis);//getPostMessage
}
private static Message getPostMessage(Runnable r) {
    Message m = Message.obtain();
    m.callback = r;//msg.callback就是postDelayed传进来的runnbale匿名类
    return m;
}

① handleCallback(msg)

由下源码可知,handleCallback(msg)就是去执行runnbale中的run函数。没错,这里将开启一个线程
所以我们就明白了最开始我们提到的使用Handler处理耗时操作和UI操作的原理了。

/* Handler源码 */
private static void handleCallback(Message message) {
    message.callback.run();
}

那么,如果你是调用handler.sendMessage()函数的话,callBack为null。

② mCallback

如下,由Handler的构造函数可知,如果mCallback是在创建Handler时传递进来callback

/* Handler源码 */
public Handler(boolean async) { this(null, async); }
public Handler(Callback callback, boolean async) {
    ...
    mLooper = Looper.myLooper();
    if (mLooper == null) {
        throw new RuntimeException(
            "Can't create handler inside thread that has not called Looper.prepare()");
    }
    mQueue = mLooper.mQueue;
    mCallback = callback;//mCallback = 创建Handler时传递进来callback
    mAsynchronous = async;
}

② mCallback.handleMessage(msg)

追溯源码,发现Callback只是一个接口:

/* Handler源码 */
public interface Callback {    
    public boolean handleMessage(Message msg);
}

于是我们应该就会想起我们在创建Handler的时候有时候会写这样子的代码:

private Handler mhandler=new Handler(new Handler.Callback() {
    @Override
    //mCallback.handleMessage(msg)其实调用的就是这个方法
    public boolean handleMessage(Message msg) {
        ...//这个时候Handler的dispatchMessage就会来执行这里的函数逻辑
        return true;
    }
});

③ handleMessage(msg)

当dispatchMessage做完一系列判断,走到了handleMessage(msg)这一步,调用的是Handler自己handleMessage方法。

/* Handler源码 */
public void handleMessage(Message msg) {
    //空实现,让子类实现
}

让我们想起了创建Handler常用写法

Handler handler = new Handler(){    
    @Override
    public void handleMessage(Message msg) {
        ...//这个时候Handler的dispatchMessage就会来执行这里的函数逻辑
    }
};

不管是send还是post,最终都是在Handler创建时所在的线程执行

Message

消息对象,就是MessageQueue里面存放的对象,一个MessageQueu可以包括多个Message。
当我们需要发送一个Message时,我们一般不建议使用new Message()的形式来创建,更推荐使用Message.obtain()来获取Message实例,因为在Message类里面定义了一个消息池,当消息池里存在未使用的消息时,便返回,如果没有未使用的消息,则通过new的方式创建返回,所以使用Message.obtain()的方式来获取实例可以大大减少当有大量Message对象而产生的垃圾回收问题

四者关系总体如下(如有不对的地方,谢谢指出)

Android Handler 消息机制_第4张图片

总结

  • 首先Looper.prepare()创建Looper初始化Looper持有的消息队列MessageQueue,创建好后将Looper保存到ThreadLocal中方便Handler直接获取。

  • 然后Looper.loop()开启循环从MessageQueue里面取消息调用handler的 dispatchMessage(msg) 方法处理消息。如果MessageQueue里没有消息,循环就会阻塞进入休眠状态,等有消息的时候被唤醒处理消息。

  • 再然后我们new Handler()的时候,Handler构造方法中获取Looper并且拿到Looper的MessageQueue对象。然后Handler内部就可以直接往MessageQueue里面插入消息了,插入消息即发送消息,这时候有消息了就会唤醒Looper循环去处理消息。处理消息就是调用dispatchMessage(msg) 方法,最终调用到我们重写的Handler的handleMessage()方法。

最后用一张图,来表示整个消息机制

Android Handler 消息机制_第5张图片
handler_java

图解:

  • Handler通过sendMessage()发送Message到MessageQueue队列;
  • Looper通过loop(),不断提取出达到触发条件的Message,并将Message交给target来处理;
  • 经过dispatchMessage()后,交回给Handler的handleMessage()来进行相应地处理。
  • 将Message加入MessageQueue时,处往管道写入字符,可以会唤醒loop线程;如果MessageQueue中没有Message,并处于Idle状态,则会执行IdelHandler接口中的方法,往往用于做一些清理性地工作。

消息分发的优先级:

  1. Message的回调方法:message.callback.run(),优先级最高;
  2. Handler的回调方法:Handler.mCallback.handleMessage(msg),优先级仅次于1;
  3. Handler的默认方法:Handler.handleMessage(msg),优先级最低。

架构图

Android Handler 消息机制_第6张图片
handler_java
  • Looper有一个MessageQueue消息队列;
  • MessageQueue有一组待处理的Message;
  • Message中有一个用于处理消息的Handler;
  • Handler中有Looper和MessageQueue。

UML图

消息主要设计到下面几个类:

  • Handler:这是消息发出的地方,也是消息处理的地方。
  • Handler拥有Looper的引用,通过得到Looper对象获得Looper中保存的MessageQueue对象
  • Handler拥有MessageQueue的引用,使Handler得以拥有发送消息(将Message放入MessageQueue)的能力
  • Handler拥有Handler.Callback的引用,使得Handler可以方便的进行消息的处理。
  • Looper:这是检测消息的地方。
  • MessageQueue:这是存放消息的地方,Handler把消息发到了这里,Looper从这里取出消息交给Handler进行处理。
  • Message:消息。
  • Thread:我在这里专门指代的是,处理消息的线程。消息的发送是在别的线程。
Android Handler 消息机制_第7张图片

源码分析

主线程默认创建Looper对象

应用程序的入口是在ActivityThreadmain方法中的(当应用程序启动的时候,会通过底层的C/C++去调用main方法),这个方法在ActivityThread类的最后一个函数里面,核心代码如下:

/* ActivityThread源码 */
public static void main(String[] args) {
    ...
    Environment.initForCurrentUser();
    ...
    Looper.prepareMainLooper();//Looper
    ...
    Looper.loop();//Looper
    ...
}
/* Looper源码 */
public static void prepareMainLooper() {    
    prepare(false);//false意思不允许我们程序员退出(面向我们开发者),因为这是在主线程里面
    synchronized (Looper.class) {
        if (sMainLooper != null) {//每个线程只允许执行一次
            throw new IllegalStateException("The main Looper has already been prepared.");
        }        
        sMainLooper = myLooper();//将当前的Looper保存为主Looper
    }
}

在main方法里面,首先初始化了我们的Environment对象,然后创建了Looper,然后开启消息循环。
根据我们的常识知道,如果程序没有死循环的话,执行完main函数(比如构建视图等等代码)以后就会立马退出了。之所以我们的APP能够一直运行着,就是因为Looper.loop()里面是一个死循环

public static void loop() {
    for (;;) {
    }
}

之所以用for (;;)而不是用while(true)是因为防止一些人通过黑科技去修改这个循环的标志(比如通过反射的方式)。
在分析源码的时候,你可能会发现一些if(false){}之类的语句,这种写法是方便调试的,通过一个标志就可以控制某些代码是否执行,比如说是否输出一些系统的Log。
看源码一定不要慌,也不要一行一行看,要抓住核心的思路去看即可。

系统的Handler

在ActivityThread的成员变量里面有一个这样的大H(继承Handler),这个就是系统的Handler

final H mH = new H();

回顾一下ActivityThread的main方法可以知道,在new ActivityThread的时候,系统的Handler就就初始化了,这是一种饿加载的方法,也就是在类被new的时候就初始化成员变量了。

/* ActivityThread源码 */
public static void main(String[] args) {
    ...
    Environment.initForCurrentUser();
    ...
    Looper.prepareMainLooper();
    
    ActivityThread thread = new ActivityThread();
    thread.attach(false);
    if (sMainThreadHandler == null) {
        sMainThreadHandler = thread.getHandler();//初始化系统的Handler
    }
    ...
    Looper.loop();
    ...
}
final Handler getHandler() {
    return mH;
}
final H mH = new H();

H

下面看系统Handler的定义(看的时候可以跳过一些case,粗略地看即可):
从系统的Handler中,在handleMessage我们可以看到很多关于四大组件的生命周期操作,比如创建、销毁、切换、跨进程通信,也包括了整个Application进程的销毁等等。

/* ActivityThread源码 */
private class H extends Handler {
    ...
    public void handleMessage(Message msg) {
        switch (msg.what) {
            case LAUNCH_ACTIVITY: { ... } break;
            case RELAUNCH_ACTIVITY: { ... } break;
            case PAUSE_ACTIVITY: { ... } break;
            case PAUSE_ACTIVITY_FINISHING: { ... } break;
            case STOP_ACTIVITY_SHOW: { ... } break;
            case STOP_ACTIVITY_HIDE: { ... } break;
            case SHOW_WINDOW: { ... } break;
            case HIDE_WINDOW: { ... } break;
            case RESUME_ACTIVITY: { ... } break;
            case SEND_RESULT: { ... } break;
            case DESTROY_ACTIVITY: { ... } break;
            case BIND_APPLICATION: { ... } break;
            case EXIT_APPLICATION://应用程序的退出过程
                if (mInitialApplication != null) {
                    mInitialApplication.onTerminate();
                }
                Looper.myLooper().quit();
                break;
            case NEW_INTENT: { ... } break;
            case RECEIVER: { ... } break;
            case CREATE_SERVICE: { ... } break;
            case BIND_SERVICE: { ... } break;
            case UNBIND_SERVICE: { ... } break;
            case SERVICE_ARGS: { ... } break;
            case STOP_SERVICE: { ... } break;
            case CONFIGURATION_CHANGED: { ... } break;
            case CLEAN_UP_CONTEXT: { ... } break;
            case GC_WHEN_IDLE: { ... } break;
            case DUMP_SERVICE: { ... } break;
            case LOW_MEMORY: { ... } break;
            case ACTIVITY_CONFIGURATION_CHANGED: { ... } break;
            case PROFILER_CONTROL: { ... } break;
            case CREATE_BACKUP_AGENT: { ... } break;
            case DESTROY_BACKUP_AGENT: { ... } break;
            case SUICIDE://我们可以通过发SUICIDE消息自杀,这样来退出应用程序
                Process.killProcess(Process.myPid());
                break;
            case REMOVE_PROVIDER: { ... } break;
            case ENABLE_JIT: { ... } break;
            case DISPATCH_PACKAGE_BROADCAST: { ... } break;
            case SCHEDULE_CRASH: { ... } break;
            case DUMP_HEAP: { ... } break;
            case DUMP_ACTIVITY: { ... } break;
            case DUMP_PROVIDER: { ... } break;
            case SLEEPING: { ... } break;
            case SET_CORE_SETTINGS: { ... } break;
            case UPDATE_PACKAGE_COMPATIBILITY_INFO: { ... } break;
            case TRIM_MEMORY: { ... } break;
            case UNSTABLE_PROVIDER_DIED: { ... } break;
            case REQUEST_ASSIST_CONTEXT_EXTRAS: { ... } break;
            case TRANSLUCENT_CONVERSION_COMPLETE: { ... } break;
            case INSTALL_PROVIDER: { ... } break;
            case ON_NEW_ACTIVITY_OPTIONS: { ... } break;
            case CANCEL_VISIBLE_BEHIND: { ... } break;
            case BACKGROUND_VISIBLE_BEHIND_CHANGED: { ... } break;
            case ENTER_ANIMATION_COMPLETE: { ... } break;
            case START_BINDER_TRACKING: { ... } break;
            case STOP_BINDER_TRACKING_AND_DUMP: { ... } break;
            case MULTI_WINDOW_MODE_CHANGED: { ... } break;
            case PICTURE_IN_PICTURE_MODE_CHANGED: { ... } break;
            case LOCAL_VOICE_INTERACTION_STARTED: { ... } break;
        }
        Object obj = msg.obj;
        if (obj instanceof SomeArgs) {
            ((SomeArgs) obj).recycle();
        }
        if (DEBUG_MESSAGES) Slog.v(TAG, "<<< done: " + codeToString(msg.what));
    }
    ...
}

应用程序的退出过程

实际上我们要退出应用程序的话,就是让主线程结束,换句话说就是要让Looper的循环结束
这里是直接结束Looper循环,因此我们四大组件的生命周期方法可能就不会执行了,因为四大组件的生命周期方法就是通过Handler去处理的,Looper循环都没有了,四大组件还玩毛线!因此我们平常写程序的时候就要注意了,onDestroy方法是不一定能够回调的。

/* ActivityThread源码 */
//H的handleMessage中部分代码
case EXIT_APPLICATION:
    if (mInitialApplication != null) {
        mInitialApplication.onTerminate();
    }
    //退出Looper的循环
    Looper.myLooper().quit();
    break;

这里实际上是调用了MessageQueue的quit,清空所有Message。

/* Looper源码 */
public void quit() {
    mQueue.quit(false);
}

1、Looper

ThreadLocal

ThreadLocal线程本地存储区(Thread Local Storage,简称为TLS),每个线程都有自己的私有的本地存储区域,不同线程之间彼此不能访问对方的TLS区域。
它是一个用来存储数据的类,类似HashMap、ArrayList等集合类。它的特点是可以在指定的线程中存储数据,然后取数据只能取到当前线程的数据

ThreadLocal是JDK提供的一个解决线程不安全的类,线程不安全问题归根结底主要涉及到变量的多线程访问问题,例如变量的临界问题、值错误、并发问题等。

ThreadLocal 内部维护了一个针对每一个线程的数组Entry[],它的初始容量是16,我们在设置value的时候将当前的value值封装Entry类里面,在然后再根据当前的ThreadLocal的索引去查中对应的Entry值,最终根据Entry对象取出value值,很明显每个线程的数组是不相同,所以就可以取出不同的Entry。

ThreadLocal保证每个线程都保持对其线程局部变量副本的隐式引用,只要线程是活动的并且 ThreadLocal 实例是可访问的;在线程消失之后,其线程局部实例的所有副本都会被垃圾回收(除非存在对这些副本的其他引用)。更多ThreadLocal的讲解参考:Android线程管理之ThreadLocal理解及应用场景

TLS常用的操作方法:

set()

ThreadLocal.set(T value)将value存储到当前线程的TLS区域,源码如下:
map.set(this, value):通过把键-ThreadLocal自身&值-Looper 放到了一个Map里面,如果再放一个的话,就会覆盖(因为map不允许键值对中的键是重复的),因此ThreadLocal绑定了线程以及Looper

/* ThreadLocal源码 */
public void set(T value) {
        Thread t = Thread.currentThread();//获取当前线程
        ThreadLocalMap map = getMap(t);
        if (map != null)
            map.set(this, value);//把键-ThreadLocal自身&值-Looper 放到了一个Map里面
        else
            createMap(t, value);
}
ThreadLocalMap getMap(Thread t) {
        return t.threadLocals;//由Thread源码知,t.threadLocals类型为ThreadLocal.ThreadLocalMap
}
void createMap(Thread t, T firstValue) {
        t.threadLocals = new ThreadLocalMap(this, firstValue);
}

static class ThreadLocalMap {
        ...
        private static final int INITIAL_CAPACITY = 16;
        ...
        /* ThreadLocalMap的构造方法 */
        ThreadLocalMap(ThreadLocal firstKey, Object firstValue) {
            table = new Entry[INITIAL_CAPACITY];//构造一个数组
            int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);//通过按位运算得到一个变量i值
            //构造一个Entry对象将ThreadLocal和Value放进去,将设置进去的值包装成一个对象存进数组里边
            table[i] = new Entry(firstKey, firstValue);
            size = 1;
            setThreshold(INITIAL_CAPACITY);
        }
        //Entry这个实体继承WeakReference(就是我们常说的弱引用)
        static class Entry extends WeakReference {
            /** The value associated with this ThreadLocal. */
            Object value;
            Entry(ThreadLocal k, Object v) {//v就是我们设置进去的value
                super(k);
                value = v;
            }
        }
}
/* Thread源码 */
ThreadLocal.ThreadLocalMap threadLocals = null;

get()

ThreadLocal.get()获取当前线程TLS区域的数据,源码如下:

public T get() {
        Thread t = Thread.currentThread();//获取当前线程
        ThreadLocalMap map = getMap(t);
        if (map != null) {
            ThreadLocalMap.Entry e = map.getEntry(this);
            if (e != null)
                return (T)e.value;//返回当前线程储存区中的数据
        }
        return setInitialValue();//目标线程存储区没有查询到则返回null
}
private T setInitialValue() {
        T value = initialValue();
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null)
            map.set(this, value);
        else
            createMap(t, value);
        return value;
}
protected T initialValue() {
        return null;
}

ThreadLocal的get()和set()方法操作的类型都是泛型。

1.1 prepare()

对于无参的情况,默认调用prepare(true),表示的是这个Looper运行退出,而对于false的情况则表示当前Looper不运行退出。

/* Looper源码 */
private static void prepare(boolean quitAllowed) {
    //每个线程只允许执行一次该方法,第二次执行时线程的TLS已有数据,则会抛出异常。
    if (sThreadLocal.get() != null) {
        throw new RuntimeException("Only one Looper may be created per thread");
    }
    //创建Looper对象,并保存到当前线程的TLS区域
    sThreadLocal.set(new Looper(quitAllowed));
}
//Looper的成员变量sThreadLocal
static final ThreadLocal sThreadLocal = new ThreadLocal();

这里的sThreadLocal变量是ThreadLocal类型,其定义如下:

static final ThreadLocal sThreadLocal = new ThreadLocal();

可见sThreadLocal的get()和set()操作的类型都是Looper类型。
这里利用ThreadLocal绑定了Looper以及线程,就可以避免其他线程去访问当前线程的Looper了。

Looper.prepare()
Looper.prepare()在每个线程只允许执行一次,该方法会创建Looper对象,Looper的构造方法中会创建一个MessageQueue对象,再将Looper对象保存到当前线程TLS。

对于Looper类型的构造方法如下:

private Looper(boolean quitAllowed) {
    mQueue = new MessageQueue(quitAllowed);  //创建MessageQueue对象. //【见3.1 创建MessageQueue】
    mThread = Thread.currentThread();  //记录当前线程.
}

另外,与prepare()相近功能的,还有一个prepareMainLooper()方法,该方法主要在ActivityThread类中使用。

public static void prepareMainLooper() {
    prepare(false); //设置不允许退出的Looper
    synchronized (Looper.class) {
        if (sMainLooper != null) {//每个线程只允许执行一次
            throw new IllegalStateException("The main Looper has already been prepared.");
        }
        sMainLooper = myLooper();//将当前的Looper保存为主Looper
    }
}
public static @Nullable Looper myLooper() {
    return sThreadLocal.get();
}
static final ThreadLocal sThreadLocal = new ThreadLocal();

1.2 loop()

loop()进入循环模式,不断重复下面的操作,直到没有消息时退出循环

  • 读取MessageQueue的下一条Message;
  • 把Message分发给相应的target;
  • 再把分发后的Message回收到消息池,以便重复利用。

这是这个消息处理的核心部分。

另外,源码中可以看到有logging方法,这是用于debug的,默认情况下logging == null,通过设置setMessageLogging()用来开启debug工作。

/* Looper源码 */
public static void loop() {
    final Looper me = myLooper();  //获取TLS存储的Looper对象 //【见1.4.1 myLooper】
    if (me == null) {
        throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
    }
    final MessageQueue queue = me.mQueue;  //获取Looper对象中的消息队列

    Binder.clearCallingIdentity();
    //确保在权限检查时基于本地进程,而不是基于最初调用进程。
    final long ident = Binder.clearCallingIdentity();

    for (;;) { //进入loop的主循环方法
        Message msg = queue.next(); //可能会阻塞 //【见3.2 next()】
        if (msg == null) { //没有消息,则退出循环
            return;
        }

        Printer logging = me.mLogging;  //默认为null,可通过setMessageLogging()方法来指定输出,用于debug功能
        if (logging != null) {
            logging.println(">>>>> Dispatching to " + msg.target + " " +
                    msg.callback + ": " + msg.what);
        }
        final long traceTag = me.mTraceTag;
        if (traceTag != 0) {
            Trace.traceBegin(traceTag, msg.target.getTraceName(msg));
        }
        try {
            msg.target.dispatchMessage(msg);//用于分发Message //【见2.2 消息分发】
        } finally {
            if (traceTag != 0) {
                Trace.traceEnd(traceTag);
            }
        }
        if (logging != null) {
            logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
        }

        final long newIdent = Binder.clearCallingIdentity(); //确保分发过程中identity不会损坏
        if (ident != newIdent) {
             //打印identity改变的log,在分发消息过程中是不希望身份被改变的。
        }
        msg.recycleUnchecked();  //回收消息,将Message放入消息池 //【见4.2.2 recycle】
    }
}

1.3 quit()

/* Looper源码 */
public void quit() {
    mQueue.quit(false); //消息移除
}

public void quitSafely() {
    mQueue.quit(true); //安全地消息移除
}

Looper.quit()方法的实现最终调用的是MessageQueue.quit()方法

MessageQueue.quit()
消息退出的方式:

  • 当safe =true时,只移除尚未触发的所有消息,对于正在触发的消息并不移除;
  • 当safe =flase时,移除所有的消息
/* MessageQueue源码 */
void quit(boolean safe) {        
        if (!mQuitAllowed) {// 当mQuitAllowed为false,表示不运行退出,强行调用quit()会抛出异常
            throw new IllegalStateException("Main thread not allowed to quit.");
        }
        synchronized (this) {
            if (mQuitting) { //防止多次执行退出操作
                return;
            }
            mQuitting = true;
            if (safe) {
                removeAllFutureMessagesLocked(); //移除尚未触发的所有消息
            } else {
                removeAllMessagesLocked(); //移除所有的消息
            }
            //如mQuitting=false,那么认定为 mPtr != 0
            nativeWake(mPtr);
        }
    }

1.4 常用方法

1.4.1 myLooper

用于获取TLS存储的Looper对象

public static @Nullable Looper myLooper() {
        return sThreadLocal.get();
    }

2、Handler

2.1 创建Handler

2.1.1 无参构造

public Handler() {
    this(null, false);
}

public Handler(Callback callback, boolean async) {
    //匿名类、内部类或本地类都必须申明为static,否则会警告可能出现内存泄露
    if (FIND_POTENTIAL_LEAKS) {
        final Class klass = getClass();
        if ((klass.isAnonymousClass() || klass.isMemberClass() || klass.isLocalClass()) &&
                (klass.getModifiers() & Modifier.STATIC) == 0) {
            Log.w(TAG, "The following Handler class should be static or leaks might occur: " +
                klass.getCanonicalName());
        }
    }
    //必须先执行Looper.prepare(),才能获取Looper对象,否则为null.
    mLooper = Looper.myLooper();  //从当前线程的TLS中获取Looper对象//【见1.1 prepare()&1.4.1 myLooper】
    if (mLooper == null) {
        throw new RuntimeException(
                "Can't create handler inside thread that has not called Looper.prepare()");
    }
    mQueue = mLooper.mQueue; //消息队列,来自Looper对象
    mCallback = callback;  //回调方法
    mAsynchronous = async; //设置消息是否为异步处理方式
}

对于Handler的无参构造方法,默认采用当前线程TLS中的Looper对象,并且callback回调方法为null,且消息为同步处理方式。只要执行的Looper.prepare()方法,那么便可以获取有效的Looper对象。

2.1.2 有参构造

public Handler(Looper looper) {
    this(looper, null, false);
}

public Handler(Looper looper, Callback callback, boolean async) {
    mLooper = looper;
    mQueue = looper.mQueue;
    mCallback = callback;
    mAsynchronous = async;
}

Handler类在构造方法中,可指定Looper,Callback回调方法以及消息的处理方式(同步或异步),对于无参的handler,默认是当前线程的Looper。

2.2 消息分发

在Looper.loop()中,当发现有消息时,调用消息的目标handler,执行dispatchMessage()方法来分发消息。

分发消息流程:

  1. Message的回调方法不为空时,则回调方法msg.callback.run(),其中callBack数据类型为Runnable,否则进入步骤2;
  2. HandlermCallback成员变量不为空时,则回调方法mCallback.handleMessage(msg),否则进入步骤3;
  3. 调用Handler自身的回调方法handleMessage(),该方法默认为空,Handler子类通过覆写该方法来完成具体的逻辑。

对于很多情况下,消息分发后的处理方法是第3种情况,即Handler.handleMessage(),一般地往往通过覆写该方法从而实现自己的业务逻辑。

2.2.1 dispatchMessage

/* Handler源码 */
public void dispatchMessage(Message msg) {
    if (msg.callback != null) {//这是调用handler.post(Runnable)方法发送的消息【见2.3.6 post】
        //当Message存在回调方法,回调msg.callback.run()方法;
        handleCallback(msg);
    } else {
        if (mCallback != null) {
            //当Handler存在Callback成员变量时,回调方法handleMessage();
            if (mCallback.handleMessage(msg)) {
                return;
            }
        }
        //Handler自身的回调方法handleMessage()
        handleMessage(msg);
    }
}


private static void handleCallback(Message message) {
    message.callback.run();
}
/**
 * Callback interface you can use when instantiating a Handler to avoid
 * having to implement your own subclass of Handler.
 *
 * @param msg A {@link android.os.Message Message} object
 * @return True if no further handling is desired
 */
public interface Callback {
    public boolean handleMessage(Message msg);
}

/**
 * Subclasses must implement this to receive messages.
 */
public void handleMessage(Message msg) {
}

2.3 消息发送

发送消息调用链:


Android Handler 消息机制_第8张图片
java_sendmessage

从上图,可以发现所有的发消息方式,最终都是调用MessageQueue.enqueueMessage();
Handler.sendEmptyMessage()等系列方法最终调用MessageQueue.enqueueMessage(msg, uptimeMillis),将消息添加到消息队列中,其中uptimeMillis为系统当前的运行时间,不包括休眠时间。

2.3.1 sendEmptyMessage

public final boolean sendEmptyMessage(int what) {
    return sendEmptyMessageDelayed(what, 0);
}

2.3.2 sendEmptyMessageDelayed

public final boolean sendEmptyMessageDelayed(int what, long delayMillis) {
    Message msg = Message.obtain();
    msg.what = what;
    return sendMessageDelayed(msg, delayMillis);
}

2.3.3 sendMessageDelayed

public final boolean sendMessageDelayed(Message msg, long delayMillis) {
    if (delayMillis < 0) {
        delayMillis = 0;
    }
    return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
}

2.3.4 sendMessageAtTime

public boolean sendMessageAtTime(Message msg, long uptimeMillis) {
    MessageQueue queue = mQueue;
    if (queue == null) {
        RuntimeException e = new RuntimeException(
                this + " sendMessageAtTime() called with no mQueue");
        Log.w("Looper", e.getMessage(), e);
        return false;
    }
    return enqueueMessage(queue, msg, uptimeMillis);
}

2.3.5 sendMessageAtFrontOfQueue

该方法通过设置消息的触发时间为0,从而使Message加入到消息队列的队头。

public final boolean sendMessageAtFrontOfQueue(Message msg) {
    MessageQueue queue = mQueue;
    if (queue == null) {
        RuntimeException e = new RuntimeException(
            this + " sendMessageAtTime() called with no mQueue");
        Log.w("Looper", e.getMessage(), e);
        return false;
    }
    return enqueueMessage(queue, msg, 0);
}

2.3.6 post

public final boolean post(Runnable r) {
   return  sendMessageDelayed(getPostMessage(r), 0);}
public final boolean postDelayed(Runnable r, long delayMillis){
    return sendMessageDelayed(getPostMessage(r), delayMillis);}
public final boolean postAtTime(Runnable r, long uptimeMillis){
    return sendMessageAtTime(getPostMessage(r), uptimeMillis);}
public final boolean postAtTime(Runnable r, Object token, long uptimeMillis){
    return sendMessageAtTime(getPostMessage(r, token), uptimeMillis);}
    
private static Message getPostMessage(Runnable r) {
    Message m = Message.obtain();//【见4.2.1 obtain】
    m.callback = r;
    return m;
}

2.3.7 postAtFrontOfQueue

public final boolean postAtFrontOfQueue(Runnable r) {
    return sendMessageAtFrontOfQueue(getPostMessage(r));
}

2.3.8 enqueueMessage

private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
    msg.target = this;//target就是Message绑定的Handler(当前Handler)
    if (mAsynchronous) {
        msg.setAsynchronous(true);
    }
    return queue.enqueueMessage(msg, uptimeMillis); //【见3.3 enqueueMessage】
}

2.4 其他方法

Handler是消息机制中非常重要的辅助类,更多的实现都是MessageQueue, Message中的方法,Handler的目的是为了更加方便的使用消息机制。

2.4.1 obtainMessage

获取消息

public final Message obtainMessage() {
    return Message.obtain(this); //【见4.2.1 obtain】
}

Handler.obtainMessage()方法,最终调用Message.obtainMessage(this),其中this为当前的Handler对象。

2.4.2 removeMessages

public final void removeMessages(int what) {
    mQueue.removeMessages(this, what, null); //【见3.4 removeMessages】
}

3、MessageQueue

MessageQueue是消息机制的Java层和C++层的连接纽带,大部分核心方法都交给native层来处理,其中MessageQueue类中涉及的native方法如下:

private native static long nativeInit();
private native static void nativeDestroy(long ptr);
private native void nativePollOnce(long ptr, int timeoutMillis);
private native static void nativeWake(long ptr);
private native static boolean nativeIsPolling(long ptr);
private native static void nativeSetFileDescriptorEvents(long ptr, int fd, int events);

关于这些native方法的介绍,见Android消息机制2-Handler(native篇)。

3.1 创建MessageQueue

MessageQueue(boolean quitAllowed) {
    mQuitAllowed = quitAllowed;
    //通过native方法初始化消息队列,其中mPtr是供native代码使用
    mPtr = nativeInit();
}

3.2 next()

提取下一条message。
消息的取出并不是直接就从队列的头部取出的,而是根据消息的when时间参数有关的,因为我们可以发送延时消息、也可以发送一个指定时间点的消息。

nativePollOnce是阻塞操作,其中nextPollTimeoutMillis代表下一个消息到来前,还需要等待的时长;当nextPollTimeoutMillis = -1时,表示消息队列中无消息,会一直等待下去。

当处于空闲时,往往会执行IdleHandler中的方法。当nativePollOnce()返回后,next()从mMessages中提取一个消息。

nativePollOnce()在native做了大量的工作,想进一步了解可查看 Android消息机制2-Handler(native篇)。

从源码可以看到消息的取出用到了一些native方法,这样做是为了获得更高的效率,

/* MessageQueue源码 */
Message next() {
    final long ptr = mPtr;
    if (ptr == 0) { //当消息循环已经退出,则直接返回
        return null;
    }
    int pendingIdleHandlerCount = -1; // 循环迭代的首次为-1
    int nextPollTimeoutMillis = 0;
    for (; ; ) {
        if (nextPollTimeoutMillis != 0) {
            Binder.flushPendingCommands();
        }
        //阻塞操作,当等待nextPollTimeoutMillis时长,或者消息队列被唤醒,都会返回
        nativePollOnce(ptr, nextPollTimeoutMillis);//nativePollOnce
        synchronized (this) {
            final long now = SystemClock.uptimeMillis();//拿到当前的时间戳
            Message prevMsg = null;
            Message msg = mMessages;
            if (msg != null && msg.target == null) {
                //当消息Handler为空时,查询MessageQueue中的下一条异步消息msg,则退出循环。
                do {
                    prevMsg = msg;
                    msg = msg.next;
                } while (msg != null && !msg.isAsynchronous());
            }
            if (msg != null) {
                if (now < msg.when) {
                //当异步消息触发时间大于当前时间(还没有到执行的时间),则设置下一次轮询的超时时长
                    nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
                } else {
                    // 到了执行时间,获取一条消息,并返回
                    mBlocked = false;
                    if (prevMsg != null) {
                        prevMsg.next = msg.next;
                    } else {
                        mMessages = msg.next;
                    }
                    msg.next = null;
                    //设置消息的使用状态,即flags |= FLAG_IN_USE
                    msg.markInUse();
                    return msg;   //成功地获取MessageQueue中的下一条即将要执行的消息
                }
            } else {
                //没有消息
                nextPollTimeoutMillis = -1;
            }
            //消息正在退出,返回null
            if (mQuitting) {
                dispose();
                return null;
            }
            //当消息队列为空,或者是消息队列的第一个消息时
            if (pendingIdleHandlerCount < 0 && (mMessages == null || now < mMessages.when)) {
                pendingIdleHandlerCount = mIdleHandlers.size();
            }
            if (pendingIdleHandlerCount <= 0) {
                //没有idle handlers 需要运行,则循环并等待。
                mBlocked = true;
                continue;
            }
            if (mPendingIdleHandlers == null) {
                mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
            }
            mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
        }
        //只有第一次循环时,会运行idle handlers,执行完成后,重置pendingIdleHandlerCount为0.
        for (int i = 0; i < pendingIdleHandlerCount; i++) {
            final IdleHandler idler = mPendingIdleHandlers[i];
            mPendingIdleHandlers[i] = null; //去掉handler的引用
            boolean keep = false;
            try {
                keep = idler.queueIdle();  //idle时执行的方法
            } catch (Throwable t) {
                Log.wtf(TAG, "IdleHandler threw exception", t);
            }
            if (!keep) {
                synchronized (this) {
                    mIdleHandlers.remove(idler);
                }
            }
        }
        //重置idle handler个数为0,以保证不会再次重复运行
        pendingIdleHandlerCount = 0;
        //当调用一个空闲handler时,一个新message能够被分发,因此无需等待可以直接查询pending message.
        nextPollTimeoutMillis = 0;
    }
}

3.3 enqueueMessage

添加一条消息到消息队列
MessageQueue是按照Message触发时间的先后顺序排列的,队头的消息是将要最早触发的消息。当有消息需要加入消息队列时,会从队列头开始遍历,直到找到消息应该插入的合适位置,以保证所有消息的时间顺序。

boolean enqueueMessage(Message msg, long when) {
    // 每一个普通Message必须有一个target(即Handler)
    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) {  //正在退出时,回收msg,加入到消息池
            msg.recycle();
            return false;
        }
        msg.markInUse();
        msg.when = when;
        Message p = mMessages;
        boolean needWake;
        if (p == null || when == 0 || when < p.when) {
            //p为null(代表MessageQueue没有消息) 或者msg的触发时间是队列中最早的, 则进入该该分支
            msg.next = p;
            mMessages = msg;
            needWake = mBlocked; //当阻塞时需要唤醒
        } else {
            //将消息按时间顺序插入到MessageQueue。一般地,不需要唤醒事件队列,
            //除非消息队头存在barrier,并且同时Message是队列中最早的异步消息。
            needWake = mBlocked && p.target == null && msg.isAsynchronous();
            //下面的代码就是遍历单链表
            Message prev;
            for (;;) {
                prev = p;
                p = p.next;
                if (p == null || when < p.when) {
                    break;//p为链表的尾部,或者时间刚好比传进来的msg晚一点
                }
                if (needWake && p.isAsynchronous()) {
                    needWake = false;
                }
            }
            msg.next = p;
            prev.next = msg;//把传进来的消息插入链表(prev和p中间)
        }
        //消息没有退出,我们认为此时mPtr != 0
        if (needWake) {
            nativeWake(mPtr);
        }
    }
    return true;
}

3.4 removeMessages

这个移除消息的方法,采用了两个while循环,第一个循环是从队头开始,移除符合条件的消息,第二个循环是从头部移除完连续的满足条件的消息之后,再从队列后面继续查询是否有满足条件的消息需要被移除。

void removeMessages(Handler h, int what, Object object) {
    if (h == null) {
        return;
    }
    synchronized (this) {
        Message p = mMessages;
        //从消息队列的头部开始,移除所有符合条件的消息
        while (p != null && p.target == h && p.what == what
               && (object == null || p.obj == object)) {
            Message n = p.next;
            mMessages = n;
            p.recycleUnchecked();
            p = n;
        }
        //移除剩余的符合要求的消息
        while (p != null) {
            Message n = p.next;
            if (n != null) {
                if (n.target == h && n.what == what
                    && (object == null || n.obj == object)) {
                    Message nn = n.next;
                    n.recycleUnchecked();
                    p.next = nn;
                    continue;
                }
            }
            p = n;
        }
    }
}

3.5 postSyncBarrier

前面小节[3.3]已说明每一个普通Message必须有一个target,对于特殊的message是没有target,即同步barrier token。 这个消息的价值就是用于拦截同步消息,所以并不会唤醒Looper。
postSyncBarrier只对同步消息产生影响,对于异步消息没有任何差别。

private int postSyncBarrier(long when) {
    // Enqueue a new sync barrier token.
    // We don't need to wake the queue because the purpose of a barrier is to stall it.
    synchronized (this) {
        final int token = mNextBarrierToken++;
        final Message msg = Message.obtain();
        msg.markInUse();
        msg.when = when;
        msg.arg1 = token;

        Message prev = null;
        Message p = mMessages;
        if (when != 0) {
            while (p != null && p.when <= when) {
                prev = p;
                p = p.next;
            }
        }
        if (prev != null) { // invariant: p == prev.next
            msg.next = p;
            prev.next = msg;
        } else {
            msg.next = p;
            mMessages = msg;
        }
        return token;
    }
}
public void removeSyncBarrier(int token) {
     synchronized (this) {
         Message prev = null;
         Message p = mMessages;
         //从消息队列找到 target为空,并且token相等的Message
         while (p != null && (p.target != null || p.arg1 != token)) {
             prev = p;
             p = p.next;
         }
         if (p == null) {
             throw new IllegalStateException("The specified message queue synchronization "
                     + " barrier token has not been posted or has already been removed.");
         }
         final boolean needWake;
         if (prev != null) {
             prev.next = p.next;
             needWake = false;
         } else {
             mMessages = p.next;
             needWake = mMessages == null || mMessages.target != null;
         }
         p.recycleUnchecked();

         if (needWake && !mQuitting) {
             nativeWake(mPtr);
         }
     }
 }

4、 Message

4.1 创建消息

每个消息用Message表示,Message主要包含以下内容:

数据类型 成员变量 解释
int what 消息类别
long when 消息触发时间
int arg1 参数1
int arg2 参数2
Object obj 消息内容
Handler target 消息响应方
Runnable callback 回调方法

创建消息的过程,就是填充消息的上述内容的一项或多项。

4.2 消息池

在代码中,可能经常看到recycle()方法,咋一看,可能是在做虚拟机的gc()相关的工作,其实不然,这是用于把消息加入到消息池的作用。这样的好处是,当消息池不为空时,可以直接从消息池中获取Message对象,而不是直接创建,提高效率。

静态变量sPool的数据类型为Message,通过next成员变量,维护一个消息池;静态变量MAX_POOL_SIZE代表消息池的可用大小;消息池的默认大小为50。

消息池常用的操作方法是obtain()和recycle()。

4.2.1 obtain

从消息池中获取消息
obtain(),从消息池取Message,就是把消息池表头的Message取走,再把表头指向next;

public static Message obtain() {
    synchronized (sPoolSync) {
        if (sPool != null) {
            Message m = sPool;
            sPool = m.next;
            m.next = null; //从sPool中取出一个Message对象,并消息链表断开
            m.flags = 0; // 清除in-use flag
            sPoolSize--; //消息池的可用大小进行减1操作
            return m;
        }
    }
    return new Message(); // 当消息池为空时,直接创建Message对象
}

4.2.2 recycle

把不再使用的消息加入消息池
recycle(),将Message加入到消息池的过程,就是把Message加到链表的表头。
关于消息的回收还有一点需要注意的就是,我们平时写Handler的时候不需要我们手动回收,因为谷歌的工程师已经有考虑到这方面的问题了。消息在Handler分发处理之后就会被自动回收的——见Looper的loop【见1.2 loop()】

public void recycle() {
    if (isInUse()) { //判断消息是否正在使用
        if (gCheckRecycle) { //Android 5.0以后的版本默认为true,之前的版本默认为false.
            throw new IllegalStateException("This message cannot be recycled because it is still in use.");
        }
        return;
    }
    recycleUnchecked();
}
boolean isInUse() {
    return ((flags & FLAG_IN_USE) == FLAG_IN_USE);
}
//对于不再使用的消息,加入到消息池
void recycleUnchecked() {
    //将消息标示位置为IN_USE,并清空消息所有的参数。
    flags = FLAG_IN_USE;
    what = 0;
    arg1 = 0;
    arg2 = 0;
    obj = null;
    replyTo = null;
    sendingUid = -1;
    when = 0;
    target = null;
    callback = null;
    data = null;
    synchronized (sPoolSync) {
        if (sPoolSize < MAX_POOL_SIZE) { //当消息池没有满时,将Message对象加入消息池
            next = sPool;
            sPool = this;
            sPoolSize++; //消息池的可用大小进行加1操作
        }
    }
}

常见问题

Looper 死循环为什么不会导致应用卡死?

线程默认没有Looper的,如果需要使用Handler就必须为线程创建Looper。我们经常提到的主线程,也叫UI线程,它就是ActivityThread,ActivityThread被创建时就会初始化Looper,这也是在主线程中默认可以使用Handler的原因。

首先我们看一段代码

new Thread(new Runnable() {
    @Override
    public void run() {
        Log.e("qdx", "step 0 ");
        Looper.prepare();

        Toast.makeText(MainActivity.this, "run on Thread", Toast.LENGTH_SHORT).show();

        Log.e("qdx", "step 1 ");
        Looper.loop();

        Log.e("qdx", "step 2 ");

    }
}).start();

我们知道Looper.loop();里面维护了一个死循环方法,所以按照理论,上述代码执行的应该是
step 0 –>step 1
也就是说循环在Looper.prepare();Looper.loop();之间。

在子线程中,如果手动为其创建了Looper,那么在所有的事情完成以后应该调用quit方法来终止消息循环,否则这个子线程就会一直处于等待(阻塞)状态,而如果退出Looper以后,这个线程就会立刻(执行所有方法并)终止,因此建议不需要的时候终止Looper。

执行结果也正如我们所说,这时候如果了解了ActivityThread,并且在main方法中我们会看到主线程也是通过Looper方式来维持一个消息循环。

/* ActivityThread源码 */
public static void main(String[] args) {
        ``````
        Looper.prepareMainLooper();//创建Looper和MessageQueue对象,用于处理主线程的消息
        ActivityThread thread = new ActivityThread();
        thread.attach(false);//建立Binder通道 (创建新线程)
        if (sMainThreadHandler == null) {
            sMainThreadHandler = thread.getHandler();
        }
        Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
        Looper.loop();

        //如果能执行下面方法,说明应用崩溃或者是退出了...
        throw new RuntimeException("Main thread loop unexpectedly exited");
    }

那么回到我们的问题上,这个死循环会不会导致应用卡死,即使不会的话,它会慢慢的消耗越来越多的资源吗?

摘自:Gityuan–Handler(Native层)

对于线程即是一段可执行的代码,当可执行代码执行完成后,线程生命周期便该终止了,线程退出。

  • 而对于主线程,我们是绝不希望会被运行一段时间,自己就退出,那么如何保证一直存活呢?
    简单做法就是可执行代码是能一直执行下去的,死循环便能保证不会被退出(例如,binder线程也是采用死循环的方法,通过循环方式不同与Binder驱动进行读写操作,当然并非简单地死循环,无消息时会休眠。)

  • 但这里可能又引发了另一个问题,既然是死循环如何去处理其他事务呢?
    通过创建新线程的方式。
    真正会卡死主线程的操作是在回调方法onCreate/onStart/onResume等操作时间过长,会导致掉帧,甚至发生ANR,looper.loop本身不会导致应用卡死。

  • 主线程的死循环一直运行是不是特别消耗CPU资源呢?
    其实不然,这里就涉及到Linux pipe/epoll机制,简单说就是在主线程的MessageQueue没有消息时,便阻塞在loop的queue.next()中的nativePollOnce()方法里,此时主线程会释放CPU资源进入休眠状态,直到下个消息到达或者有事务发生,通过往pipe管道写端写入数据来唤醒主线程工作。这里采用的epoll机制,是一种IO多路复用机制,可以同时监控多个描述符,当某个描述符就绪(读或写就绪),则立刻通知相应程序进行读或写操作,本质同步I/O,即读写是阻塞的。 所以说,主线程大多数时候都是处于休眠状态,并不会消耗大量CPU资源。

主线程的消息循环机制是什么?

事实上,会在进入死循环之前便创建了新binder线程,在代码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");
    }
  • Activity的生命周期都是依靠主线程的Looper.loop,当收到不同Message时则采用相应措施:一旦退出消息循环,那么你的程序也就可以退出了。
    从消息队列中取消息可能会阻塞,取到消息会做出相应的处理。如果某个消息处理时间过长,就可能会影响UI线程的刷新速率,造成卡顿的现象。

  • thread.attach(false)方法函数中便会创建一个Binder线程(具体是指ApplicationThread,Binder的服务端,用于接收系统服务AMS发送来的事件),该Binder线程通过Handler将Message发送给主线程。「Activity 启动过程」
    比如收到msg=H.LAUNCH_ACTIVITY,则调用ActivityThread.handleLaunchActivity()方法,最终会通过反射机制,创建Activity实例,然后再执行Activity.onCreate()等方法;
    再比如收到msg=H.PAUSE_ACTIVITY,则调用ActivityThread.handlePauseActivity()方法,最终会执行Activity.onPause()等方法。

主线程的消息又是哪来的呢?当然是App进程中的其他线程通过Handler发送给主线程

  • system_server进程
    system_server进程是系统进程,java framework框架的核心载体,里面运行了大量的系统服务,比如这里提供ApplicationThreadProxy(简称ATP),ActivityManagerService(简称AMS),这个两个服务都运行在system_server进程的不同线程中,由于ATP和AMS都是基于IBinder接口,都是binder线程,binder线程的创建与销毁都是由binder驱动来决定的。

  • App进程
    App进程则是我们常说的应用程序,主线程主要负责Activity/Service等组件的生命周期以及UI相关操作都运行在这个线程; 另外,每个App进程中至少会有两个binder线程 ApplicationThread(简称AT)和ActivityManagerProxy(简称AMP),除了图中画的线程,其中还有很多线程

  • Binder
    Binder用于不同进程之间通信,由一个进程的Binder客户端向另一个进程的服务端发送事务,比如图中线程2向线程4发送事务;
    而handler用于同一个进程中不同线程的通信,比如图中线程4向主线程发送消息。

Android Handler 消息机制_第9张图片

结合图说说Activity生命周期,比如暂停Activity,流程如下:

  1. 线程1的AMS中调用线程2的ATP;(由于同一个进程的线程间资源共享,可以相互直接调用,但需要注意多线程并发问题)
  2. 线程2通过binder传输到App进程的线程4;
  3. 线程4通过handler消息机制,将暂停Activity的消息发送给主线程;
  4. 主线程在looper.loop()中循环遍历消息,当收到暂停Activity的消息时,便将消息分发给
    ActivityThread.H.handleMessage()方法,再经过方法的调用,
    最后便会调用到Activity.onPause(),当onPause()处理完后,继续循环loop下去。

补充:
ActivityThread的main方法主要就是做消息循环,一旦退出消息循环,那么你的程序也就可以退出了。

从消息队列中取消息可能会阻塞,取到消息会做出相应的处理。如果某个消息处理时间过长,就可能会影响UI线程的刷新速率,造成卡顿的现象。

总结

最后通过《Android开发艺术探索》的一段话总结 :
ActivityThread通过ApplicationThread和AMS进行进程间通讯,AMS以进程间通信的方式完成ActivityThread的请求后会回调ApplicationThread中的Binder方法,然后ApplicationThread会向H发送消息,H收到消息后会将ApplicationThread中的逻辑切换到ActivityThread中去执行,即切换到主线程中去执行,这个过程就是。主线程的消息循环模型。

另外,ActivityThread实际上并非线程,不像HandlerThread类,ActivityThread并没有真正继承Thread类。

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而创建的进程。

子线程有哪些更新UI的方法

  1. 主线程中定义Handler,子线程通过mHandler发送消息,主线程Handler的handleMessage更新UI。
  2. 用Activity对象的runOnUiThread方法。
  3. 创建Handler,传入getMainLooper
  4. View.post(Runnable r) 。

runOnUiThread

Looper在哪个线程创建,就跟哪个线程绑定,并且Handler是在他关联的Looper对应的线程中处理消息的。(敲黑板)

new Thread(new Runnable() {
    @Override
    public void run() {
        runOnUiThread(new Runnable() {
            @Override
            public void run() {
                //DO UI method
            }
        });
    }
}).start();
/* Activity源码 */
final Handler mHandler = new Handler();
public final void runOnUiThread(Runnable action) {
    if (Thread.currentThread() != mUiThread) {
        mHandler.post(action);//子线程(非UI线程)
    } else {
        action.run();
    }
}

进入Activity类里面,可以看到如果是在子线程中,通过mHandler发送的更新UI消息。
而这个Handler是在Activity中创建的,也就是说在主线程中创建,所以便和我们在主线程中使用Handler更新UI没有差别。
因为这个Looper,就是ActivityThread中创建的Looper(Looper.prepareMainLooper())。

创建Handler,传入getMainLooper

同理,我们在子线程中,是否也可以创建一个Handler,并获取MainLooper,从而在子线程中更新UI呢?
首先我们看到,在Looper类中有静态对象sMainLooper,并且这个sMainLooper就是在ActivityThread中创建的MainLooper

/* Looper源码 */
private static Looper sMainLooper;  // guarded by Looper.class
public static void prepareMainLooper() {
    prepare(false);
    synchronized (Looper.class) {
        if (sMainLooper != null) {
            throw new IllegalStateException("The main Looper has already been prepared.");
        }
        sMainLooper = myLooper();
    }
}

所以不用多说,我们就可以通过这个sMainLooper来进行更新UI操作。

new Thread(new Runnable() {
    @Override
    public void run() {
        Log.e("qdx", "step 1 "+Thread.currentThread().getName());
        Handler handler=new Handler(getMainLooper());
        handler.post(new Runnable() {
            @Override
            public void run() {
                //Do Ui method
                Log.e("qdx", "step 2 "+Thread.currentThread().getName());
            }
        });
    }
}).start();

View.post(Runnable r)

老样子,我们点入源码

/* View源码 */
/**
 * 

Causes the Runnable to be added to the message queue. * The runnable will be run on the user interface thread.

* * @param action The Runnable that will be executed. * * @return Returns true if the Runnable was successfully placed in to the * message queue. Returns false on failure, usually because the * looper processing the message queue is exiting. * */ 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; } /** * A Handler supplied by a view's {@link android.view.ViewRootImpl}. This * handler can be used to pump events in the UI events queue. */ final Handler mHandler;

居然也是Handler从中作祟,根据Handler的注释,也可以清楚该Handler可以处理UI事件,也就是说它的Looper也是主线程的sMainLooper。这就是说我们常用的更新UI都是通过Handler实现的。

另外更新UI 也可以通过AsyncTask来实现,这个AsyncTask的线程切换也是通过 Handler 。

子线程中Toast、showDialog的方法

new Thread(new Runnable() {
    @Override
    public void run() {
        Toast.makeText(MainActivity.this, "run on thread", Toast.LENGTH_SHORT).show();//崩溃无疑
    }
}).start();
Android Handler 消息机制_第10张图片

看到这个崩溃日志,是否有些疑惑,因为一般如果子线程不能更新UI控件是会报如下错误的(子线程不能更新UI)

Android Handler 消息机制_第11张图片

所以子线程不能更新Toast的原因就和Handler有关了,据我们了解,每一个Handler都要有对应的Looper对象,那么。
满足你:

new Thread(new Runnable() {
    @Override
    public void run() {
        Looper.prepare();
        Toast.makeText(MainActivity.this, "run on thread", Toast.LENGTH_SHORT).show();//成功在子线程中Toast
        Looper.loop();
    }
}).start();

这样便能在子线程中Toast。
看一下Toast内部执行方式:

/* Toast源码 */
/**
 * Show the view for the specified duration.
 */
public void show() {
    ``````
    INotificationManager service = getService();//从SMgr中获取名为notification的服务
    String pkg = mContext.getOpPackageName();
    TN tn = mTN;
    tn.mNextView = mNextView;

    try {
        service.enqueueToast(pkg, tn, mDuration);//enqueue? 难不成和Handler的队列有关?
    } catch (RemoteException e) {
        // Empty
    }
}

show方法中,我们看到Toast的show方法和普通UI 控件不太一样,并且也是通过Binder进程间通讯方法执行Toast绘制。这其中的过程就不在多讨论了,有兴趣的可以在NotificationManagerService类中分析。

现在把目光放在TN 这个类上(难道越重要的类命名就越简洁,如H类),通过TN 类,可以了解到它是Binder的本地类。在Toast的show方法中,将这个TN对象传给NotificationManagerService就是为了通讯!并且我们也在TN中发现了它的show方法。

/* Toast源码 */
private static class TN extends ITransientNotification.Stub {//Binder服务端的具体实现类
    /**
     * schedule handleShow into the right thread
     */
    @Override
    public void show(IBinder windowToken) {
        mHandler.obtainMessage(0, windowToken).sendToTarget();
    }
    final Handler mHandler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
            IBinder token = (IBinder) msg.obj;
            handleShow(token);
        }
    };
}

看完上面代码,就知道子线程中Toast报错的原因,因为在TN中使用Handler,所以需要创建Looper对象。
那么既然用Handler来发送消息,就可以在handleMessage中找到更新Toast的方法。
handleMessage看到由handleShow处理。

/* Toast源码 */
//Toast的TN类
public void handleShow(IBinder windowToken) {
        ``````
        mWM = (WindowManager)context.getSystemService(Context.WINDOW_SERVICE);

        mParams.x = mX;
        mParams.y = mY;
        mParams.verticalMargin = mVerticalMargin;
        mParams.horizontalMargin = mHorizontalMargin;
        mParams.packageName = packageName;
        mParams.hideTimeoutMilliseconds = mDuration ==
            Toast.LENGTH_LONG ? LONG_DURATION_TIMEOUT : SHORT_DURATION_TIMEOUT;
        mParams.token = windowToken;
        if (mView.getParent() != null) {
            mWM.removeView(mView);
        }
        mWM.addView(mView, mParams);//使用WindowManager的addView方法
        trySendAccessibilityEvent();
    }
}

总结

Toast本质是通过window显示和绘制的(操作的是window),而子线程不能更新UI 是因为ViewRootImpl的checkThread方法在Activity维护的View树的行为。
Toast中TN类使用Handler是为了用队列和时间控制排队显示Toast,所以为了防止在创建TN时抛出异常,需要在子线程中使用Looper.prepare();和Looper.loop();(但是不建议这么做,因为它会使线程无法执行结束,导致内存泄露)

Dialog亦是如此。同时我们又多了一个知识点要去研究:Android 中Window是什么,它内部有什么机制?

如何处理Handler 使用不当导致的内存泄露?

首先上文在子线程中为了节目效果,使用如下方式创建Looper

Looper.prepare();
...
Looper.loop();

实际上这是非常危险的一种做法

在子线程中,如果手动为其创建Looper,那么在所有的事情完成以后应该调用quit方法来终止消息循环,否则这个子线程就会一直处于等待的状态,而如果退出Looper以后,这个线程就会立刻终止,因此建议不需要的时候终止Looper。(【 Looper.myLooper().quit(); 】)

那么,如果在Handler的handleMessage方法中(或者是run方法)处理消息,如果这个是一个延时消息,会一直保存在主线程的消息队列里,并且会影响系统对Activity的回收,造成内存泄露。

解决Handler内存泄露主要2点

  1. 有延时消息,要在Activity销毁的时候移除Messages
  2. 匿名内部类导致的泄露改为匿名静态内部类,并且对上下文或者Activity使用弱引用。

消息机制的应用

在Android中有很多消息机制的应用,如:

  • UI的更新
  • HandlerThread
  • IntentService

UI的更新

【见 常见问题-子线程有哪些更新UI的方法】

IntentService

IntentService继承自Service,运行时优先级更高,内部使用了HandlerThread作为处理消息的线程。内部有一个私有内部类ServiceHandler继承自Handler,并且会创建一个ServiceHandler对象。
使用startService()方法启动IntentService时,不会重新创建一个服务,会调用ServiceHandler对象发送包含该Intent的Message对象,该对象通过HandlerThread处理后交给ServiceHandler重写的handleMessage方法进行处理,处理的方式是调用IntentService的onHandleIntent(Intent)方法,所以使用的方式就是创建一个继承自IntentService类的子类,并重写onHandleIntent方法,在该方法中处理startService时传递的Intent。Intent中包含有要交给Service处理的信息。

引用:

★★★★★Android的消息机制
★★★★★Android消息机制1-Handler(Java层)
★★Android 源码分析之旅3.1--消息机制源码分析
★★★Android 消息机制——你真的了解Handler?
Android消息机制-ThreadLocal原理解析:数据存取
Android消息机制详解
Android Handler消息机制实现原理
★★★★Android基础夯实--你了解Handler有多少?
★★★Android消息机制3-Handler(实战)

你可能感兴趣的:(Android Handler 消息机制)