本文已经收录到我的Github个人博客,欢迎大佬们光临寒舍:
Handler的基本概念及使用
Handler?在Android平台上,主要用到的通信机制有两种:Handler和Binder,前者用于进程内部的通信,后者主要用于跨进程通信。
在多线程的应用场景中,Handler将工作线程中需更新UI的操作信息 传递到 UI主线程,从而实现工作线程对UI的更新处理,最终实现异步消息的处理。
作为一个Android程序猿,知其然而必须知其所以然,理解其源码能更好地了解Handler机制的原理。下面,我就从消息机制入手,带大家畅游在Handler的世界中,体会Google工程师的智慧之光。
A.作用:跨线程通信
B.常用场景:当子线程中进行耗时操作后需要更新UI时,通过Handler将有关UI的操作切换到主线程中执行
系统不建议在子线程访问
UI的原因:UI控件非线程安全,在多线程中并发访问可能会导致UI控件处于不可预期的状态
而不对
UI控件的访问加上锁机制的原因有:1.上锁会让UI控件变得复杂和低效
2.上锁后会阻塞某些进程的执行
C.四要素:
Message:需要被传递的消息,其中包含了消息ID,消息处理对象以及处理的数据等,由MessageQueue统一列队,最终由Handler处理MessageQueue:用来存放Handler发送过来的消息,内部通过单链表的数据结构来维护消息列表,等待Looper的抽取。Handler:负责Message的发送及处理
Handler.sendMessage():向消息队列发送各种消息事件
Handler.handleMessage():处理相应的消息事件
Looper:通过Looper.loop()不断地从MessageQueue中抽取Message,按分发机制将消息分发给目标处理者,可以看成是消息泵
Thread:负责调度整个消息循环,即消息循环的执行场所存在关系:
- 一个
Thread只能有一个Looper,可以有多个Handler
Looper有一个MessageQueue,可以处理来自多个Handler的Message
MessageQueue有一组待处理的Message,这些Message可来自不同的Handler
Message中记录了负责发送和处理消息的Handler
Handler中有Looper和MessageQueue


D.使用方法:
ActivityThread主线程实例化一个全局的Handler对象UI操作的子线程里实例化一个Message并填充必要数据,调用Handler.sendMessage(Message)方法发送出去handleMessage()方法,对不同Message执行相关操作E.总体工作流程:
这里先总体地说明一下
Android消息机制的工作流程,具体的ThreadLocal,MessageQueue,Looper,Handler的工作原理会在下文详细解析
Handler.sendMessage()发送消息时,会通过MessageQueue.enqueueMessage()向MessageQueue中添加一条消息Looper.loop()开启循环后,不断轮询调用MessageQueue.next()Handler.dispatchMessage()去传递消息,目标Handler收到消息后调用Handler.handleMessage()处理消息简单来看,即
Handler将Message发送到Looper的成员变量MessageQueue中,之后Looper不断循环遍历MessageQueue从中读取Message,最终回调给Handler处理。如图:

ThreadLocal了解
ThreadLocal,有助于我们后面对Looper的探究
Q1:ThreadLocal是什么
首先我们来看一下官方源码(Android 9.0)
This class provides thread-local variables. These variables differ from their normal counterparts in that each thread that accesses one (via its {@code get} or {@code set} method) has its own, independently initialized copy of the variable. {@code ThreadLocal} instances are typically private static fields in classes that wish to associate state with a thread (e.g., a user ID or Transaction ID).
大致意思:
ThreadLocal是一个线程内部的数据存储类,通过它可以在指定的线程中存储数据,只有在指定线程中才能获取到存储的数据(也就是说,每个线程的一个变量,有自己的值)
Q2:ThreadLocal的使用场景:
Android中具体的使用场景:Looper,ActivityThread,AMS
如果不采用
ThreadLocal的话,需要采取的措施:提供一个全局哈希表
采用
ThreadLocal让监听器作为线程中的全局对象,线程内部只有通过get方法即可得到监听器
如果不采用
ThreadLocal的方案:a.将监听器作为参数传递
缺点:当调用栈很深的时候,程序设计看起来不美观
b.将监听器作为静态变量
缺点:状态不具有可扩充性
Q3:ThreadLocal和synchronized的区别:
- 对于多线程资源共享的问题,
synchronized机制采用了“以时间换空间”的方式- 而
ThreadLocal采用了“以空间换时间”的方式- 前者仅提供一份变量,让不同的线程排队访问,而后者为每一个线程都提供了一份变量,因此可以同时访问而互不影响,所以
ThreadLocal和synchronized都能保证线程安全,但是应用场景却大不一样。
Q4:原理
ThreadLocal主要操作为set,get操作,下面分别介绍流程
A1:set的原理

A2:get的原理

综上所述,ThreadLocal之所以有这么奇妙的效果,是因为:
ThreadLocal.get(),其内部会从各种线程中取出table数组,然后根据当前ThreadLocal的索引查找出对应的values值想要了解
ThreadLocal源码的读者,推荐一篇文章:ThreadLocal详解
MessageQueue数据结构:MessageQueue的数据结构是单链表
操作:
A.enqueueMessage
主要操作是单链表的插入操作
B.next
是一个无限循环的方法,如果没有消息,会一直阻塞;当有消息的时候,next会返回消息并将其从单链表中移出
LooperQ1:Looper的作用
- 作为消息循环的角色
- 它会不停地从
MessageQueue中查看是否有新消息,若有新消息则立即处理,否则一直阻塞(不是ANR)
Handler需要Looper,否则将报错
Q2:Looper的使用
a1:开启:
UI线程会自动创建Looper,子线程需自行创建
//子线程中需要自己创建一个Looper
new Thread(new Runnable() {
            @Override
            public void run() {
                Looper.prepare();//为子线程创建Looper   
                Handler handler = new Handler();
                Looper.loop(); //开启消息轮询
            }
        }).start();
- 除了
prepare(),还提供prepareMainLooper(),本质也是通过prepare()
getMainLooper()作用:获取主线程的Looper
a2:关闭:
quit:直接退出quitSafely:设定退出标记,待MessageQueue中处理完所有消息再退出退出
Looper的话,子线程会立刻终止;因此:建议在不需要的时候终止Looper
Q3:原理:

HandlerQ1:Handler的两种使用方式:
注意:创建
Handler实例之前必须先创建Looper实例,否则会抛RuntimeException(UI线程自动创建Looper)
send方式//第一种:send方式的Handler创建
Handler mHandler = new Handler() {
            @Override
            public void handleMessage(Message msg) {
                //如UI操作
            }
        };
//send
mHandler.sendEmptyMessage(0);post方式最终是通过一系列
send方法来实现
//实例化Handler
private Handler mHandler = new Handler();
//这里调用了post方法,和sendMessage一样达到了更新UI的目的
     mHandler.post(new Runnable() {
            @Override
            public void run() {
                mTextView.setText(new_str);
            }
        });Q2:Handler处理消息过程


Handler 的延伸在初学
Handler的时候,往往会发现AS亮起一大块黄色,以警告可能会发生内存泄漏

发生场景:Handler 允许我们发送延时消息,如果在延时期间用户关闭了Activity,那么该Activity会泄露
原因:这个泄露是因为因为 Java 的特性,内部类会持有外部类, Handler 持有 Activity 的引用,Message持有Handler的引用,而MessageQueue会持有Message的引用,而MessageQueue是属于TLS(ThreadLocalStorage)线程,是与Activity不同的生命周期。所以当Activity的生命周期结束后,而MessageQueue中还存在未处理的消息,那么上面一连串的引用链就不允许Activity的对象被回收,就造成了内存泄漏
解决方式:
A.Activity销毁时,清空Handler中未执行或正在执行的Callback以及Message
    // 清空消息队列,移除对外部类的引用
    @Override
    protected void onDestroy() {
        super.onDestroy();
        mHandler.removeCallbacksAndMessages(null);
    }? B.静态内部类+弱引用
private static class AppHandler extends Handler {
    //弱引用,在垃圾回收时,被回收
    WeakReference<Activity> mActivityReference;
    AppHandler(Activity activity){
        mActivityReference=new WeakReference<Activity>(activity);
    }
    public void handleMessage(Message message){
        switch (message.what){
             HandlerActivity activity=mActivityReference.get();
             super.handleMessage(message);
            if(activity!=null){
                //执行业务逻辑
               
            }
        }
    }
}
Handler里藏着的Callback首先看下Handler.dispatchMessage(msg)
public void dispatchMessage(Message msg) {
  //这里的 callback 是 Runnable
  if (msg.callback != null) {
    handleCallback(msg);
  } else {
    //如果 callback 处理了该 msg 并且返回 true, 就不会再回调 handleMessage
    if (mCallback != null) {
      if (mCallback.handleMessage(msg)) {
        return;
      }
    }
    handleMessage(msg);
  }
}可以看到 Handler.Callback 有优先处理消息的权利
Callback 处理并拦截(返回 true),那么 Handler.handleMessage(Msg) 方法就不会被调用了Callback处理了消息,但是并没有拦截,那么就意味着一个消息可以同时被Callback以及 Handler 处理这个就很有意思了,这有什么作用呢?
我们可以利用 Callback 这个拦截机制来拦截 Handler 的消息!
场景:Hook ActivityThread.mH ,笔者在进阶之路 | 奇妙的四大组件之旅介绍过ActivityThread,在 ActivityThread中有个成员变量 mH ,它是个 Handler,又是个极其重要的类,几乎所有的插件化框架都使用了这个方法
限于当前知识水平,笔者尚未研究过插件化的知识,以后有机会的话希望能给大家介绍!
Message 的最佳方式为了节省开销,尽量复用
Message,减少内存消耗
法一:Message msg=Message.obtain();
法二:Message msg=handler.obtainMessage();
Looper 机制我们可以利用Looper的机制来帮助我们做一些事情:
Runnable post 到主线程执行Looper 判断当前线程是否是主线程public final class MainThread {
    private MainThread() {
    }
    private static final Handler HANDLER = new Handler(Looper.getMainLooper());
    //将 Runnable post 到主线程执行
    public static void run(@NonNull Runnable runnable) {
        if (isMainThread()) {
            runnable.run();
        }else{
            HANDLER.post(runnable);
        }
    }
    //判断当前线程是否是主线程
    public static boolean isMainThread() {
        return Looper.myLooper() == Looper.getMainLooper();
    }
}
Android中为什么主线程不会因Looper.loop()的死循环卡死?这个是老生常谈的问题了,记得当初被学长问到这个问题的时候,一脸懵逼,然后胡说一通,实属羞愧
要弄清这个问题,我们可以通过几个问题来逐层深入剖析
Q1:什么是线程?
线程是一段可执行的代码,当可执行代码执行完成后,线程生命周期便该终止了,线程退出
Q2:进入死循环是不是说明一定会阻塞?
前面也说到了线程既然是一段可执行的代码,当可执行代码执行完成后,线程生命周期便该终止了,线程退出。而对于主线程,我们是绝不希望会被运行一段时间,自己就退出,那么如何保证能一直存活呢?简单做法就是可执行代码是能一直执行下去的,死循环便能保证不会被退出
想到这就理解,主线程也是一个线程,它也要维持自己的周期,所以也是需要一个死循环的。所以死循环并不是那么让人担心。
Q3:什么是Looper的阻塞?
Looper的阻塞,前提是没有输入事件,此时MessageQueue是空的,Looper进入空闲,线程进入阻塞,释放CPU,等待输入事件的唤醒Looper阻塞的时候,主线程大多数时候都是处于休眠状态,并不会消耗大量CPU资源
Looper的阻塞涉及到Linux pipe/epoll机制,想了解的读者可自行
Q4:聊聊ANR
ANR和Looper的阻塞二者相混淆UI耗时导致卡死,前提是要有输入事件,此时MessageQueue不是空的,Looper正常轮询,线程并没有阻塞,但是该事件执行时间过长(一般5秒),而且与此期间其他的事件(按键按下,屏幕点击..也是通过Looper处理的)都没办法处理(卡死),然后就ANR异常了Q5:卡死的真正原因:
onCreate/onStart/onResume等操作时间过长恭喜你!已经看完了前面的文章,相信你对
Handler已经有一定深度的了解,下面,进行一下课堂小测试,验证一下自己的学习成果吧!PS:限于篇幅,笔者就不提供答案了,不过答案一搜就有了
Q1:如何将一个Thread线程变成Looper线程?Looper线程有哪些特点
Q2:简述下Handler、Message、Looper的作用,以及他们之间的关系
Q3: 简述消息机制的回调处理过程,怎么保证消息处理机制的唯一性
Q4:为什么发送消息在子线程,而处理消息就变成主线程了,在哪儿跳转的
如果文章对您有一点帮助的话,希望您能点一下赞,您的点赞,是我前进的动力
本文参考链接:
原文:https://www.cnblogs.com/xcynice/p/qi_miao_de_handler_zhi_lv.html