Handler机制之源码解析

Handler源码解析

刚入行Android那会,看过好多遍这方面的不同的博客,每次看完都似懂非懂,今天我打算自己来分析一下Handler机制及其相关源码。

主要涉及以下几个类:

  1. Handler
  2. MessageQueue
  3. Looper
  4. Message

看一下官方对Handler这个类的解释:Handler允许你向其发送Message或者是post Runnable,一个Handler只能绑定一个线程以及线程对应的MessageQueue。当我们创建一个新的Handler的时候,它就和创造它的时候所在的线程以及线程对应的MessageQueue绑定了,它将用来将messages和runnables传送给MessageQueue,以及执行他们当他们从MessageQueue队列中被pop出来的时候。

Handler有两种用处:一是用来执行同一线程中的messages以及runnables,二是在另一个线程中执行。
发送消息的方式有很多种,主要是由以下方法来完成的:
一类是post runnable
post
postAtTime
postDelayed
一类是send message
sendEmptyMessage
sendMessage
sendMessageAtTime
sendMessageDelayed

这些方法能够让你控制是现在执行,还是需要延迟多长时间来执行。

当我们开启一个应用时,即开启了一个进程,应用的主线程就会开启一个MessageQueue队列用来管理最重要的一些对象,如Activity和广播,你可以创建一个子线程,通过Handler来与主线程或者应用来进行通信,当合适的时候,这些runnable或者message会被执行。

通过大概翻译官方注释,我们可以发现Handler主要是用来做线程间通信的,分析Handler我们主要分析上面提到的两类方法:1.post runnable 2.send message

我们先分析send 系列方法:

  通过查看源码,我们可以发现,不论是sendMessage,还是sendMessageDelayed还是sendEmptyMessage,最终都会调用sendMessageAtTime方法。这里面涉及到一个Message对象,我们稍后来分析,最终会走到enqueueMessage方法,enqueueMessage方法会走到MessageQueue里面的enqueueMassage。待会我们一起分析。

我们再来看post runnable系列方法:

  通过查看源码,我们可以发现,最终也是走到sendMessageAtTime方法,然后调用enqueueMessage。只不过,在这个过程中,创建了一个Message实例,并将runnable赋给了message的callback。

Handler我们先分析到这里。

下面我们来分析Message这个类:

Message这个类的数据结构可以说是一个单链表,它有几个重要的成员变量:

  1. next 指向链表下一item的引用
  2. what 用来区别是哪一类消息,相当于一个type
  3. target 用来保存所属Handler的引用
  4. callback 用来保存要执行的任务runnable

其他还包括arg1,arg2 ,object等,这些就不一一解释了

Message类还有一个重要方法:obtain。

当我们创建一个Message对象时,我们可以new,也可以通过Message.obtain方法来获取一个实例。官方推荐后者,

/**
     * Return a new Message instance from the global pool. Allows us to
     * avoid allocating new objects in many cases.
     */
    public static Message obtain() {
        synchronized (sPoolSync) {
            if (sPool != null) {
                Message m = sPool;
                sPool = m.next;
                m.next = null;
                m.flags = 0; // clear in-use flag
                sPoolSize--;
                return m;
            }
        }
        return new Message();
    }

意思就是说,这种方式能够避免重复创建新对象。从代码可以看出,只有当Message回收池为空的时候才会去new一个Message。那么这个Message回收池是什么时候建立的呢,以及什么时候往里面放对象的呢?我们找到recycleUnchecked这个方法,可以发现这个方法就是将Message的flag置为FLAG_IN_USE,并且清空其他参数,并将其加入到缓存池。这个方法是在MessageQueue执行enqueueMessage的时候才会调用。

下面我们来分析MessageQueue这个类:

首先,看它的构造,除了传了一个参数,其它的都在native处理了,我们也看不见什么,感兴趣的可以去看一下native层代码。

再看一下MessageQueue的数据结构,我们可以发现它其实是一个优先级队列。

队列的插入以及移除item有两个重要方法:

第一个是我么上面提到的enqueueMessage方法:这个方法主要是向队列中插入Message对象:

    boolean enqueueMessage(Message msg, long when) {
        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) {
                IllegalStateException e = new IllegalStateException(
                        msg.target + " sending message to a Handler on a dead thread");
                Log.w(TAG, e.getMessage(), e);
                msg.recycle();
                return false;
            }

            msg.markInUse();
            msg.when = when;
            Message p = mMessages;
            boolean needWake;
            if (p == null || when == 0 || when < p.when) {
                //这里是向头部插入
                // New head, wake up the event queue if blocked.
                msg.next = p;
                mMessages = msg;
                needWake = mBlocked;
            } else {
                //这里是往中间插入,循环链表触发时间,找到对应的插入位置
                // Inserted within the middle of the queue.  Usually we don't have to wake
                // up the event queue unless there is a barrier at the head of the queue
                // and the message is the earliest asynchronous message in the queue.
                needWake = mBlocked && p.target == null && msg.isAsynchronous();
                Message prev;
                for (;;) {
                    prev = p;
                    p = p.next;
                    if (p == null || when < p.when) {
                        break;
                    }
                    if (needWake && p.isAsynchronous()) {
                        needWake = false;
                    }
                }
                msg.next = p; // invariant: p == prev.next
                prev.next = msg;
            }

            // We can assume mPtr != 0 because mQuitting is false.
            if (needWake) {
                nativeWake(mPtr);
            }
        }
        return true;
    }

第二个就是MessageQueue的next方法,这个方法主要处理的是MessageQueue的出队操作,即从队头开始一个个执行移除.代码太多,就不贴过来了,主要部分就是指针后移:

mBlocked = false;
if (prevMsg != null) {
    prevMsg.next = msg.next;
    } else {
      mMessages = msg.next;
   }
    msg.next = null;
    if (DEBUG) Log.v(TAG, "Returning message: " + msg);
    msg.markInUse();
    return msg;

那么,什么时候才会执行next的方法呢?这就得来到Looper这个类了.

Looper这个类,每个线程都只有一个,跟线程绑定.我们看一下他的主要方法:

 public static void loop() {
        final Looper me = myLooper();
      

        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 slowDispatchThresholdMs = me.mSlowDispatchThresholdMs;

            final long traceTag = me.mTraceTag;
            if (traceTag != 0 && Trace.isTagEnabled(traceTag)) {
                Trace.traceBegin(traceTag, msg.target.getTraceName(msg));
            }
            final long start = (slowDispatchThresholdMs == 0) ? 0 : SystemClock.uptimeMillis();
            final long end;
            try {
                msg.target.dispatchMessage(msg);
                end = (slowDispatchThresholdMs == 0) ? 0 : SystemClock.uptimeMillis();
            } finally {
                if (traceTag != 0) {
                    Trace.traceEnd(traceTag);
                }
            }
            if (slowDispatchThresholdMs > 0) {
                final long time = end - start;
                if (time > slowDispatchThresholdMs) {
                    Slog.w(TAG, "Dispatch took " + time + "ms on "
                            + Thread.currentThread().getName() + ", h=" +
                            msg.target + " cb=" + msg.callback + " msg=" + msg.what);
                }
            }

            msg.recycleUnchecked();
        }
    }

从上面的代码可以发现,loop差不多就是一个死循环,只有当MessageQueue为空的时候,才会退出.Looper当中有两个重要的地方:

第一个是 Message msg = queue.next(),从队列中取出一个Message,
第二个是 Message msg = queue.next(),这个方法最终会调用message对应handler的dispatchMessage方法
public void dispatchMessage(Message msg) {
        if (msg.callback != null) {
            handleCallback(msg);
        } else {
            if (mCallback != null) {
                if (mCallback.handleMessage(msg)) {
                    return;
                }
            }
            handleMessage(msg);
        }
    }

当msg的callback不为空时,执行callback.run,如果为空的话则判断在创建Handler的时候有没有给mCallback赋值,如果有,则走mCallback里面的handleMessage方法,如果没有则走Handler的handleMessage方法.

但是,在实际开发当中,我们发现我们并没有创建Looper,也没有调用Looper的loop方法,为什么也能够执行到我们重写的handleMessage方法呢?

这是因为,我们一般是在主线程即UI线程中创建的Handler,而在主线程中是默认创建了Looper的.看代码:

 public static void main(String[] args) {
        

        Looper.prepareMainLooper();

        ActivityThread thread = new ActivityThread();
        thread.attach(false);

        if (sMainThreadHandler == null) {
            sMainThreadHandler = thread.getHandler();
        }

        if (false) {
            Looper.myLooper().setMessageLogging(new
                    LogPrinter(Log.DEBUG, "ActivityThread"));
        }

        // End of event ActivityThreadMain.
        Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
        Looper.loop();

        throw new RuntimeException("Main thread loop unexpectedly exited");
    }

这段代码是截取自ActivityThread的main函数,在我们应用启动的时候,就执行了这个函数.

至此,我们把Handler机制的重要代码都分析完了!!

总结一下:画个图,看懂你就赢了

Handler机制.png
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 217,185评论 6 503
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,652评论 3 393
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 163,524评论 0 353
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,339评论 1 293
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,387评论 6 391
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,287评论 1 301
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,130评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,985评论 0 275
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,420评论 1 313
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,617评论 3 334
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,779评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,477评论 5 345
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,088评论 3 328
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,716评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,857评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,876评论 2 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,700评论 2 354

推荐阅读更多精彩内容