Android Handler機制詳解原理

Posted on by

Looper是整個跨線程通信的管理者

    // 內部持有的變量如下：
    ThreadLocal<Looper>
    MainLooper
    Observer
    MessageQueue
    Thread

1.首先先回憶一下Handler怎麼用

Android線程通信分為以下兩種情況

  • 1.子線程發消息給UI線程
  • 2.UI線程發消息給子線程
  • 3.子線程發消息給另個子線程

1.子線程發消息給UI線程

class FragmentContentActivity : AppCompatActivity() {
    val FLAG = 1
    lateinit var handler: Handler
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        handler = object : Handler(Looper.getMainLooper()) {
            override fun handleMessage(msg: Message) {
                when (msg.what) {
                    FLAG -> {
                        findViewById<TextView>(R.id.text).text = msg.data["Text"].toString()
                    }
                }
            }
        }
        thread {
            Thread.sleep(2000L)
            handler.sendMessage(Message.obtain().apply {
                what = FLAG
                data = Bundle().apply {
                    this.putString("Text", "ThreadMessage")
                }
            })
        }
    }
}

2.UI線程/子線程發消息給子線程

class FragmentContentActivity : AppCompatActivity() {
    val THREAD_FLAG =2
    lateinit var threadHandler: Handler
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        thread {
            Looper.prepare()
            threadHandler = object :Handler(Looper.myLooper()!!){
                override fun handleMessage(msg: Message) {
                    when(msg.what){
                        THREAD_FLAG -> {
                            Toast.makeText(
                                this@FragmentContentActivity,
                                "${msg.data["Text"]}",
                                Toast.LENGTH_SHORT
                            ).show()
                        }
                    }
                }
            }
            Looper.loop()
        }
    }

    override fun onResume() {
        super.onResume()
        findViewById<TextView>(R.id.text).postDelayed({
           threadHandler.sendMessage(Message.obtain().apply {
               what = THREAD_FLAG
               data = Bundle().apply {
                   putString("Text","UI Message")
               }
           })
        },2000L)
    }
}

**在子線程的使用中，我們發現必須要進行Looper.prepare()和Looper.loop()前後這兩個操作，因此，帶著這個疑問來看一下Looper的邏輯
**

// 在調用prepare()之後一定要調用loop(),最後結束消息循環的時候調用quit()
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();
}

prepare()就是將初始化一個Looper對象放入到ThreadLocal中，初始化Looper，同時mQueue

    public static void loop(){
    
    Binder.clearCallingIdentity()
for (;;) {
    Message msg = queue.next(); // might block
 
    long origWorkSource = ThreadLocalWorkSource.setUid(msg.workSourceUid);
    try {
        // 其實 loop()隻做瞭這一個調用，其他的都是監控當前消息循環時間是否超時，應該和ANR有關
        msg.target.dispatchMessage(msg);
        if (observer != null) {
            observer.messageDispatched(token, msg);
        }
        dispatchEnd = needEndTime ? SystemClock.uptimeMillis() : 0;
    } catch (Exception exception) {
        if (observer != null) {
            observer.dispatchingThrewException(token, msg, exception);
        }
        throw exception;
    } finally {
        ThreadLocalWorkSource.restore(origWorkSource);
        if (traceTag != 0) {
            Trace.traceEnd(traceTag);
        }
    }
    if (logSlowDelivery) {
        if (slowDeliveryDetected) {
            if ((dispatchStart - msg.when) <= 10) {
                Slog.w(TAG, "Drained");
                slowDeliveryDetected = false;
            }
        } else {
            if (showSlowLog(slowDeliveryThresholdMs, msg.when, dispatchStart, "delivery",
                    msg)) {
                // Once we write a slow delivery log, suppress until the queue drains.
                slowDeliveryDetected = true;
            }
        }
    }
    if (logSlowDispatch) {
        showSlowLog(slowDispatchThresholdMs, dispatchStart, dispatchEnd, "dispatch", msg);
    }
    //消息實體回收
    msg.recycleUnchecked();

可以看到Looper.loop其實隻是在for循環中，獲取mQueue的下一個msg節點，然後調用msg.target.dispatchMessage(msg)。乍看隻是msg對象內部的操作。

因為loop()其實邏輯上算死循環，這意味著，當前線程的自發的順序執行命令到此結束瞭，隻能通過其他線程觸發handler機制，來被動的在當前線程執行命令，當前線程完全變成瞭一個響應線程

Looper類隻是初始化並開啟線程死循環的一個開關，具體工作在MessageQueue中進行

MessageQueue 消息隊列

隊列內消息的添加不是直接調用MessageQueue，而是由與Looper相關聯的Handler調用

MessageQueue的內部持有的變量如下： ArrayList mMessages SparseArray IdleHandler[] mBlocked

MessageQueue類的功能主要有：元素插入隊列，獲取隊列的頭部元素，查找隊列中元素，綜述就是對隊列的增刪改查，其中 mMessage就是這個隊列的入口也是這個隊列的頭結點

  boolean enqueueMessage(Message msg,long when) //msg 元素插入隊列
  boolean hasMessages(Handler h,int what,Object object) //查找handler下的msg.what/object相同的Msg
  boolean hasEqualMessages(Handler h,int what,Object obj)//查找 msg.object.equal(obj)的msg
  removeMessages(Handler h,int what,Object obj)/(Handler h,Runnable r,Object obj)
  removeEqualMessages(...) //刪除與參數msg.object相同或equal的msg
  
  Message next() //獲取隊列中的頭部元素

可以看出，這些方法內部都調用瞭 synchronized(this),隊列的操作都是線程同步的

Message next() ->
...

// linux機制下的總線進入輪詢，線程相當於掛起狀態，nextPollTimeOut是掛起多長時間
nativePollOnce(ptr, nextPollTimeoutMillis);

synchronized (this) {

   final long now = SystemClock.uptimeMillis();
   Message prevMsg = null;
   Message msg = mMessages;
   //先判斷msg.target是否為null，表示當前消息是不是異步消息
   if (msg != null && msg.target == null) {
   // Stalled by a barrier.  Find the next asynchronous message in the queue.
   //同步屏障：取出當前隊列中的異步消息
   do {
       prevMsg = msg;
       msg = msg.next;
       } while (msg != null && !msg.isAsynchronous());
   }
   if (msg != null) {
       if (now < msg.when) {
           // Next message is not ready.  Set a timeout to wake up when it is ready.
           //重新計算線程進入掛起狀態的時間
           nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
       } else {
           // Got a message.
               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;
       }
   } else {
   // No more messages.
       nextPollTimeoutMillis = -1;
}
...

可以看出next()內部主要有兩種獲取msg的邏輯

1.當前消息都是普通消息，按照msg.when的大小排序，每一次循環執行，通過檢測when是否大於now來決定是否獲取msg，或是掛起當前線程。
2.當前消息中有異步消息，優先獲取msg.isAsynchronous()==true的，或者按照此異步消息的等待時間，來重新設置掛起線程的時間，從而達到精準的獲取異步消息。

通俗的來講就是說，當前所有普通消息按照預約的執行時間的先後來排隊，這樣可基本上既可以達到按照預約時間執行消息，也可以最大效率的在一定時間段內執行最多的消息，但是這忽略瞭每個消息的執行消耗的時間，比如A消息是隊列內的No.1,A消息預約執行時間是1s之後，整個隊列是等待狀態的，這個時候來瞭B消息，B消息預約的時間是0.999s之後，按照預約時間的排隊機制，B消息要插隊到A消息之前，B成瞭這個隊列的No.1，A成瞭No.2,整個隊列的等待時間還是1s(因為之前設置瞭等待時間，所以不用喚醒)，但是B消息的執行過程長達0.5s，已經超過瞭之後的很多消息的預約執行時間點瞭，這樣就不能保證某些重要的消息按時執行。

於是就有瞭異步消息同步屏障的機制，這相當於普通消息排隊時來瞭一個VIP消息，先按照預約時間找到自己的位置，然後大喝一聲：“都把腳給我挪開，我的前面不允許有人”，這個時候排在他之前的普通消息就隻能全部挪到隊列的一邊，然後隊列重新按照這位VIP消息，設置等待時間，期間新來的普通消息也插到隊邊等待，保證精準按時執行VIP消息。等VIP消息執行完，之後再把之前等待普通消息的隊列合並執行。當然之前等待的消息全耽誤瞭，但畢竟是普通消息不重要。

 // 同步屏障的方法，此方法隻在 ViewRootImpl類中調用
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;
        //沒有設置target
        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變為同步屏障消息，next()下一次循環，首先獲取到的是同步屏障
            mMessages = msg;
        }
        return token;
    }
    // ViewRootImpl
 void scheduleTraversals() {
        if (!mTraversalScheduled) {
        mTraversalScheduled = true;
        mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
        mChoreographer.postCallback(
                Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
        if (!mUnbufferedInputDispatch) {
            scheduleConsumeBatchedInput();
        }
        notifyRendererOfFramePending();
        pokeDrawLockIfNeeded();
    }
    
//設置同步屏障之後，通過設置瞭Aysnc標記位的Handler發送的Msg都是異步消息，
//MessageQueue也優先處理此類異步消息，直到移除同步屏障標記位，再恢復到普通消息隊列。

由此可見，同步屏障的設置和View刷新機制有關，因為要保證Vsync信號按時完成刷新操作，具體分析待續…
綜述，異步消息可以保證精準的執行，但也因此消息事件的先後順序被打亂，有可能在代碼執行中執行瞭Handler.sendMsg(1,time0.2)->AsyncHandler.sendMsg(2,time0.5),但是實際執行的是 2->1。

再看Handler
Handler的成員變量如下

mLooper ：初始化時獲取當前線程的Looper對象引用 mQueue ：通過Looper.mQueue 獲取到的MessageQueue隊列引用mAsynchronous ：標記當前Handler是否發送異步消息 mCallback : Handler自身的callback接口，此callback調用在Message.callback之前mMessenger ：IMessager 和進程通信相關

以上成員變量大都是final類型，表示Handler也是在其使用上也是final類型，也就是說，沒有辦法通過將Handler與context的生命周期相剝離來避免內存泄漏

Handler的方法如下

    //Handler 發送Message第一種方法，設置Message的what，data
    //不設置 runnable：Callback 
    boolean sendMessage(Message msg) -> boolean sendMessageDelayed(Message msg,long delayTime)
    -> boolean sendMessageAtTime(Message msg，SystemClock.uptimeMillis()+delayTime)
    -> mQueue.enqueueMessage(msg,uptime)
    //第二種方法，Message隻設置runnable:Callback
    boolean postAtTime(Runnable r,Object token，long uptime)
    -> sendMessageAtTime(getPostMessage(r,token),uptime)
    --> Message getPostMessage(Runnable r,Object token){
        Message.obtain().callback=r
        ...
        }
   //移除Message和檢驗Message
   removeMessages() 
   hasMessages()
   ...
   //Message 回調執行
   void dispatchMessage(Message msg){
       if(msg.callback!=null){
           handleCallback(msg) ->
       }else{
           if(mCallback!=null){
            mCallback.handleMessage(msg)
           }
           handleMessage(msg)
   }
   //可以看到 Message的回調分為三個等級
   //No.1 msg自身的callback
   //No.2 Handler自身的mCallback成員變量，mCallback是final類型
   //No.3 Handler的子類重載的handleMessage方法

Message

Message 實現瞭Parcelable接口，也就是說可以作為進程間通信的載體

Message成員變量如下

    int what //Handler發送主體下的Message的消息碼
    int arg1 //低成本的參數傳遞
    int arg2 
    Object obj //可以為空的token對象，一般在進程通信中用到
    Bundle data //線程通信中常用的參數容器
    Handler target //發送主體
    Runnable callback //Message自身回調
    Messenger replyTo   //進程通信，一般在AMS中用到
    ------
    // Message緩存池相關
    Object sPoolSync = new Object() // 同步標記
    Messsage next 
    static Message sPool
    static int sPoolSize

Message方法如下

    //可以看出這是一個非常巧妙的方法
    static Message obtain(){
        synchronized(sPoolsSync){
            if(sPools!=null){
                Message m= sPool;
                sPool = m.next;
                m.next = null;
                sPoolSize--;
                return m;
              }
        }
        return new Message();
    }
    //主體上是一個帶緩存池鏈表的同步工廠模式，同時也考慮到較多線程阻塞時
    //可以直接聲明初始化對象
    
    //回收Message對象到緩存池鏈表
    void recycleUnchecked(){
        ...參數=null
        synchronized(sPoolSync){
            if(sPoolSize < MAX_SIZE){
                next = sPool;
                sPools = this;
                sPoolSize++;
          }
       }
    }

到此這篇關於Android Handler機制詳解原理的文章就介紹到這瞭,更多相關Android Handler內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

推薦閱讀：