Android_Handler源码分析

时间 2020-06-17

标签 android handler 源码分析栏目 Android 繁體版

原文原文链接

什么是Handler?

Handler主要用于异步消息的处理:当发出一个消息以后,首先进入一个消息队列,发送消息的函数即刻返回,而另一个部分在消息队列中逐一将消息取出,而后对消息进行处理git

相信大部分Android开发者对于Handler都有所了解,概念的知识就不作赘述,下面咱们主要是带着几个问题去分析(面试中常被问到的问题~)github

① Handler是否存在内存泄漏?
② 为何不能在子线程建立Handler?
③ textView.setText() 只能在主线程执行??
④ new Handler() 两种写法有什么区别?
⑤ ThreadLocal 用法和原理

①首先第一个问题比较简单,咱们直接测试下:

代码也比较简单,简单说下,在MainActivity中建立了一个Handler,而且开启了一个子线程,休眠5s后,handler发送一条消息,handler收到消息跳转到SecondActivity,,贴下代码面试

private static final String TAG="HANDLER_TEST";
    private TextView mTextView;

    //第一种方式建立handler
    Handler handler = new Handler(){
        @Override
        public void handleMessage(Message msg) {
            //跳转另外一个Activity
            startActivity(new Intent(MainActivity.this,SecondActivity.class));
            super.handleMessage(msg);
        }
    };

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        mTextView = findViewById(R.id.tv);
        leakTest();
    }

    //内存泄露测试,开启一个线程,休眠5s后handler发送消息
    private void leakTest() {
        new Thread(new Runnable(){
            @Override
            public void run() {
                Message message = new Message();
                message.what=123;//能够不设置
                message.obj="并无销毁";
                //休眠五秒钟,假设是一些耗时操做
                SystemClock.sleep(5000);
                handler.sendMessage(message);
            }
        }).start();
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        Log.e(TAG,"onDestroy");
    }
复制代码

咱们的操做是,在休眠过程当中,点击返回键,销毁MainActivity,看下效果和日志: api

日志:bash

com.frizzle.handler E/HANDLER_TEST: onDestroy
复制代码

咱们能够看到,咱们点击返回按钮销毁了,而且MainActivity触发了onDestroy(),可是休眠结束,仍是跳转了SecondActivity,因此这里是存在内存泄漏的,而且很严重,看到这里其实,不少小伙伴会说,在onDestroy()方法中调用handler.removeCallbacksAndMessages(123)不就能够解决内存泄露的问题了,然而这么作并无效果,仍是会形成内存泄漏,表现与上面一致,这是为何呢?缘由是上述代码的方式,handler会在休眠五秒结束以后以后,才会sendMessage(),也就是将消息放进队列queue,在message没有被放入队里中时,调用handler.removeCallbacksAndMessages()是没有实际意义的。正确的处理方式举例:异步

//内存泄露测试,开启一个线程,休眠5s后handler1发送消息
    private void leakTest() {
        new Thread(new Runnable(){
            @Override
            public void run() {
                Message message = new Message();
                message.what=123;//能够不设置
                message.obj="并无销毁";
                //休眠五秒钟,假设是一些耗时操做
                SystemClock.sleep(5000);
                if (handler!=null) {
                    handler.sendMessage(message);
                }
            }
        }).start();
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        Log.e(TAG,"onDestroy");
        if (handler!=null) {
            handler.removeCallbacksAndMessages(123);
            handler=null;
        }
    }
复制代码

须要注意的是:若是发送消息是采用的是handler.sendMessageDelayed()的方式,在onDestroy()中经过handler.removeCallbacksAndMessages()是能够已解决内存泄漏的问题的,由于handler.removeCallbacksAndMessages()会将消息放进队列queue,可是handler.sendMessageDelayed()在开发中并不经常使用,由于耗时操做耗时多久一般是不肯定的,还有一点是Message对象的建立建议使用Message.obtain(),还有就是若是Message被定义为全局变量的话,使用时也须要注意,好比以下方式会发生异常This message is already in use.:ide

//内存泄露测试,开启一个线程,休眠5s后handler1发送消息
    private void leakTest() {
        new Thread(new Runnable(){
            @Override
            public void run() {
                message = new Message();
                message.what=123;//能够不设置
                message.obj="并无销毁";
                //休眠五秒钟,假设是一些耗时操做
                SystemClock.sleep(5000);
                if (handler1!=null) {
                    handler1.sendMessage(message);
                }
            }
        }).start();
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        Log.e(TAG,"onDestroy");
        message.recycle();
    }
复制代码

和上面内存泄漏的缘由相似~函数

②为何不能在子线程中建立Handler?

这里须要说明下,不是全部Android手机在子线程中new Handler()都会抛异常,好比华为的部分手机改写了源码,并不会出现异常,这里咱们主要关注出现异常的缘由,那么出现异常的缘由是什么?oop

首先咱们要知道应用启动时,ActivityThread是建立了一个主线程的Looper对象的,过程大体以下: 在应用启动时建立开启ActivityThread,在ActivityThread的main()方法中调用了Looper.prepareMainLooper()方法,而后建立了一个Looper对象,这个Looper对象是存在主线程中的,而且调用了sThreadLocal.set(new Looper(quitAllowed)); sThreadLocal是存在在ThreadLocalMap中的,sThreadLocal在存和取的时候,调用的是ThreadLocalMap的get()和set()方法,而且key就是当前线程
而后咱们在使用new Handler()系统作了什么呢?

api的调用循序大概是这样的: mLooper = Looper.myLooper()→sThreadLocal.get() 由于子线程没有建立Looper对象,因此已子线程做为key找到的Looper对象为null就会抛出异常post

mLooper = Looper.myLooper();
        if (mLooper == null) {
            throw new RuntimeException(
                "Can't create handler inside thread " + Thread.currentThread()
                        + " that has not called Looper.prepare()");
        }
复制代码

注:在子线程建立Looper并开启轮询,这种方式能够在子线程使用Handler,这种方式这里不作讨论~

③textView.setText() 只能在主线程执行??

首先咱们先写一段测试代码:

//开启子线程
 private void leakTest() {
        new Thread(new Runnable(){
            @Override
            public void run() {

            }
        }).start();
    }
复制代码

而后咱们在run()方法中写几行代码,并记录现象和日志~

①直接改变TextView的文本内容

mTextView.setText("子线程更新文本内容");
复制代码

现象: 华为手机 : 没有闪退,文本内容发生改变! 谷歌手机 : 没有闪退,文本内容发生改变!

对上述有疑问的小伙伴请自行测试~ 在下面会分析缘由 ↓

②休眠一秒钟,改变TextView的文本内容

SystemClock.sleep(1000);
mTextView.setText("子线程更新文本内容");
复制代码

现象: 华为手机 : 闪退谷歌手机 : 闪退闪退的日志为:

Only the original thread that created a view hierarchy can touch its views.
复制代码

③弹Toast提示

Toast.makeText(MainActivity.this,"子线程弹吐司",Toast.LENGTH_SHORT).show();
复制代码

现象: 华为手机 : 部分闪退,部分没有发生闪退,可是也不显示Toast内容谷歌手机 : 闪退闪退的日志为:

Can't toast on a thread that has not called Looper.prepare() 复制代码

根据第②点的日志,能够咱们能够找到源码中抛出异常的地方,在ViewRootImpl类的checkThread()方法:

void checkThread() {
        if (mThread != Thread.currentThread()) {
            throw new CalledFromWrongThreadException(
                    "Only the original thread that created a view hierarchy can touch its views.");
        }
    }
复制代码

对于子线程不能更新UI,小伙伴们应该都是比较了解的,这里不作过多赘述,简单说就是View或ViewGroup在更新UI时调用的invalidate()都会在ViewRootImpl中执行线程的检查,如上,若是不是主线程,会直接抛异常。 注: TextView继承自View实现了ViewParent接口,而ViewRootImpl是接口实现类,在ViewRootImpl的requestLayout中调用checkThread()校验线程因此为何第一种写法不会抛异常呢? 缘由是: ViewRootImpl是在 Activity 建立对象完毕以后再建立对象的,若是咱们调用setText()等api的速度快于 ViewRootImpl对象的建立,就不会抛出异常!因此咱们直接调用不会异常,而子线程休眠一秒钟以后就会抛出异常,对于第三种方式使用Toast的状况,首先这种方式最终会调用,setText()的api,与上面两种状况相似,可是在这中间还有不少代码要执行,至关于延迟了一段时间,更新UI的方法是在ViewRootImpl对象建立以后作的,因此会发生异常。因此textView.setText() 只能在主线程执行这种说法太过绝对

④ new Handler() 两种写法有什么区别?

建立Handler的两种方式示例以下:

在Android Studio中使用第一种方式的话会自动加浅黄色背景,如上图,由于这种方式并不推荐使用,咱们直接看下源码中是如何使用的:

/**
     * Handle system messages here.
     */
    public void dispatchMessage(@NonNull Message msg) {
        if (msg.callback != null) {
            handleCallback(msg);
        } else {
            if (mCallback != null) {
                if (mCallback.handleMessage(msg)) {
                    return;
                }
            }
            handleMessage(msg);
        }
    }
复制代码

二者的区别:

第一种重写的handleMessage()方法是Handler对外提供可重写的方法第二种重写的handleMessage()方法是Handler.ClaaBack接口的重写方法

注 使用Hander切换主线程的实现方式: message.callback是主线程的Runnable对象,使用切换主线程其实就会调用了调用了主线程的Runnable的run()方法这里说的run()方法是Thread必须实现的run()方法,源码以下:

private static void handleCallback(Message message) {
        message.callback.run();
    }
复制代码

⑤ ThreadLocal 用法和原理

这个问题网上有不少文章是讲解ThreadLocal 的用法和原理,有兴趣的能够去搜一下,这里主要说下在使用的时候注意的问题:

① ThreadLocal 的使用key是线程,因此不一样的线程调用set方法是互不影响的 ② 线程中使用ThreadLocal .set()方法使用完毕记得remove(),避免没必要要的内存浪费~

Handler + Message原理

对于Handler + Message原理分析,网上有不少不少文章了,这里主要就主要用流程图来简单介绍吧~ 咱们都知道要分析Handler + Message,离不开四个对象: Handler 、 Message 、Looper 、 MessageQueue

先看下运做的流程图

简单来讲:就是Handler发送消息和处理消息(知识最少原则)

大体流程就是: 应用在启动时,ActivityThread建立了一个主线程惟一的Looper对象,调用了Looper.loop()开启了消息轮询(死循环),而后Handler对象就能够调用sendMessage()方法将消息压入消息队列,压入的过程调用的就是equeueMessage()方法,Looper经过轮询取出队首的message(先进先出),而且调用message.target.dispatchMessage()方法分发消息,而message.target对象就是Handler,也就是回调了Handler的handleMessage()方法

这里有几点要说明:

① Handler的sendMessage()、post()、sendEmptyMessageAttime()等这些发送消息的api都会经过equeueMessage()将消息压入消息队列
② 利用Handler的能够切换主线程的缘由是 Message中有个变量callback是一个Runnable对象而且这个Runnable是在主线程当中的代码以下,咱们能够看到若是msg.callback != null最终就调用了它的run()方法,因此post()能实现线程的调度的缘由就在这里

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

 private static void handleCallback(Message message) {
        message.callback.run();
    }
复制代码

若是以为上面的图有点抽象的话,结合下面这种详细的流程图,可能更容易理解:

到这里差很少就分析完了,可是还有一个疑问没有说明,既然在Looper.loop()中是一个死循环,为何主线程不会ANR?

//这里就贴了几行代码,相信大部分小伙伴都看过~
for (;;) {
            Message msg = queue.next(); // might block
            if (msg == null) {
                // No message indicates that the message queue is quitting.
                return;
            }
        .....
}
复制代码

首先要明确一点,若是ActivityThread没有在主线程调用Looper.loop(),ActivityThread的main()方法执行完毕就退出了,这显然是不符合实际状况的

其实在Looper.next()开启死循环的时候，一旦须要等待时或尚未执行到执行的时候，会调用NDK里面的JNI方法，释放当前时间片，这样就不会引起ANR异常了代码大体以下:

① Binder.clearCallingIdentity()

// Make sure that during the course of dispatching the
// identity of the thread wasn't corrupted. final long newIdent = Binder.clearCallingIdentity(); 复制代码

② Trace.traceBegin(traceTag, msg.target.getTraceName(msg))

if (traceTag != 0 && Trace.isTagEnabled(traceTag)) {
                Trace.traceBegin(traceTag, msg.target.getTraceName(msg));
            }
复制代码

最后总结几个相对重要的问题:

① Q :为何主线程用Looper死循环不会引起ANR异常? A : 由于在Looper.next()开启死循环的时候，一旦须要等待时或尚未执行到执行的时候，会调用NDK里面的JNI方法释放当前时间片,这样就不会引起ANR异常了,同上~
② Q :为何Handler构造方法里面的Looper不是直接new? A : 若是在Handler构造方法里面new Looper,怕是没法保证保证Looper惟一，只有用 Looper.prepare()才能保证惟一性，具体去看prepare方法
③ Q : MessageQueue为何要放在Looper私有构造方法初始化? A : 由于一个线程只绑定一个Looper, 因此在Looper构造方法里面初始化就能够保证mQueue也是惟的Thread对应一个Looper 对应一个mQueue
④ Q :主线程里面的Looper.prepare/Looper.loop, 是一直在无限循环里面的吗? A : yes

最最后附一下简单实现Handler+Message机制代码

注: 简单模拟实现Handler机制的代码在单元测试test包下舒适提示:直接右键test包下的ActivityThread执行便可看到日志 github