Android啓動速度優化-總會遇到的不痛不癢的坎~

時間 2019-11-06

原文原文鏈接

#Android啓動速度優化-總會遇到的不痛不癢的坎~android

###1、直奔主題來自用戶、測試、產品、包括開發人員反饋：git

app啓動很慢，歡迎頁停留過久或者啓動黑屏等等，但有時候又不會。github

起初一直不過重視，後來隨着產品迭代更新，發現啓動速度慢的問題愈來愈明顯，已經影響到用戶體驗，甚至爲了加快啓動速度而要發一個升級包。因而決定優化一下啓動速度，研究以後發現，仍是有不少能夠拿出來分享的；app

###2、基礎知識異步

####冷啓動：當後臺不存在該應用的任何進程或者服務時，用戶點擊icon圖標啓動，咱們稱之爲冷啓動。 ####熱啓動當後臺存在該應用的進程或者服務時，用戶點擊icon圖標啓動，咱們稱之爲熱啓動。通常是用戶按了home鍵回到桌面，或者返回鍵沒有殺進程，或者app自己作了進程重啓的機制。 ####啓動組成時間咱們主要優化冷啓動時間，只要冷啓動時間優化了，熱啓動其實也跟着優化了。冷啓動時間分佈以下： application啓動時間+歡迎頁停留時間按用戶體驗的啓動時間應該是： application啓動時間+歡迎頁停留時間+進入主頁後顯示主題的話時間；ide

###3、優化點測試

###一、Application的啓動優化-兵家必爭之地；優化

Application啓動會通過attachBaseContext-->onCreate;動畫

這兩個方法不執行完是不會出現lanucher頁面的；因此用戶反饋點擊圖片後，要過一會纔出現歡迎頁的緣由如下幾個：插件

一、這兩個方法太過費時致使的。
二、application的Theme被設置會透明的（系統通常默認有個白色或者黑色的）
三、對啓動頁不要作自定義動畫，效果沒有原聲的好，會有一點點影響。

####attachBaseContext優化

這個方法在沒有MultiDex的app中或者沒有特殊業務的app中通常是不用重寫的，可是因爲業務須要，咱們的app須要集成multidex，致使咱們須要在此方法裏進行MultiDex.install操做,這個操做實際上是耗時的，沒辦法優化，可是也不能讓用戶傻等. #####（1）優化初次啓動咱們知道5.0如下初次安裝啓動須要進行dexopt的過程，這個過程是很是耗時的，在一些比較低端的機子上甚至能到達20秒，並且只能在主UI線程進行，若是咱們直接執行install的話，頗有可能出現ANR,黑屏，等各類很是很差的體驗，怎麼辦呢，咱們能夠繞過咱們的主進程: 咱們開啓一個新的進程用於install操做，並彈出一個歡迎頁；而後再咱們的主線程一直檢測是否安裝完成，超時時間設置爲30秒；完成以後彈出主進程的歡迎頁面（注意：爲了讓用戶無感知，這兩個頁面必須如出一轍，且中間不能用過渡動畫）。通過實踐：基本上這套方案能夠適用全部目前兼容的機型。

#####（2）Application Theme建議設置爲透明的（處於用戶體驗的考慮）

####onCreate優化

每次application啓動或者重啓的時候都會觸發onCreate；若是這個方法耗時超過500ms的話，你能夠很明顯的感覺到點擊icon以後，歡迎頁不會馬上展現出來。

然而不幸的是，不少第三方的組件，如友盟，百川等等都須要在此進行初始化，緣由是防止進程被回收以後他們還有機會進行從新初始化而不影響業務。

緣由上咱們能夠接受，但一旦初始化耗費時間多少徹底沒法控制，徹底看第三方「良心」了，但即便在咱們既沒法改變第三方初始化速度慢的問題，也不能將其從application移除的狀況下，咱們依然要優化啓動速度，由於用戶體驗是在過重要。

####迎難而上吧！

優化思路：最大的優化思路就是onCreate什麼都不執行，先讓歡迎頁彈窗出來；這個想法初步很簡單，也很好實現，然而存在幾個問題：

（1）進程被回收重啓後，如何從新初始化？

（2）通知欄推送後，進入到目的頁面，如何防止由於沒初始化致使的閃退或者功能異常？

（3）application oncreate什麼都不作，那初始化放在哪裏作呢；

只要這兩個問題解決了，基本上application的優化就算完成了，怎麼解決呢，咱們採用了下面的辦法咱們在application只幹了一件事，並且幾乎不費時，他就是：監聽頁面的生命週期: #####registerActivityLifecycleCallbacks 這個方法可讓咱們監聽全部頁面的生命週期，包括啓動，可見，銷燬等等，而啓動的時候android自己帶了一個參數 public void onActivityCreated(Activity activity, Bundle savedInstanceState)；中的Bundle，若是Bundle不爲空，說明是回收回來的，咱們能夠在這裏進行從新初始化，而不影響其餘功能；所以（1）（2）問題迎刃而解；關於（3）的問題是正常流程問題，若是放在歡迎頁初始化，是不妥的，並非全部的入口都走歡迎頁；因此咱們在application接收了一個初始化的事件，只要收到這個事件，就能夠進行初始化，初始化完了以後，再發出初始化完成的通知；（其實這一步是爲了優化歡迎頁作的準備，繼續往下看。）

####application經過以上幾步優化以後，就只剩下5.0如下dexopt和multidex.install消耗的時間優化的，要作到不執行Multi.install多個dex，只能本身動態實現dex的加載，也就是插件化，還有一段很長的路要走，繼續往下說。

###二、啓動頁啓動優化-用戶可見的第一感知

application優化完了之後，就會執行啓動頁的onCreate,咱們發現oncreate一旦耗時，也會致使啓動頁有一順氣的卡頓，精益求精，咱們把啓動頁的啓動邏輯延遲初始化並通知application進行初始化，而後等待application初始化完成的事件以後，繼續往下走，知道進入主頁；啓動也的優化邏輯比較簡單，只是純業務的上的調整。

###三、主頁優化

主要優化onCreate便可。把能夠放線程初始化的都放到線程裏去。

通過以上幾步優化以後，咱們發現啓動速度有了很是明顯的提示，其實大部分的時候都花在了業務的整理和application啓動的優化上邊，比較容易出bug的地方是咱們至關於改變了應該在appliation oncreate初始化方式，因爲有些組件初始化是異步的，仍是可能出現初始化未完成就被使用的狀況，這須要業務上進行相關的處理。貼一組優化後的數據，效果很理想。

####優化前：

application正常啓動 耗時：1299	
application延遲啓動 耗時：4081
Welcome 啓動 耗時：289
Tab啓動 耗時：1143

###優化後： D/耗時統計: meiyou : application onCreate 耗時:3 D/耗時統計: meiyou : application initNeedAtApplication 耗時:190 D/耗時統計: meiyou : welcome oncreate耗時:89 D/WelcomeController: meiyou : welcome handleGo 耗時:324 D/耗時統計: meiyou : welcome initLogic 耗時:324 D/耗時統計: meiyou : MainActivity onCreate 耗時:136 D/耗時統計: meiyou : HomeFragment onCreate 耗時:72

總的來講，對於一個比較大型的app的啓動邏輯仍是蠻複雜的，有必要的話都須要整理並優化一下，歡迎你們吐槽，共勉。