1. 程式人生 > >IdleHandler,頁面啟動優化神器

IdleHandler,頁面啟動優化神器

隨著App的開發到了某個階段必然會遇到一個需求,那就是優化頁面的啟動時間。

第一個問題:有什麼方法可以去統計頁面的啟動時間呢?

adb logcat -s ActivityManager | grep "Displayed"

複製程式碼

上面的命令列可用來進行檢視。

第二個問題:啟動時間是包括了哪些流程,是如何被計算出來的呢?

App啟動主要經過如下幾個流程

  1. Launch the process.
  2. Initialize the objects.
  3. Create and initialize the activity.
  4. Inflate the layout.
  5. Draw your application for the first time.

最末尾的步驟5是繪製你的介面。所以完整的啟動時間是要到繪製完成為止。

那麼繪製介面對應的是什麼時候呢?一般我們開發,最晚能被回撥的是在onResume方法,那麼onResume方法是在繪製之後還是之前呢?

no code no truth

    final void handleResumeActivity(IBinder token,
            boolean clearHide, boolean isForward, boolean reallyResume, int seq, String reason) {
            //省略部分程式碼
            r = performResumeActivity(token, clearHide, reason);
            //省略部分程式碼
            if
(a.mVisibleFromClient) { if (!a.mWindowAdded) { a.mWindowAdded = true; wm.addView(decor, l); 複製程式碼

看上面的程式碼,就先放結論了。

在performResumeActivity 中進行了onResume的回撥,在wm.addView 中進行了繪製,因此onResume的方法是在繪製之前,在onResume中做一些耗時操作都會影響啟動時間。

下面就剝一下onResume的邏輯,繪製的有興趣可以自己看原始碼。 首先performResumeActivity中會呼叫r.activity.performResume();

    public final ActivityClientRecord performResumeActivity(IBinder token,
            boolean clearHide, String reason) {
          //省略部分程式碼
        
            try {
                r.activity.onStateNotSaved();
                r.activity.mFragments.noteStateNotSaved();
                checkAndBlockForNetworkAccess();
                if (r.pendingIntents != null) {
                    deliverNewIntents(r, r.pendingIntents);
                    r.pendingIntents = null;
                }
                if (r.pendingResults != null) {
                    deliverResults(r, r.pendingResults);
                    r.pendingResults = null;
                }
                r.activity.performResume();

               //省略部分程式碼
               }
               }
複製程式碼

然後在performResume中呼叫了 mInstrumentation.callActivityOnResume(this);

 final void performResume() {
       //省略部分程式碼
        mInstrumentation.callActivityOnResume(this);
        //省略部分程式碼
    }
複製程式碼

最後在callActivityOnResume 呼叫了onResume

 public void callActivityOnResume(Activity activity) {
        activity.mResumed = true;
        activity.onResume();
        //省略程式碼
    }
複製程式碼

到了此處就算真正呼叫到了onResume的方法。

既然知道了onResume中做的操作會影響到啟動時間,那麼就有一個優化啟動時間的思路了。

思路

把在onResume以及其之前的呼叫的但非必須的事件(如某些介面View的繪製)挪出來找一個時機(即繪製完成以後)去呼叫。那樣啟動時間自然就縮短了。但是整體做的事並沒有明顯變化。那麼這個時機是什麼呢?

IdleHandler

看下IdleHandler的原始碼

   /**
     * Callback interface for discovering when a thread is going to block
     * waiting for more messages.
     */
    public static interface IdleHandler {
        /**
         * Called when the message queue has run out of messages and will now
         * wait for more.  Return true to keep your idle handler active, false
         * to have it removed.  This may be called if there are still messages
         * pending in the queue, but they are all scheduled to be dispatched
         * after the current time.
         */
        boolean queueIdle();
    }
複製程式碼

從這個原始碼可知道,IdleHandler即在looper裡面的message處理完了的時候去呼叫,這不就是我們onResume呼叫完了以後的時機麼。

來一張圖說明一下,明顯的IdleHandler在onResume以及performTraversals繪製之後呼叫 idlehandler

由這個思路我把自己負責的頁面中的一些介面的繪製邏輯挪到了IdleHandler中,由於有LoadingView時間,我把Adapter的繫結也挪出去了。看下優化前後效果圖 defaultdefault效果還是挺明顯的。

參考資料