Android 性能優化 閱讀筆記

源:Android性能優化典範 - 第1季 http://hukai.me/android-performance-patterns/

筆記:

Android系統每隔16ms發出VSYNC信號,觸發對UI進行渲染,如果每次渲染都成功,這樣就能夠達到流暢的畫面所需要的60fps,爲了能夠實現60fps,這意味着程序的大多數操作都必須在16ms內完成。但是,layout太過複雜、UI上有層疊太多的繪製單元、動畫執行的次數過多等原因都會導致CPU或者GPU負載過重,從而無法在16ms內完成。開發者選項裏面有個“調試GPU過度繪製”功能可供開發者調試。

僅僅是通過移除非必須的背景圖片,這就能夠減少大量的紅色Overdraw區域,增加藍色區域的佔比。這一措施能夠顯著提升程序性能。

Android需要把XML佈局文件轉換成GPU能夠識別並繪製的對象。這個操作是在DisplayList的幫助下完成的。在某個View第一次需要被渲染時,DisplayList會因此而被創建,當這個View要顯示到屏幕上時,我們會執行GPU的繪製指令來進行渲染。如果你在後續有執行類似移動這個View的位置等操作而需要再次渲染這個View時,我們就僅僅需要額外操作一次渲染指令就夠了。然而任何時候View中的繪製內容發生變化時,都會重新執行創建DisplayList,渲染DisplayList,更新到屏幕上等一系列操作。這個流程的表現性能取決於你的View的複雜程度,View的狀態變化以及渲染管道的執行性能。

那些簡化不了的多組重疊組件的自定義View,我們可以通過canvas.clipRect()來幫助系統識別那些可見的區域,指定一塊矩形區域,只有在這個區域內纔會被繪製,其他的區域會被忽視,在clipRect區域之外的繪製指令都不會被執行,那些部分內容在矩形區域內的組件,仍然會得到繪製。從而達到可以幫助節約CPU與GPU資源的目的。

內存抖動。在同一幀裏面創建過多的對象。1、Memory Churn內存抖動,內存抖動是因爲大量的對象被創建又在短時間內馬上被釋放。2、瞬間產生大量的對象會嚴重佔用Young Generation的內存區域,當達到閥值,剩餘空間不夠的時候,也會觸發GC。即使每次分配的對象佔用了很少的內存,但是他們疊加在一起會增加Heap的壓力,從而觸發更多其他類型的GC。這個操作有可能會影響到幀率,並使得用戶感知到性能問題。例如,你需要避免在for循環裏面分配對象佔用內存,需要嘗試把對象的創建移到循環體之外,自定義View中的onDraw方法也需要引起注意,每次屏幕發生繪製以及動畫執行過程中,onDraw方法都會被調用到,避免在onDraw方法裏面執行復雜的操作,避免創建對象。對於那些無法避免需要創建對象的情況,我們可以考慮對象池模型,通過對象池來解決頻繁創建與銷燬的問題,但是這裏需要注意結束使用之後,需要手動釋放對象池中的對象。

內存泄漏。首先你需要在activity處於前臺的時候使用Heap Tool獲取一份當前狀態的內存快照,然後你需要創建一個幾乎不這麼佔用內存的空白activity用來給前一個Activity進行跳轉,其次在跳轉到這個空白的activity的時候主動調用System.gc()方法來確保觸發一個GC操作。最後,如果前面這個activity的內存都有全部正確釋放,那麼在空白activity被啓動之後的內存快照中應該不會有前面那個activity中的任何對象了。如果你發現在空白activity的內存快照中有一些可疑的沒有被釋放的對象存在,那麼接下去就應該使用Alocation Track Tool來仔細查找具體的可疑對象。我們可以從空白activity開始監聽,啓動到觀察activity,然後再回到空白activity結束監聽。這樣操作以後,我們可以仔細觀察那些對象,找出內存泄漏的真兇。

爲了尋找內存的性能問題,Android Studio提供了工具來幫助開發者。
Memory Monitor:查看整個app所佔用的內存,以及發生GC的時刻,短時間內發生大量的GC操作是一個危險的信號。
Allocation Tracker:使用此工具來追蹤內存的分配,前面有提到過。

Heap Tool:查看當前內存快照,便於對比分析哪些對象有可能是泄漏了的,請參考前面的Case。

電量優化:減少電量的消耗的方法:

  1. 我們應該儘量減少喚醒屏幕的次數與持續的時間,使用WakeLock來處理喚醒的問題,能夠正確執行喚醒操作並根據設定及時關閉操作進入睡眠狀態。
  2. 某些非必須馬上執行的操作,例如上傳歌曲,圖片處理等,可以等到設備處於充電狀態或者電量充足的時候才進行。
  3. 觸發網絡請求的操作,每次都會保持無線信號持續一段時間,我們可以把零散的網絡請求打包進行一次操作,避免過多的無線信號引起的電量消耗。


總結以上內容:1、UI儘可能簡單;2、經可能減少UI的overdraw;3、用API限定區域;4、避免內存抖動和泄漏;5、電量優化


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章