應用的啟動速度緩慢這是很多開發者都遇到的一個問題，比如啟動緩慢導致的黑屏，白屏問題，大部分的答案都是做一個透明的主題，或者是做一個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。
總結:如果只關心某個應用自身啟動耗時，參考TotalTime；如果關心系統啟動應用耗時，參考WaitTime；如果關心應用有界面Activity啟動耗時，參考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);
}
});
極力推薦用第二種，在窗口完成以后進行加載，這里面的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);
}
});
8、Multidex的使用，也是拖慢啟動速度的元兇，必須要做優化。后面有空專門寫一篇Multidex。
相關鏈接：
Android性能優化之加快應用啟動速度http://www.open-open.com/lib/view/open1452821612355.html
手機淘寶性能優化全記錄http://www.open-open.com/lib/view/open1452488209370.html
Android客戶端性能優化（魅族資深工程師毫無保留奉獻）http://blog.tingyun.com/web/article/detail/155#rd
Please accept mybest wishes for your happiness and success !
