性能相關

App啟動

提高程序的啟動速度意義重大，很顯然，啟動時間越短，用戶才越有耐心等待打開這個APP進行使用，反之啟動時間越長，用戶則越有可能來不及等到APP打開就已經切換到其他APP了。程序啟動過程中的那些復雜錯誤的操作很可能導致嚴重的性能問題。Android系統會根據用戶的操作行為調整程序的顯示策略，用來提高程序的顯示性能。例如，一旦用戶點擊桌面圖標，Android系統會立即顯示一個啟動窗口，這個窗口會一直保持顯示直到畫面中的元素成功加載並繪制完第一幀。這種行為常見於程序的冷啟動，或者程序的熱啟動場景（程序從後台被喚起或者從其他APP界面切換回來）。那麼關鍵的問題是，用戶很可能會因為從啟動窗口到顯示畫面的過程耗時過長而感到厭煩，從而導致用戶沒有來得及等程序啟動完畢就切換到其他APP了。更嚴重的是，如果啟動時間過長，可能導致程序出現ANR。我們應該避免出現這兩種糟糕的情況。
從技術角度來說，當用戶點擊桌面圖標開始，系統會立即為這個APP創建獨立的專屬進程，然後顯示啟動窗口，直到APP在自己的進程裡面完成了程序的創建以及主線程完成了Activity的初始化顯示操作，再然後系統進程就會把啟動窗口替換成APP的顯示窗口。

上述流程裡面的絕大多數步驟都是由系統控制的，一般來說不會出現什麼問題，可是對於啟動速度，我們能夠控制並且需要特別關注的地方主要有三處：<喎?/kf/ware/vc/" target="_blank" class="keylink">vcD4NCjxwPjGjqUFjdGl2aXR5tcRvbkNyZWF0ZcH3s8yjrMzYsfDKx1VJtcSyvL7W0+vk1si+stnX96OsyOe5+7K8vta5/dPauLTU07rcv8nE3LW81sLRz9bYtcTG9Lav0NTE3M7KzOKhozxiciAvPg0KMqOpQXBwbGljYXRpb261xG9uQ3JlYXRlwfezzKOsttTT2rTz0M21xEFQUMC0y7WjrM2os6O74dTa1eLA79f2tPPBv7XEzajTw9fpvP61xLP1yry7r7LZ1/ehozxiciAvPg0KM6OpxL/HsNPQsr+31kFQULvhzOG5qdfUtqjS5bXExvS2r7Swv9qjrNXiwO+/ydLU1/azyca3xcbQ+7SrvefD5rvy1d/Kx7j408O7p8zhuanSu9bWs8zQ8tLRvq3G9LavtcTK07710Ke5+6GjPGJyIC8+DQrU2tX9yr3XxcrWveK+9s7KzOLWrsewo6zO0sPH0OjSqtXGztXSu8zX1f3It7Liwb/GwLnAxvS2r9DUxNy1xLe9t6iho8v50NK1xMrHo6xBbmRyb2lkz7XNs9PQzOG5qdK70Km5pL7fwLSw79b6ztLDx7aozrvOyszioaM8L3A+DQo8cD4xo6nK18/IysdkaXNwbGF5IHRpbWWjurTTQW5kcm9pZCBLaXRLYXSw5rG+v6rKvKOsTG9nY2F01tC74crks/a007PM0PLG9Lavtb3Es7j2QWN0aXZpdHnP1Mq+tb27rcPmyc/L+buot9G1xMqxvOSho9XiuPa3vbeosci9z8rKus+y4sG/s8zQ8rXExvS2r8qxvOShozxiciAvPg0KPGltZyBhbHQ9"這裡寫圖片描述" src="/uploadfile/Collfiles/20161019/20161019092045309.png" title="\" />

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

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

4）最後是Systrace：我們可以在onCreate方法裡面添加trace.beginSection()與trace.endSection()方法來聲明需要跟蹤的起止位置，系統會幫忙統計中間經歷過的函數調用耗時，並輸出報表。

啟動閃屏

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

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


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

打包APK相關：

減小APK大小：

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

減少程序圖片資源的大小

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

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

4）盡量復用已經存在的資源圖片，使用代碼的方式對已有的資源進行復用，如下圖所示：

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

減少程序的代碼量

1）注意因為編譯行為額外產生的方法數，例如類似Enum，Protocal Buffer可能導致方法數與類的個數增加。
2）部分引入到工程中的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(由於國內應用分發市場的現狀，這一條幾乎沒有辦法執行)。

UI相關：

Profile GPU Rendering：

從Android M系統開始，系統更新了GPU Profiling的工具來幫助我們定位UI的渲染性能問題。早期的CPU Profiling工具只能粗略的顯示出Process，Execute，Update三大步驟的時間耗費情況。

但是僅僅顯示三大步驟的時間耗費情況，還是不太能夠清晰幫助我們定位具體的程序代碼問題，所以在Android M版本開始，GPU Profiling工具把渲染操作拆解成如下8個詳細的步驟進行顯示。

舊版本中提到的Proces，Execute，Update還是繼續得到了保留，他們的對應關系如下：

接下去我們看下其他五個步驟分別代表了什麼含義：

Sync & Upload：通常表示的是准備當前界面上有待繪制的圖片所耗費的時間，為了減少該段區域的執行時間，我們可以減少屏幕上的圖片數量或者是縮小圖片本身的大小。
Measure & Layout：這裡表示的是布局的onMeasure與onLayout所花費的時間，一旦時間過長，就需要仔細檢查自己的布局是不是存在嚴重的性能問題。
Animation：表示的是計算執行動畫所需要花費的時間，包含的動畫有ObjectAnimator，ViewPropertyAnimator，Transition等等。一旦這裡的執行時間過長，就需要檢查是不是使用了非官方的動畫工具或者是檢查動畫執行的過程中是不是觸發了讀寫操作等等。
Input Handling：表示的是系統處理輸入事件所耗費的時間，粗略等於對於的事件處理方法所執行的時間。一旦執行時間過長，意味著在處理用戶的輸入事件的地方執行了復雜的操作。
Misc/Vsync Delay：如果稍加注意，我們可以在開發應用的Log日志裡面看到這樣一行提示：I/Choreographer(691): Skipped XXX frames! The application may be doing too much work on its main thread。這意味著我們在主線程執行了太多的任務，導致UI渲染跟不上vSync的信號而出現掉幀的情況。
上面八種不同的顏色區分了不同的操作所耗費的時間，為了便於我們迅速找出那些有問題的步驟，GPU Profiling工具會顯示16ms的阈值線，這樣就很容易找出那些不合理的性能問題，再仔細看對應具體哪個步驟相對來說耗費時間比例更大，結合上面介紹的細化步驟，從而快速定位問題，修復問題。