導語

自2008年智慧時代開始，Android作業系統一路高歌，10年智慧機發展之路，如今 Android 9.0 代號P  都發布了，Android系統性能已經非常流暢了。但是，到了各大廠商手裡，改原始碼自定系統，使得Android原生系統變得魚龍混雜。另外，到了不同層次的開發工程師手裡，因為開發技術的水平參差不齊，使得應用安裝到配置極好的手機上，開啟應用依然存在卡頓現象。最後，隨著產品內容迭代，功能需求越來越複雜，UI頁面也越來越豐富，也成為流暢執行的一種阻礙。效能優化提升使用者體驗成為開發工程師的使命，那麼該如何完成這樣一個使命呢？首先，我們需要藉助效能檢測工具來進行分析。

一、效能檢測工具

    Emmagee(機關槍)是網易杭州研究院QA團隊開發的一個簡單易上手的Android效能監測小工具，主要用於監控單個App的CPU，記憶體，流量，啟動耗時，電量，電流等效能狀態的變化，且使用者可自定義配置監控的頻率以及效能的實時顯示，並最終生成一份效能統計檔案。

（1）優勢              

1. 開源；
2. 無需root許可權；
3. 支援2.2以及以上版本。但由於Google 安全限制，在7.0版本手機已不支援。
4. 實時展示資料；
5. 操作簡單，支援自定義採集頻率；
6. CSV格式儲存資料，方便為電腦使用Excel表格開啟；

（2）檢測案例步驟

1、在GitHub下載安裝包Apk

2、執行Emmagee.app。可以設定採集頻率。

3、點選APP"測試報告"檢視，也可以配置郵件下發CSV檔案。而我選擇盜取檔案到電腦上用Excel表格看。

（本地內部儲存Emmagee目錄”storage\sdcard0\Emmagee\某日期時間_APP包名.csv”的檔案，即為監控資料）

$ adb shell    //回車
$ cd storage/sdcard0/Emmagee/    //回車
$ ls   //回車 ，結果如下：

20180605154517_com.daojia.csv
20180605160747_me.ele.csv
 

*手機匯出的csv檔案出現亂碼，原因是由於匯出的CSV檔案編碼為UTF-8 。解決辦法：（Windows）使用記事本開啟另存為“ANSI編碼”的CSV格式檔案即可。(Mac OS）文字編輯開啟重新儲存即可。

上面分別是對到家點餐APP、餓了麼點餐APP的CSV檢測資料。移動檔案到電腦Excel開啟檢視：

（1）什麼是GT?

    GT是一款同時支援安卓手機端和IOS手機端效能測試工具。

    GT（隨身調），即僅憑一部手機，無需連線電腦，就可以對APP進行快速的效能測試(CPU、記憶體、流量、電量、幀率/流暢度等)、 開發日誌的檢視、Crash日誌檢視、網路資料包的抓取、APP內部引數的除錯、真機程式碼耗時統計等等；更重要的是，您可以在任意真實場所、 任何時候做如上的系列事情，這就是“隨身調

”。

    如果您覺得GT提供的功能還不夠滿足您的需要， 您還可以利用GT提供的基礎API自行開發有特殊功能的GT外掛（僅iOS版支援）， 幫助您解決更加複雜的APP除錯、測試問題。

（2）如何使用？

    GT支援iOS和Android兩個手機平臺，其中： Android版由一個可直接安裝的GT控制檯APP 和GT SDK外掛擴充套件檢測。GT控制檯可以獨立安裝使用，SDK需嵌入被調測的應用、並利用GT控制檯進行資訊展示和引數修改。 iOS版是一個Framework包，必須嵌入APP工程，編譯出帶GT的APP才能使用；iPhone和iPad應用都能支援。

以下為Android版GT控制檯APP 檢測基礎功能案例，使用步驟：

1、應用寶下載GT.APP，安裝執行GT。

2、選擇應用                                                                        

3、選擇關注的監控資料     

iTest官方說該工具由科大訊飛測試技術部開發，在多個專案中成功應用，具有較高的準確性和穩定性。它填補了手機端自動化測試的空白，以實用高效為宗旨，記錄特定應用的效能消耗情況，包括cpu、記憶體、流量、電量等資訊。我們知道科大訊飛在業界是很有名氣的是訊飛語音。但是關於這款檢測工具，遺憾本人尋遍全網，只能查詢下載安裝Apk的地址，查閱其他的相關介紹和資料太少。

    Battery Historian是一款用於檢測與電池有關的資訊和事件的工具。執行在Android5.0Lollipop(APIlevel21)及其之後。它會生成一張具有時間座標的圖紙,使用者可以檢視各種事件耗電時間。官方文件是英文版，網上可以搜到大量中文資料。使用需要先配置環境，包括go/java/python/git。最後git命令下載 Battery Historian，並使用命令操作 adb bugreport 得到 bugreport.txt(~16m)。使用 Battery Historian開啟會生成圖表，最終效果圖如下。

縱座標	解釋
CPU runing	cpu執行的狀態，是否被喚醒
Kernel only uptime	只有核心執行時間
Activity Manager Proc	活躍的使用者程序
Mobile network type	網路型別
Mobile radio active	移動蜂窩訊號 BP側耗電
Crashes(logcat)	某個時間點出現crash的應用
Doze	是否進入doze模式
Device active	和Doze相反
JobScheduler	非同步作業排程
SyncManager	同步操作
Temp White List	電量優化白名單
Phone call	是否打電話
GPS	是否使用GPS
Network connectivity	網路連線狀態（wifi、mobile是否連線）
Mobile signal strength	移動訊號強度（great\good\moderate\poor）
Wifi scan	是否在掃描wifi訊號
Wifi supplicant	是否有wifi請求
Wifi radio	是否正在通過wifi傳輸資料
Wifi signal strength	wifi訊號強度（great\good\moderate\poor）
Wifi running	wifi元件是否在工作(未傳輸資料)
Wifi on	同上
Audio	音訊是否開啟
Camera	相機是否在工作
Video	是否在播放視訊
Foreground process	前臺程序
Package install	是否在進行包安裝
Package active	包管理在工作
Battery level	電池當前電量
Temperature	電池溫度
Charging on	在充電
Logcat misc	是否在匯出日誌

（五）Android 自帶 Lint 工具

    Android Lint Tool 是 Android Sutido 整合的一個程式碼規範提示工具，使用 Lint 檢測程式碼、佈局檔案、去除多餘資源。

• 硬編碼會提示以級別警告，例如：在佈局檔案中寫了三層冗餘的LinearLayout佈局、直接在TextView中寫要顯示的文字、字型大小使用dp而不是sp為單位，就會在編輯器右邊看到提示。
• 使用Android Studio的lint可以清除無用的資原始檔（點選選單欄的Analyze -> Run Inspection by Name, 輸入unused resource）。

    當然兩個都是一個簡單的舉例，Lint的功能非常強大，大家應該養成寫完程式碼檢視Lint的習慣，這不僅讓你及時發現程式碼種隱藏的一些問題，更能讓你養成良好的程式碼風格，要知道，這些Lint提示可都是Google大牛們汗水合智慧的結晶。

二、效能優化

    說完了效能檢查工具，接下來該思考如何進行制定系統化的優化改進方案。本著人道主義，首先從使用者體驗的角度去思考，置身處地得把自己當做使用者去玩一款應用時候會在意些什麼呢？假如飯點將至，需要開啟訂餐APP進行點餐，首先一定不希望，在瀏覽商家和菜品列表內容很豐富的時候遇到卡頓現象，然後千挑萬選後在期待美食將至的心情下準備下單，突然遇到閃退崩潰那簡直想解除安裝APP的心都有了。其次就是配送員在配送過程中不希望耗電和耗流量太嚴重。最後就是使用者和配送員都希望版本更新的時候安裝包希望能小一點。

根據使用者的四個方面需求，總結如下：

1. 追求流暢，防止卡頓
2. 追求穩定，防止閃退
3. 追求續航，防止耗損
4. 追求精簡，防止臃腫

（最重要是穩定，app出現閃退崩潰是致命的。相比之下卡頓耗損安裝包大都還好些。）

（一）追求穩定，防止閃退

    一般造成Crash和ANR的都會出現應用崩潰的表現。造成ANR程式無響應的原因主要是在四大元件的耗時操作；而造成Crash的原因卻有很多，比如執行時異常的空指標、陣列越界、未例項化、強制型別、低記憶體機制等等，有些時候我們在開發測試階段都沒有出現異常崩潰現象，而釋出上線後到了使用者手機就會出現各種奇怪閃退。所以，我們要去努力實現一個永遠打不死的小強 —— 不會出現Crash閃退的APP。

    雖然我們無法保證開發完美至極不出現異常，但是可以努力做好異常的捕獲。通常我們會使用 try - catch，在發現容易出現崩潰的程式碼塊，主動加上try-catch 預防異常閃退。但是沒加try-catch的程式碼塊出現異常還是閃退該怎麼辦？我們可以通過設定 UncaughtExceptionHandler 捕獲全域性執行緒異常，而在主執行緒丟擲異常時，APP依舊會閃退程序重啟。那麼可以使用 Cockroach （蟑螂），可以保證不管怎樣拋異常都不會閃退，App程序也不會重啟。

    以上治標不治本，需要不斷加強程式碼的嚴謹性去減少Crash率。由於Android應用的沙箱機制，每個應用程式都執行在一個程序中，擁有一個獨立的Dalvik虛擬機器例項，系統預設分配給虛擬機器的記憶體是有限度的。當系統記憶體太低依然會觸發LMK（Low Memory Killer）機制，即閃退、崩潰現象。不同廠商不同，如：華為mate7，192m ；小米4，128m ；紅米，128m 。而在，Android4.0以後，可以通過在application節點中設定屬性android:largeHeap=”true”來設定最大可分配多少記憶體空間就可以突破一定限制。

如果懂得記憶體如何分配和回收機制，對記憶體優化會有一定的認識和掌握的話，看下面這個例子，程式碼如下所示：

public class CommUtil {
    private static CommUtil instance;
    private Context context;
    private CommUtil(Context context) {
        this.context=context;
    }
    public static CommUtil getInstance(Context context){
        if(null==instance){
            instance=new CommUtil(context);
        }
        return instance;
    }
}
public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        CommUtil instance = CommUtil.getInstance(this);//
    }
}

    一個工具類 CommUtil.class 使用建立型設計模式——單例模式，在MainActivity.class中引用，那麼這個單例物件會持有Activity的例項。然後執行起來 ，再將手機螢幕旋轉幾下。這樣的程式碼會造成什麼錯誤？
（旋轉螢幕的時候 Activity會被銷燬重新建立，但是這裡的單例會持有銷燬Activity的例項就造成記憶體洩漏）

這時，我們可以藉助記憶體分析工具，可以顯示記憶體資料的視覺化頁面，方便定位記憶體洩漏的程式碼。使用分析工具如下：

（1）Memory Monitor 工具：

    它是Android Studio自帶的一個記憶體監視工具，它可以很好地幫助我們進行記憶體實時分析。通過點選Android Studio右下角的Memory Monitor標籤，開啟工具可以看見較淺藍色代表free的記憶體，而深色的部分代表使用的記憶體從記憶體變換的走勢圖變換，可以判斷關於記憶體的使用狀態，例如當記憶體持續增高時，可能發生記憶體洩漏；當記憶體突然減少時，可能發生GC等，如下圖所示。*案例參考

（2）Memory Analyzer 工具：

    MAT(Memory Analyzer Tool) 是一個快速，功能豐富的 Java Heap 分析工具，通過分析 Java 程序的記憶體快照 HPROF 分析，從眾多的物件中分析，快速計算出在記憶體中物件佔用的大小，檢視哪些物件不能被垃圾收集器回收，並可以通過檢視直觀地檢視可能造成這種結果的物件。

    檢測步驟如下：

（a）螢幕多次翻轉，出現記憶體持續增高時。點選 Dump java Heap就會生成執行記憶體快照hprof檔案。

（b）然後將APP完全退出，重新啟動，開啟Android Monitor 再次點選Dump java Heap 生成一份還沒操作(旋轉螢幕)前的記憶體快照hprof檔案。現在就已經生成好了2份hprof檔案， 一份是沒有旋轉過螢幕的 ，一份是旋轉過螢幕多次的。

（c）然後選中Android Studio 最左邊的Captures 進行將hprof檔案匯出。匯出的時候需要選擇儲存的目錄以及檔名。

（d）開啟MAT ，匯入我們的2個hprof檔案 Open File-->選擇檔案-->Leak Suspects Report-->Finish：*案例參考

可以通過檢索包名，檢視某個類的例項個數和所在記憶體資料，還可以檢視被引用的記憶體資料。如下：

Objects：例項個數
Shallow Heap：所佔記憶體大小
Retained Heap：釋放後能回收多少記憶體

（3）LeakCanary工具：

    簡單，傻瓜式操作，最重要的是LeakCanary 只在debug版本下檢測，正版先上線後自動跳過檢測這就方便開發者無需操作每次上線時註釋檢測程式碼。這個工具是Square公司在Github開源的。行業內不是有一句話嘛，Square出品必屬精品，主流的庫像okhttp、Picasso、retrofit、Dagger等都出自Square之手。說到這不得不讓我聯想到一位在Android開發領域神一般存在的人物，他就是大名鼎鼎的Jake Wharton（傑克.沃頓），ButterKnife的創造者，也參與貢獻了Retrofit, okhttp等。

在Application中寫方法：

    private RefWatcher setupLeakCanary() {
        if (LeakCanary.isInAnalyzerProcess(this)) {
            return RefWatcher.DISABLED;
        }
        return LeakCanary.install(this);
    }

    public static RefWatcher getRefWatcher(Context context) {
        MyApplication leakApplication = (MyApplication) context.getApplicationContext();
        return leakApplication.refWatcher;
    }

然後onCreate()中呼叫即可：refWatcher = setupLeakCanary();

在Activity中單獨呼叫檢測：

@Override
    protected void onDestroy() {
        super.onDestroy();
        RefWatcher refWatcher = MyApplication.getRefWatcher(this);//1
        refWatcher.watch(this);
    }

小結

    影響穩定性的原因很多，比如記憶體使用不合理、程式碼異常場景考慮不周全、程式碼邏輯不合理等，都會對應用的穩定性造成影響。其中最常見的兩個場景是：Crash 和 ANR，這兩個錯誤將會使得程式無法使用。所以做好Crash全域性監控，處理閃退同時把崩潰資訊、異常資訊收集記錄起來，以便後續分析;合理使用主執行緒處理業務，不要在主執行緒中做耗時操作，防止ANR程式無響應發生。

（二）追求流暢，防止卡頓

    卡頓的場景通常是發生在使用者互動體驗最直接的方面。大概分為四個方面，如下圖所示。影響卡頓的兩大因素，分別是介面繪製和資料處理。

• 介面繪製：主要原因是繪製的層級深、頁面複雜、重新整理不合理，由於這些原因導致卡頓的場景更多出現在 UI 和啟動後的初始介面以及跳轉到頁面的繪製上。

• 資料處理：導致這種卡頓場景的原因是資料處理量太大，一般分為三種情況，一是資料在處理 UI 執行緒，二是資料處理佔用 CPU 高，導致主執行緒拿不到時間片，三是記憶體增加導致 GC 頻繁，從而引起卡頓。

（1）佈局優化

    在Android種系統對View進行測量、佈局和繪製時，都是通過對View數的遍歷來進行操作的。如果一個View數的高度太高就會嚴重影響測量、佈局和繪製的速度。Google也在其API文件中建議View高度不宜哦過10層。現在版本種Google使用RelativeLayout替代LineraLayout作為預設根佈局，目的就是降低LineraLayout巢狀產生布局樹的高度，從而提高UI渲染的效率。

• 佈局複用，使用<include>標籤重用layout；
• 提高顯示速度，使用<ViewStub>延遲View載入；
• 減少層級，使用<merge>標籤替換父級佈局；

• 注意使用wrap_content，會增加measure計算成本；

• 刪除控制元件中無用屬性；

（2）繪製優化

    過度繪製是指在螢幕上的某個畫素在同一幀的時間內被繪製了多次。在多層次重疊的 UI 結構中，如果不可見的 UI 也在做繪製的操作，就會導致某些畫素區域被繪製了多次，從而浪費了多餘的 CPU 以及 GPU 資源。如何避免過度繪製？

• 佈局上的優化。移除 XML 中非必須的背景，移除 Window 預設的背景、按需顯示佔位背景圖片

• 自定義View優化。使用 canvas.clipRect() 幫助系統識別那些可見的區域，只有在這個區域內才會被繪製。

（3）啟動優化

   啟動優化工具。 應用一般都有閃屏頁SplashActivity，優化閃屏頁的 UI 佈局，可以通過 Profile GPU Rendering 檢測丟幀情況。

  （另外，還可以IDE自帶的一款UI繪製檢測圖形化資料分析工具 Systrace ，4.0版本以上版本可以使用。這裡暫不介紹）

    啟動白屏或黑屏問題優化處理。當我們在啟動一個應用時，系統會去檢查是否已經存在這樣一個程序，如果不存在，系統的服務會先檢查startActivity中的intent的資訊，然後在去建立程序，最後啟動Acitivy，即冷啟動。而啟動出現白黑屏的問題，就是在這段時間內產生的。系統在繪製頁面載入佈局之前，首先會初始化視窗（Window），而在進行這一步操作時，系統會根據我們設定的Theme來指定它的Theme 主題顏色，我們在Style中的設定就決定了顯示的是白屏還是黑屏。詳情檢視請點選

<style name="Theme.Splash" parent="AppTheme">
        <item name="windowNoTitle">true</item>
        <item name="android:windowContentOverlay">@null</item>
        <item name="android:windowBackground">@drawable/splash_pic</item>
        <item name="android:windowFullscreen">true</item>
    </style>

    啟動載入邏輯優化處理。閃屏頁的存在可以說就是啟動優化，通常在閃屏頁延遲2秒跳轉到主介面，但是在進入首頁的時候，首頁複雜的View渲染以及必須在UI執行緒執行的業務邏輯，必然拖慢了啟動速度。啟動閃屏頁雖然簡單執行快，首頁卻複雜執行慢，應用啟動前輕後重。可以採用分佈載入、非同步載入、延期載入策略來提高應用啟動速。例如，把SplashActivity改成SplashFragment,應用程式的入口變成MainActivity，在MainActivity中先展示SplashFragment，顯示完畢後再移除SplashFragment。這樣，在SplashFragment的2S的友好時間內進行資料準備的同時，首頁的View就能夠被載入，首頁的業務邏輯就能夠被執行。在閃屏頁視窗載入完畢後，我們載入activity_main的佈局，考慮到這個佈局有可能比較複雜，耽誤View的解析時間，可以採用ViewStub的形式進行懶載入。

（4）重新整理優化

1. 減少重新整理次數，靈活利用快取及限時重新整理；
2. 縮小重新整理區域，區域性重新整理，避免多餘請求；

（5）動畫優化

需要實現動畫效果時，需要根據不同場景選擇合適的動畫框架來實現。

      有些情況下，可以用硬體加速方式來提供流暢度降低動畫卡頓。

（三）節省——耗電優化

    在移動裝置中，電池的重要性自然不言而喻，如果手機沒電了應用功能技術實現再怎麼牛逼，使用者也什麼都幹不成。對於Android作業系統和裝置各大開發商來說，對手機耗電的優化從沒有停止過，不斷地追求更長的待機時間。而對於開發一款應用來說，絕不可以忽略電量耗損的問題，被歸為“電池殺手”的應用，最終的結果無疑是走向被使用者解除安裝的道路。比如，有些應用為了保持應用程序長期在後臺存活，使用各種不合理程序保活方案，破壞作業系統“生態平衡”，導致使用者電量嚴重耗損，雖然這種流氓開發行為並不違法吧，但是也屬於不道德的行為，也同樣會被同行所被鄙視的行為。

    在 Android5.0 以前，關於應用電量消耗的測試即麻煩又不準確，而5.0 之後Google專門引入了一個獲取裝置上電量消耗資訊的API—— Battery Historian。Battery Historian 是一款由 Google 提供的 Android 系統電量分析工具，直觀地展示出手機的電量消耗過程，通過輸入電量分析檔案，顯示消耗情況。

    最後提供一些可供參考耗電優化的方法：

        浮點運算：計算機裡整數和小數形式就是按普通格式進行儲存，例如1024、3.1415926等等，這個沒什麼特點，但是這樣的數精度不高，表達也不夠全面，為了能夠有一種數的通用表示法，就發明了浮點數。浮點數的表示形式有點像科學計數法（*.*****×10^***），它的表示形式是0.*****×10^***，在計算機中的形式為 .***** e ±***），其中前面的星號代表定點小數，也就是整數部分為0的純小數，後面的指數部分是定點整數。利用這樣的形式就能表示出任意一個整數和小數，例如1024就能表示成0.1024×10^4，也就是 .1024e+004，3.1415926就能表示成0.31415926×10^1，也就是 .31415926e+001，這就是浮點數。浮點數進行的運算就是浮點運算。浮點運算比常規運算更復雜，因此計算機進行浮點運算速度要比進行常規運算慢得多。Wake Lock是一種鎖的機制，主要是相對系統的休眠而言的，,只要有人拿著這個鎖，系統就無法進入休眠意思就是我的程式給CPU加了這個鎖那系統就不會休眠了，這樣做的目的是為了全力配合我們程式的執行。有的情況如果不這麼做就會出現一些問題，比如微信等及時通訊的心跳包會在熄屏不久後停止網路訪問等問題。所以微信裡面是有大量使用到了Wake_Lock鎖。系統為了節省電量，CPU在沒有任務忙的時候就會自動進入休眠。有任務需要喚醒CPU高效執行的時候，就會給CPU加Wake_Lock鎖。大家經常犯的錯誤，我們很容易去喚醒CPU來工作，但是很容易忘記釋放Wake_Lock。   在Android 5.0 API 21 中，google提供了一個叫做JobScheduler API的元件，來處理當某個時間點或者當滿足某個特定的條件時執行一個任務的場景，例如當使用者在夜間休息時或裝置接通電源介面卡連線WiFi啟動下載更新的任務。這樣可以在減少資源消耗的同時提升應用的效率。

（四）安裝包——APK瘦身

    其實APK大小對應用使用並沒有影響，但應用的安裝包越大，使用者下載的門檻越高。例如，應用版本的迭代更新，特別是當用戶在行動網路情況下，又不得不去下載安裝包，才能使用產品滿足自身需求。因此，開發應該減小安裝包大小，使得讓更多使用者願意下載產品和體驗產品。

（1）安裝包的組成結構

• assets資料夾。存放一些配置檔案、資原始檔，assets不會自動生成對應的 ID，而是通過 AssetManager 類的介面獲取。

• res。res 是 resource 的縮寫，這個目錄存放資原始檔，會自動生成對應的 ID 並對映到 .R 檔案中，訪問直接使用資源 ID。

• META-INF。儲存應用的簽名信息，簽名信息可以驗證 APK 檔案的完整性。

• AndroidManifest.xml。這個檔案用來描述 Android 應用的配置資訊，一些元件的註冊資訊、可使用許可權等。

• classes.dex。Dalvik 位元組碼程式，讓 Dalvik 虛擬機器可執行，一般情況下，Android 應用在打包時通過 Android SDK 中的 dx 工具將 Java 位元組碼轉換為 Dalvik 位元組碼。

• resources.arsc。記錄著資原始檔和資源 ID 之間的對映關係，用來根據資源 ID 尋找資源。

（2）減少安裝包大小

1.程式碼混淆。使用IDE 自帶的 proGuard 程式碼混淆器工具 ，它包括壓縮、優化、混淆等功能。

2.資源優化。比如使用 Android Lint 刪除冗餘資源，資原始檔最少化等。（這個前面已經講過了）3.圖片優化。比如利用 PNG優化工具 對圖片做壓縮處理。如果應用在4.0版本以上，推薦使用 WebP圖片格式。5.外掛化熱修復開發。比如功能模組放在伺服器上，按需下載，可以減少安裝包大小。6.避免重複或無用功能的第三方庫。例如，百度地圖接入基礎地圖即可、訊飛語音無需接入離線、圖片庫Glide\Picasso等

三、總結

   綜上所述，對應用進行效能優化已然成為當下開發工程師應該具備的基本技能之一，也是對開發工程師是否有能力維護高質量應用程式的重要考核之一。另外，效能優化是一個非常具有挑戰性的工作，上面列出很多分析檢查的工具和方法，但是真正優化工作遠不止如此，想要進行完美的效能優化絕非一日之功，需要考驗開發者長期研究的耐心和深厚的技術功底。

值得一看的博文推薦：