Android效能優化筆記（一）——啟動優化

本文主要是學習了極客時間張紹文老師的 Android開發高手課 以及 谷歌官網文章 的啟動優化筆記~

參考文章： 
https://time.geekbang.org/column/article/73651 https://mp.weixin.qq.com/s/eaArt5Udc4WZ3NoH5RlEkQ https://juejin.im/post/5874bff0128fe1006b443fa0 https://developer.android.google.cn/topic/performance/vitals/launch-time

應用啟動型別

• 冷啟動

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

• 溫啟動

1. 場景：應用已經啟動，返回鍵退出
2. 生命週期：onCreate->onStart->onResume->Activity生命週期
3. 啟動速度：較快

• 熱啟動

1. 場景：Home鍵最小化應用
2. 生命週期：onResume->Activity生命週期
3. 啟動速度：快

從上面的總結可以看出，在應用的啟動過程中，冷啟動是最慢最耗時的，系統以及應用本身都有大量的工作需要處理，所以，冷啟動對於應用的啟動速度是最具挑戰以及最有必要進行優化的。

冷啟動流程

冷啟動指的是應用程式從程式在系統不存在，到系統建立應用執行程式空間的過程。冷啟動通常會發生在一下兩種情況：

• 裝置啟動以來首次啟動應用程式
• 系統殺死應用程式之後再次啟動應用程式

在冷啟動的最開始，系統需要負責做三件事：

• 載入以及啟動app
• app啟動之後立刻顯示一個空白的預覽視窗
• 建立app程式

一旦系統完成建立app程式後，app程式將要接著負責完成下面的工作：

• 建立Application物件
• 建立並且啟動主執行緒ActivityThread
• 建立啟動第一個Activity
• Inflating views
• 佈局螢幕
• 執行第一次繪製

一旦app程式完完成了第一次繪製工作，系統程式就會用main activity替換前面顯示的預覽視窗，這個時候，使用者就可以正式開始與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();
    }
}複製程式碼

只有準確的資料評估才能指引優化的方向，這一步是非常重要的。沒有充分評估或者評估使用了錯誤的方法，最終得到了錯誤的方向，會導致最後發現根本達不到預期的優化效果。

啟動優化方法

在拿到整個啟動流程的全景圖之後，我們可以清楚地看到這段時間內系統、應用各個程式和執行緒的執行情況，現在我們要開始真正開始“幹活”了。

具體的優化方式，我把它們分為預覽視窗優化、業務梳理、業務優化、多程式優化、執行緒優化、GC 優化和系統呼叫優化。業務梳理、業務優化、執行緒優化、GC 優化、系統呼叫優化和佈局優化。

預覽視窗優化

當使用者點選應用桌面圖示啟動應用的時候，利用提前展示出來的 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 毫秒。退而求其次，我們要考慮這些任務是不是可以通過非同步執行緒預載入實現，但需要注意的是過多的執行緒預載入會讓我們的邏輯變得更加複雜。

業務優化做到後面，會發現一些架構和歷史包袱會拖累我們前進的步伐。比較常見的是一些事件會被各個業務模組監聽，大量的回撥導致很多工作集中執行，部分框架初始化“太厚”，例如一些外掛化框架，啟動過程各種反射、各種 Hook，整個耗時至少幾百毫秒。還有一些歷史包袱非常沉重，而且“牽一髮動全身”，改動風險比較大。但是我想說，如果有合適的時機，我們依然需要勇敢去償還這些“歷史債務”。

多程式優化

Android app 是支援多程式的，在 Manifest 中只要在元件宣告中加入android:process屬性就可以讓元件在啟動時執行在不同的程式中。舉個例子： 對於多程式 app ，可能擁有主程式，外掛程式以及下載程式，但開發者只能在 Manifest 中宣告一個 Application 元件，如果對應不同程式的元件啟動時，系統會建立三個程式，建立三個 Application 物件，同時attachBaseContext、onCreate等生命週期回撥方法也會被呼叫三次。

但是每個程式需要初始化的內容肯定是不一樣的，所以，為了防止資源的浪費，我們需要在Application 中區分程式，對應程式只初始化對應的內容。

執行緒優化

執行緒優化分兩方面：

第一，耗時任務非同步化。子執行緒處理耗時任務，主執行緒做的事情越少，越早進入Acitivity繪製階段，介面越早展現。例如不在主執行緒做如 IO 、網路等耗時操作。但是要注意，子執行緒不能阻塞主執行緒。

proc/[pid]/sched: 
 nr_voluntary_switches：主動上下文切換次數，因為執行緒無法獲取所需資源導致上下文切換，最普遍的是 IO。 
 nr_involuntary_switches：被動上下文切換次數，執行緒被系統強制排程導致上下文切換，例如大量執行緒在搶佔 CPU。 複製程式碼

class GetClassLoader extends PathClassLoader {
    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        // 將類名 name 記錄到檔案
        writeToFile(name, "coldstart_classes.txt");
        return super.findClass(name);
    }
}複製程式碼

// Dalvik Globals.h
gDvm.classVerifyMode = VERIFY_MODE_NONE;
// Art runtime.cc
verify_ = verifier::VerifyMode::kNone;複製程式碼

AndroidRuntime runtime = AndroidRuntime.getInstance();
runtime.init(context);
runtime.setVerificationEnabled(false);複製程式碼

初到掘金，人生地不熟，喜歡的朋友，點個贊鼓勵下新手唄~