Android性能測試之卡頓ANR測試

一直以來Android性能測試一直是android測試中一個被一部分人遺忘，有被一部分人迫不得已的東西。在絕大部分的創業公司，性能測試基本上都是被遺忘的，由於功能測試和穩定性測試纔是重點，而在中等公司中一部分測試人員向對Android進行性能測試，卻無從下手。Android性能測試一直存在測試維度少，測試數據難收集，已收集數據難量化的特色，這些特色又是由於Android手機版本碎片化、硬件多樣化、App功能複雜形成的。

性能測試總的來講，能夠分爲卡頓ANR測試、流暢度測試、電量測試、流量測試。一個APP爲何須要性能測試，總的來講就是一些不嚴謹的代碼，在低端機型形成卡頓，對手機上有限電量的浪費，昂貴流量的浪費，形成用戶流失。

今天先說說卡頓ANR測試

卡頓ANR與Android就是天生的朋友，從Android第一天誕生直到如今的8核CPU，Android仍是未能擺脫頁面不流暢，卡，死機的詬病，因此我的認爲卡頓ANR測試是性能測試最主要的一塊。

卡頓簡單的來講，就是手機沒有及時響應、頁面延遲，出現丟幀的現象，或者點擊無響應。絕大多數的卡頓，稍等片刻系統就會恢復正常，但假如超過5S,就可能會引起手機ANR,形成更高級別的警告。

什麼會引起ANR？

在Android裏，應用程序的響應性是由Activity Manager和WindowManager系統服務監視的 。當它監測到如下狀況中的一個時，Android就會針對特定的應用程序顯示ANR：
ANR通常有三種類型：

1）KeyDispatchTimeout(5 seconds) --主要類型按鍵或觸摸事件在特定時間內無響應
2）BroadcastTimeout(10 seconds) --BroadcastReceiver在特定時間內沒法處理完成
3）ServiceTimeout(20 seconds) --小几率類型 Service在特定的時間內沒法處理完成

這三種緣由都會形成ANR，可是第一種狀況基本上佔了全部ANR的百分之九十以上，第三種的狀況微乎其微。這三種ANR不是孤立的，有可能會相互影響。例如一個應用程序進程中同時有一個正在顯示的Activity和一個正在處理消息的BroadcastReceiver，它們都運行在這個進程的主線程中。若是BR的onReceive函數沒有返回，此時用戶點擊屏幕，而onReceive超過5秒仍然沒有返回，主線程沒法處理用戶輸入事件，就會引發第1種ANR。若是繼續超過10秒沒有返回，又會引發第2種ANR。發生ANR的主要緣由是潛在的耗時操做，例如網絡或數據庫操做，或者高耗時的計算如改變位圖尺寸，應該在子線程裏（或者以數據庫操做爲例，經過異步請求的方式）來完成。然而，不是說你的主線程阻塞在那裏等待子線程的完成——也不是調用 Thread.wait()或是Thread.sleep()。替代的方法是，主線程應該爲子線程提供一個Handler，以便完成時可以提交給主線程。以這種方式設計你的應用程序，將能保證你的主線程保持對輸入的響應性並能避免因爲5秒輸入事件的超時引起的ANR對話框。

三種ANR發生時都會在log中輸出錯誤信息，你會發現各個應用進程和系統進程的函數堆棧信息都輸出到了一個/data/anr/traces.txt的文件中，ROOT手機導出該文件後，分析此日誌能夠得出一些結論，但traces文件信息比較抽象，難理解。總的來講，日誌難收集，結果難分析。

如何避免ANR？

1） 運行在主線程裏的任何方法都儘量少作事情。特別是，Activity應該在它的關鍵生命週期方法（如onCreate()和onResume()）裏儘量少的去作建立操做。（能夠採用從新開啓子線程的方式，而後使用Handler+Message的方式作一些操做，好比更新主線程中的ui等）

2） 應用程序應該避免在BroadcastReceiver裏作耗時的操做或計算。但再也不是在子線程裏作這些任務（由於 BroadcastReceiver的生命週期短），替代的是，若是響應Intent廣播須要執行一個耗時的動做的話，應用程序應該啓動一個 Service。（此處須要注意的是能夠在廣播接受者中啓動Service，可是卻不能夠在Service中啓動broadcasereciver,關於緣由後續會有介紹，此處不是本文重點）

3）避免在Intent Receiver裏啓動一個Activity，由於它會建立一個新的畫面，並從當前用戶正在運行的程序上搶奪焦點。若是你的應用程序在響應Intent廣 播時須要向用戶展現什麼，你應該使用Notification Manager來實現。

TestBird