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