這裡是Android效能優化典範第 6 季的課程學習筆記，從被@知會到有連載更新，這篇學習筆記就一直被惦記著。現在學習記錄分享一下，請多多指教包涵！這次一共才 6 個小段落，涉及的內容主要有程式啟動時間效能優化的三個方面：優化 activity 的建立過程，優化 Application 物件的啟動過程，正確使用啟動顯屏達到優化程式啟動效能的目的。另外還介紹了減少安裝包大小的 checklist 以及如何使用 VectorDrawable 來減少安裝包的大小。

1）App Launch time 101

提高程式的啟動速度意義重大，很顯然，啟動時間越短，使用者才越有耐心等待開啟這個 App 進行使用。反之啟動時間越長，使用者則越有可能來不及等到 App 開啟就已經切換到其他 App 了。程式啟動過程中的那些複雜錯誤的操作很可能導致嚴重的效能問題。

Android 系統會根據使用者的操作行為調整程式的顯示策略，用來提高程式的顯示效能。例如，一旦使用者點選桌面圖示，Android 系統會立即顯示一個啟動視窗，這個視窗會一直保持顯示，直到畫面中的元素成功載入並繪製完第一幀。這種行為常見於程式的冷啟動，或者程式的熱啟動場景（程式從後臺被喚起或者從其他 App 介面切換回來）。那麼關鍵的問題是，使用者很可能會因為從啟動視窗到顯示畫面的過程耗時過長而感到厭煩，從而導致使用者沒有來得及等程式啟動完畢就切換到其他 App 了。更嚴重的是，如果啟動時間過長，可能導致程式出現 ANR。我們應該避免出現這兩種糟糕的情況。

從技術角度來說，當用戶點選桌面圖示開始，系統會立即為這個 App 建立獨立的專屬程序，然後顯示啟動視窗，直到 App 在自己的程序裡面完成了程式的建立以及主執行緒完成了 Activity 的初始化顯示操作，再然後系統程序就會把啟動視窗替換成APP的顯示視窗。

上述流程裡面的絕大多數步驟都是由系統控制的，一般來說不會出現什麼問題，可是對於啟動速度，我們能夠控制並且需要特別關注的地方主要有三處：

1. Activity 的 onCreate 流程，特別是 UI 的佈局與渲染操作，如果佈局過於複雜很可能導致嚴重的啟動效能問題。
2. Application 的 onCreate 流程，對於大型的 App 來說，通常會在這裡做大量的通用元件的初始化操作。
3. 目前有部分 App 會提供自定義的啟動視窗，這裡可以做成品牌宣傳介面或者是給使用者提供一種程式已經啟動的視覺效果。

在正式著手解決問題之前，我們需要掌握一套正確測量評估啟動效能的方法。所幸的是，Android 系統有提供一些工具來幫助我們定位問題。

1. 首先是 display time：從 Android KitKat 版本開始，Logcat 中會輸出從程式啟動到某個 Activity 顯示到畫面上所花費的時間。這個方法比較適合測量程式的啟動時間。

2. 其次是 reportFullyDrawn 方法：我們通常來說會使用非同步懶載入的方式來提升程式畫面的顯示速度，這通常會導致的一個問題是，程式畫面已經顯示，可是內容卻還在載入中。為了衡量這些非同步載入資源所耗費的時間，我們可以在非同步載入完畢之後呼叫activity.reportFullyDrawn()方法來告訴系統此時的狀態，以便獲取整個載入的耗時。

3. 然後是 Method Tracing：前面兩個方法提供了啟動耗時的總時間，可是卻無法提供具體的耗時細節。為了獲取具體的耗時分佈情況，我們可以使用 Method Tracing工具來進行詳細的測量。

4. 最後是 Systrace：我們可以在 onCreate 方法裡面新增trace.beginSection()與trace.endSection()方法來宣告需要跟蹤的起止位置，系統會幫忙統計中間經歷過的函式呼叫耗時，並輸出報表。

2）App Launch Time & Activity Creation

提升 Activity 的建立速度是優化 App 啟動速度的首要關注目標。從桌面點選 App 圖示啟動應用開始，程式會顯示一個啟動視窗等待 Activity 的建立載入完畢再進行顯示。在 Activity 的建立載入過程中，會執行很多的操作，例如設定頁面的主題、初始化頁面的佈局、載入圖片、獲取網路資料、讀寫 Preference 等。

上述操作的任何一個環節出現效能問題都可能導致畫面不能及時顯示，影響了程式的啟動速度。上一個段落我們介紹了使用 Method Tracing 來發現那些耗時佔比相對較多的方法。假設發現某個方法執行時間過長，接下去就可以使用 Systrace 來幫忙定位到底是什麼原因導致那個方法執行時間過長。

除了使用工具進行具體定位分析效能問題之外，以下兩點經驗可以幫助我們對 Activity 啟動做效能優化：

1. 優化佈局耗時：一個佈局層級越深，裡面包含需要載入的元素越多，就會耗費更多的初始化時間。關於佈局效能的優化，這裡就不展開描述了。
2. 非同步延遲載入：一開始只初始化最需要的佈局，非同步載入圖片，非立即需要的元件可以做延遲載入。

3）App Launch Time & Bloated Application Objects

在 Application 初始化的地方做太多繁重的事情是可能導致嚴重啟動效能問題的元凶之一。Application 裡面的初始化操作不結束，其他任意的程式操作都無法進行。

有時候，我們會一股腦地把絕大多數全域性元件的初始化操作都放在 Application 的onCreate裡面，但其實很多元件是需要做區別對待的，有些可以做延遲載入，有些可以放到其他的地方做初始化操作，特別需要留意包含 Disk IO 操作、網路訪問等嚴重耗時的任務，它們會嚴重阻塞程式的啟動。

優化這些問題的解決方案是做延遲載入，可以在 Application 裡面做延遲載入，也可以把一些初始化的操作延遲到元件真正被呼叫到的時候再做載入。

4）App Launch Time & Theme Launch Screens

啟動閃屏不僅僅可以作為品牌宣傳頁，還能夠減輕使用者對啟動耗時的感知，但是如果使用不當，將適得其反。前面介紹過當點選桌面圖示啟動 App 的時候，程式會顯示一個啟動視窗，一直到頁面的渲染載入完畢。如果程式的啟動速度足夠快，我們看到的閃屏視窗停留顯示的時間則會很短，但是當程式啟動速度偏慢的時候，這個啟動閃屏可以一定程度上減輕使用者等待的焦慮感，避免使用者過於輕易的關閉應用。

目前大多數開發者都會通過設定啟動視窗主題的方式來替換系統預設的啟動視窗，通過這種方式只是使用『障眼法』弱化了使用者對啟動時間的感知，但本質上並沒有對啟動速度做什麼優化。也有些 App 通過關閉啟動視窗屬性android:windowDisablePreview的方式來直接移除系統預設的啟動視窗，但是這樣的弊端是使用者從點選桌面圖示到真的看到實際頁面的這段時間當中，畫面沒有任何變化，這樣的使用者體驗是十分糟糕的！

對於啟動閃屏，正確的使用方法是自定義一張圖片，把這張圖片通過設定主題的方式顯示為啟動閃屏，程式碼執行到主頁面的onCreate的時候設定為程式正常的主題。

5）Smaller APKs: A Checklist

減少應用程式安裝包的大小，不僅僅減少了使用者的網路資料流量還減少了下載等待的時間。毋庸置疑，儘量減少程式安裝包的大小是十分有必要的。通常來說，減少程式安裝包的大小有兩條規律：要麼減少程式資源的大小，要麼就是減少程式的程式碼量。這裡總結一個簡易版的減少安裝包大小的 Checklist。

減少程式圖片資源的大小

1. 確保在 build.gradle 檔案中開啟了minifEnabled與shrinkResources的屬性，這兩個屬性可以幫助移除那些在程式中使用不到的程式碼與資源，幫助減少 App 的安裝包大小。

2. 有選擇性的提供對應解析度的圖片資源，系統會自動匹配最合適解析度的圖片並執行拉伸或者壓縮的處理。

3. 在符合條件的情況下，使用 Vertor Drawable 替代傳統的 PNG/JPEG 圖片，能夠極大地減少圖片資源的大小。傳統模式下，針對不同 dpi 的手機都需要提供一套 PNG/JPEG 的圖片，而如果使用 Vector Drawable 的話，只需要一個 XML 檔案即可。

4. 儘量複用已經存在的資源圖片，使用程式碼的方式對已有的資源進行復用，如下圖所示：

以上幾點雖然看起來都微不足道，但是真正執行之後，能夠顯著減少安裝包的資源圖片大小。

減少程式的程式碼量

1. 開啟 MinifEnabled、Proguard。開啟這些編譯屬性之後，程式在打包的時候就不會把沒有引用到的程式碼編譯進來，以此達到減少安裝包大小的目的。

2. 注意因為編譯行為額外產生的方法數，例如類似 Enum、Protocal Buffer 可能導致方法數與類的個數增加。

3. 部分引入到工程中的 jar 類庫可能並不是專門針對移動端 App 而設計的，它們最開始可能是運用在 PC 或者 Server 上的。使用這些類庫不僅僅額外增加了包的大小，還增加了編譯時間。單純依靠 Proguard 可能無法完全移除那些使用不到的方法，最佳的方式是使用一些更加輕量化，專門為 Android App 設計的 jar 類庫。

安裝包的拆分

設想一下，一個 low dpi，API<14 的使用者手機下載安裝的 APK 裡面卻包含了大量 xxhdpi 的資原始檔，對於這個使用者來說，這個 APK 是存在很大的資源浪費的。幸好 Android 平臺為我們提供了拆分 APK 的方法，它能夠根據 API Level、螢幕大小以及 GPU 版本的不同進行拆分，使得對應平臺的使用者下載到最合適自己手機的安裝包。

6）VectorDrawable for smaller APKs

針對不同的解析度提供多張精度的圖片會額外增加 APK 的大小，這個問題的解決方案是考慮使用 VectorDrawable，它僅僅只需要一個檔案，能夠動態生成對應解析度的圖片。

VectorDrawable通過XML檔案描述圖片的形狀，大小，樣式。

通過這種方式，我們可以顯著減少圖片資源對安裝包大小的影響。

使用 VectorDrawable 還可以避免因為使用幀動畫導致的圖片資源過多的情況，如下圖所示：

前面介紹了 VectorDrawable(VD) 的優勢，但是在使用 VectorDrawable 的時候，還是有以下的問題需要特別注意的？

• 首先 VD 的載入有異於 JPEG/PNG 檔案，圖片檔案可以依靠硬體進行紋理的渲染，而 VD 檔案需要先進行載入解析，然後才能夠進行紋理的渲染。

• 其次 VD 檔案適用於簡單有規則的圖片渲染，不適用於那些紋理過於複雜的圖片，這樣不僅僅會過度增加描述檔案的複雜度還可能無法獲取到想要的渲染效果。

• 最後，VD 檔案中關於 Path 的描述需要儘量簡化，複雜冗餘的 Path 資訊不僅對得到想要的圖片沒有益處，還增加了載入渲染的難度。