Android 性能優化之工具和優化點總結

Android性能優化學習

最近公司主抓性能優化工做，藉此春風也學習到了許多Android性能優化方面的知識。因爲組內隊友的給力，優化的成果也是比較喜人。同時也學習和實踐了很多知識，特此記錄。

1.性能優化分析工具學習

在開始代碼優化以前，先得學會使用性能分析工具。如下三個工具都是谷歌官方推出的，能夠幫助咱們定位分析問題，從而優化咱們的APP。

• System Trace

  Systrace是一個收集和檢測時間信息的工具, 它能顯示CPU和時間被消耗在哪兒了, 每一個進程和線程都在其CPU時間片內作了
  什麼事兒. 並且會指示哪一個地方出了問題, 以及給出Fix建議。給出的結果trace文件是以html形式打開的，直接用瀏覽器打開
  查看十分方便。打開方法：打開DDMS後，鏈接手機，點擊手機上方一排按鈕中的SysTrace按鈕。

  打開的效果以下圖：
  

  在代碼中打點方式以下

  

• Hierarchy Viewer

  Hierarchy Viewer提供了一個可視化的界面來觀測佈局的層級, 讓咱們能夠優化佈局層級, 刪除多餘的沒必要要的View
  層級, 提高佈局速度。另外，開發者模式中調試GPU過分繪製選項也能夠進行視圖層級調試。在SDK-> tools目錄下
  打開hierarchyviewer.bat便可。

  效果以下圖：
  

• TraceView

  一個圖形化的工具, 用來展現和分析方法的執行時間。也是一款性能優化的神器。能夠經過像打log同樣的方式去定位代碼的執行時
  間，從而能夠準肯定位是哪一段代碼的執行消耗了太多時間。相比SysTrace，功能更強大，使用起來也更復雜。

   

2.佈局優化

佈局優化相對比較容易，優化能夠先從佈局來展開。使用Hierarchy Viewer和開發者模式中關於佈局繪製的選項，能夠查到一些問題而後進行修改。

• 佈局嵌套過深 有的時候爲了趕進度，佈局設計的不是很好。層級嵌套過深的話，深度遍歷各個節點會很是消耗時間，這也是佈局優化餘地最大的一個點了。不少過深的層級是沒必要要的。若是佈局真的很複雜，不深度嵌套無法實現想要的效果。試試最新的約束佈局Constraintlayout吧。沒有使用過的話，下面這篇官方文檔能夠幫助你：
  Constraintlayout官方介紹文檔

• 使用合適的佈局 三種常見的ViewGroup的繪製速度：FrameLayout > LinerLayout > RelativeLayout。固然，若是用RelativeLayout能夠避免佈局嵌套的話是值得的。能夠根據這些去決定選用什麼樣的佈局。

• 列表控件優化 不管是ListView仍是RecycleView都有優化點，一個是convertView的複用，一個是ViewHolder的使用避免重複遍歷節點。固然這些都是基礎中的基礎了。若是發現項目中的代碼ListView或者RecycleView的使用不規範的話，趕忙進行修改吧。

• 使用include標籤 在佈局文件中，<include>標籤能夠指定插入一段佈局文件到當前佈局。這樣的話既提升了佈局複用，也減小了咱們的代碼書寫。另外，<merge>標籤能夠和<include>的標籤一塊兒使用從而減小布局層級。

• ViewStub延時加載 有些佈局，好比網絡出錯的佈局，不必在全部時候都加載出來。使用ViewStub能夠實現按需加載。ViewStub自己沒有寬高，加載起來幾乎不消耗什麼資源。當對他setVisibility(View.VISIBLE)的時候會調用它引用的真實佈局填充到當前位置，從而實現了延時加載，節省了正常加載的時間。

• 移除Activity默認背景 只要咱們不須要Activity的默認背景，就能夠移除掉，以減小Activity啓動時的渲染時間，提高啓動效率。移動方法見下：
  

3.線程優化

線程的建立和銷燬會帶來比較大的性能開銷。所以線程優化也頗有必要。查看項目中是否存在隨意new thread，線程缺少管理的狀況。使用AsyncTask或者線程池對線程進行管理，能夠提高APP的性能。另外，我比較推薦使用Rxjava來實現異步操做，既方便又優雅。

推薦一篇Rxjava的入門文章

4.內存泄露

內存泄露會致使APP佔用內存太高，影響效率，嚴重的話會致使OOM。所以若是項目存在內存泄露的話要優先解決。查找內存泄露能夠用LeakCanary等工具，具體怎麼解決，有哪些泄露點，之後有時間也寫篇總結。

5.算法優化

毋庸置疑，使用合適的算法處理事務能夠大幅提高APP的性能。固然算法不是個人強項，也只能給出一些大體的點：查詢考慮二分查找節省時間，儘可能不要使用耗時的遞歸算法。必要的時候能夠空間換時間來提升APP運行效率。

6.其餘優化點

• 異步處理耗時任務 在Activity、Fragemnt的onCreate等初始化方法中，若是執行了太耗時的操做（例如讀取各類數據），會影響頁面的加載速度，讓用戶以爲APP太慢。這時候能夠異步處理這些耗時任務，減少應用啓動的時候的負擔。

• 替換矢量圖 儘管矢量圖有諸多優勢，但矢量圖的繪製是消耗性能的。在應用初始化加載等比較影響用戶體驗的地方，仍是建議使用Bitmap來代替矢量圖，提升APP開啓效率。

• 正則表達式 經小夥伴用TraceView不斷的打點發現，正則表達式很是消耗時間。所以儘管正則表達式很是優雅，涉及到性能問題的時候，能夠改成其餘判斷方式來提升APP性能。

• 浮點類型 在Java中浮點類型的運算大概比整型數據慢兩倍，所以整型數據能解決的問題儘可能用整型。

• 減小冗餘log 開發的時候用於調試的log，在項目上線的時候沒用的要及時刪除。固然有用的log仍是要留下，以便之後分析問題。

• 刪除無用資源 沒用用的資源會增大APK大小，既然沒有用了，上線的時候固然要及時刪除。

• Lint代碼檢查 使用Lint等靜態代碼檢查工具能夠幫助咱們發現不少隱藏的問題。Lint檢查出來的問題越少，說明代碼越規範，越不容易出現各類問題，APP性能天然也會提高。

• 濫用全局廣播 全局廣播也是十分消耗性能的一個點。對於應用內的通信，使用接口回調，EventBus等手段比起廣播是更好地選擇。動態註冊廣播的時候，也不要忘了廣播的註銷。

7.總結

能夠看到除了工具的使用外，性能優化是很考驗代碼功底的。所以想要作好性能優化，強化基本功不可少。性能優化也是一件相對枯燥而難度大的工做。由於不少優化的努力可能立馬看不到效果，或者說優化的成果在數據上難以體現。咱們在作性能優化的時候也遇到果瓶頸，找不到優化方向而感到泄氣。可是堅持下來，利用好工具，從各個點去優化，總會有撥開雲霧見青天的一天！

做者：業鬆連接：https://www.jianshu.com/p/31485a3cf5ca來源：簡書簡書著做權歸做者全部，任何形式的轉載都請聯繫做者得到受權並註明出處。