啓動優化

　　啓動分析

　　在真正動手開始優化以前，咱們應該先搞清楚從用戶點擊圖標開始，...

　　啓動過程分析

　　

　　

　　用戶從桌面點擊圖標開始，會經歷四個階段

　　

　　T1 預覽窗口顯示。系統在拉起微信進程以前，會先根據應用的Theme屬性建立預覽窗口，固然若是咱們禁用預覽窗口或者將預覽窗口指定爲透明，用戶在這段時間依然看到的是桌面

　　T2閃屏顯示。在應用進程和閃屏窗口頁面建立完畢，而且完成一系列inflate view onmeasure,onlayout等準備工做以後，用戶能夠看到flash

　　T3主頁顯示。在完成主窗口建立和頁面顯示的準備以後，用戶能夠看到主界面

　　T4界面可操做。在啓動完成以後，應用會有比較多的工做須要繼續執行，應用界面的預加載等等，在這些都完成以後才能夠操做

　　2.啓動問題分析

　　從啓動流程的4個關鍵階，咱們能夠推測出用戶啓動過程會遇到的3個問題，這3個問題其實也是大多數應用在啓動時可能會遇到的

　　1.點擊圖標好久都不響應

　　若是咱們禁用了預覽窗口或者指定透明的皮膚，那用戶點擊圖標以後，須要T2時間才能真正看到應用閃屏，對於用戶體驗來講，點擊了圖標，過了幾秒仍是停留在桌面，看起來像是沒有點擊成功，中低端機更加明顯

　　2.首頁顯示太慢

　　如今應用啓動流程愈來愈複雜，閃屏廣告，熱修復框架，插件化框架、大前端框架，全部準備工做都須要集中在啓動階段完成，上面說的T3首頁顯示時間對於中低端機來講簡直是噩夢

　　3,首頁顯示後沒法操做

　　既然頁面顯示那麼慢，那我能不能把儘可能多的工做都經過異步化延後執行呢？不少應用的確就是這麼作的，但這會形成兩種結果，要麼首頁會出現白屏，要麼首頁出來後用戶根本沒法操做

　　不少應用吧啓動時間結束時間的統計放到首頁剛出現時，這對用戶是不負責的，看到一個首頁，可是停住十幾秒不能滑動，這對用戶來講徹底沒有意義，啓動優化不能過於kpi化，要從真實體驗出發，着重於從點擊圖標到用戶可操做的整個過程

　　啓動優化

　　咱們但願啓動期間加載的每一個功能和業務都是必須的

　　1優化工具

　　綜合來看 systrace+函數插樁 是比較理想的方案，並且還能夠看到系統的一些關鍵事件，例如：GC、System Sever/CPU調度等

　　經過插樁咱們能夠看到應用主線程和其餘線程的函數調用流程，它的實現原理很是簡單

　　2.優化方式

　　當拿到整個啓動流程的全景圖後，咱們能夠清楚的看到這段時間內系統、應用各個進程和線程的運行狀況

　　具體的優化方式、咱們分爲閃屏優化、業務梳理、業務優化，線程優化、GC優化和系統調用優化

　　閃屏優化

　　今日頭條把預覽窗口實現成閃屏的效果，這樣用戶只須要很短的時間就能夠看到「預覽閃屏」這種徹底「跟手」的感受在高端機上體驗很是的好，但對於中低端機，會把閃屏時間變得更長

　　合併閃屏和主頁面的Activity，減小一個Activity會給線上帶來100毫秒左右的優化，可是若是這樣作的話，管理時會很是複雜，特別是有不少PWA掃一掃這樣的第三方啓動流程的時候

　　業務梳理

　　 經過梳理以後，剩下的都是啓動過程必定要用的模塊，這個時候，咱們前期要「抓大放小」 經過算法進行優化，需注意過多的線程預加載會讓咱們的邏輯變得更加複雜

　　頁面優化到後面，會發現一些架構和歷史包袱會拖累咱們前進的步伐，比較常見的是一些事件會被各個模塊監聽，大量的回調致使不少工做集中執行，部分的框架初始化「太厚」

　　線程優化

　　線程的優化主要在於減小CPU調度帶來的波動，讓應用的啓動時間更加穩定

　　從具體的作法來看，線程的優化一方面試控制線程數量，線程數量太多會相互競爭cpu資源，所以要有統一的線程池，而且根據機器性能拉控制數量