Android性能優化（一）之啟動加速35%

一、前言

隨着項目版本的迭代，App的性能問題會逐漸暴露出來，而好的用戶體驗與性能表現緊密相關，從本篇文章開始，我將開啟一個Android應用性能優化的專題，從理論到實戰，從入門到深挖，手把手將性能優化實踐到項目中，歡迎持續關注！

那么第一篇文章我就從應用的啟動優化開始，根據實際案例，打造閃電般的App啟動速度。

二、初識啟動加速

來看一下Google官方文檔《Launch-Time Performance》對應用啟動優化的概述；

應用的啟動分為冷啟動、熱啟動、溫啟動，而啟動最慢、挑戰最大的就是冷啟動：系統和App本身都有更多的工作要從頭開始！
應用在冷啟動之前，要執行三個任務：

1. 加載啟動App；
2. App啟動之后立即展示出一個空白的Window；
3. 創建App的進程；

而這三個任務執行完畢之后會馬上執行以下任務：

1. 創建App對象；
2. 啟動Main Thread；
3. 創建啟動的Activity對象；
4. 加載View；
5. 布置屏幕；
6. 進行第一次繪制；

而一旦App進程完成了第一次繪制，系統進程就會用Main Activity替換已經展示的Background Window，此時用戶就可以使用App了。

 

應用冷啟動流程圖
作為普通應用，App進程的創建等環節我們是無法主動控制的，可以優化的也就是Application、Activity創建以及回調等過程。

 

同樣，Google也給出了啟動加速的方向：

1. 利用提前展示出來的Window，快速展示出來一個界面，給用戶快速反饋的體驗；
2. 避免在啟動時做密集沉重的初始化（Heavy app initialization）；
3. 定位問題：避免I/O操作、反序列化、網絡操作、布局嵌套等。

備注：方向1屬於治標不治本，只是表面上快；方向2、3可以真實的加快啟動速度。
接下來我們就在項目中實際應用。

三、啟動加速之主題切換

按照官方文檔的說明：使用Activity的windowBackground主題屬性來為啟動的Activity提供一個簡單的drawable。
Layout XML file:

資源文件配置Manifest file:

 

 

Manifest文件中

 

 

Activity中

 

這樣在啟動的時候，會先展示一個界面，這個界面就是Manifest中設置的Style，等Activity加載完畢后，再去加載Activity的界面，而在Activity的界面中，我們將主題重新設置為正常的主題，從而產生一種快的感覺。不過如上文總結這種方式其實並沒有真正的加速啟動過程，而是通過交互體驗來優化了展示的效果。
備注：截圖同樣來自官方文檔《Launch-Time Performance》。

四、啟動加速之Avoid Heavy App Initialization

通過代碼分析我們可以得到App啟動的業務工作流程圖：

 

App冷啟動業務工作流程圖

 

這一章節我們重點關注初始化的部分：在Application以及首屏Activity中我們主要做了：

• MultiDex以及Tinker的初始化，最先執行；關於MultiDex的優化本文不再贅述，參考我之前Multidex的系列文章。
• Application中主要做了各種三方組件的初始化；

項目中除聽雲之外其余所有三方組件都搶占先機，在Application主線程初始化。這樣的初始化方式肯定是過重的:

• 考慮異步初始化三方組件，不阻塞主線程；
• 延遲部分三方組件的初始化；實際上我們粗粒度的把所有三方組件都放到異步任務里，可能會出現WorkThread中尚未初始化完畢但MainThread中已經使用的錯誤，因此這種情況建議延遲到使用前再去初始化；
• 而如何開啟WorkThread同樣也有講究，這個話題在下文詳談。

項目修改：

1. 將友盟、Bugly、聽雲、GrowingIO、BlockCanary等組件放在WorkThread中初始化；
2. 延遲地圖定位、ImageLoader、自有統計等組件的初始化：地圖及自有統計延遲4秒，此時應用已經打開；而ImageLoader
   因為調用關系不能異步以及過久延遲，初始化從Application延遲到SplashActivity；而EventBus因為再Activity中使用所以必須在Application中初始化。

 

三方組件調用優化示例代碼

 

注意：閃屏頁的2秒停留可以利用，把耗時操作延遲到這個時間間隔里。

五、啟動加速之Diagnosing The Problem

本節我們實際定位耗時的操作，在開發階段我們一般使用BlockCanary或者ANRWatchDog找耗時操作，簡單明了，但是無法得到每一個方法的執行時間以及更詳細的對比信息。我們可以通過Method Tracing或者DDMS來獲得更全面詳細的信息。
啟動應用，點擊 Start Method Tracing，應用啟動后再次點擊，會自動打開剛才操作所記錄下的.trace文件，建議使用DDMS來查看，功能更加方便全面。

 

 

優化之前應用啟動trace文件分析圖

 

左側為發生的具體線程，右側為發生的時間軸，下面是發生的具體方法信息。注意兩列：Real Time/Call（實際發生時間），Calls+RecurCalls/Total（發生次數）；
上圖我們可以得到以下信息：

• 可以直觀看到MainThread的時間軸很長，說明大多數任務都是在MainThread中執行；
• 通過Real Time/Call 降序排列可以看到程序中的部分代碼確實非常耗時；
• 在下一頁可以看出來部分三方SDK也比較耗時；

即便是耗時操作，但是只要正確發生在WorkThread就沒問題。因此我們需要確認這些方法執行的線程以及發生的時機。這些操作如果發生在主線程，可能不構成ANR的發生條件，但是卡頓是再算難免的！結合上章節圖App冷啟動業務工作流程圖中業務操作以及分析圖，再次查看代碼我們可以看到：部分耗時操作例如IO讀取等確實發生在主線程。事實上在traceview里點擊執行函數的名稱不僅可以跟蹤到父類及子類的方法耗時，也可以在方法執行時間軸中看到具體在哪個線程以及耗時的界面閃動。

分析到部分耗時操作發生在主線程，那我們把耗時操作都改到子線程是不是就萬事大吉了？非也！！

• 卡頓不能都靠異步來解決，錯誤的使用工程線程不僅不能改善卡頓，反而可能加劇卡頓。是否需要開啟工作線程需要根據具體的性能瓶頸根源具體分析，對症下葯，不可一概而論；
• 而如何開啟線程同樣也有學問：Thread、ThreadPoolExecutor、AsyncTask、HandlerThread、IntentService等都各有利弊；例如通常情況下ThreadPoolExecutor比Thread更加高效、優勢明顯，但是特定場景下單個時間點的表現Thread會比ThreadPoolExecutor好：同樣的創建對象，ThreadPoolExecutor的開銷明顯比Thread大；
• 正確的開啟線程也不能包治百病，例如執行網絡請求會創建線程池，而在Application中正確的創建線程池勢必也會降低啟動速度；因此延遲操作也必不可少。

通過對traceview的詳細跟蹤以及代碼的詳細比對，我發現卡頓發生在：

• 部分數據庫及IO的操作發生在首屏Activity主線程；
• Application中創建了線程池；
• 首屏Activity網絡請求密集；
• 工作線程使用未設置優先級；
• 信息未緩存，重復獲取同樣信息；
• 流程問題：例如閃屏圖每次下載，當次使用；

以及其它細節問題：

• 執行無用老代碼；
• 執行開發階段使用的代碼；
• 執行重復邏輯；
• 調用三方SDK里或者Demo里的多余代碼；

項目修改：
1. 數據庫及IO操作都移到工作線程，並且設置線程優先級為THREAD_PRIORITY_BACKGROUND，這樣工作線程最多能獲取到10%的時間片，優先保證主線程執行。

2. 流程梳理，延后執行；
實際上，這一步對項目啟動加速最有效果。通過流程梳理發現部分流程調用時機偏早、失誤等，例如：

• 更新等操作無需在首屏尚未展示就調用，造成資源競爭；
• 調用了IOS為了規避審核而做的開關，造成網絡請求密集；
• 自有統計在Application的調用里創建數量固定為5的線程池，造成資源競爭，在上圖traceview功能說明圖中最后一行可以看到編號12執行5次，耗時排名前列；此處線程池的創建是必要但可以延后的。
• 修改廣告閃屏邏輯為下次生效。

3.其它優化；

• 去掉無用但被執行的老代碼；
• 去掉開發階段使用但線上被執行的代碼；
• 去掉重復邏輯執行代碼；
• 去掉調用三方SDK里或者Demo里的多余代碼；
• 信息緩存，常用信息只在第一次獲取，之后從緩存中取；
• 項目是多進程架構，只在主進程執行Application的onCreate()；

 

業務代碼優化示例

 

通過以上三步及三方組件的優化：Application以及首屏Activity回調期間主線程就沒有耗時、爭搶資源等情況了。此外還涉及布局優化、內存優化等部分技術，因對於應用冷啟動一般不是瓶頸點，這里不展開詳談，可根據實際項目實際處理。

六、對比效果：

通過ADB命令統計應用的啟動時間：adb shell am start -W 首屏Activity。
同等條件下使用MX3及Nexus6P，啟動5次，比較優化前與優化后的啟動時間；

優化前：
MX3

ThisTime	TotalTime	WaitTime
1237	2205	2214
1280	2181	2189
1622	2508	2513
1485	2434	2443
1442	2418	2429

Nexus6P

ThisTime	TotalTime	WaitTime
1229	1832	1868
1268	1849	1880
1184	1780	1812
1262	1845	1876
1164	1766	1807

優化后：
MX3

ThisTime	TotalTime	WaitTime
865	1516	1523
911	1565	1573
812	1406	1418
962	1564	1574
925	1566	1577

Nexus6P

ThisTime	TotalTime	WaitTime
603	1192	1243
614	1076	1115
650	1120	1163
642	1107	1139
624	1084	1124

對比：
MX3提升35%

	ThisTime平均數	TotalTime平均數	WaitTime平均數
優化前	1413	2349	2357
優化后	895	1523	1533

Nexus6P提升39%

	ThisTime平均數	TotalTime平均數	WaitTime平均數
優化前	1221	1814	1848
優化后	626	1115	1156

• 命令含義：
  ThisTime:最后一個啟動的Activity的啟動耗時；
  TotalTime:自己的所有Activity的啟動耗時；
  WaitTime: ActivityManagerService啟動App的Activity時的總時間（包括當前Activity的onPause()和自己Activity的啟動）。

七、問題：

1、還可以繼續優化的方向？

• 項目里使用Retrofit網絡請求庫，FastConverterFactory做Json解析器，TraceView中看到FastConverterFactory在創建過程中也比較耗時，考慮將其換為GsonConverterFactory。但是因為類的繼承關系短時間內無法直接替換，作為優化點暫時遺留；
• 可以考慮根據實際情況將啟動時部分接口合並為一，減少網絡請求次數，降低頻率；
• 相同功能的組件只保留一個，例如：友盟、GrowingIO、自有統計等功能重復；
• 使用ReDex進行優化；實驗Redex發現Apk體積確實是小了一點，但是啟動速度沒有變化，或許需要繼續研究。

2、異步、延遲初始化及操作的依據？
注意一點：並不是每一個組件的初始化以及操作都可以異步或延遲；是否可以取決組件的調用關系以及自己項目具體業務的需要。保證一個准則：可以異步的都異步，不可以異步的盡量延遲。讓應用先啟動，再操作。

3、通用應用啟動加速套路？

• 利用主題快速顯示界面；
• 異步初始化組件；
• 梳理業務邏輯，延遲初始化組件、操作；
• 正確使用線程；
• 去掉無用代碼、重復邏輯等。

4、其它

• 將啟動速度加快了35%不代表之前的代碼都是問題，從業務角度上將，代碼並沒有錯誤，實現了業務需求。但是在啟動時這個注重速度的階段，忽略的細節就會導致性能的瓶頸。
• 開發過程中，對核心模塊與應用階段如啟動時，使用TraceView進行分析，盡早發現瓶頸。

參考文章：《官方文檔——Launch-Time Performance》

歡迎關注微信公眾號：定期分享Java、Android干貨！