Android設備作爲一種移動設備，不管是內存還是CPU的性能都受到了一定的限制，也意味着Android程序不可能無限制的使用內存和CPU資源，過多的使用內存容易導致OOM，過多的使用CPU資源容易導致手機變得卡頓甚至無響應（ANR）。這也對開發人員提出了更高的要求。
本章主要介紹一些有效的性能優化方法。主要包括佈局優化、繪製優化、內存泄漏優化、響應速度優化、ListView優化、Bitmap優化、線程優化等；同時還介紹了ANR日誌的分析方法。
Android的性能優化方法
Google官方的Android性能優化典範專題短視頻課程是學習Android性能優化極佳的課程，目前已更新到第五季；
放一個Google官方維護的國內方便訪問的鏈接地址 youku地址
佈局優化
佈局優化的思想就是儘量減少佈局文件的層級，這樣繪製界面時工作量就少了，那麼程序的性能自然就高了。
刪除無用的控件和層級，其次就是有選擇的使用性能較低的ViewGroup，如果佈局中既可以使用Linearlayout也可以使用RelativeLayout，那就是用LinearLayout，因爲RelativeLayout功能比較複雜，它的佈局過程需要花費更多的CPU時間。有時候通過LinearLayou無法實現產品效果，需要通過嵌套來完成，這種情況還是推薦使用RelativeLayout，因爲ViewGroup的嵌套相當於增加了佈局的層級，同樣降低程序性能。
另一種手段是採用標籤、標籤和ViewStub。
標籤
標籤用於佈局重用，可以將一個指定的佈局文件加載到當前佈局文件中。只支持android:layout_開頭的屬性，當然android:id這個屬性是個特例；如果指定了android:layout_這種屬性，那麼要求android:layout_width和android:layout_height必須存在，否則android:layout_屬性無法生效。如果指定了id屬性，同時被包含的佈局文件的根元素也指定了id屬性，會以指定的這個id屬性爲準。
標籤
標籤一般和標籤一起使用從而減少佈局的層級。如果當前佈局是一個豎直方向的LinearLayout，這個時候被包含的佈局文件也採用豎直的LinearLayout，那麼顯然被包含的佈局文件中的這個LinearLayout是多餘的，通過標籤就可以去掉多餘的那一層LinearLayout。
ViewStub
ViewStub意義在於按需加載所需的佈局文件，因爲實際開發中，有很多佈局文件在正常情況下是不會現實的，比如網絡異常的界面，這個時候就沒必要在整個界面初始化的時候將其加載進來，在需要使用的時候再加載會更好。在需要加載ViewStub佈局時：
((ViewStub)findViewById(R.id.stub_import)).setVisibility(View.VISIBLE);
//或者
View importPanel = ((ViewStub)findViewById(R.id.stub_import)).inflate();
當ViewStub通過setVisibility或者inflate方法加載後，ViewStub就會被它內部的佈局替換掉，ViewStub也就不再是整個佈局結構的一部分了。
繪製優化
View的onDraw方法要避免執行大量的操作；
- onDraw中不要創建大量的局部對象，因爲onDraw方法會被頻繁調用，這樣就會在一瞬間產生大量的臨時對象，不僅會佔用過多內存還會導致系統頻繁GC，降低程序執行效率。
- onDraw也不要做耗時的任務，也不能執行成千上萬的循環操作，儘管每次循環都很輕量級，但大量循環依然十分搶佔CPU的時間片，這會造成View的繪製過程不流暢。根據Google官方給出的標準，View繪製保持在60fps是最佳的，這也就要求每幀的繪製時間不超過16ms(1000/60)；所以要儘量降低onDraw方法的複雜度。
內存泄露優化
內存泄露是最容易犯的錯誤之一，內存泄露優化主要分兩個方面；
一方面是開發過程中避免寫出有內存泄露的代碼，另一方面是通過一些分析工具如LeakCanary或MAT來找出潛在的內存泄露繼而解決。
- 靜態變量導致的內存泄露
比如Activity內，一靜態Conext引用了當前Activity，所以當前Activity無法釋放。或者一靜態變量，內部持有了當前Activity，Activity在需要釋放的時候依然無法釋放。 - 單例模式導致的內存泄露
比如單例模式持有了Activity，而且也沒用解註冊的操作。因爲單例模式的生命週期和Application保存一致，生命週期比Activity要長，這樣一來就導致Activity對象無法及時被釋放。 - 屬性動畫導致的內存泄露
屬性動畫中有一類無限循環的動畫，如果在Activity播放了此類動畫並且沒有在onDestroy中去停止動畫，那麼動畫會一直播放下去，並且這個時候Activity的View會被動畫持有，而View又持有了Activity，最終導致Activity無法釋放。解決辦法是在Activity的onDrstroy中調用animator.cancel()來停止動畫。
響應速度優化和ANR日誌分析
響應速度優化的核心思想就是避免在主線程中去做耗時操作，將耗時操作放在其他線程當中去執行。Activity如果5秒無法響應屏幕觸摸事件或者鍵盤輸入事件就會觸發ANR，而BroadcastReceiver如果10秒還未執行完操作也會出現ANR。
當一個進程發生ANR以後系統會在/data/anr的目錄下創建一個文件traces.txt，通過分析該文件就能定位出ANR的原因。
ListView優化和Bitmap優化
ListView/GridView優化：採用ViewHolder避免在getView中執行耗時操作；其次通過列表的滑動狀態來控制任務的執行頻率，比如快速滑動時不是和開啓大量異步任務；最後可以嘗試開啓硬件加速使得ListView的滑動更加流暢。
Bitmap優化：主要是想是根據需要對圖片進行採樣顯示，詳細請參考12章。
線程優化
線程優化的思想是採用線程池，避免程序存在大量的Thread。詳細參考第11章的內容。
一些性能優化的小建議
- 避免創建過多的對象，尤其在循環、onDraw這類方法中，謹慎創建對象；
- 不要過多的使用枚舉，枚舉佔用的內存空間比整形大。
- 常量使用static final來修飾；
- 使用一些Android特有的數據結構，比如SparseArray和Pair等，他們都具有更好的性能；
- 適當的使用軟引用和弱引用；
- 採用內存緩存和磁盤緩存；
- 儘量採用靜態內部類，這樣可以避免非靜態內部類隱式持有外部類所導致的內存泄露問題。
提高程序的可維護性
- 提高可讀性：命名規範；代碼之間排版需留出合理的空白來區分不同的代碼塊；針對非常關鍵的代碼添加註釋。
- 代碼的層級性：不要把一段業務邏輯放在一個方法或者一個類中全部實現，要把它分成幾個子邏輯，然後每個子邏輯做自己的事情，這樣即顯得代碼層級分明，這樣利於提高程序的可擴展性。
- 恰當的使用設計模式可以提高代碼的可維護性和可擴展性，Android程序容易遇到性能瓶頸，要控制設計的度，不能太牽強，避免過度設計。