這裡是Android性能優化典範第6季的課程學習筆記，從被@知會到有連載更新，這篇學習筆記就一直被惦記著，現在學習記錄分享一下，請多多指教包涵！這次一共才6個小段落，涉及的內容主要有：程式啟動時間性能優化的三個方面：優化activity的創建過程，優化application對象的啟動過程，正確使用啟... ...
本文來自於騰訊bugly開發者社區，非經作者同意，請勿轉載，原文地址：http://dev.qq.com/topic/580d91208d80e49771f0a07c
導語
這裡是Android性能優化典範第6季的課程學習筆記，從被@知會到有連載更新，這篇學習筆記就一直被惦記著，現在學習記錄分享一下，請多多指教包涵！這次一共才6個小段落，涉及的內容主要有：程式啟動時間性能優化的三個方面：優化activity的創建過程，優化application對象的啟動過程，正確使用啟動顯屏達到優化程式啟動性能的目的。另外還介紹了減少安裝包大小的checklist以及如何使用VectorDrawable來減少安裝包的大小。
1. App Launch time 101
提高程式的啟動速度意義重大，很顯然，啟動時間越短，用戶才越有耐心等待打開這個APP進行使用，反之啟動時間越長，用戶則越有可能來不及等到APP打開就已經切換到其他APP了。程式啟動過程中的那些複雜錯誤的操作很可能導致嚴重的性能問題。Android系統會根據用戶的操作行為調整程式的顯示策略，用來提高程式的顯示性能。例如，一旦用戶點擊桌面圖標，Android系統會立即顯示一個啟動視窗，這個視窗會一直保持顯示直到畫面中的元素成功載入並繪製完第一幀。這種行為常見於程式的冷啟動，或者程式的熱啟動場景（程式從後臺被喚起或者從其他APP界面切換回來）。那麼關鍵的問題是，用戶很可能會因為從啟動視窗到顯示畫面的過程耗時過長而感到厭煩，從而導致用戶沒有來得及等程式啟動完畢就切換到其他APP了。更嚴重的是，如果啟動時間過長，可能導致程式出現ANR。我們應該避免出現這兩種糟糕的情況。
從技術角度來說，當用戶點擊桌面圖標開始，系統會立即為這個APP創建獨立的專屬進程，然後顯示啟動視窗，直到APP在自己的進程裡面完成了程式的創建以及主線程完成了Activity的初始化顯示操作，再然後系統進程就會把啟動視窗替換成APP的顯示視窗。
上述流程裡面的絕大多數步驟都是由系統控制的，一般來說不會出現什麼問題，可是對於啟動速度，我們能夠控制並且需要特別關註的地方主要有三處：
- Activity的onCreate流程，特別是UI的佈局與渲染操作，如果佈局過於複雜很可能導致嚴重的啟動性能問題。
- Application的onCreate流程，對於大型的APP來說，通常會在這裡做大量的通用組件的初始化操作。
- 目前有部分APP會提供自定義的啟動視窗，這裡可以做成品牌宣傳界面或者是給用戶提供一種程式已經啟動的視覺效果。
在正式著手解決問題之前，我們需要掌握一套正確測量評估啟動性能的方法。所幸的是，Android系統有提供一些工具來幫助我們定位問題。
- 首先是display time：從Android KitKat版本開始，Logcat中會輸出從程式啟動到某個Activity顯示到畫面上所花費的時間。這個方法比較適合測量程式的啟動時間。
- 其次是reportFullyDrawn方法：我們通常來說會使用非同步懶載入的方式來提升程式畫面的顯示速度，這通常會導致的一個問題是，程式畫面已經顯示，可是內容卻還在載入中。為了衡量這些非同步載入資源所耗費的時間，我們可以在非同步載入完畢之後調用
activity.reportFullyDrawn()方法來告訴系統此時的狀態，以便獲取整個載入的耗時。
- 然後是Method Tracing：前面兩個方法提供了啟動耗時的總時間，可是卻無法提供具體的耗時細節。為了獲取具體的耗時分佈情況，我們可以使用Method Tracing工具來進行詳細的測量。
- 最後是Systrace：我們可以在onCreate方法裡面添加trace.beginSection()與trace.endSection()方法來聲明需要跟蹤的起止位置，系統會幫忙統計中間經歷過的函數調用耗時，並輸出報表。
2. App Launch Time & Activity Creation
提升Activity的創建速度是優化APP啟動速度的首要關註目標。從桌面點擊APP圖標啟動應用開始，程式會顯示一個啟動視窗等待Activity的創建載入完畢再進行顯示。在Activity的創建載入過程中，會執行很多的操作，例如設置頁面的主題，初始化頁面的佈局，載入圖片，獲取網路數據，讀寫Preference等等。
上述操作的任何一個環節出現性能問題都可能導致畫面不能及時顯示，影響了程式的啟動速度。上一個段落我們介紹了使用Method Tracing來發現那些耗時占比相對較多的方法。假設我們發現某個方法執行時間過長，接下去就可以使用Systrace來幫忙定位到底是什麼原因導致那個方法執行時間過長。
除了使用工具進行具體定位分析性能問題之外，以下兩點經驗可以幫助我們對Activity啟動做性能優化：
- 優化佈局耗時：一個佈局層級越深，裡面包含需要載入的元素越多，就會耗費更多的初始化時間。關於佈局性能的優化，這裡就不展開描述了！
- 非同步延遲載入：一開始只初始化最需要的佈局，非同步載入圖片，非立即需要的組件可以做延遲載入。
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:
減少程式圖片資源的大小
- 確保在build.gradle文件中開啟了
minifEnabled與shrinkResources的屬性，這兩個屬性可以幫助移除那些在程式中使用不到的代碼與資源，幫助減少APP的安裝包大小。
- 有選擇性的提供對應解析度的圖片資源，系統會自動匹配最合適解析度的圖片並執行拉伸或者壓縮的處理。
- 在符合條件的情況下，使用Vertor Drawable替代傳統的PNG/JPEG圖片，能夠極大的減少圖片資源的大小。傳統模式下，針對不同dpi的手機都需要提供一套PNG/JPEG的圖片，而如果使用Vector Drawable的話，只需要一個XML文件即可。
- 儘量復用已經存在的資源圖片，使用代碼的方式對已有的資源進行復用，如下圖所示：
以上幾點雖然看起來都微不足道，但是真正執行之後，能夠顯著減少安裝包的資源圖片大小。
減少程式的代碼量
開啟MinifEnabled，Proguard。打開這些編譯屬性之後，程式在打包的時候就不會把沒有引用到的代碼編譯進來，以此達到減少安裝包大小的目的。
註意因為編譯行為額外產生的方法數，例如類似Enum，Protocal Buffer可能導致方法數與類的個數增加。
部分引入到工程中的jar類庫可能並不是專門針對移動端APP而設計的，他們最開始可能是運用在PC或者Server上的。使用這些類庫不僅僅額外增加了包的大小，還增加了編譯時間。單純依靠Proguard可能無法完全移除那些使用不到的方法，最佳的方式是使用一些更加輕量化，專門為Android APP設計的jar類庫。
安裝包的拆分
設想一下，一個low dpi，API<14的用戶手機下載安裝的APK裡面卻包含了大量xxhdpi的資源文件，對於這個用戶來說，這個APK是存在很大的資源浪費的。幸好Android平臺為我們提供了拆分APK的方法，它能夠根據API Level，屏幕大小以及GPU版本的不同進行拆分，使得對應平臺的用戶下載到最合適自己手機的安裝包。
更多關於安裝包拆分的信息，請查看Configure APK Splits與Maintaining Multiple APKs(由於國內應用分發市場的現狀，這一條幾乎沒有辦法執行)。
6. VectorDrawable for smaller APKs
針對不同的解析度提供多張精度的圖片會額外增加APK的大小，針對這個問題的解決方案是考慮使用VectorDrawable，它僅僅只需要一個文件，能夠動態生成對應解析度的圖片。
VectorDrawable通過XML文件描述圖片的形狀，大小，樣式。
通過這種方式，我們可以顯著減少圖片資源對安裝包大小的影響。
使用VectorDrawable還可以避免因為使用幀動畫導致的圖片資源過多的情況，如下圖所示
前面介紹了VectorDrawable(VD)的優勢，但是在使用VectorDrawable的時候，還是有以下的問題需要特別註意的？
- 首先VD的載入有異於JPEG/PNG文件，圖片文件可以依靠硬體進行紋理的渲染，而VD文件需要先進行載入解析，然後才能夠進行紋理的渲染。
- 其次VD文件適用於簡單有規則的圖片渲染，不適用於那些紋理過於複雜的圖片，這樣不僅僅會過度增加描述文件的複雜度還可能無法獲取到想要的渲染效果。
- 最後VD文件中關於Path的描述需要儘量簡化，複雜冗餘的Path信息不僅對得到想要的圖片沒有益處，還增加了載入渲染的難度。
作者簡介：
胡凱，騰訊 Android 工程師，熱愛開源與分享，維護 Android 官方培訓課程協作項目，關註 Android 應用性能優化的總結與分享，推崇 Android 官方最佳實踐。
個人博客：http://hukai.me
Github：https://github.com/kesenhoo。
