App啓動速度優化

時間 2019-12-05

標籤 app 啓動速度優化简体版

原文原文鏈接

應用啓動類型

冷啓動

場景：開機後第一次啓動應用或者應用被殺死後再次啓動生命週期：Process.start->Application建立->attachBaseContext->onCreate->onStart->onResume->Activity生命週期啓動速度：在幾種啓動類型中最慢，也是咱們優化啓動速度最大的攔路虎android

溫啓動

場景：應用已經啓動，返回鍵退出生命週期：onCreate->onStart->onResume->Activity生命週期啓動速度：較快算法

熱啓動

場景：Home鍵最小化應用生命週期：onResume->Activity生命週期啓動速度：快shell

從上面的總結能夠看出，在應用的啓動過程當中，冷啓動是最慢最耗時的，系統以及應用自己都有大量的工做須要處理，因此，冷啓動對於應用的啓動速度是最具挑戰以及最有必要進行優化的。數組

冷啓動流程

冷啓動指的是應用程序從進程在系統不存在，到系統建立應用運行進程空間的過程。冷啓動一般會發生在一下兩種狀況：bash

設備啓動以來首次啓動應用程序
系統殺死應用程序以後再次啓動應用程序

在冷啓動的最開始，系統須要負責作三件事：微信

加載以及啓動app
app啓動以後馬上顯示一個空白的預覽窗口
建立app進程

一旦系統完成建立app進程後，app進程將要接着負責完成下面的工做：網絡

建立Application對象
建立而且啓動主線程ActivityThread
建立啓動第一個Activity
Inflating views
佈局屏幕
執行第一次繪製

一旦app進程完完成了第一次繪製工做，系統進程就會用main activity替換前面顯示的預覽窗口，這個時候，用戶就能夠正式開始與app進行交互了。併發

從冷啓動的流程看，咱們沒法干預app進程建立等系統操做，咱們可以干預的有：app

預覽窗口框架
Application生命週期回調
Activity生命週期回調

測量應用啓動時間工具

adb shell am start -W [packageName]/[ packageName. AppstartActivity]

在統計 app 啓動時間時，系統爲咱們提供了 adb 命令,能夠輸出啓動時間。系統在繪製完成後，ActivityManagerService 會回調該方法，可是可以方便咱們經過腳本屢次啓動測量 TotalTime，對比版本間啓動時間差別。可是統計時間不如 Systrace 準確。

代碼埋點

經過代碼埋點來準確獲取記錄每一個方法的執行時間，知道哪些地方耗時，而後再有針對性地優化。例如經過在 app 啓動生命週期中，關鍵位置加入時間點記錄，達到測量目的；又例如能夠在 Application 的 attachBaseContext方法中記錄開始時間，而後在啓動的第一個 Activity 的 onWindowFocusChanged方法記錄結束時間。可是從用戶點擊 app Icon 到 Application 被建立，再到 Activity 的渲染，中間仍是有不少步驟的，好比冷啓動的進程建立過程，而這個時間用此版本是沒辦法統計了，必須得承受這點數據的不許確性。

Nanoscope

Nanoscope 很是真實，不過暫時只支持 Nexus 6 和 x86 模擬器。

Simpleperf

Simpleperf 的火焰圖並不適合作啓動流程分析。

TraceView

經過 TraceView 主要能夠獲得兩種數據：單次執行耗時的方法以及執行次數多的方法。可是TraceView 性能耗損太大，不能比較正確反映真實狀況。

Systrace

Systrace 可以追蹤關鍵系統調用的耗時狀況，如系統的 IO 操做、內核工做隊列、CPU 負載、Surface 渲染、GC 事件以及 Android 各個子系統的運行情況等。可是不支持應用程序代碼的耗時分析。

「Systrace + 函數插樁」

除了可以看到例如 GC、System Server、CPU 調度等系統調用的耗時，還可以經過 Android 工程編譯的過程當中，在指定的方法先後，自動化插入插樁函數，統計方法執行時間。經過插樁，咱們能夠看到應用主線程和其餘線程的函數調用流程。它的實現原理很是簡單，就是將下面的兩個函數經過用ASM框架修改字節碼的方式分別插入到每一個方法的入口和出口。

class TraceMethod {
    public static void i() {
        Trace.beginSection();
    }

    public static void o() {
        Trace.endSection();
    }
}
複製代碼

固然這裏面有很是多的細節須要考慮，好比怎麼樣下降插樁對性能的影響、哪些函數須要被排除掉。函數插樁後的效果以下：

class Test {

    public void test() {
        TraceMethod.i();
        // 原來的工做
        TraceMethod.o();
    }
}
複製代碼

啓動優化方法

預覽窗口優化

當用戶點擊應用桌面圖標啓動應用的時候，利用提早展現出來的 Window，快速展現出一個界面，用戶只須要很短的時間就能夠看到「預覽頁」，這種徹底「跟手」的感受在高端機上體驗很是好，但對於中低端機，會把總的的閃屏時間變得更長。若是點擊圖標沒有響應，用戶主觀上會認爲是手機系統響應比較慢。因此比較推薦的作法是，只在 Android 6.0 或者 Android 7.0 以上才啓用「預覽窗口」方案，讓手機性能好的用戶能夠有更好的體驗。要實現預覽窗口的顯示，只須要在利用 activity 的windowBackground主題屬性提供一個簡單的自定義 drawable 給啓動的 activity，以下：Layout XML file：

<layer-list xmlns:android="http://schemas.android.com/apk/res/android" android:opacity="opaque">
  <!-- The background color, preferably the same as your normal theme -->
  <item android:drawable="@android:color/white"/>
  <!-- Your product logo - 144dp color version of your app icon -->
  <item>
    <bitmap
      android:src="@drawable/product_logo_144dp"
      android:gravity="center"/>
  </item>
</layer-list>
複製代碼

Manifest file：

<activity ...
android:theme="@style/AppTheme.Launcher" />
複製代碼

這樣一個 activity 啓動的時候，就會先顯示一個預覽窗口，給用戶快速響應的體驗。當 activity想要恢復原來 theme，能夠經過在調用super.onCreate() 和setContentView()以前調用 setTheme(R.style.AppTheme)，以下：

public class MyMainActivity extends AppCompatActivity {
  @Override
  protected void onCreate(Bundle savedInstanceState) {
    // Make sure this is before calling super.onCreate
    setTheme(R.style.Theme_MyApp);
    super.onCreate(savedInstanceState);
    // ...
  }
}
複製代碼

業務梳理

不要一股腦把所有初始化工做放在 Application 中作，須要梳理清楚當前啓動過程正在運行的每個模塊，哪些是必定須要的、哪些能夠砍掉、哪些能夠懶加載。可是須要注意的是，懶加載要防止集中化，不然容易出現首頁顯示後用戶沒法操做的情形。總的來講，用如下四個維度分整理啓動的各個點：

必要且耗時：啓動初始化，考慮用線程來初始化。
必要不耗時：首頁繪製。
非必要但耗時：數據上報、插件初始化。
非必要不耗時：不用想，這塊直接去掉，在須要用的時再加載。

把數據整理出來後，按需實現加載邏輯，採起分步加載、異步加載、延期加載策略，以下圖所示：

業務優化

經過梳理以後，剩下的都是啓動過程必定要用的模塊。這個時候，咱們只能硬着頭皮去作進一步的優化。優化前期須要「抓大放小」，先看看主線程究竟慢在哪裏。最理想是經過算法進行優化，例如一個數據解密操做須要 1 秒，經過算法優化以後變成 10 毫秒。退而求其次，咱們要考慮這些任務是否是能夠經過異步線程預加載實現，但須要注意的是過多的線程預加載會讓咱們的邏輯變得更加複雜。

多進程優化

Android app 是支持多進程的，在 Manifest 中只要在組件聲明中加入android:process屬性就可讓組件在啓動時運行在不一樣的進程中。舉個例子：對於多進程 app ，可能擁有主進程，插件進程以及下載進程，但開發者只能在Manifest 中聲明一個 Application 組件，若是對應不一樣進程的組件啓動時，系統會建立三個進程，建立三個 Application 對象，同時attachBaseContext、onCreate等生命週期回調方法也會被調用三次。可是每一個進程須要初始化的內容確定是不同的，因此，爲了防止資源的浪費，咱們須要在Application 中區分進程，對應進程只初始化對應的內容。

線程優化線

程優化分兩方面：第一，耗時任務異步化。子線程處理耗時任務，主線程作的事情越少，越早進入Acitivity繪製階段，界面越早展示。例如不在主線程作如 IO 、網絡等耗時操做。可是要注意，子線程不能阻塞主線程。第二，線程池管理線程，控制線程的數量。線程數量太多會相互競爭 CPU 資源，致使分給主線程的時間片減小，從而致使啓動速度變慢。線程切換的數據咱們能夠經過卡頓優化中學到的 sched 文件查看，這裏特別須要注意 nr_involuntary_switches 被動切換的次數。

proc/[pid]/sched: 
 nr_voluntary_switches：主動上下文切換次數，由於線程沒法獲取所需資源致使上下文切換，最廣泛的是 IO。 
 nr_involuntary_switches：被動上下文切換次數，線程被系統強制調度致使上下文切換，例如大量線程在搶佔 CPU。 
複製代碼

第三，避免主線程與子線程之間的鎖阻塞等待。有一次咱們把主線程內的一個耗時任務放到線程中併發執行，可是發現這樣作根本沒起做用。仔細檢查後發現線程內部會持有一個鎖，主線程很快就有其餘任務由於這個鎖而等待。經過 Systrace 能夠看到鎖等待的事件，咱們須要排查這些等待是否能夠優化，特別是防止主線程出現長時間的空轉。

特別是如今有不少啓動框架，會使用 Pipeline 機制，根據業務優先級規定業務初始化時機。好比微信內部使用的 mmkernel 、阿里最近開源的 Alpha 啓動框架，它們爲各個任務創建依賴關係，最終構成一個有向無環圖。對於能夠併發的任務，會經過線程池最大程度提高啓動速度。若是任務的依賴關係沒有配置好，很容易出現下圖這種狀況，即主線程會一直等待 taskC 結束，空轉 2950 毫秒。

第四，設置子線程優先級。不重要任務，設置子線程優先級爲 THREAD_PRIORITY_BACKGROUND，這樣子線程最多能獲取到10%的時間片，優先保證主線程執行。

GC優化

在啓動過程，要儘可能減小 GC 的次數，避免形成主線程長時間的卡頓，特別是對 Dalvik 來講，咱們能夠經過 Systrace 單獨查看整個啓動過程 GC 的時間。啓動過程避免進行大量的字符串操做，特別是序列化跟反序列化過程。一些頻繁建立的對象，例如網絡庫和圖片庫中的 Byte 數組、Buffer 能夠複用。若是一些模塊實在須要頻繁建立對象，能夠考慮移到 Native 實現。Java 對象的逃逸也很容易引發 GC 問題，咱們在寫代碼的時候比較容易忽略這個點。咱們應該保證對象生命週期儘可能的短，在棧上就進行銷燬。

系統調用優化

部分系統的API使用是阻塞性的，文件很小可能沒法感知，當文件過大，或者使用頻繁時，可能形成阻塞。例如：SharedPreference.Editor 的提交操做建議使用異步的 apply，而不是阻塞的 commit。經過 systrace 的 System Service 類型，咱們能夠看到啓動過程 System Server 的CPU 工做狀況。在啓動過程，咱們儘可能不要作系統調用，例如 PackageManagerService 操做、Binder 調用等待。在啓動過程也不要過早地拉起應用的其餘進程，System Server 和新的進程都會競爭 CPU 資源。特別是系統內存不足的時候，當咱們拉起一個新的進程，可能會成爲「壓死駱駝的最後一根稻草」。它可能會觸發系統的 low memorykiller 機制，致使系統殺死和拉起（保活）大量的進程，從而影響前臺進程的 CPU。

佈局優化佈局越複雜，測量佈局繪製的時間就越長。主要作到如下幾點：佈局的層級越少，加載速度越快。一個控件的屬性越少，解析越快，刪除控件中的無用屬性。使用標籤加載一些不經常使用的佈局，作到使用時在加載。使用標籤減小布局的嵌套層次。儘量少用wrap_content，wrap_content會增長佈局measure時的計算成本，已知寬高爲固定值時，不用wrap_content。