Framework 源码解析知识梳理(4) - 从源码角度谈谈 Handler 的应用

一、前言

其实，这篇文章本来应该叫做"Handler源码解析"的，但是想想写Handler源码的文章太多了，还是缓一缓，先写些不一样的，今天，我们从源码的角度来总结一下应用Handler的一些场景的原理。

二、Handler 的应用

2.1 线程间的通信

在平时的开发当中，Handler最常见的用法就是用于线程之间的通信，特别是当我们在子线程中去处理耗时的任务，当任务完成之后，我们希望将结果发送到主线程中进行处理，那么就会使用到Handler，基本的思想如下图所示：


当我们在子线程中通过Handler放入在主线程中的循环队列时，那么主线程就会收到消息，之后，我们就可以在主线程中进行后续的处理，例如下面这样：

public class MainActivity extends AppCompatActivity {

    private Handler mHandler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
            Log.d("Handler", "HandleMessageThreadId=" + Thread.currentThread().getId());
        }
    };

    private void startThread() {
        new Thread() {
            @Override
            public void run() {
                super.run();
                Log.d("Handler", "ThreadId=" + Thread.currentThread().getId());
                mHandler.sendEmptyMessage(0);
            }
        }.start();
    }

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        Log.d("Handler", "MainThreadId=" + Thread.currentThread().getId());
        startThread();
    }
    
}

打印出上面的线程Id，可以看到最后handleMessage收到消息的时候是在主线程当中：

2.2 实现延时操作

除了线程间的通信之外，我们还可以通过Handler提供的sendXXXDelay方法，实现延时操作，延时操作有两种目的：

  • 一种是希望让不那么紧急的任务延后执行，例如在应用启动过程中，我们在onCreate方法中的任务不是那个紧急，那么可以通过Handler发送一个延时消息出去，让它不占用主线程去渲染布局的资源，从而提高应用的启动速度。
  • 另一种就是防抖动操作，我们收到一个命令，并不是马上执行它，而是通过Handler的sendxxxDelay方法延时，如果在这段事件内又有一个相同的命令来到了，那么就把之前的消息移除，再放入一个新的延时消息。
    例如下面的例子，当我们点击一个按钮之后，我们不立刻执行任务，而是一段时间之后仍然没有收到第二次点击事件采取执行任务：
    private Handler mDelayHandler = new Handler() {

        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            Log.d("Handler", "handleMessage");
        }

    };

    private void performClickDelay() {
        Log.d("Handler", "performClickDelay");
        mDelayHandler.removeMessages(1);
        mDelayHandler.sendEmptyMessageDelayed(1, 500);
    }

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        mTv = (TextView) findViewById(R.id.tv);
        mTv.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                performClickDelay();
            }
        });
    }

我们连续多次点击按钮之后，只收到了一次消息：


2.3 使用HandlerThread在异步线程执行耗时操作

由于Looper其实是线程的一个私有变量（ThreadLocal），主线程可以有Looper，子线程同样也可以有Looper，只不过从子线程中的Looper中的MessageQueue中取出消息之后，是在子线程当中处理的，那么我们就可以通过它来执行异步操作，其基本思想如下图所示：


HandlerThread就是基于这一思想来实现的，关于HandlerThread的内部实现，可以参考之前的这篇文章 Android 异步任务知识梳理(2) - HandlerThread 源码解析，它的本质就是当异步线程启动之后，会初始化这个线程私有的Looper，因此，当我们通过HandlerThread中的getLooper()方法获得这个Looper之后，在通过这个Looper来创建一个Handler，那么这个Handler的handleMessage回调时所在的线程就是这个异步线程。

下面是一个简单的事例：

    private void useHandlerThread() {
        final HandlerThread handlerThread = new HandlerThread("handlerThread");
        System.out.println("MainThreadId=" + Thread.currentThread().getId() + ",handlerThreadId=" + handlerThread.getId());
        handlerThread.start();
        MyHandler handler = new MyHandler(handlerThread.getLooper());
        handler.sendEmptyMessage(0);
    }

    private class MyHandler extends Handler {

        MyHandler(Looper looper) {
            super(looper);
        }

        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            System.out.println("handleMessageThreadId=" + Thread.currentThread().getId());
        }
    }

我们打印出handleMessage的执行时的线程ID，可以看到它就是HandlerThread的线程ID，因此我们就可以通过发送消息的方式，在异步线程执行一些耗时的操作：

2.4 使用AsyncQueryHandler对ContentProvider进行操作

如果你的本地数据使用ContentProvider封装的，那么对这些数据的增删改查操作，为了不影响主线程，应该在子线程中进行操作，而AsyncQueryHandler就是系统为我们提供的很方便的工具类，它通过Handler + HandlerThread的方式，实现了异步的增删改查。

它是在HandlerThread的基础之上扩展出来的，其基本思想如下图所示，这一框架就保证了发起命令和接收回调是在同一个线程，而任务的执行则是在另一个线程：


具体的实现原理可以参考这篇文章 Android 异步任务知识梳理(3) - AsyncQueryHandler 源码解析。

当然AsyncQueryHandler限制了只能操作通过ContentProvider封装的数据，我们可以参考它的思想，进行扩展，实现对于数据库的增删改查。

2.5 使用Handler机制检测应用中的卡顿问题

对于每个应用程序来说，它的入口函数为ActivityThread中的main()方法：

   public static void main(String[] args) {
        //...
        Looper.prepareMainLooper();
        //...
        Looper.loop();
        throw new RuntimeException("Main thread loop unexpectedly exited");
    }

而在main()函数的最后，则构建一个在主线程中的循环队列，之后应用程序收到的事件之后，还主线程就会被唤醒，进行事件的处理，假如这一处理的事件过长，那么就会发生ANR，因此，我们就可以通过计算主线程中对于单次消息的处理时间，从而间隔地判断是否存在卡顿问题。
那么要怎么知道主线程中单次消息的处理时间呢，我们查看Looper的源码：

public static void loop() {
        final Looper me = myLooper();
        if (me == null) {
            throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
        }
        final MessageQueue queue = me.mQueue;

        // Make sure the identity of this thread is that of the local process,
        // and keep track of what that identity token actually is.
        Binder.clearCallingIdentity();
        final long ident = Binder.clearCallingIdentity();

        for (;;) {
            Message msg = queue.next(); // might block
            if (msg == null) {
                // No message indicates that the message queue is quitting.
                return;
            }

            // This must be in a local variable, in case a UI event sets the logger
            final Printer logging = me.mLogging;
            if (logging != null) {
                logging.println(">>>>> Dispatching to " + msg.target + " " +
                        msg.callback + ": " + msg.what);
            }

            final long traceTag = me.mTraceTag;
            if (traceTag != 0 && Trace.isTagEnabled(traceTag)) {
                Trace.traceBegin(traceTag, msg.target.getTraceName(msg));
            }
            try {
                msg.target.dispatchMessage(msg);
            } finally {
                if (traceTag != 0) {
                    Trace.traceEnd(traceTag);
                }
            }

            if (logging != null) {
                logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
            }

            // Make sure that during the course of dispatching the
            // identity of the thread wasn't corrupted.
            final long newIdent = Binder.clearCallingIdentity();
            if (ident != newIdent) {
                Log.wtf(TAG, "Thread identity changed from 0x"
                        + Long.toHexString(ident) + " to 0x"
                        + Long.toHexString(newIdent) + " while dispatching to "
                        + msg.target.getClass().getName() + " "
                        + msg.callback + " what=" + msg.what);
            }

            msg.recycleUnchecked();
        }
    }

对于消息的处理对应这句：

msg.target.dispatchMessage(msg);

而在这句话的前后，则调用了Printer类打印，那么我们就可以通过这两次打印的之间的时长来获得单次消息的处理时间。

public class MainLoopMonitor {

    private static final String MSG_START = ">>>>> Dispatching";
    private static final String MSG_END = "<<<<< Finished";
    private static final int TIME = 1000;
    private Handler mExecuteHandler;
    private Runnable mExecuteRunnable;

    private static class Holder {
        private static final MainLoopMonitor INSTANCE = new MainLoopMonitor();
    }

    public static MainLoopMonitor getInstance() {
        return Holder.INSTANCE;
    }

    private MainLoopMonitor() {
        HandlerThread monitorThread = new HandlerThread("LooperMonitor");
        monitorThread.start();
        mExecuteHandler = new Handler(monitorThread.getLooper());
        mExecuteRunnable = new ExecutorRunnable();
    }

    public void startMonitor() {
        Looper.getMainLooper().setMessageLogging(new Printer() {
            @Override
            public void println(String x) {
                if (x.startsWith(MSG_START)) {
                    mExecuteHandler.postDelayed(mExecuteRunnable, TIME);
                } else if (x.startsWith(MSG_END)) {
                    mExecuteHandler.removeCallbacks(mExecuteRunnable);
                }
            }
        });
    }
    
    private class ExecutorRunnable implements Runnable {

        @Override
        public void run() {
            StringBuilder sb = new StringBuilder();
            StackTraceElement[] stackTrace = Looper.getMainLooper().getThread().getStackTrace();
            for (StackTraceElement s : stackTrace) {
                sb.append(s).append("\n");
            }
            System.out.println("MainLooperMonitor:" + sb.toString());
        }
    }
}

假如我们像下面这样，在主线程中进行了耗时的操作：

public void anrButton(View view) {
        for (int i = 0; i < (1 << 30); i++) {
            int b = 6;
        }
}

那么就会打印出下面的堆栈信息：


三、Handler 使用注意事项

在介绍完Handler的这些用法，我们再来总结一下使用Handler是比较容易犯的一些错误。

3.1 内存泄漏

一个比较常见的错误就是将定义Handler的子类时将它作为Activity的内部类，而由于内部类会默认持有外部类的引用，因此，如果这个内部类的实例在Activity试图被回收的时候，没有被销毁掉，那么就会导致Activity无法被回收，从而引起内存泄漏。

而Handler实例无法被销毁掉最常见的情况就是，我们通过它发送了一个延时消息出去，此时这个消息会被放入到该线程所对应的Looper中的MessageQueue当中，而该消息为了能在得到执行之后，回调到对应的Handler，因此它会持有这个Handler的实例。

从引用链的角度来看就是下面的情况：


这个大家见得很多，就不多举例子了。

3.2 在子线程中实例化 new Handler()

在子线程中new Handler()有下面两个需要注意的点：

(1) 在 new Handler() 之前调用 Looper.prepare() 方法

另外一个错误就是我们在子线程当中，直接调用new Handler()，那么这时候会抛出异常，例如下面这样：

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_handler);
        new Thread() {

            @Override
            public void run() {
                mHandler = new MyHandler();
            }

        }.start();
    }

抛出的异常为：


原因是在Handler的构造函数中，会去检查当前线程的Looper是否已经被初始化：

    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;
        mAsynchronous = async;
    }

如果没有，那么就会抛出上面代码当中的异常，正确的做法，是需要保证我们在new Handler之前，要保证当前线程的Looper对象已经被初始化，也就是Looper当中的下面这个方法被调用：

     /** Initialize the current thread as a looper.
      * This gives you a chance to create handlers that then reference
      * this looper, before actually starting the loop. Be sure to call
      * {@link #loop()} after calling this method, and end it by calling
      * {@link #quit()}.
      */
    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));
    }

(2) 如果希望通过该 Looper 接收消息那么要调用 Looper.loop() 方法，并且需要放在最后一句调用

假如我们只调用了prepare()方法，仅仅只是初始化了一个线程的私有的变量，此时是无法通过这个Looper构建的Handler来接收消息的，例如下面这样：

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_handler);
        new Thread() {

            @Override
            public void run() {
                Looper.prepare();
                mHandler = new MyHandler();
            }
            
        }.start();
    }

    public void anrButton(View view) {
        mHandler.sendEmptyMessage(0);
    }

    private static class MyHandler extends Handler {

        @Override
        public void handleMessage(Message msg) {
            Log.e("TAG", "handleMessageId=" + Thread.currentThread().getId());
        }
    }

此时我们应当调用loop方法让这个循环队列开始工作，并且该调用一定要位于最后一句，因为一旦调用了loop方法，那么它就会进入等待 -> 收到消息 -> 唤醒 -> 处理消息 -> 等待的循环过程，而这一过程只有等到loop方法返回的时候才会结束，因此，我们初始化Handler的语句要放在loop方法之前，类似于下面这样：

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_handler);
        new Thread() {

            @Override
            public void run() {
                Looper.prepare();
                mHandler = new MyHandler();
                //最后一句再调用
                Looper.loop();
            }

        }.start();
    }

四、小结

Handler的机制似乎已经成为面试必问的题目，如果大家能在回答完内部的实现原理，再根据这些实现原理引申出上面的几个应用和注意事项，可以加分不少哦~

更多文章，欢迎访问我的 Android 知识梳理系列：

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 204,293评论 6赞 478
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 85,604评论 2赞 381
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 150,958评论 0赞 337
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 54,729评论 1赞 277
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 63,719评论 5赞 366
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 48,630评论 1赞 281
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 38,000评论 3赞 397
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,665评论 0赞 258
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 40,909评论 1赞 299
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,646评论 2赞 321
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,726评论 1赞 330
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,400评论 4赞 321
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 38,986评论 3赞 307
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,959评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,197评论 1赞 260
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 44,996评论 2赞 349
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,481评论 2赞 342

推荐阅读更多精彩内容