要點提煉|開發藝術之性能優化

時間 2019-11-09

標籤要點提煉開發藝術性能優化欄目系統性能简体版

原文原文鏈接

本篇重點是性能優化，包括內容：

佈局優化
繪製優化
內存泄漏優化
- MAT工具
響應速度優化
ListView優化
Bitmap優化
線程優化
其餘

1.佈局優化java

a.核心思想：儘可能減小布局文件的層級。git

b.方式：github

多嵌套狀況下可以使用RelativeLayout減小嵌套。
佈局層級相同的狀況下使用LinearLayout，它比RelativeLayout更高效。
使用<include>標籤重用佈局、<merge>標籤減小層級、<ViewStub>標籤懶加載。詳見佈局篇--佈局原則

補充實例： Android最佳性能實踐--佈局優化技巧緩存

2.繪製優化性能優化

a.核心思想：避免在View.onDraw()中執行大量的操做。數據結構

b.方式：工具

避免建立新的局部對象，由於onDraw()可能被屢次調用而產生大量的臨時對象，致使佔用過多內存、系統頻繁gc，下降了執行效率。
避免作耗時任務，以及大量循環操做。

3.內存泄漏優化佈局

a.內存泄漏(Memory Leak)：程序在申請內存後，沒法釋放已申請的內存空間。是形成應用程序OOM的主要緣由之一。post

內存溢出(out of memory)：指程序在申請內存時，沒有足夠的內存空間供其使用。性能

補充閱讀：內存溢出和內存泄漏的區別

b.可能緣由：

靜態變量致使的內存泄漏
- 詳情：一個靜態變量又是非靜態內部類會一直持有對外部類的引用，致使外部類Activity沒法被回收。
- 解決辦法：將內部類設爲靜態內部類或獨立出來；使用context.getApplicationContext()。
單例模式致使的內存泄漏
- 詳情：單例傳入參數this來自Activity，使得持有對Activity的引用。
- 解決辦法：傳參context.getApplicationContext()。
屬性動畫致使的內存泄漏
- 詳情：沒有在onDestroy()中中止無限循環的屬性動畫，使得View持有了Activity。
- 解決辦法：在Activity.onDestroy()中調用Animator.cancel()中止動畫。
Handler致使的內存泄漏
- 詳情：Message持有對Handler的引用，而非靜態內部類的Handler又隱式持有對外部類Activity的引用，使得引用關係會保持至消息獲得處理，從而阻止了Activity的回收。
- 解決辦法：使用靜態內部類+WeakReference弱引用；當外部類結束生命週期時清空消息隊列。
線程致使的內存泄漏
- 詳情：AsyncTask/Runnable以匿名內部類的方式存在，會隱式持有對所在Activity的引用。
- 解決辦法：將AsyncTask和Runnable設爲靜態內部類或獨立出來；在線程內部採用弱引用保存Context引用。
資源未關閉致使的內存泄漏
- 詳情：未及時註銷資源致使內存泄漏，如BraodcastReceiver、File、Cursor、Stream、Bitmap等。
- 解決辦法：在Activity銷燬的時候要及時關閉或者註銷。
  - BraodcastReceiver：調用unregisterReceiver()註銷；
  - Cursor，Stream、File：調用close()關閉；
  - Bitmap：調用recycle()釋放內存（2.3版本後無需手動）。
Adapter致使的內存泄漏
- 詳情：不使用緩存而只依靠getView() 每次從新實例化Item，會給gc製造壓力。
- 解決辦法：在構造Adapter時使用緩存的convertView。