結論：加載時間從436ms-->96ms(優化率78%)
github: https://github.com/long8313002/ActivityOptimization
概述
本文主要是和大家探討一下，極限減少頁面加載耗時的可能性，在這里我們盡量追求方案的通用，而本文論述的方案，非互聯網上的主流方案，獨此一家，先到先得！
主流方案
本文不會花太多篇幅討論這些主流方案，另外這些方案在百度也很容易可以找到，不過這些方案也都有一個共同的特點，它們不是很通用，需要針對具體的業務具體進行分析，我所知道的主流方案如下：
- 主執行緒避免耗時操作、建議異步化（異步化也會導致業務復雜度提高）
- 優化頁面布局，減少多層嵌套、提高扁平度（難度大、收益低）
- 延遲加載不必要元素（大多數頁面都沒有懶加載條件）
- 避免過多的執行緒、推薦執行緒池
- 優化xml布局決議程序中反射創建View的耗時（略黑科技、通過復寫onCreateView來實作手動創建View，減少了反射的耗時，實測效果微乎其微，現在反射已經很快了）
耗時分析
我們一起來分析下頁面加載耗時，因為我們討論的是一個通用方案，所以我們定義一個存加載布局的頁面，沒有任何業務邏輯（業務邏輯導致的加載耗時屬于漏洞），首先，我們先寫一個巨復雜的XML（4000行）：
現在我們需要拿到，頁面加載各個地方耗時的資料，測驗代碼如下：
當第一幀開始繪制，我們算Activity的加載結束，因為onDrawListener在繪制前會被呼叫，所以這種統計方式會忽略掉繪制耗時，具體資料如下：
針對程序優化
創建程序
通過資料可以看出來，布局創建是最耗時的階段（291ms），占比總耗時66%，創建階段主要耗時的有這幾個步驟：io讀取xml、決議xml、創建視圖物件，
優化邏輯：采用異步預加載的方式、先在子執行緒創建好視圖，當使用的時候可以省去加載決議xml的時間：
優化后資料如下：
結論：
優化結果：布局創建時間從291ms--->4ms（優化率99%）
總加載時間從436-->163（優化率63%）
測量程序
測量程序耗時占比也比較客觀，有43ms之多（26%），雖然“準備時間”的耗時多于測量，但是這部分主要是WMS和ViewRootImpl之間通信的消耗，我們無法直接進行優化，
優化邏輯：采用異步預先測量的方式進行優化，因為視圖在進行過測量后有自己的快取機制，這部分可提前構建快取來進行優化，
android原始碼（View.measure）
優化代碼
優化后資料
結論
優化結果：布局測量時間從47ms--->10ms（優化率80%）
總加載時間從163ms-->96ms（優化率42%）
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/4449.html
標籤：其他
上一篇：axios的使用