說說Android的UI刷新機制的實現(xiàn)

更新時間：2020年03月10日 10:35:05 作者：Raina

這篇文章主要介紹了說說Android的UI刷新機制的實現(xiàn)，文中通過示例代碼介紹的非常詳細，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧

本文主要解決以下幾個問題：

我們都知道Android的刷新頻率是60幀/秒，這是不是意味著每隔16ms就會調(diào)用一次onDraw方法？
如果界面不需要重繪，那么16ms到后還會刷新屏幕嗎？
我們調(diào)用invalidate()之后會馬上進行屏幕刷新嗎？
我們說丟幀是因為主線程做了耗時操作，為什么主線程做了耗時操作就會引起丟幀？
如果在屏幕快要刷新的時候才去OnDraw（）繪制，會丟幀嗎？

好了，帶著以上問題，我們進入源碼來找尋答案。

一、屏幕繪制流程

屏幕繪制機制的基本原理可以概括如下：

整個屏幕繪制的基本流程是：

應(yīng)用向系統(tǒng)服務(wù)申請buffer
系統(tǒng)服務(wù)返回buffer
應(yīng)用繪制后提交buffer給系統(tǒng)服務(wù)

如果放到Android中來，那么就是：

在Android中，一塊Surface對應(yīng)一塊內(nèi)存，當(dāng)內(nèi)存申請成功后，App端才有繪圖的地方。由于Android的view繪制不是今天的重點，所以這里點到為止~

二、屏幕刷新分析

屏幕刷新的時機是當(dāng)Vsync信號到來的時候，具體如圖：

在Android端，是誰在控制 Vsync 的產(chǎn)生？又是誰來通知我們應(yīng)用進行刷新的呢？在Android中， Vysnc 信號的產(chǎn)生是由底層 HWComposer 負責(zé)的，而通知應(yīng)用進行刷新，是Java層的 Choreographer ，Android整個屏幕刷新的核心就在于這個 Choreographer 。

下面我們結(jié)合代碼一起來看一下。

每次當(dāng)我們要進行ui重繪的時候，都會調(diào)用 requestLayout() ，所以，我們從這個方法入手：

2.1 requestLayout()

----》類名:ViewRootImpl

  @Override
  public void requestLayout() {
    if (!mHandlingLayoutInLayoutRequest) {
      checkThread();
      mLayoutRequested = true;
      //重點
      scheduleTraversals();
    }
  }

2.2 scheduleTraversals()

----》類名:ViewRootImpl

  void scheduleTraversals() {
    if (!mTraversalScheduled) {
      mTraversalScheduled = true;
      mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
      mChoreographer.postCallback(
          Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
      ......
    }
  }

可以看到，在這里并沒有立即進行重繪，而是做了兩件事情：

往消息隊列里面插入一條SyncBarrier（同步屏障）
通過Cherographer post了一個callback

接下來，我們簡單說一下這個 SyncBarrier （同步屏障）。

異步屏障的作用在于：

阻止同步消息的執(zhí)行
優(yōu)先執(zhí)行異步消息

為什么要設(shè)計這個 SyncBarrier 呢？主要原因在于，在Android中，有些消息是十分緊急的，需要馬上執(zhí)行，如果說消息隊列里面普通消息太多的話，那等到執(zhí)行它的時候可能早就過了時機了。

到這里，可能有人會跟我一樣，覺得為什么不干脆在Message里搞個優(yōu)先級，按照優(yōu)先級來進行排序呢？弄個 PriorityQueue 不就完了嗎？

我自己的理解是，在Android中，消息隊列的設(shè)計是一個 單鏈表 ，整個鏈表的排序是根據(jù)時間進行排序的，如果此時再加入一個優(yōu)先級的排序規(guī)則，一方面會復(fù)雜會排序規(guī)則，另一方面，也會使得消息不可控。因為優(yōu)先級是可以用戶自己在外面填的，那樣不就亂套了嗎？如果用戶每次總填最高的優(yōu)先級，這樣就會導(dǎo)致系統(tǒng)消息很久才會消費，整個系統(tǒng)運作就會出問題，最后影響用戶體驗，所以，我自己覺得Android的同步屏障這個設(shè)計還是挺巧妙的~

好了，總結(jié)一下，執(zhí)行 scheduleTraversals() 后，會插入一個屏障，保證異步消息的優(yōu)先執(zhí)行。

插入一個小小的思考題：如果說我們在一個方法里連續(xù)調(diào)用了 requestLayout() 多次，那么請問：系統(tǒng)會插入多條屏障或者 post 多個 Callback 嗎？答案是不會，為什么呢？看到 mTraversalScheduled 這個變量了嗎？它就是答案~

2.3 Choreographer.postCallback()

先來簡單說一下 Choreographer ， Choreographer 中文翻譯叫 編舞者 ，它的主要作用是進行系統(tǒng)協(xié)調(diào)的。（大家可以上網(wǎng)google下實際工作中的編舞者，這個類名真的起的很貼切了~）

Choreographer 這個類是應(yīng)用怎么初始化的呢？是通過 getInstance() 方法：

 public static Choreographer getInstance() {
    return sThreadInstance.get();
  }
  
    // Thread local storage for the choreographer.
  private static final ThreadLocal<Choreographer> sThreadInstance =
      new ThreadLocal<Choreographer>() {
    @Override
    protected Choreographer initialValue() {
      Looper looper = Looper.myLooper();
      if (looper == null) {
        throw new IllegalStateException("The current thread must have a looper!");
      }
      Choreographer choreographer = new Choreographer(looper, VSYNC_SOURCE_APP);
      if (looper == Looper.getMainLooper()) {
        mMainInstance = choreographer;
      }
      return choreographer;
    }
  };

這里貼出來是為了提醒大家， Choreographer 不是單例，而是每個線程都有單獨的一份。

好了，回到我們的代碼：

 ----》類名:Choreographer
 //1
  public void postCallback(int callbackType, Runnable action, Object token) {
    postCallbackDelayed(callbackType, action, token, 0);
  }
 //2 
   public void postCallbackDelayed(int callbackType,
      Runnable action, Object token, long delayMillis) {
    ....
    postCallbackDelayedInternal(callbackType, action, token, delayMillis);
  }
  //3
   private void postCallbackDelayedInternal(int callbackType,
      Object action, Object token, long delayMillis) {
        ...
        mCallbackQueues[callbackType].addCallbackLocked(dueTime, action, token);
        if (dueTime <= now) {
        scheduleFrameLocked(now);
      } else {
        ...
       }
      }

Choreographer post的callback會放入 CallbackQueue 里面，這個 CallbackQueue 是一個單鏈表。

首先會根據(jù)callbackType得到一條 CallbackQueue 單鏈表，之后會根據(jù)時間順序，將這個callback插入到單鏈表中；

2.4 scheduleFrameLocked（）

 ----》類名:Choreographer
 private void scheduleFrameLocked(long now) {
    ...
    // If running on the Looper thread, then schedule the vsync immediately,
        // otherwise post a message to schedule the vsync from the UI thread
        // as soon as possible.
        if (isRunningOnLooperThreadLocked()) {
          scheduleVsyncLocked();
        } else {
          Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_VSYNC);
          msg.setAsynchronous(true);
          mHandler.sendMessageAtFrontOfQueue(msg);
        }
      } else {
        ...
      }
    }
  }

scheduleFrameLocked 的作用是：

如果當(dāng)前線程就是 Cherographer 的工作線程的話，那么就直接執(zhí)行 scheduleVysnLocked
否則，就發(fā)送一個異步消息到消息隊列里面去，這個異步消息是不受同步屏障影響的，而且這個消息還要插入到消息隊列的頭部，可見這個消息是非常緊急的

跟蹤源代碼，我們發(fā)現(xiàn)，其實 MSG_DO_SCHEDULE_VSYNC 這條消息，最終執(zhí)行的也是 scheduleFrameLocked 這個方法，所以我們直接跟蹤 scheduleVsyncLocked() 這個方法。

2.5 scheduleVsyncLocked()

 ----》類名:Choreographer
 
  private void scheduleVsyncLocked() {
    mDisplayEventReceiver.scheduleVsync();
  }
  
 ----》類名:DisplayEventReceiver
 
    public void scheduleVsync() {
    if (mReceiverPtr == 0) {
      Log.w(TAG, "Attempted to schedule a vertical sync pulse but the display event "
          + "receiver has already been disposed.");
    } else {
    //mReceiverPtr是Native層一個類的指針地址
    //這里這個類指的是底層NativeDisplayEventReceiver這個類
    //nativeScheduleVsync底層會調(diào)用到requestNextVsync（）去請求下一個Vsync，
    //具體不跟蹤了，native層代碼更長，還涉及到各種描述符監(jiān)聽以及跨進程數(shù)據(jù)傳輸
      nativeScheduleVsync(mReceiverPtr);
    }
  }

這里我們可以看到一個新的類： DisplayEventReceiver ,這個類的作用是注冊Vsync信號的監(jiān)聽，當(dāng)下個Vsync信號到來的時候就會通知到這個 DisplayEventReceiver 了。

在哪里通知呢？源碼里注釋寫的非常清楚了：

 ----》類名:DisplayEventReceiver
 
  // Called from native code. <---注釋還是很良心的
  private void dispatchVsync(long timestampNanos, int builtInDisplayId, int frame) {
    onVsync(timestampNanos, builtInDisplayId, frame);
  }

當(dāng)下一個Vysnc信號到來的時候，會最終調(diào)用 onVsync 方法：

 public void onVsync(long timestampNanos, int builtInDisplayId, int frame) {
  }

點進去一看，是個空實現(xiàn)，回到類定義，原來是個抽象類，它的實現(xiàn)類是： FrameDisplayEventReceiver ,定義在 Cherographer 里面：

 ----》類名:Choreographer
 
private final class FrameDisplayEventReceiver extends DisplayEventReceiver
      implements Runnable {
      ....
      }

2.6 FrameDisplayEventReceiver.onVysnc()

 ----》類名:Choreographer
 
 private final class FrameDisplayEventReceiver extends DisplayEventReceiver
      implements Runnable {

    @Override
    public void onVsync(long timestampNanos, int builtInDisplayId, int frame) {
       ....
      mTimestampNanos = timestampNanos;
      mFrame = frame;
      Message msg = Message.obtain(mHandler, this);
      msg.setAsynchronous(true);
      mHandler.sendMessageAtTime(msg, timestampNanos / TimeUtils.NANOS_PER_MS);
    }

    @Override
    public void run() {
      ....
      doFrame(mTimestampNanos, mFrame);
    }
  }

onVsync 方法往 Cherographer 所在線程的消息隊列中發(fā)送的一個消息，這個消息是就是它自己（它實現(xiàn)了Runnable），所以最終會調(diào)用到 doFrame() 方法。

2.7 doFrame(mTimestampNanos, mFrame)

doFrame（）的處理分為兩個階段：

  void doFrame(long frameTimeNanos, int frame) {
    final long startNanos;
    synchronized (mLock) {
      //1、階段一
      long intendedFrameTimeNanos = frameTimeNanos;
      startNanos = System.nanoTime();
      final long jitterNanos = startNanos - frameTimeNanos;
      if (jitterNanos >= mFrameIntervalNanos) {
        final long skippedFrames = jitterNanos / mFrameIntervalNanos;
        if (skippedFrames >= SKIPPED_FRAME_WARNING_LIMIT) {
          Log.i(TAG, "Skipped " + skippedFrames + " frames! "
              + "The application may be doing too much work on its main thread.");
        }
        ...
      }
      ...
    }

frameTimeNanos 是當(dāng)前的時間戳，將當(dāng)前的時間和開始時間相減，得到這一幀處理花費了多長，如果大于 mFrameIntervalNano ，說明處理耗時了，之后就打印出我們?nèi)粘Ｒ姷降?The application may be doing too much work on its main thread 。

階段二：

 void doFrame(long frameTimeNanos, int frame) {
 ...
try {
//階段2
      Trace.traceBegin(Trace.TRACE_TAG_VIEW, "Choreographer#doFrame");
      AnimationUtils.lockAnimationClock(frameTimeNanos / TimeUtils.NANOS_PER_MS);

      mFrameInfo.markInputHandlingStart();
      doCallbacks(Choreographer.CALLBACK_INPUT, frameTimeNanos);

      mFrameInfo.markAnimationsStart();
      doCallbacks(Choreographer.CALLBACK_ANIMATION, frameTimeNanos);

      mFrameInfo.markPerformTraversalsStart();
      doCallbacks(Choreographer.CALLBACK_TRAVERSAL, frameTimeNanos);

      doCallbacks(Choreographer.CALLBACK_COMMIT, frameTimeNanos);
    } 
    ...
    }

doFrame() 的第二個階段做的是處理各種callback，從CallbackQueue里面取出到執(zhí)行時間的callback進行處理，那這個callback是怎么樣呢？

這里要回憶一下之前的 postCallback() 操作：

這個 Callback 其實就一個 mTraversalRunnable ，它是一個 Runnable ，最終會調(diào)用到 run() 方法，實現(xiàn)界面的真正刷新：

 ----》類名:ViewRootImpl

  final class TraversalRunnable implements Runnable {
    @Override
    public void run() {
      doTraversal();
    }
  }
  
  void doTraversal() {
    if (mTraversalScheduled) {
     ...
      performTraversals();
     ...
    }
  }
  
  private void performTraversals() {
   ...
   //開始真正的界面繪制
    performDraw();
   ...
  }

三、總結(jié)

經(jīng)過漫長的代碼跟蹤，整個界面刷新流程算是跟蹤完了，下面我們來總結(jié)一下：