越整理越要找更多資料，越寫越發覺自己不懂的東西更多。學習的路還很長…
本文主要從 界面，內存，電量優化三個方面展開，梳理一下自己的知識。
界面、GPU
渲染性能
大多數用戶感知到的卡頓等性能問題的最主要根源都是因爲渲染性能。從設計師的角度，他們希望App能夠有更多的動畫，圖片等時尚元素來實現流暢的用戶體驗。但是Android系統很有可能無法及時完成那些複雜的界面渲染操作。
Android系統每隔16ms發出VSYNC信號，觸發對UI進行渲染，如果每次渲染都成功，這樣就能夠達到流暢的畫面所需要的60fps，爲了能夠實現60fps，這意味着程序的大多數操作都必須在16ms內完成。
如果你的某個操作花費時間是24ms，系統在得到VSYNC信號的時候就無法進行正常渲染，這樣就發生了丟幀現象。那麼用戶在32ms內看到的會是同一幀畫面。
(fps：每秒傳輸幀數。人眼與大腦之間的協作無法感知超過60fps的畫面更新。)
失幀原因：
用戶容易在UI執行動畫或者滑動ListView的時候感知到卡頓不流暢，是因爲這裏的操作相對複雜，容易發生丟幀的現象，從而感覺卡頓。有很多原因可以導致丟幀，也許是因爲你的layout太過複雜，無法在16ms內完成渲染，有可能是因爲你的UI上有層疊太多的繪製單元，還有可能是因爲動畫執行的次數過多。這些都會導致CPU或者GPU負載過重。
- layout太過複雜
- UI層級太深
優化方法：
佈局優化：
- 刪除佈局中無用的控件和層級
- 選擇性能較低的viewGroup(FrameLayout>LinearLayout>RelativeLayout）
- 巧用< merge/>標籤
繪製優化：
- 移除Window默認的Background （getWindows().setBackgroudDrawable(null)）
- 移除XML佈局文件中非必需的Background
- 按需顯示佔位背景圖片
- clipRect方法（繪製指定區域）<>
工具
- 開發者選項裏面的 Show GPU view updates：查看視圖更新的操作
- HierarchyViewer：查看佈局，使得佈局儘量扁平化，移除非必需的UI組件，這些操作能夠減少Measure，Layout的計算時間。
內存、CPU
雖然Android有自動管理內存的機制，但是對內存的不恰當使用仍然容易引起嚴重的性能問題。
Android執行GC操作的時候，所有線程的任何操作都會需要暫停，等待GC操作完成之後，其他操作才能夠繼續運行。
通常來說，單個的GC並不會佔用太多時間，但是大量不停的GC操作則會顯著佔用幀間隔時間(16ms)。如果在幀間隔時間裏面做了過多的GC操作，那麼自然其他類似計算，渲染等操作的可用時間就變得少了,並使得用戶感知到性能問題(卡頓，數據被GC掉)。
導致GC頻繁執行de原因：
- Memory Churn內存抖動，內存抖動是因爲大量的對象被創建又在短時間內馬上被釋放。
造成內存不恰當使用的因素：
- （內存抖動）大量的對象被創建又在短時間內馬上被釋放導致頻繁GC。
- （內存泄漏）不必要的數據不易被GC 導致內存佔用過大，必要數據被優先清除。
- 使用佔用內存大的對象
- 內存對象沒有被重複利用
- …
工具：
爲了尋找內存的性能問題，Android Studio提供了工具來幫助開發者。
- Memory Monitor：查看整個app所佔用的內存，以及發生GC的時刻。（短時間內發生大量的GC操作是一個危險的信號。)
- Allocation Tracker：使用此工具來追蹤內存的分配。
- Heap Tool：查看當前內存快照，便於對比分析哪些對象有可能是泄漏了的。
策略
- 減少對象佔用的內存
- 內存de重複利用
- 避免對象的內存泄露
- 內存使用策略優化
電源
電量其實是目前手持設備最寶貴的資源之一，大多數設備都需要不斷的充電來維持繼續使用。
千萬不能讓你的應用成爲消耗電量的大戶。
有下面一些措施能夠顯著減少電量的消耗：
- 我們應該儘量減少喚醒屏幕的次數與持續的時間，使用WakeLock來處理喚醒的問題，能夠正確執行喚醒操作並根據設定及時關閉操作進入睡眠狀態。
- 某些非必須馬上執行的操作，例如上傳歌曲，圖片處理等，可以等到設備處於充電狀態或者電量充足的時候才進行。
- 觸發網絡請求的操作，每次都會保持無線信號持續一段時間，我們可以把零散的網絡請求打包進行一次操作，避免過多的無線信號引起的電量消耗。關於網絡請求引起無線信號的電量消耗，還可以參考這裏:http://blog.csdn.net/sinat_15877283/article/details/50762297
獻上我寫這邊博文的大綱：
項目中一直需要考慮的問題：如何高效的保留更多的電量與不斷促使用戶使用你的App會消耗電量！！！
