應用的啟動速度緩慢這是很多開發者都遇到的一個問題，比如啟動緩慢導致的黑屏，白屏問題，大部分的答案都是做一個透明的主題，或者是做一個Splash介面，但是這並沒有從根本上解決這個問題。那麼如何從根本上解決這個問題或者做到一定程度的緩解？

一、應用的啟動方式

1、冷啟動：當啟動應用時，後臺沒有該應用的程序，這時系統會首先會建立一個新的程序分配給該應用，這種啟動方式就是冷啟動。

2、熱啟動：當啟動應用時，後臺已有該應用的程序，比如按下home鍵，這種在已有程序的情況下，這種啟動會從已有的程序中來啟動應用，這種啟動方式叫熱啟動。

3、溫啟動 ：當啟動應用時，後臺已有該應用的程序，但是啟動的入口Activity被幹掉了，比如按了back鍵，應用雖然退出了，但是該應用的程序是依然會保留在後臺，這種啟動方式叫溫啟動。

二、應用的啟動時間統計

adb shell am start -W [PackageName]/[PackageName.MainActivity]

執行成功後將返回三個測量到的時間： 

這裡面涉及到三個時間，ThisTime、TotalTime 和 WaitTime。WaitTime 是 startActivityAndWait 這個方法的呼叫耗時，ThisTime 是指呼叫過程中最後一個 Activity 啟動時間到這個 Activity 的 startActivityAndWait 呼叫結束。TotalTime 是指呼叫過程中第一個 Activity 的啟動時間到最後一個 Activity 的 startActivityAndWait 結束。如果過程中只有一個 Activity ，則 TotalTime 等於 ThisTime。

三、效能檢查項

從我們Application開始到首頁顯示出來，這個過程，我們應該注意一些什麼，將這個過程細分一下，會有下面的時間點需要注意。

Application的構造器方法——>attachBaseContext()——>onCreate()——>Activity的構造方法——>onCreate()——>配置主題中背景等屬性——>onStart()——>onResume()——>測量、佈局、繪製顯示在介面上。

因為上面這些階段全部都是在主執行緒中執行的，任何不經意的操作都可能拖慢應用的啟動速度。所以我們不應在Application以及Activity的生命週期回撥中做任何費時操作，具體指標大概是你在onCreate，onResume，onStart等回撥中所花費的總時間最好不要超過400ms，否則使用者在桌面點選你的應用圖示後，將感覺到明顯的卡頓。但是有些不得以的任務又必須在UI顯示之前執行。所以我們要將任務劃分優先順序。

• 優先順序為1的在應用啟動時，就開始載入
• 優先順序為2的在首頁渲染完成後，開始載入
• 優先順序為3的在首頁渲染完成後，延遲載入

對於首頁渲染完成後，開始載入，或者延遲載入，延遲載入的目的就是介面先顯示出來，然後載入，但是你覺得要延遲多久呢？在 Android 的高階機型上,應用的啟動是非常快的 , 這時候只需要 Delay 很短的時間就可以了, 但是在低端機型上,應用的啟動就沒有那麼快了,而且現在應用為了相容舊的機型,往往需要 Delay 較長的時間,這樣帶來體驗上的差異是很明顯的。延遲載入有一種方式。

  第一種寫法:直接PostDelay 300ms.
  myHandler.postDelayed(mLoadingRunnable, DEALY_TIME);
  第二種寫法:優化的DelayLoad
  getWindow().getDecorView().post(new Runnable() {
    @Override
   public void run() {
        myHandler.post(mLoadingRunnable);
   }
  });

1. 第一種寫法:直接PostDelay 300ms.

2. myHandler.postDelayed(mLoadingRunnable, DEALY_TIME);

3. 第二種寫法:優化的DelayLoad

4. getWindow().getDecorView().post(new Runnable() {

5. @Override

6. public void run() {

7. myHandler.post(mLoadingRunnable);

8. }

9. });

極力推薦用第二種，在視窗完成以後進行載入，這裡面的run方法是在onResume之後執行的。關於這種懶載入機制，參考Android應用啟動優化:一種DelayLoad的實現和原理(上篇)，給出了詳細的解釋。

四、利用TraceView逐個修復

通過上面我們知道一種懶載入機制，所以我們可以將Application中和首頁的onCreate中的有些耗時任務，放到首頁渲染完畢後加載。如何找出這些耗時任務，TraceView就派上用場了，TraceView的用法，移步我的前面的部落格Android效能優化第（六）篇---TraceView 分析圖怎麼看？

比如在首頁的onCreate中我們進行了使用者啟動上報，這個進行懶載入是不是分分鐘減少139毫秒呢？

在比如在Application裡面用到了GSON，將String轉化成json,我將這個移動到懶載入裡面，是不是又減少了100毫秒呢？

在比如，有些Application中做了支付SDK的初始化，使用者又不會一開啟App就要支付，放在Application中載入幹嘛？

此處我們這裡舉得例子是優化了139毫秒和100毫秒的，其實真正耗時的任務有的有1秒多，都被我優化完了，所以trace圖中看不到了，就舉個了這兩個例子，還有SharedPreferences也是耗時大戶，經過檢測儲存一個boolean變數耗時120+毫秒以上。

利用TraceView可以清楚我們每一個方法的耗時時間，極大的幫助了我們做優化工作。

五、優化思路總結
1、UI渲染優化，去除重複繪製，減少UI重複繪製時間，開啟設定中的GPU過度繪製開關，各介面過度繪製不應超過2.5x；也就是開啟此除錯開關後，介面整體呈現淺色，特別複雜的介面，紅色區域也不應該超過全螢幕的四分之一；
2、根據優先順序的劃分，KoMobileApplication的一些初始化工作能否將任務優先順序劃分成3,在首頁渲染完成後進行載入，比如：PaySDKManager。
3、主執行緒中的所有SharedPreference能否在非UI執行緒中進行，SharedPreferences的apply函式需要注意，因為Commit函式會阻塞IO，這個函式雖然執行很快，但是系統會有另外一個執行緒來負責寫操作，當apply頻率高的時候，該執行緒就會比較佔用CPU資源。類似的還有統計埋點等，在主執行緒埋點但非同步執行緒提交，頻率高的情況也會出現這樣的問題。
4、檢查BaseActivity,不恰當的操作會影響所有子Activity的啟動。
5、對於首次啟動的黑屏問題，對於“黑屏”是否可以設計一個.9圖片替換掉，間接減少使用者等待時間。
6、對於網路錯誤介面，友好提示介面，使用ViewStub的方式，減少UI一次性繪製的壓力。
7、任務優先順序為2，3的，通過下面這種方式進行懶載入的方式

  getWindow().getDecorView().post(new Runnable() {
   @Override
   public void run() {
       myHandler.post(mLoadingRunnable);
    }
  });

1. getWindow().getDecorView().post(new Runnable() {

2. @Override

3. public void run() {

4. myHandler.post(mLoadingRunnable);

5. }

6. });

8、Multidex的使用，也是拖慢啟動速度的元凶，必須要做優化。後面有空專門寫一篇Multidex。

相關連結：