提高Android 應用效能
開發Android系統的應用程式，開發人員獲得了很多的自由，App的擁有者也見證了使用者的不斷增長。不過，在此過程中開發者也面對著很多應用開發的挑戰。
- 開發人員發現很多Android os版本很難跟進開發。
- 執行Android系統的裝置型別有170+種，這也是Android開發一個巨大的挑戰。每種裝置有不同的螢幕尺寸、攝像頭按鈕、鍵盤形式等等，使得開發成為一個噩夢。
記住以下幾點，我們可以在一定程度上提高我們應用程式的效能。以下介紹會降低程式的效能的因素和我們可以做的一些提升。
Slow Rendering
Slow Rendering 是最常見的效能問題。設計師希望我們做出的效果和我們最後做出的效果可能是不同的， 如果過分追求視覺化的效果，可能會導致開發的失敗。
渲染是根據時間來定義的，以保證60fps的平滑執行，不發生掉幀或者延時。
什麼會引起Slow Rendering
系統每16ms嘗試繪製一次介面，這意味著我們的應用必須在16ms內完成所有的更新介面的邏輯。
如果我們的應用不能在16ms完成邏輯會怎麼樣呢：
以上圖中就是掉幀。舉例來說，如果我們的邏輯處理時間消耗了24ms，就會發生掉幀。系統嘗試去繪製新的一幀，但是更新邏輯還沒有完成。所以系統只能不重新整理介面。這使得使用者看到的介面是32ms重新整理而不是16ms。即使只掉了一幀，動畫也會看出不夠流暢。
以下的工具可以用於提高渲染效果
Hierarchy Viewer
Hierarchy Viewer是Android裝置檢視器中內嵌的一個工具，可以幫助我們檢視層級佈局中各個View的屬性和佈局速度。它可以幫助我們發現由於介面層級結構引起的效能問題，幫助我們簡化佈局，減少過度繪製。GPU渲染模式分析
GPU渲染模式分析可以快速視覺化顯示每一幀相對於16ms的實際繪製時間。
開啟GUP渲染模式分析的方法如下：
- 設定> 開發者工具
- 在監控設定裡選擇GPU呈現模式分析
- 在彈出的選擇框中選擇 在螢幕上顯示為條形圖
- 開啟需要除錯的應用，可以看到代表著繪製時間的條形圖?。
螢幕上的橫座標顯示時間的流動，縱座標顯示每幀的繪製時間。如果繪製時間超過了16ms的基準線，使用者就會感覺到應用卡頓。
應用啟動時間
App啟動有兩種情況，每種啟動情況會影響應用從圖示到使用者可見使用的時間。
冷啟動
冷啟動是指應用從0開始啟動，即應用在裝置重啟或者在被系統kill掉之後的第一次啟動。
在冷啟動時，系統有三個任務：
- 裝置並啟動App
- 隨著應用的啟動立即展示一個黑色的啟動視窗
- 建立應用程式
熱啟動
相比冷啟動，熱啟動更簡單，消耗更小。在熱啟動中，系統的工作就是把activity放置到前臺。如果應用中的所有Activity是保留在記憶體中，app就可以不用重複初始化物件，佈局設定，和渲染。
如何解決應用啟動延時的問題
只初始化必要的物件，比如，可以把全域性靜態變數放置在單例模式中，這樣應用在真正使用變數時才會初始化而不是在應用啟動時。
壓扁應用層級，減少冗餘的view和巢狀。
資源初始化放置在非同步執行緒中執行。
讓應用先載入並展示view，之後再更新view依賴於bitmap或者其他資源的屬性。
佈局
佈局是App直接影響使用者體驗的一個重要部分。如果實現不合理，則在展示時導致記憶體資源緊張。每一個在app中小部件或者佈局，都需要執行初始化、佈局、和繪製。比如：使用LinearLayout的巢狀例項可能會導致檢視層次結構過深。
如何優化佈局呢
優化佈局層級
使用基本的佈局結構可以獲得最有效的佈局。然而，每一個在app中小部件或者佈局，都需要執行初始化、佈局、和繪製。比如：使用LinearLayout的巢狀例項可能會導致檢視層次結構過深。此外，巢狀多個使用了layout_weight屬性的LiaearLayout會非常耗時，因為每個child要被計算兩次。這一點在佈局被多次載入時更要注意，比如在listview或者gridview中載入。複用佈局
複用佈局非常強大，允許我們建立複雜的可複用的佈局。比如，一個yes/no的button，一個自定義的進度條，或者一個Textview。也就是說可以單獨提取、管理在多個佈局中使用的通用元素，然後在layout中include它們。按需載入檢視
有時我們的佈局中有些複雜的佈局很少使用，無論是專案詳細資訊，進度指示器還是撤消訊息，可以通過僅在需要時載入檢視來減少記憶體使用並加快渲染速度。
電池使用
電量使用也是Android開發中需要優化的一個很重要的部分，有助於使用者的存留。
節約電量使用一些建議：
- 減少網路請求的次數
- 避免使用喚醒鎖
- 謹慎使用GPS
- 謹慎使用Alarm 管理器
- 使用批量排程