『壹』 android 手機自動化測試工具有哪幾種
Feb 23 2012更新: 還有Sikuli (http://sikuli.org)，基於優秀的圖像對比庫opencv的測試工具，測試腳本使用Python編寫，非常強大。如果你的app沒有源碼，可以選擇它；或者你想做系統測試（跨app的測試），也可以選擇它。其它的還是用下面說的那些個吧。
我通過其核心包sikuli-script.jar實現了android的sikuli化，暫時不打算開源。其實原理挺簡單的，認真看過sikuli源碼的應該都能寫出來。
看lz的意思應該只是想問應用層的，我來說點應用層的
先說說開源的吧：
Robotium
Monkeyrunner
Robolectric
CTS
還有個新興的測試工具，以前在GitHub看到，現在找不到了，好像是BDD類型的語法；現在還不成熟。
另外基於web的測試也有基於Selenium Webdriver 的 Android WebDriver：
有兩種：
基於Remote Server的：官方提供了java介面的，但是Python版的官方裡面卻沒有。我非常喜歡Python，所以自己實現了並且開源到了GitHub：https://github.com/truebit/AndroidWebDriver4Python 有問題大家可以提到上面
基於Instrumentation的：已經在Android SDK r14裡面可以安裝了
不開源的就多了，不過我見過的一般是以下幾種思路：
1. 基於Android Java Instrumentation框架：
基於Robotium，比如bitbar的產品:http://bitbar.com/procts
基於Instrumentation，那就海了去了，很多公司自家寫的工具都基於這個;另外Robotium就是基於這個的
2. 基於Android lib層的各種命令，比如sendevent,getevent, monkey, service這些，然後用各種語言封裝
MonkeyRunner還是很有前景的，Google自己弄的。現在最新的dev版本已經有支持UI的id操作的EasyMonkey了。可以git clone git://http://android.kernel.org/platform/sdk.git看看
編輯於 2012-02-23 7 條評論 • 作者保留權利
贊同23反對，不會顯示你的姓名
乙醇，打雜的......
落小雪、蔣金龍、Reeta L 等人贊同
appium是最近我關注的一個不錯的移動端自動化測試工具，支持android和ios。
放上兩段視頻。第一段是講解appium的原理及quick start；第二段講解了appium的源碼結構和具體實現。有興趣可以看一下，相信應該有收獲。
1，appium 原理與quick start
乙醇的appium視頻教程之appium入門及原理剖析
http://v.youku.com/v_show/id_XNjQzMjI4NDcy.html?firsttime=2212
2，appium源碼解析
乙醇的appium源碼解讀
http://v.youku.com/v_show/id_XNjQzODIwMzA4.html?firsttime=0
發布於 2013-12-07 5 條評論 • 作者保留權利
贊同25反對，不會顯示你的姓名
知乎用戶，Coding/Reading/Hiking/Running
知乎用戶、曹媛媛、石存灃 等人贊同
1、Monkey是Android SDK自帶的測試工具，在測試過程中會向系統發送偽隨機的用戶事件流，如按鍵輸入、觸摸屏輸入、手勢輸入等)，實現對正在開發的應用程序進行壓力測試，也有日誌輸出。實際上該工具只能做程序做一些壓力測試，由於測試事件和數據都是隨機的，不能自定義，所以有很大的局限性。
2、MonkeyRunner也是Android SDK提供的測試工具。嚴格意義上來說MonkeyRunner其實是一個Api工具包，比Monkey強大，可以編寫測試腳本來自定義數據、事件。缺點是腳本用Python來寫，對測試人員來說要求較高，有比較大的學習成本。
3、Instrumentation是早期Google提供的Android自動化測試工具類，雖然在那時候JUnit也可以對Android進行測試，但是Instrumentation允許你對應用程序做更為復雜的測試，甚至是框架層面的。通過Instrumentation你可以模擬按鍵按下、抬起、屏幕點擊、滾動等事件。Instrumentation是通過將主程序和測試程序運行在同一個進程來實現這些功能，你可以把Instrumentation看成一個類似Activity或者Service並且不帶界面的組件，在程序運行期間監控你的主程序。缺點是對測試人員來說編寫代碼能力要求較高，需要對Android相關知識有一定了解，還需要配置AndroidManifest.xml文件，不能跨多個App。
4、UiAutomator也是Android提供的自動化測試框架，基本上支持所有的Android事件操作，對比Instrumentation它不需要測試人員了解代碼實現細節（可以用UiAutomatorviewer抓去App頁面上的控制項屬性而不看源碼）。基於Java，測試代碼結構簡單、編寫容易、學習成本，一次編譯，所有設備或模擬器都能運行測試，能跨App（比如：很多App有選擇相冊、打開相機拍照，這就是跨App測試）。缺點是只支持SDK 16（Android 4.1）及以上，不支持Hybird App、WebApp。
5、Espresso是Google的開源自動化測試框架。相對於Robotium和UIAutomator，它的特點是規模更小、更簡潔，API更加精確，編寫測試代碼簡單，容易快速上手。因為是基於Instrumentation的，所以不能跨App。配合Android Studio來編寫測試的簡單例子
6、Selendroid：也是基於Instrumentation的測試框架，可以測試Native App、Hybird App、Web App，但是網上資料較少，社區活躍度也不大。
7、Robotium也是基於Instrumentation的測試框架，目前國內外用的比較多，資料比較多，社區也比較活躍。缺點是對測試人員來說要有一定的Java基礎，了解Android基本組件，不能跨App。
8、Athrun是淘寶出的一個移動測試框架/平台，同時支持iOS和Android。Android部分也是基於Instrumentation，在Android原有的類基礎上進行了擴展，提供一整套面向對象的API。這里有詳細介紹。
9、Appium是最近比較熱門的框架，社區也很活躍。這個框架應該是是功能最強大的，
它的優點：
它的哲理是：
它的設計理念：
相關限制：
總結：
在iOS部分是封裝了UIAutomation；Android 4.2以上是用UiAutomator，Android 2.3 ~ 4.1用的是 Instrumentation，也就說Appium同時封裝了UiAutomator和Instrumentation。所以Appium擁有了以上幾大框架的所有優點：跨App，支持Native App、Hybird App、Web App，還支持N種語言來編寫你的測試腳本。
如果你在Windows使用Appium，你沒法使用預編譯專用於OS X的.app文件，因為Appium依賴OS X專用的庫來支持iOS測試，所以在Windows平台你不能測試iOS Apps。這意味著你只能通過在Mac上來運行iOS測試。
Client/Server架構，運行的時候Server端會監聽Client端發過來的命令，翻譯這些命令發送給移動設備或模擬器，然後移動設備或模擬器做出響應的反應。正是因為這種架構，所以Client可以使用Appium client libraries多種語言的測試腳本，而且Server端完全可以部署在伺服器上，甚至雲伺服器。
Session，每個Client連接到Server以後都會有一個Session ID，而且Client發送命令到Server端都需要這個Session ID，因為這個seesion id代表了你所打開的瀏覽器或者是移動設備的模擬器。所以你甚至可以打開N個Session，同時測試不同的設備或模擬器。
Desired Capabilities，其實就是一個鍵值對，設置一些測試的相關信息來告訴Server端，我們需要測試iOS、還是Android，或者換是WebApp等信息。
Appium Server是Node.js寫的，所以可以直接用NPM來進行安裝。
Appium Clients，Mac OS和Win下提供GUI，不需要裝Node.js，方便測試人員操作。
用Appium自動化測試不需要重新編譯App；
支持很多語言來編寫測試腳本，Java、Javascript、PHP、Python、C#、Ruby等主流語言；
不需要為了自動化測試來重造輪子，因為擴展了WebDriver。（WebDriver是測試WebApps的一種簡單、快速的自動化測試框架，所以有Web自動化測試經驗的測試人員可以直接上手）；
移動端自動化測試應該是開源的；
開源；
支持Native App、Hybird App、Web App；
支持Android、iOS、Firefox OS；
Server也是跨平台的，你可以使用Mac OS X、Windows或者linux；
顯示全部
編輯於 2015-03-20 1 條評論 • 作者保留權利
贊同4反對，不會顯示你的姓名
知乎用戶，hello rabbit
郝思遠、man Nor、徐佳琦 等人贊同
當前有很大的趨勢是轉向移動應用平台，Android 是最廣泛使用的移動操作系統，2014 年大約占 80% 以上的市場。在開發 Android 應用的時候要進行測試，現在市場上有大量的測試工具。
本文提到的開源 Android 軟體測試工具包括：Android Test Kit, AndroidJUnit4, Appium, calabash-android, Monkey, MonkeyTalk, NativeDriver, Robolectric, RoboSpock, Robotium, UIAutomator, Selendroid。
Android Test Kit
Android Test Kit 是一組 Google 開源測試工具，用於 Android 平台，包含 Espresso API 可用於編寫簡潔可靠的 Android UI 測試。
OSChina URL: Android Test Kit首頁、文檔和下載
相關資源
* Android application testing with the Android test framework – Tutorial
* Espresso for Android is here!
AndroidJUnit4
AndroidJUnit4 是一個讓 JUnit 4 可以直接運行在 Android 設備上的開源命令行工具。
OSChina URL: AndroidJUnit4首頁、文檔和下載
Appium
Appium 是一個開源、跨平台的自動化測試工具，用於測試原生和輕量移動應用，支持 iOS, Android 和 FirefoxOS 平台。Appium 驅動蘋果的 UIAutomation 庫和 Android 的 UiAutomator 框架，使用 Selenium 的 WebDriver JSON 協議。
Appinm 的 iOS 支持是基於 Dan Cuellar's 的 iOS Auto. Appium 同時綁定了 Selendroid 用於老的 Android 平台測試。
OSChina URL: Appium首頁、文檔和下載
相關資源
* Appium Tutorial
* Android UI testing with Appium
Calabash-android
calabash-android 是一個基於 Cucumber 的 Android 的功能自動化測試框架。Calabash 允許你寫和執行，是開源的自動化移動應用測試工具，支持 Android 和 iOS 原生應用。Calabash 的庫允許原生和混合應用的交互測試，交互包括大量的終端用戶活動。Calabash 可以媲美 Selenium WebDriver。但是， 需要注意的是 web 應用和桌面環境的交互跟觸摸屏應用的交互是不同的。Calabash 專為觸摸屏設備的原生應用提供 APIs。
OSChina URL: calabash-android首頁、文檔和下載
相關資源
* A better way to test Android applications using Calabash
* Calabash Android: query language basics
Monkey
Monkey 是 Google 開發的 UI/應用測試工具，也是命令行工具，主要針對壓力測試。你可以在任意的模擬器示例或者設備上運行。Monkey 發送一個用戶事件的 pseudo-random 流給系統，作為你開發應用的壓力測試。
OSChina URL: UI/Application Exerciser Monkey
MonkeyTalk
MonkeyTalk 是世界上最強大的移動應用測試工具。MonkeyTalk 自動為 iOS 和 Android 應用進行真實的，功能性交互測試。MonkeyTalk 提供簡單的 "smoke tests"，復雜數據驅動的測試套件。
MonkeyTalk 支持原生，移動和混合應用，真實設備或者模擬器。MonkeyTalk 使得場景捕獲非常容易，可以記錄高級別，可讀的測試腳本。同樣的命令可以用在 iOS 和 Android 應用上。你可以記錄一個平台的一個測試，並且可以在另外一個平台回放。MonkeyTalk 支持移動觸摸和基於手勢交互為主的移動體驗。點擊，拖拽，移動，甚至是手指繪制也可以被記錄和回放。
OSChina URL: MonkeyTalk首頁、文檔和下載
相關資源
* Using MonkeyTalk in AndroidStudio
NativeDriver
NativeDriver 是 WebDriver API 的實現，是原生應用 UI 驅動，而不是 web 應用。
OSChina URL: NativeDriver首頁、文檔和下載
Robolectric
Robolectric 是一款Android單元測試框架，使用 Android SDK jar，所以你可以使用測試驅動開發 Android 應用。測試只需幾秒就可以在工作站的 JVM 運行。Robolectric 處理視圖縮放，資源載入和大量 Android 設備原生的 C 代碼實現。
Robolectric 允許你做大部分真實設備上可以做的事情，可以在工作站中運行，也可以在常規的 JVM 持續集成環境運行，不需要通過模擬器。
OSChina URL: Robolectric首頁、文檔和下載
Additional resources
* Better Android Testing with Robolectric 2.0
Using Robolectric for Android testing – Tutorial
RoboSpock
RoboSpock 是一個開源的 Android 測試框架。提供簡單的編寫 BDD 行為驅動開發規范的方法，使用Groovy 語音，支持 Google Guice 庫。RoboSpock 合並了 Robolectric 和 Spock 的功能。
OSChina URL: RoboSpock首頁、文檔和下載
相關資源
* RoboSpock – Behavior Driven Development (BDD) for Android
Robotium
Robotium 是一款國外的Android自動化測試框架，主要針對Android平台的應用進行黑盒自動化測試，它提供了模擬各種手勢操作（點擊、長 按、滑動等）、查找和斷言機制的API，能夠對各種控制項進行操作。
Robotium結合Android官方提供的測試框架達到對應用程序進行自動化的測 試。另外，Robotium 4.0版本已經支持對WebView的操作。Robotium 對Activity，Dialog，Toast，Menu 都是支持的。
OSChina URL: Robotium首頁、文檔和下載
相關資源
* Robotium – Testing Android User Interface
* Android user interface testing with Robotium – Tutorial
UIAutomator
uiautomator 測試框架提高用戶界面（UI）的測試效率，通過自動創建功能 UI 測試示例，可以在一個或者多個設備上運行你的應用。
OSChina URL: uiautomator首頁、文檔和下載
相關資源
* Automatic Android Testing with UiAutomator
Selendroid
Selendroid 是一個 Android 原生應用的 UI 自動化測試框架。測試使用 Selenium 2 客戶端 API 編寫。Selendroid 可以在模擬器和實際設備上使用，也可以集成網格節點作為縮放和並行測試。
OSChina URL: Selendroid首頁、文檔和下載
相關資源
* Mobile Test Automation with Selendroid
* Road to setup Selendroid and create first test script of android application
* Up and running with: Selendroid
一些停止維護的 Android 測試工具
一些幾乎沒有繼續維護的開源 Android 測試工具項目（至少是最近幾個月都沒有更新的項目）。
Emmagee
Emmagee 是監控指定被測應用在使用過程中佔用機器的CPU、內存、流量資源的性能測試小工具。Emmagee 同時還提供非常酷的一些特性，比如定製間隔來收集數據，使用浮動窗口呈現實時進程狀態等。
OSChina URL: Emmagee首頁、文檔和下載
Sirocco
Scirocco（scirocco-webdriver） 是開源的應用自動化測試工具，可以從 Eclipse 訪問必要的測試設備。Scirocco 提供自動化的 Android 應用測試功能，代替手工測試。Scirocco 支持谷歌的 NativeDriver，把 AndroidDriver 作為主要的測試庫。Scirocco 包括三個部分：NativeDriver，AndroidDriver，scirocco 插件（一個 Eclipse 插件；可以自動執行 scenario 測試和製作測試報告截圖）。
OSChina URL: Scirocco首頁、文檔和下載
via softwaretestingmagazine
內容來源：開源中國社區顯示全部
發布於 2015-03-27 添加評論 • 作者保留權利
贊同11反對，不會顯示你的姓名
知乎用戶，擁抱移動互聯網
『貳』 如何在Android平台上使用IO分析工具
你好，提問者： js腳本語言中可以post請求： 給你個例子： 123456789101112$.post( _path + "/mobile/cardManager/transactionRecords", //方法的路徑 { //下面是參數 "cardno" : cardno, "startDate" : startDate, "endDate" : endDate, "currentPage" : currentPage, },function(data) { //返回的參數 if(data.length!=0){ //存在數據 成功 }else{ //失敗 } });}或者用ajax 非同步請求： 12345678910 $.ajax({ type:"POST", url:_path + "/mobile/cardManager/transactionRecords?cardno="+cardno+"&startDate="+startDate+"&endDate="+endDate+"¤tPage="+$("#currentPage").val(), dataType:'json', cache : false, beforeSend:function(){ }, success:function(data){ } })如果對你有幫助，望採納！
『叄』 有什麼apk分析工具
GDA 呀，不需要安裝Java環境就可以用，直接拖拉就可以快速分析，絕對是最快速的apk分析工具，可以直接掃描惡意行為，反編譯，修改編輯Android apk文件，還可以mp apk內存。
android-apktool可以把你apk裡面的classes.dex轉換為jar格式，然後可以使用Java Decompiler 打開這個jar文件，直接可以看到裡面class文件反編譯的內容。
不過如果之前的jar被混淆過得話，反編譯之後的內容可能看起來會比較郁悶。
另外，apk裡面也可能包含有NDK開發的.so文件，這個就只能用一個支持arm格式的反匯編器來看反匯編之後的匯編代碼了。
以上是網上找的資料，希望能幫助到你。
『肆』 android studio有哪些性能分析工具
導言：
Android應用在CPU佔用，內存消耗方面的性能指標是影響產品質量的重要因素，由於QQ管家，360手機助手等應用都提供直觀的內存消耗，流量監控功能，致使用戶比以往更加關注軟體的性能，並以此進行軟體選用的決策。
目前，已經有很多可以監控android app 性能的工具可以供開發人員使用，如：基於Eclipse插件體系的MAT，其通過生成.hprof文件對內存泄露情況進行排查；內存檢測工具APT：提供CPU利用率實時曲線圖，方便對比測試內存泄露問題[圖0-1]
『伍』 APP的安全漏洞怎麼檢測，有什麼工具可以進行檢測
目前我經常用的漏洞檢測工具主要就是愛內測，因為愛內測會根據應用特性，對程序機密性會採取不同程度不同方式的檢測，檢測項目包括代碼是否混淆，DEX、so庫文件是否保護，程序簽名、許可權管理是否完整等；組件安全檢測主要針對Activity、Broadcast Receiver、Service、WebView、Intent等是否存在漏洞，並給出針對性建議；數據安全會全面檢測APP存在的數據泄漏漏洞和輸出層、協議層等所有涉及數據安全的漏洞，確保APP里那些可能導致帳號泄露的漏洞被全部檢測出。
『陸』 做Android手機軟體測試需要掌握哪些工具
請注意測試本身不是靠工具的而是靠設計，這是我的理念，所以我一向覺得，很多人認為做測試做的好就是靠掌握一門好的工具，這個觀點是不正確的，所以我可以負責任的告訴你，做Android手機需要掌握的不是工具、而是理念、思維、以及框架，總的來說是本質，而工具只是輔助，那麼現在我來介紹一些我了解的工具（僅僅是了解，很多沒用過）
開源 Android 軟體測試工具包括：Android Test Kit, AndroidJUnit4, Appium, calabash-android, Monkey, MonkeyTalk, NativeDriver, Robolectric, RoboSpock, Robotium, UIAutomator, Selendroid。
Android Test Kit
Android Test Kit 是一組 Google 開源測試工具，用於 Android 平台，包含 Espresso API 可用於編寫簡潔可靠的 Android UI 測試。
AndroidJUnit4
AndroidJUnit4 是一個讓 JUnit 4 可以直接運行在 Android 設備上的開源命令行工具。
Appium
Appium 是一個開源、跨平台的自動化測試工具，用於測試原生和輕量移動應用，支持 iOS, Android 和 FirefoxOS 平台。Appium 驅動蘋果的 UIAutomation 庫和 Android 的 UiAutomator 框架，使用 Selenium 的 WebDriver JSON 協議。Appinm 的 iOS 支持是基於 Dan Cuellar's 的 iOS Auto. Appium 同時綁定了 Selendroid 用於老的 Android 平台測試。
Calabash-android
calabash-android 是一個基於 Cucumber 的 Android 的功能自動化測試框架。Calabash 允許你寫和執行，是開源的自動化移動應用測試工具，支持 Android 和 iOS 原生應用。Calabash 的庫允許原生和混合應用的交互測試，交互包括大量的終端用戶活動。Calabash 可以媲美 Selenium WebDriver。但是， 需要注意的是 web 應用和桌面環境的交互跟觸摸屏應用的交互是不同的。Calabash 專為觸摸屏設備的原生應用提供 APIs。
Monkey
Monkey 是 Google 開發的 UI/應用測試工具，也是命令行工具，主要針對壓力測試。你可以在任意的模擬器示例或者設備上運行。Monkey 發送一個用戶事件的 pseudo-random 流給系統，作為你開發應用的壓力測試。
MonkeyTalk
MonkeyTalk 是世界上最強大的移動應用測試工具。MonkeyTalk 自動為 iOS 和 Android 應用進行真實的，功能性交互測試。MonkeyTalk 提供簡單的 "smoke tests"，復雜數據驅動的測試套件。MonkeyTalk 支持原生，移動和混合應用，真實設備或者模擬器。MonkeyTalk 使得場景捕獲非常容易，可以記錄高級別，可讀的測試腳本。同樣的命令可以用在 iOS 和 Android 應用上。你可以記錄一個平台的一個測試，並且可以在另外一個平台回放。MonkeyTalk 支持移動觸摸和基於手勢交互為主的移動體驗。點擊，拖拽，移動，甚至是手指繪制也可以被記錄和回放。
NativeDriver
NativeDriver 是 WebDriver API 的實現，是原生應用 UI 驅動，而不是 web 應用。
Robolectric
Robolectric 是一款Android單元測試框架，使用 Android SDK jar，所以你可以使用測試驅動開發 Android 應用。測試只需幾秒就可以在工作站的 JVM 運行。Robolectric 處理視圖縮放，資源載入和大量 Android 設備原生的 C 代碼實現。Robolectric 允許你做大部分真實設備上可以做的事情，可以在工作站中運行，也可以在常規的 JVM 持續集成環境運行，不需要通過模擬器。
RoboSpock
RoboSpock 是一個開源的 Android 測試框架。提供簡單的編寫 BDD 行為驅動開發規范的方法，使用Groovy 語音，支持 Google Guice 庫。RoboSpock 合並了 Robolectric 和 Spock 的功能。
Robotium
Robotium 是一款國外的Android自動化測試框架，主要針對Android平台的應用進行黑盒自動化測試，它提供了模擬各種手勢操作（點擊、長 按、滑動等）、查找和斷言機制的API，能夠對各種控制項進行操作。Robotium結合Android官方提供的測試框架達到對應用程序進行自動化的測 試。另外，Robotium 4.0版本已經支持對WebView的操作。Robotium 對Activity，Dialog，Toast，Menu 都是支持的。
UIAutomator
uiautomator 測試框架提高用戶界面（UI）的測試效率，通過自動創建功能 UI 測試示例，可以在一個或者多個設備上運行你的應用。
Selendroid
Selendroid 是一個 Android 原生應用的 UI 自動化測試框架。測試使用 Selenium 2 客戶端 API 編寫。Selendroid 可以在模擬器和實際設備上使用，也可以集成網格節點作為縮放和並行測試。
『柒』 如何實現一個android的log自動化分析工具
首先，讓我們看一看AndroidLog的格式。下面這段log是以所謂的long格式列印出來的。從前面Logcat的介紹中可以知道，long格式會把時間，標簽等作為單獨的一行顯示。
[ 12-09 21:39:35.510 396: 416 I/ActivityManager ]
Start procnet.coollet.infzmreader:umengService_v1 for service
net.coollet.infzmreader/com.umeng.message.
UmengService:pid=21745 uid=10039 gids={50039, 3003, 1015,1028}
[ 12-09 21:39:35.518 21745:21745I/dalvikvm ]
Turning on JNI app bug workarounds fortarget SDK version 8...
[ 12-09 21:39:35.611 21745:21745D/AgooService ]
onCreate()
我們以第一行為例：12-09 是日期，21:39:35.510是時間396是進程號，416是線程號；I代表log優先順序，ActivityManager是log標簽。
在應用開發中，這些信息的作用可能不是很大。但是在系統開發中，這些都是很重要的輔助信息。開發工程師分析的log很多都是由測試工程師抓取的，所以可能有些log根本就不是當時出錯的log。如果出現這種情況，無論你怎麼分析都不太可能得出正確的結論。如何能最大限度的避免這種情況呢？筆者就要求測試工程師報bug時必須填上bug發生的時間。這樣結合log里的時間戳信息就能大致判斷是否是發生錯誤時的log。而且根據測試工程師提供的bug發生時間點，開發工程師可以在長長的log信息中快速的定位錯誤的位置，縮小分析的范圍。
同時我們也要注意，時間信息在log分析中可能被錯誤的使用。例如：在分析多線程相關的問題時，我們有時需要根據兩段不同線程中log語句執行的先後順序來判斷錯誤發生的原因，但是我們不能以兩段log在log文件中出現的先後做為判斷的條件，這是因為在小段時間內兩個線程輸出log的先後是隨機的，log列印的先後順序並不完全等同於執行的順序。那麼我們是否能以log的時間戳來判斷呢？同樣是不可以，因為這個時間戳實際上是系統列印輸出log時的時間，並不是調用log函數時的時間。遇到這種情況唯一的辦法是在輸出log前，調用系統時間函數獲取當時時間，然後再通過log信息列印輸出。這樣雖然麻煩一點，但是只有這樣取得的時間才是可靠的，才能做為我們判斷的依據。
另外一種誤用log中時間戳的情況是用它來分析程序的性能。一個有多年工作經驗的工程師拿著他的性能分析結果給筆者看，但是筆者對這份和實際情況相差很遠的報告表示懷疑，於是詢問這位工程師是如何得出結論的。他的回答讓筆者很驚訝，他計算所採用的數據就是log信息前面的時間戳。前面我們已經講過，log前面時間戳和調用log函數的時間並不相同，這是由於系統緩沖log信息引起的，而且這兩個時間的時間差並不固定。所以用log信息前附帶的時間戳來計算兩段log間代碼的性能會有比較大的誤差。正確的方法還是上面提到的：在程序中獲取系統時間然後列印輸出，利用我們列印的時間來計算所花費的時間。
了解了時間，我們再談談進程Id和線程Id，它們也是分析log時很重要的依據。我們看到的log文件，不同進程的log信息實際上是混雜在一起輸出的，這給我們分析log帶來了很大的麻煩。有時即使是一個函數內的兩條相鄰的log，也會出現不同進程的log交替輸出的情況，也就是A進程的第一條log後面跟著的是B進程的第二條log，對於這樣的組合如果不細心分析，就很容易得出錯誤的結論。這時一定要仔細看log前面的進程Id，把相同Id的log放到一起看。
不同進程的log有這樣的問題，不同的線程輸出的log當然也存在著相同的問題。Logcat加上-vthread就能列印出線程Id。但是有一點也要引起注意，就是Android的線程Id和我們平時所講的Linux線程Id並不完全等同。首先，在Android系統中，C++層使用的Linux獲取線程Id的函數gettid()是不能得到線程Id的，調用gettid()實際上返回的是進程Id。作為替代，我們可以調用pthread_self()得到一個唯一的值來標示當前的native線程。Android也提供了一個函數androidGetThreaId()來獲取線程Id，這個函數實際上就是在調用pthread_self函數。但是在Java層線程Id又是另外一個值，Java層的線程Id是通過調用Thread的getId方法得到的，這個方法的返回值實際上來自Android在每個進程的java層中維護的一個全局變數，所以這個值和C++層所獲得的值並不相同。這也是我們分析log時要注意的問題，如果是Java層線程Id，一般值會比較小，幾百左右；如果是C++層的線程，值會比較大。在前裡面的log樣本中，就能很容易的看出，第一條log是Jave層輸出的log，第二條是native層輸出的。明白了這些，我們在分析log時就不要看見兩段log前面的線程Id不相同就得出是兩個不同線程log的簡單結論，還要注意Jave層和native層的區別，這樣才能防止被誤導。
AndroidLog的優先順序在列印輸出時會被轉換成V，I，D，W，E等簡單的字元標記。在做系統log分析時，我們很難把一個log文件從頭看到尾，都是利用搜索工具來查找出錯的標記。比如搜索「E/」來看看有沒有指示錯誤的log。所以如果參與系統開發的每個工程師都能遵守Android定義的優先順序含義來輸出log，這會讓我們繁重的log分析工作變得相對輕鬆些。
Android比較常見的嚴重問題有兩大類，一是程序發生崩潰；二是產生了ANR。程序崩潰和ANR既可能發生在java層，也可能發生在native層。如果問題發生在java層，出錯的原因一般比較容易定位。如果是native層的問題，在很多情況下，解決問題就不是那麼的容易了。我們先看一個java層的崩潰例子：
I/ActivityManager( 396): Start proccom.test.crash for activity com.test.crash/.MainActivity:
pid=1760 uid=10065 gids={50065, 1028}
D/AndroidRuntime( 1760): Shutting downVM
W/dalvikvm( 1760): threadid=1: threadexiting with uncaught exception(group=0x40c38930)
E/AndroidRuntime( 1760): FATALEXCEPTION: main
E/AndroidRuntime( 1760):java.lang.RuntimeException: Unable to start activityComponentInfo
{com.test.crash/com.test.crash.MainActivity}:java.lang.NullPointerException
E/AndroidRuntime( 1760): atandroid.app.ActivityThread.performLaunchActivity(ActivityThread.java:2180)
E/AndroidRuntime( 1760): atandroid.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2230)
E/AndroidRuntime( 1760): atandroid.app.ActivityThread.access$600(ActivityThread.java:141)
E/AndroidRuntime( 1760): atandroid.app.ActivityThread$H.handleMessage(ActivityThread.java:1234)
E/AndroidRuntime( 1760): atandroid.os.Handler.dispatchMessage(Handler.java:99)
E/AndroidRuntime( 1760): atandroid.os.Looper.loop(Looper.java:137)
E/AndroidRuntime( 1760): atandroid.app.ActivityThread.main(ActivityThread.java:5050)
E/AndroidRuntime( 1760): atjava.lang.reflect.Method.invokeNative(NativeMethod)
E/AndroidRuntime( 1760): atjava.lang.reflect.Method.invoke(Method.java:511)
E/AndroidRuntime( 1760): atcom.android.internal.os.ZygoteInit$MethodAndArgsCaller.run
(ZygoteInit.java:793)
E/AndroidRuntime( 1760): atcom.android.internal.os.ZygoteInit.main(ZygoteInit.java:560)
E/AndroidRuntime( 1760): atdalvik.system.NativeStart.main(NativeMethod)
E/AndroidRuntime( 1760): Caused by:java.lang.NullPointerException
E/AndroidRuntime( 1760): atcom.test.crash.MainActivity.setViewText(MainActivity.java:29)
E/AndroidRuntime( 1760): atcom.test.crash.MainActivity.onCreate(MainActivity.java:17)
E/AndroidRuntime( 1760): atandroid.app.Activity.performCreate(Activity.java:5104)
E/AndroidRuntime( 1760): atandroid.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1080)
E/AndroidRuntime( 1760): atandroid.app.ActivityThread.performLaunchActivity(ActivityThread.java:2144)
E/AndroidRuntime( 1760): ... 11more
I/Process ( 1760): Sending signal.PID: 1760 SIG: 9
W/ActivityManager( 396): Force finishing activitycom.test.crash/.MainActivity
Jave層的代碼發生crash問題時，系統往往會列印出很詳細的出錯信息。比如上面這個例子，不但給出了出錯的原因，還有出錯的文件和行數。根據這些信息，我們會很容易的定位問題所在。native層的crash雖然也有棧log信息輸出，但是就不那麼容易看懂了。下面我們再看一個native層crash的例子：
F/libc ( 2102): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread2102 (testapp)
D/dalvikvm(26630):GC_FOR_ALLOC freed 604K, 11% free 11980K/13368K, paused 36ms, total36ms
I/dalvikvm-heap(26630):Grow heap (frag case) to 11.831MB for 102416-byteallocation
D/dalvikvm(26630):GC_FOR_ALLOC freed 1K, 11% free 12078K/13472K, paused 34ms, total34ms
I/DEBUG ( 127):*** *** *** *** *** *** *** *** *** *** *** *** *** *** ******
I/DEBUG ( 127):Build fingerprint:
'Android/full_maguro/maguro:4.2.2/JDQ39/eng.liuchao.20130619.201255:userdebug/test-keys'
I/DEBUG ( 127):Revision: '9'
I/DEBUG ( 127):pid: 2102, tid: 2102, name: testapp >>>./testapp <<<
I/DEBUG ( 127):signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr00000000
I/DEBUG ( 127): r0 00000020 r173696874 r2 400ff520 r300000000
I/DEBUG ( 127): r4 400ff469 r5beb4ab24 r6 00000001 r7beb4ab2c
I/DEBUG ( 127): r8 00000000 r900000000 sl 00000000 fpbeb4ab1c
I/DEBUG ( 127): ip 4009b5dc spbeb4aae8 lr 400ff46f pc400ff45e cpsr 60000030
I/DEBUG ( 127): d0 000000004108dae8 d1 4108ced84108cec8
I/DEBUG ( 127): d2 4108cef84108cee8 d3 4108cf184108cf08
I/DEBUG ( 127): d4 4108c5a84108c598 d5 4108ca084108c5b8
I/DEBUG ( 127): d6 4108ce684108ce58 d7 4108ce884108ce78
I/DEBUG ( 127): d8 0000000000000000 d9 0000000000000000
I/DEBUG ( 127): d10 0000000000000000 d110000000000000000
I/DEBUG ( 127): d120000000000000000 d130000000000000000
I/DEBUG ( 127): d14 0000000000000000 d150000000000000000
I/DEBUG ( 127): d16 c1dcf7c087fec8b4 d173f50624dd2f1a9fc
I/DEBUG ( 127): d18 41c7b1ac89800000 d190000000000000000
I/DEBUG ( 127): d20 0000000000000000 d210000000000000000
I/DEBUG ( 127): d22 0000000000000000 d230000000000000000
I/DEBUG ( 127): d24 0000000000000000 d250000000000000000
I/DEBUG ( 127): d26 0000000000000000 d270000000000000000
I/DEBUG ( 127): d28 0000000000000000 d290000000000000000
I/DEBUG ( 127): d30 0000000000000000 d310000000000000000
I/DEBUG ( 127): scr 00000010
I/DEBUG ( 127):
I/DEBUG ( 127):backtrace:
I/DEBUG ( 127): #00 pc0000045e /system/bin/testapp
I/DEBUG ( 127): #01 pc0000046b /system/bin/testapp
I/DEBUG ( 127): #02 pc0001271f /system/lib/libc.so (__libc_init+38)
I/DEBUG ( 127): #03 pc00000400 /system/bin/testapp
I/DEBUG ( 127):
I/DEBUG ( 127):stack:
I/DEBUG ( 127): beb4aaa8 000000c8
I/DEBUG ( 127): beb4aaac 00000000
I/DEBUG ( 127): beb4aab0 00000000
I/DEBUG ( 127): beb4aab4 401cbee0 /system/bin/linker
I/DEBUG ( 127): beb4aab8 00001000
I/DEBUG ( 127): beb4aabc 4020191d /system/lib/libc.so (__libc_fini)
I/DEBUG ( 127): beb4aac0 4020191d /system/lib/libc.so (__libc_fini)
I/DEBUG ( 127): beb4aac4 40100eac /system/bin/testapp
I/DEBUG ( 127): beb4aac8 00000000
I/DEBUG ( 127): beb4aacc 400ff469 /system/bin/testapp
I/DEBUG ( 127): beb4aad0 beb4ab24 [stack]
I/DEBUG ( 127): beb4aad4 00000001
I/DEBUG ( 127): beb4aad8 beb4ab2c [stack]
I/DEBUG ( 127): beb4aadc 00000000
I/DEBUG ( 127): beb4aae0 df0027ad
I/DEBUG ( 127): beb4aae4 00000000
I/DEBUG ( 127): #00 beb4aae8 00000000
I/DEBUG ( 127): ........ ........
I/DEBUG ( 127): #01 beb4aae8 00000000
I/DEBUG ( 127): beb4aaec 401e9721 /system/lib/libc.so (__libc_init+40)
I/DEBUG ( 127): #02 beb4aaf0 beb4ab08 [stack]
I/DEBUG ( 127): beb4aaf4 00000000
I/DEBUG ( 127): beb4aaf8 00000000
I/DEBUG ( 127): beb4aafc 00000000
I/DEBUG ( 127): beb4ab00 00000000
I/DEBUG ( 127): beb4ab04 400ff404 /system/bin/testapp
I/DEBUG ( 127):
這個log就不那麼容易懂了，但是還是能從中看出很多信息，讓我們一起來學習如何分析這種log。首先看下面這行：
pid: 2102, tid: 2102,name: testapp >>>./testapp <<<
從這一行我們可以知道crash進程的pid和tid，前文我們已經提到過，Android調用gettid函數得到的實際是進程Id號，所以這里的pid和tid相同。知道進程號後我們可以往前翻翻log，看看該進程最後一次列印的log是什麼，這樣能縮小一點范圍。
接下來內容是進程名和啟動參數。再接下來的一行比較重要了，它告訴了我們從系統角度看，出錯的原因：
signal 11 (SIGSEGV), code 1(SEGV_MAPERR), fault addr 00000000
signal11是Linux定義的信號之一，含義是Invalidmemory reference，無效的內存引用。加上後面的「faultaddr 00000000」我們基本可以判定這是一個空指針導致的crash。當然這是筆者為了講解而特地製造的一個Crash的例子，比較容易判斷，大部分實際的例子可能就沒有那麼容易了。
再接下來的log列印出了cpu的所有寄存器的信息和堆棧的信息，這裡面最重要的是從堆棧中得到的backtrace信息：
I/DEBUG ( 127):backtrace:
I/DEBUG ( 127): #00 pc0000045e /system/bin/testapp
I/DEBUG ( 127): #01 pc0000046b /system/bin/testapp
I/DEBUG ( 127): #02 pc0001271f /system/lib/libc.so (__libc_init+38)
I/DEBUG ( 127): #03 pc00000400 /system/bin/testapp
因為實際的運行系統里沒有符號信息，所以列印出的log里看不出文件名和行數。這就需要我們藉助編譯時留下的符號信息表來翻譯了。Android提供了一個工具可以來做這種翻譯工作：arm-eabi-addr2line，位於prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/bin目錄下。用法很簡單：
#./arm-eabi-addr2line -f -eout/target/proct/hammerhead/symbols/system/bin/testapp0x0000045e
參數-f表示列印函數名；參數-e表示帶符號表的模塊路徑；最後是要轉換的地址。這條命令在筆者的編譯環境中得到的結果是：
memcpy /home/rd/compile/android-4.4_r1.2/bionic/libc/include/string.h:108
剩餘三個地址翻譯如下：
main /home/rd/compile/android-4.4_r1.2/packages/apps/testapp/app_main.cpp:38
out_vformat /home/rd/compile/android-4.4_r1.2/bionic/libc/bionic/libc_logging.cpp:361
_start libgcc2.c:0
利用這些信息我們很快就能定位問題了。不過這樣手動一條一條的翻譯比較麻煩，筆者使用的是從網上找到的一個腳本，可以一次翻譯所有的行，有需要的讀者可以在網上找一找。
了解了如何分析普通的Log文件，下面讓我們再看看如何分析ANR的Log文件。
『捌』 如何讀懂和分析Android的logcat以及stack traces
一般在平時工作中，基本上很多代碼可以在eclipse+ndk進行調試，但如果需要用到具體的硬體設備，如媒體播放設備無法模擬的情況下，只能上硬體(盒子或手機)上進行調試。此時唯一的調試手段就是logcat產生log信息進行分析問題了。
什麼時候會有Log文件的產生 ?一般在如下幾種情況會產生log文件 。
1、程序異常退出 uncaused exception
2、程序強制關閉 Force Closed (簡稱FC)
3、程序無響應 Application No Response(簡稱ANR),一般主線程超過5秒么有處理就會ANR
4、手動生成
進入控制台輸入：logcat命令即可進行輸出
第一部分
1、分析工具介紹
a、cat /proc/meminfo 顯示基本的內存信息
------ MEMORY INFO (/proc/meminfo) ------
MemTotal: 285184 kB
MemFree: 106360 kB
Buffers: 0 kB
Cached: 60036 kB
SwapCached: 0 kB
Active: 98160 kB
Inactive: 49100 kB
Active(anon): 87260 kB
Inactive(anon): 288 kB
Active(file): 10900 kB
Inactive(file): 48812 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 87240 kB
Mapped: 26500 kB
Shmem: 324 kB
Slab: 13340 kB
SReclaimable: 1672 kB
SUnreclaim: 11668 kB
KernelStack: 2160 kB
PageTables: 5600 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 142592 kB
Committed_AS: 1065600 kB
VmallocTotal: 417792 kB
VmallocUsed: 137700 kB
VmallocChunk: 254980 kB
重點關注這下面幾個值：
MemTotal: 285184 kB //總計物理內存的大小
MemFree: 106360 kB //可用內存有多少
Buffers: 0 kB //磁碟緩存內存的大小
Cached: 60036 kB
# free
free
total used free shared buffers
Mem: 285184 178884 106300 0 0
Swap: 0 0 0
Total: 285184 178884 106300
在linux中有這么一種思想，內存不用白不用，因此它盡可能的cache和buffer一些數據，以方便下次使用。
但實際上這些內存也是可以立刻拿來使用的。
所以空閑內存=free+buffers+cached=total-used
還有幾個命令可使用：
/proc/meminfo 機器的內存使用信息
/proc/pid/maps pid為進程號，顯示當前進程所佔用的虛擬地址。
/proc/pid/statm 進程所佔用的內存
b、查看進程信息
------ CPU INFO (top -n 1 -d 1 -m 30 -t) ------
能夠實時顯示系統中各個進程的資源佔用狀況，類似於 Windows 的任務管理器
c、android提供的一些操作工具
------ PROCRANK (procrank) ------
------ PROCMEM (procmem) ------
------ SHOWMAP (showmap) ------
... 就不一一列舉了，有興趣的朋友可以去看看
這此工具的代碼位於android的 /system/extras
d、虛擬內存的查看工具
------ VIRTUAL MEMORY STATS (/proc/vmstat) ------
------ VMALLOC INFO (/proc/vmallocinfo) ------
2、時間信息,也是我們主要分析的信息
格式如下：
------ SYSTEM LOG (logcat -b system -v time -d *:v) ------
$:logcat -b system -v time -d *:v
01-02 08:00:02.570 I/SystemServer( 957): Notification Manager
01-02 08:00:02.570 I/SystemServer( 957): Device Storage Monitor
01-02 08:00:02.580 I/SystemServer( 957): Location Manager
01-02 08:00:02.580 I/SystemServer( 957): Search Service
01-02 08:00:02.590 I/SystemServer( 957): DropBox Service
01-02 08:00:02.590 I/SystemServer( 957): Wallpaper Service
3、虛擬機信息,包括進程的,線程的跟蹤信息,這是用來跟蹤進程和線程具體點的好地方 。
------ VM TRACES JUST NOW (/data/anr/traces.txt.bugreport: 2011-01-15 16:49:02) ------
------ VM TRACES AT LAST ANR (/data/anr/traces.txt: 2011-01-15 16:49:02) ------
格式如下 ：
----- pid 1516 at 1970-01-02 08:03:07 -----
Cmd line: com.ipanel.join.appstore
DALVIK THREADS:
(mutexes: tll=0 tsl=0 tscl=0 ghl=0 hwl=0 hwll=0)
"main" prio=5 tid=1 NATIVE
| group="main" sCount=1 dsCount=0 obj=0x4001f188 self=0xd028
| sysTid=1516 nice=0 sched=3/0 cgrp=[fopen-error:2] handle=-1345017744
第二部分
如何分析log信息
1、查找錯誤信息的關鍵字眼
"error" "failxx" "E/" 等的錯誤信息
將這些問題先行解決掉
2、動態庫死機
查看類似的「Build fingerprint:」這些關鍵字
I/DEBUG ( 692): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG ( 692): Build fingerprint: 'generic/generic/generic:2.3.1/GRH78/eng.userdev-rd6-input.20120221.113348:eng/test-keys'
I/DEBUG ( 692): pid: 694, tid: 694 >>> /system/bin/mediaserver <<<
I/DEBUG ( 692): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000input mole init -->
010
對於這此信息，可以查看動態庫的分析：
http://blog.csdn.net/andyhuabing/article/details/7074979
3、解決java拋異常的問題解決
E/UsbObserver( 957): java.lang.NullPointerException
E/UsbObserver( 957): at com.android.server.UsbObserver.init(UsbObserver.java:131)
E/UsbObserver( 957): at com.android.server.UsbObserver.<init>(UsbObserver.java:65)
E/UsbObserver( 957): at com.android.server.ServerThread.run(SystemServer.java:419)
I/SystemServer( 957): UI Mode Manager Service
這個直接找到java代碼，分析其實現即可解決
4、ANR問題
搜索「ANR」關鍵詞，快速定位到關鍵事件信息 。
定位到關鍵的事件信息如下:
I/dalvikvm( 1014): Wrote stack traces to '/data/anr/traces.txt'
I/Process ( 957): Sending signal. PID: 1124 SIG: 9
指定哪個java包出問題
E/ActivityManager( 957): ANR in com.ipanel.join.appstore
進程號為957發生了如下錯誤：com.ipanel.join.appstore 包下面 Broadcast問題
ANR原因：
E/ActivityManager( 957): Reason: Broadcast of Intent { act=android.appwidget.action.APPWIDGET_UPDATE cmp=com.ipanel.join.appstore/.widget.SmallWidget1 (has extras) }
這是ANR的堆棧調用文件
I/dalvikvm( 1014): Wrote stack traces to '/data/anr/traces.txt'
通過上面的log信息分析，應該是接收一個廣播消息時超時了
我們再分析虛擬機信息 ，打開/data/anr/traces.txt,可有通過adb pull /data/anr/traces.txt .
這里每一段都是一個線程 ，當然我們還是看線程號為1的主線程了。通過分析發現關鍵問題是這樣：
搜索「DALVIK THREADS」關鍵詞，快速定位到本應用程序的虛擬機信息日誌
----- pid 1516 at 1970-01-02 08:03:07 -----
Cmd line: com.ipanel.join.appstore
DALVIK THREADS:
。。。
at com.ipanel.join.appstore.widget.AbsSmallWidget.getRemoteViews(AbsSmallWidget.java:56)
其實從這句話：
at org.apache.harmony.luni.platform.OSNetworkSystem.connect(Native Method)
基本上確認是 socket ->connect 連接超時了，導致主線程5s內沒有響應從而產生ANR錯誤。默認的connect連接timeout時間是75s
其實解決辦法就是利用非阻塞方式進行連接即可。
從CPU佔用率上也可以看出是在kernel中執行堵塞住了
E/ActivityManager( 957): 75% TOTAL: 4.7% user + 70% kernel
5、執行DexOpt錯誤
W/dalvikvm( 1803): DexOpt: --- END 'SettingsProvider.apk' --- status=0x000a, process failed
E/dalvikvm( 1803): Unable to extract+optimize DEX from '/system/app/SettingsProvider.apk'
。。。。android.app.ActivityThread.installProvider(ActivityThread.java:3557)
E/SystemServer( 1803): at android.app.ActivityThread.getProvider(ActivityThread.java:3356)
從上面的列印看，是在解壓或優化extract+optimize DEX的apk文件時出錯了
1、沒有出現magic number錯誤，這個原因與原子操作無關(這是一快速的加鎖和解鎖的輕量級操作函數)
2、執行dexopt出錯
查明是伺服器硬碟沒空間了，導致引導文件系統的時候沒有空間進行解壓而失敗
6、系統啟動後默認其妙或隨機死機情況
出現這種錯誤：
12-01 08:11:56.027: WARN/SharedBufferStack(312): waitForCondition(LockCondition) timed out (identity=19, status=0). CPU may be pegged. trying again.
12-01 08:11:57.315: WARN/SharedBufferStack(312): waitForCondition(LockCondition) timed out (identity=19, status=0). CPU may be pegged. trying again.
12-01 08:11:59.318: WARN/SharedBufferStack(312): waitForCondition(LockCondition) timed out (identity=19, status=0). CPU may be pegged. trying again.
12-01 08:12:03.332: WARN/SharedBufferStack(312): waitForCondition(LockCondition) timed out (identity=19, status=0). CPU may be pegged. trying again.
12-01 08:12:05.329: WARN/SharedBufferStack(312): waitForCondition(LockCondition) timed out (identity=19, status=0). CPU may be pegged. trying again.
12-01 08:12:07.216: WARN/KeyCharacterMap(312): No keyboard for id 0
12-01 08:12:07.216: WARN/KeyCharacterMap(312): Using default keymap: /system/usr/keychars/qwerty.kcm.bin
『玖』 android數據分析工具有哪些詳細的有嗎
微信公眾號數據分析工具有不少，介紹你微問數據，可以從下面5點分析： 1、圖文內容分析：優化內容提升消費者信任 2、用戶分析：用戶增長和流失一目瞭然， 3、自定義菜單點擊分析：全面記錄用戶軌跡，優化自定義菜單排序 4、關鍵詞分析：快速提升關鍵詞命中率 5、渠道分析：發現流量，發現好渠道
『拾』 android性能測試工具有哪些
大概有如下幾個工具：
android針對上面這些會影響到應用性能的情況提供了一些列的工具：
1 布局復雜度：
hierarchyviewer：檢測布局復雜度，各視圖的布局耗時情況：
Android開發者模式—GPU過渡繪制：
2 耗電量：Android開發者模式中的電量統計；
3 內存：
應用運行時內存使用情況查看：Android Studio—Memory/CPU/GPU；
內存泄露檢測工具：DDMS—MAT；
4 網路：Android Studio—NetWork；
5 程序執行效率：
靜態代碼檢查工具：Android studio—Analyze—Inspect Code.../Code cleanup... ，用於檢測代碼中潛在的問題、存在效率問題的代碼段並提供改善方案；
DDMS—TraceView，用於查找程序運行時具體耗時在哪；
StrictMode：用於查找程序運行時具體耗時在哪，需要集成到代碼中；
Andorid開發者模式—GPU呈現模式分析。
6 程序穩定性：monkey，通過monkey對程序在提交測試前做自測，可以檢測出明顯的導致程序不穩定的問題，執行monkey只需要一行命令，提交測試前跑一次可以避免應用剛提交就被打回的問題。
說明：
上面提到的這些工具可以進Android開發者官網性能工具介紹查看每個工具的介紹和使用說明；
Android開發者選項中有很多測試應用性能的工具，對應用性能的檢測非常有幫助，具體可以查看：All about your phone's developer options和15個必知的Android開發者選項對Android開發者選項中每一項的介紹；
針對Android應用性能的優化，Google官方提供了一系列的性能優化視頻教程，對應用性能優化具有非常好的指導作用，具體可以查看：優酷Google Developers或者Android Performance Patterns。
二 第三方性能優化工具介紹
除了android官方提供的一系列性能檢測工具，還有很多優秀的第三方性能檢測工具使用起來更方便，比如對內存泄露的檢測，使用leakcanry比MAT更人性化，能夠快速查到具體是哪存在內存泄露。
leakcanary：square/leakcanary · GitHub，通過集成到程序中的方式，在程序運行時檢測應用中存在的內存泄露，並在頁面中顯示，在應用中集成leancanry後，程序運行時會存在卡頓的情況，這個是正常的，因為leancanry就是通過gc操作來檢測內存泄露的，gc會知道應用卡頓，說明文檔：LeakCanary 中文使用說明、LeakCanary: 讓內存泄露無所遁形。
GT：GT Home，GT是騰訊開發的一款APP的隨身調測平台，利用GT，可以對CPU、內存、流量、點亮、幀率/流暢度進行測試，還可以查看開發日誌、crash日誌、抓取網路數據包、APP內部參數調試、真機代碼耗時統計等等，需要說明的是，應用需要集成GT的sdk後，GT這個apk才能在應用運行時對各個性能進行檢測。