愛奇藝技術分享：愛奇藝Android用戶端啟動速度優化實踐總結

本文由愛奇藝技術團隊原創分享，原題《愛奇藝Android用戶端啟動優化與分析》。

1、引言

網際網路領域裡有個八秒定律，如果網頁打開時間超過8秒，便會有超過70%的使用者放棄等待，對Android APP而言，要求更加嚴格，如果系統無響應時間超過5秒，便會出現ANR，APP可能會被強制關閉，是以，啟動時間作為一個重要的性能名額，關系着使用者的第一體驗。

愛奇藝安卓APP非常重視啟動速度的優化，本文将從啟動過程、啟動時間測量、啟動優化、以及後續監控等方面分享我們在啟動優化方面積累的經驗。

相關文章：

《 移動端IM實踐：Android版微信如何大幅提升互動性能（一） 》 移動端IM實踐：Android版微信如何大幅提升互動性能（二） 移動端IM實踐：iOS版微信界面卡頓監測方案 微信團隊原創分享：Android記憶體洩漏監控和優化技巧總結 美圖App的移動端DNS優化實踐：HTTPS請求耗時減小近半

（本文同步釋出于：

http://www.52im.net/thread-2221-1-1.html

）

2、啟動模式

要準确的測量APP的啟動時間，首先我們要了解APP整個啟動過程。

啟動過程，一般可以分為以下三類：

從上圖可以看出，啟動過程中，Cold的模式下，生命周期中做的事情最多，啟動的時間最長。是以，我們以冷啟動來衡量APP啟動時間。

那麼啟動過程中，如何判斷哪些生命周期影響啟動速度呢？請繼續往下讀。

3、啟動過程

我們知道，APP的啟動和運作，就是Linux系統建立程序群組件對象，并在UI線程中處理元件消息的過程。

啟動過程圖：

App的啟動過程，可以劃分為三個階段，下面就各個階段進行詳細講解。

3.1 建立程序

當APP啟動時，如果目前app的程序不存在，便會建立新的程序；App主程序啟動後，如果啟動某個元件，并且該元件設定了android:process屬性，元件所運作的程序不存在，也會建立新的程序。

需要注意的是，如果在啟動階段，初始化的元件中，包含了多個程序，便會建立多次程序，BindApplication操作也會重複執行多次

3.2 建立UI線程及Handler

程序建立後，會通過反射，執行ActivityThread入口函數,建立Handler，并在目前線程中prepareMainLooper，并在Handler中接收元件的消息。

我們來看一下Handler中處理的消息：

1）LAUNCH_ACTIVITY：啟動，執行Activity；

2）RESUME_ACTIVITY：恢複Activity；

3）BIND_APPLICATION，啟動app；

4）BIND_SERVICE：Service建立, onBind；

5）LOW_MEMORY：記憶體不足，回收背景程式。

sMainThreadHandler中，處理的消息很多，這裡隻羅列了，可能在啟動階段可能會執行的操作， 這些操作都是運作在Main Thread中，對啟動而言，屬于阻塞性的。

Activity生命周期，自然需要在啟動階段執行，但，對于Service的建立，Trim_memory回調，廣播接收等操作，就需要重點考慮，其操作耗時性。

3.3 Activity運作及繪制

前兩個過程，建立程序和UI線程及Handler，都是由系統決定的，對APP開發者而言，并不能控制其執行時間，在本階段，執行BindApplication,和Acitivity生命周期，都是可以由開發者自定義。

Activity執行到onResume之後，會執行至ViewRootImpl，執行兩次performTraversals，第二次traversal操作中，會執行performDraw操作，同時通知RenderThread線程執行繪制。

從啟動的三個階段，我們可以看出，啟動啟動時間的長短的決定因素在于：主線程中所做事情消耗的時間的多少。

是以：我們的優化工作主要集中在，排查主線程中耗時性的工作，并進行合理的優化。

Android手機，系統的資源是有限的，過多的異步線程，會搶占CPU，導緻主線程執行時間片間隔增大。同樣的，記憶體消耗狀态，GC頻率，也會影響啟動的時間。

4、分析及測量

通過上述的源碼的解讀，我們已經了解了啟動過程，以及可能引起啟動過慢的原因。接下來介紹一些常用的分析手段及時間測量方法。

我們的啟動分析工具主要使用SysTrace，具體的使用方法請參考官網文檔：

https://developer.android.com/studio/command-line/systrace

。

▲ Andriod上的各種各樣分析工具，請自行選用

4.1 SysTrace分析技巧

【4.1.1、UI Thread 顔色顯示】

綠色：Running

白色：Sleeping

棕色：Uninterruptible Sleep

橙色：Uninterruptible Sleep - Block I/O

其中10ms以内的，較短時間的Sleeping狀态，不用關注，可能是由于CPU排程的時間片配置設定間隔引起的；較長時間的Block I/O和Sleep狀态，可以确定有阻塞啟動的邏輯在這個階段運作，需要進一步對代碼進行分析定位。

【4.1.2、檢視CPU狀态及線程運作時長】

檢視CPU占用狀态：

線程執行：

通過該階段密集程度，反映出CPU占用率，也能在一定程度上反映出該階段執行時間被阻塞情況；線程執行情況統計，可以檢視線程執行時間排名，對執行時間較長的子線程進行優化。

4.2 SysTrace啟動時間

在SysTrace圖中，UI Thread中包含了bindApplication,activityStart,traversal等操作，RenderThread中包含DrawFrame等操作。這些TAG節點是源碼已經添加的，可參考#3.2中介紹。

Trace上啟動時間：

從bindApplication至第二次traversal完成，可認為UI第一次繪制完成，啟動完成。選中開始點和結束點，可以檢視過程消耗的時間。

4.3 adb shell am start -W

在統計APP啟動時間時，系統為我們提供了adb指令,可以輸出啟動時間

TotalTime: 

表示新應用啟動的耗時，包括新程序的啟動和 Activity 的啟動，但不包括前一個應用 Activity pause 的耗時。

系統在繪制完成後，ActivityManagerService會回調該方法,統計時間不如SysTrace準确，但是能夠友善我們通過腳本多次啟動測量TotalTime,對比版本間啟動時間差異。

4.4 埋點

通過APP啟動生命周期中，關鍵位置加入時間點記錄，達到測量目的。

4.5 錄屏

錄屏方式收集到的時間，更接近于使用者的真實體感。

5、優化總結

為了讓使用者在進入APP之後，更快更流暢的使用服務，是以會在啟動過程中，提前對一些基礎庫群組建進行初始化操作，這就意味着系統有限的資源會被搶占，影響啟動時間。啟動時間的優化，是一個平衡性能和體驗的過程。

通過Systrace工具分析，我們發現愛奇藝愛奇藝安卓APP啟動過程中一些問題，接下來，我們就結合具體的業務實踐，進行啟動問題進行優化。

5.1 區分程序初始化Application

由第3章我們了解到，對于一個app而言，App内元件可以運作在不同的程序之中。

舉個例子： 

一個APP擁有主程序，插件程序，下載下傳程序三個程序，會在啟動階段建立相應的元件，但隻有一個QYApplication繼承自系統Application，建立三次程序，QYApplication中attach(),onCreate()方法都會被執行三次。

每個程序說需要初始化的内容肯定是不一樣的，是以，為了防止資源的浪費，我們需要區分程序，初始化Appcation.

成果：對多程序應用而言，通過對初始化内容進行梳理，合理區分初始化，會大幅減少記憶體和CPU占用。

5.2 異步處理耗時任務

子線程處理耗時任務，主線程做的事情越少，越早進入Acitivity繪制階段，界面越早展現。

注意：

1）不在主線程做耗時任務，如檔案，網絡等；

2）啟動階段初始化任務，盡量在異步線程處理；

3）主線程，不用等待或者依賴于子線程任務。

進一步優化：可以自建線程池，維持一定線程個數，管理任務隊列。

5.3 防止多線程搶占CPU

Android系統資源有限，特别是CPU資源，理論上來說，UI線程執行的任務，也無法保證一直被排程狀态，當并發的線程數過多，UI線程時間片會更短，進而導緻啟動時間被變慢。

下面羅列一些常見，容易造成CPU被搶占的場景：

成果：通過對執行時間較久，執行頻率的業務進行優化，将CPU占有率維持在合理的程度，會大幅減少啟動時間，減少300ms以上。

5.4 系統API使用

部分系統的API使用是阻塞性的，檔案很小可能無法感覺，當檔案過大，或者使用頻繁時，可能造成阻塞。

例如：

1）SharedPreference.Editor送出操作：

  - commit方法屬于屬于阻塞性質API，建議使用apply；

  - 此外，我們知道，SP檔案的存儲是一個XML檔案，以key-value形式存儲，當業務過多時，需要拆分為多個檔案存儲，防止檔案過大，出現讀取耗時及ANR；

  - 進一步優化，可對啟動階段，頻繁的SP操作在記憶體中，統一送出。

2）AssetManager.open操作： 

Android開發中，我們有時會将資源檔案放在assets目錄中，然後使用open操作讀取檔案，如果檔案過大，需要在異步線程中執行。

成果：随着業務量日積月累，正常的系統API的使用，也可能出現問題，通過排除，可減少50-100ms。

5.5 精簡布局

布局的複雜程度，直接影響繪制的時間。

舉個例子：

在啟動過程中，會有需要大的背景圖，隻有第一次安裝時使用，後續屬性設定為android:visibility="gone",但是，雖然設定了gone屬性，不會顯示，但依舊會被解析。

建議：

1）減少布局層次；

2）無用資源使用ViewStub，使用時加載。

成果：啟動階段的布局較簡單，通過優化背景圖檔的加載，減少50-100ms。

5.6 Service延後初始化

App啟動中過程中，經常進行Service初始化操作，由于Service使用一般不涉及界面，可能會認為初始化生命周期不在主線程中，其實不然，在3.2的啟動過程源碼介紹中講到，Service的生命周期，也屬于主線程Handler接收的Message之一。

建議：Service生命周期中，注意邏輯執行時間性能優化，初始化盡量延後。

成果：取決于初始化Service的生命周期執行時間，可減少200ms以上。

5.7 将任務delay至首頁繪制完成後

對于APP首頁展示不需要的初始化邏輯，可延後至首頁繪制完成後初始化。

注意：需要post兩次才能保證在第一次繪制之後顯示，因為，系統繪制會執行兩次Performtraversal。

進一步優化：可将業務邏輯的初始化劃分為，首頁繪制後，5s,10s,20s三個階段分别初始化，防止首頁繪制執行任務過多造成掉幀。

成果：釋放繪制階段的CPU，可将複雜的繪制提前200ms以上。

6、性能監控

穩定的使用者體驗依賴于持續的監控，愛奇藝為監控啟動性能建立了一套監控體系、測試、工具、開發等幾個團隊從不同的緯度搭建不同的監控方案。

監控方案如下：

1）測試：錄屏，從使用者的真實體驗角度，擷取最準确的啟動時間；

2）實時監控：通過埋點，大資料采樣投遞擷取真實線上環境資料，從地域，時間，機型，app版本，系統版本等各個緯度對啟動時間進行監控；

3）腳本測試：通過對腳本，對同一收集多次啟動資料進行收集，通過不同版本間的對比，監控啟動時間的變化情況。

7、SysTrace擴充

SysTrace通過TAG節點可以清晰展現，啟動過程以及方法執行時間，但是，從發現問題，然後通過節點去定位問題，是一件很繁瑣的工作，如果你們工程編譯又比較慢，簡直讓人崩潰。

比如：自動化TAG注入。

在Android工程編譯的過程中，指定class，在方法前後，自動化插入Trace節點，統計方法執行時間。

流程：

1）在編譯的過程中，插入自定義Task任務；

2）讀取配置檔案，檔案中包含了需要注入java檔案名和路徑名和method；

3）找到需要注入的class檔案，然後通過ASM改變位元組碼，方法前後，插入自定義自定義方法。

通過工具的操作，能夠做到不用修改原有工程檔案，自動在打包時注入TAG節點和邏輯代碼，配置檔案可以循環利用，提高分析效率，節能環保。

8、優化成果

啟動時間，由于不同的機型性能同，Android系統版本不同，同一APP版本啟動時間，相差很大，是以統計一般以同一手機，不同版本做比較，盡量保證手機狀态一緻。

SysTrace手機優化時間對比：

腳本多次啟動時間收集對比：

經過多個版本的持續優化，有無廣告兩種不同的場景下，啟動時間分别減少40%和35%，啟動速度得到了較大的提升。

9、本文小結

啟動時間的優化和監控，是一項長期的任務，需要對異常的情況進行分析，對可能造成阻塞的代碼邏輯進行合理的優化，非常感謝各個業務團隊支援和配合。

以上就是全部啟動時間優化相關的内容，謝謝大家能夠閱讀到這裡，如果有更好的建議，歡迎交流！

附錄：更多移動端進階開發技術分享

全面了解移動端DNS域名劫持等雜症：技術原理、問題根源、解決方案等 金蝶随手記團隊分享：還在用JSON? Protobuf讓資料傳輸更省更快(原理篇) 金蝶随手記團隊分享：還在用JSON? Protobuf讓資料傳輸更省更快(實戰篇) 騰訊技術分享：社交網絡圖檔的帶寬壓縮技術演進之路 通俗易懂：基于叢集的移動端IM接入層負載均衡方案分享 QQ音樂團隊分享：Android中的圖檔壓縮技術詳解（上篇） QQ音樂團隊分享：Android中的圖檔壓縮技術詳解（下篇） 騰訊原創分享(一)：如何大幅提升移動網絡下手機QQ的圖檔傳輸速度和成功率 騰訊原創分享(二)：如何大幅壓縮移動網絡下APP的流量消耗（上篇） 騰訊原創分享(三)：如何大幅壓縮移動網絡下APP的流量消耗（下篇） 基于社交網絡的Yelp是如何實作海量使用者圖檔的無損壓縮的？ 騰訊技術分享：騰訊是如何大幅降低帶寬和網絡流量的(圖檔壓縮篇) 騰訊技術分享：騰訊是如何大幅降低帶寬和網絡流量的(音視訊技術篇) 最火移動端跨平台方案盤點：React Native、weex、Flutter iPhone X 的 UI界面适配官方指南！》 新浪微網誌技術分享：微網誌短視訊服務的優化實踐之路 全面掌握移動端主流圖檔格式的特點、性能、調優等 邁向高階：優秀Android程式員必知必會的網絡基礎 HTTPS時代已來，打算更新你的HTTP服務了嗎？ 移動端APP的日志上報機制的優化實踐 移動端網絡優化之HTTP請求的DNS優化 僞即時通訊：分享滴滴出行iOS用戶端的演進過程 Android版微信從300KB到30MB的技術演進(PPT講稿) [附件下載下傳] 微信團隊原創分享：Android版微信從300KB到30MB的技術演進 Android程式員的痛你永遠不懂(一)：Bitmap到底占用多大記憶體？ Android程式員的痛你永遠不懂(二)：如何減少Bitmap記憶體占用？ Android反編譯利器APKDB：沒有美工的日子裡繼續堅強的撸 全面總結iOS版微信更新iOS9遇到的各種“坑” 微信團隊原創資源混淆工具：讓你的APK立減1M 微信團隊原創Android資源混淆工具：AndResGuard [有源碼] Android版微信安裝包“減肥”實戰記錄 iOS版微信安裝包“減肥”實戰記錄 iOS端移動網絡調優的8條建議 微信“紅包照片”背後的技術難題 移動端IM實踐：iOS版微信小視訊功能技術方案實錄 移動端IM實踐：iOS版微信的多裝置字型适配方案探讨 愛奇藝技術分享：愛奇藝Android用戶端啟動速度優化實踐總結 >>  更多同類文章 ……