android分析
A. 分析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才能在應用運行時對各個性能進行檢測。
B. 如何從技術上全面分析一款android app
一、用戶體驗是王道
1.這是一個看臉的時代，不論是人還是app。
2.Android出現也已經是很長的一段時間了，各種技術相對比較成熟，開源社區里那些圖片庫、網路庫、UI界面、數據框架一抓一大把，在同一個類別的應用中，如果沒點干貨真的很難脫穎而出。誰來判斷干貨，不是研發，不是pm，是用戶。
3.我現在的Leader之前跟我說過一句話，我深以為然--做一款app，其實最核心的是怎麼獲取到用戶，怎麼願意讓用戶去使用你，而不是你應用內的技術怎麼怎麼牛B。不喜勿噴，其實我剛開始的時候也不能理解，但是後來逐漸領悟到他說的竟然是對的。對於移動互聯網來說，app的生生死死真是太常見了，各個公司每年新開的項目一大片，真正能夠活下來的又有幾個。所以在應用的前期還是努力迭代功能，讓自己的app活下去之後，再考慮技術的問題吧
二、應用架構是否合理
1.簡單就一句話，不要重復造輪子，不要重復造輪子，尤其是不要在一個應用里反復造多個輪子。現在的軟體開發早就過了單槍匹馬闖天下的時代了，很多個研發同時工作，難免會造成各自代碼不熟悉，這時候就需要有人能夠將整個應用的架構能夠捋清楚，千萬不要出現項目中我用我的庫方法，你用你的庫方法，大家一起造輪子玩這種情況。
2.能夠使用開源庫就從了他吧。還是那句話，別人造好的輪子，為嘛不用，非得自己造一個，真以為自己是全能嗎？你不累我看著都累啊。
三、內存、網路、界面性能響應優化
其實大家都說過了軟體性能的重要性，我在這里也就不再進行復述了，反正LeakCanary,TraceView等等性能工具，誰用誰知道。
四、單元測試
感覺國內好像很少有研發自己寫單元測試的情況啊，其實我覺得很多時候，研發才是對功能最熟悉的人，很多邊界條件只有在代碼中才能夠恰好遇到，所以寫好單元測試做一隻不麻煩QA的猿才是好猿。
五、安全
Sorry，我對應用安全不是很懂，就是簡單用用Proguard混淆就Over了，加殼什麼的感覺貌似沒有太大必要，畢竟對於很多Android應用而言，其實看一眼大概知道他的界面邏輯了，ui層自己重寫絕對比逆向快，而api介面之類的東西，或許是我不太敏感吧。
C. 怎麼分析android代碼是否存在內存泄露
1、首先確定是否有內存泄露及哪個程序造成。
1.1、內存泄露已彈出out of memory對話框的情況。
這種情況很簡單，直接看對話框就知道是哪個應用的問題了。然後再分析該應用是否是因為內存泄露造成的
out of memory對話框。
》中介紹的各種方法進行分析，確定是否有內存泄露以及是哪個進程造成的內存泄露。
2、生成hprof文件，用MAT進行分析。
生
成hprof文件可以在DDMS選中進程點擊窗口左上角的mp hprof
file按鈕來直接生成，也可以通過在程序加代碼中來生成代碼2：voidgenerateHprof(){String
packageName=getApplicationInfo().packageName;
StringhpFilePath=/data/data/+packageName+/input.hprof;try{//Debug.mpHprofData(/sdcard/input.hprof);Debug.
mpHprofData
(hpFilePath);}catch(IOException e) {//TODOAuto-generated catch block
e.printStackTrace();}}建議使用代碼生成hprof，然後使用《
Android內存泄露利器（hprof篇）》中的工具自動提取多個hprof文件，然後用MAT進行比較分析。在MAT導入.hprof文件以後，
MAT會自動解析並生成報告，點擊
Dominator Tree
，並按Package分組，選擇自己所定義的Package類,比較各個類在不同時期的RetainedHeap
,找出可疑類，然後選擇該類，點右鍵，選中
show retained Set項,參看Retained Heap
的詳細信息，進一步找出嫌疑項。
3、在代碼中查找內存泄露。
根據在MAT找到的內存泄露信息，參照《
Android內存泄漏簡介
》進一步在內存中查找內存泄露的原因並解決。
另外如果代碼很簡單，可以直接參照《
Android內存泄漏簡介
》在內存中查找內存泄露的原因並解決。
D. 如何在android畫分析圖（例如 柱狀圖、趨勢圖、餅圖）
目前android上圖標引擎並不少見，像aChartEngine就能很好的完成繪圖：
aChartEngine支持：1、linechart(折線圖)2、areachart(面積圖；分區圖，對比圖)3、scatterchart(散點圖)4、timechart(時間圖；進度表)5、barchart(條形圖;柱狀圖)6、piechart(餅圖)7、bubblechart(氣泡圖)8、doughnutchart(圓環圖)9、range(high-low)barchart(范圍條形圖)10、dialchart/gauge(撥號盤/壓力表)11、combined(anycombinationofline,cubicline,scatter,bar,rangebar,bubble)chart(組合圖)12、cubiclinechart(立方折線圖)
上述所有支持的圖表類型，都可以包含多個系列，都支持水平（默認）或垂直方式展示圖表,並且支持許多其他的自定義功能。所有圖表都可以建立為一個view,也可以建立為一個用於啟動activity的intent.
下面是一個餅狀圖的源碼事例：
package org.achartengine.chartdemo.demo.chart;
import org.achartengine.ChartFactory;
import org.achartengine.renderer.DefaultRenderer;
import android.content.Context;
import android.content.Intent;
import android.graphics.Color;
public class BudgetPieChart extends AbstractDemoChart {
public String getName() {
return "Budget chart";
}
public String getDesc() {
return "The budget per project for this year (pie chart)";
}
public Intent execute(Context context) {
double[] values = new double[] { 12, 14, 11, 10, 19 };//餅圖分層5塊,每塊代表的數值
int[] colors = new int[] { Color.BLUE, Color.GREEN, Color.MAGENTA, Color.YELLOW, Color.CYAN };//每塊餅圖的顏色
DefaultRenderer renderer = buildCategoryRenderer(colors);
renderer.setZoomButtonsVisible(true);//設置顯示放大縮小按鈕
renderer.setZoomEnabled(true);//設置允許放大縮小.
renderer.setChartTitleTextSize(20);//設置圖表標題的文字大小
return ChartFactory.getPieChartIntent(context, buildCategoryDataset("Project budget", values),
renderer, "Budget");//構建Intent, buildCategoryDataset是調用AbstraDemoChart的構建方法.
}
}
E. android 內存問題怎麼分析
使用eclipse 自帶的 DDMS 工具分析各線程的內存使用情況，如下圖所示
Heap視圖界面會定時刷新，在對應用的不斷的操作過程中就可以看到內存使用的變化。
怎樣判斷當前進程是否有內存泄漏呢？
這里需要注意一個值：VM Heap頁面中部有一個data object選項，即數據對象，也就是我們的程序中大量存在的類類型的對象。
在data object一行中有一列是「Total Size」，其值就是當前進程中所有java數據對象的內存總量，一般情況下，這個值的大小決定了是否會有內存泄漏。如上圖中選中行所示。
可以據此判斷內存有泄漏：
1) 不斷的操作當前應用，或者重復某一動作，注意觀察data object的Total Size值。
2) 正常情況下Total Size值都會穩定在一個有限的范圍內，也就是說如果程序中的的代碼邏輯良好，
沒有創建的對象不被GC機制正常回收的情況，即便 我們不斷的操作生成很多對象，而在虛擬機不斷的進行垃圾回收的過程中，這些對象都被正常回收了，內存使用量會保持在一個比較穩定的水平。
3) 如果代碼中存在對象引用沒有釋放的情況，則data object的Total Size值在每次GC後不會有明顯的回落，隨著操作次數的增多Total Size的值會越來越大。
正常情況下，一個虛擬機的進程的內存在64M, 如果內存泄漏會發現 Heap Size 在不斷的逼近 64M, 一旦達到這個值時，就會出現退出應用等情況。
發生內存泄露，Total Size的值越來越大時，按下「Dump HPROF file」按鈕，這個時候會提示設置hprof文件的保存路徑。保存後，可以對比log來分析是哪些操作造成了內存泄漏。
F. 如何分析android 內存泄漏
1.資源對象沒關閉造成的內存泄漏描述：資源性對象比如(Cursor，File文件等)往往都用了一些緩沖，我們在不使用的時候，應該及時關閉它們，以便它們的緩沖及時回收內存。它們的緩沖不僅存在於 java虛擬機內，還存在於java虛擬機外。如果我們僅僅是把它的引用設置為null,而不關閉它們，往往會造成內存泄漏。因為有些資源性對象，比如 SQLiteCursor(在析構函數finalize(),如果我們沒有關閉它，它自己會調close()關閉)，如果我們沒有關閉它，系統在回收它時也會關閉它，但是這樣的效率太低了。因此對於資源性對象在不使用的時候，應該調用它的close()函數，將其關閉掉，然後才置為null.在我們的程序退出時一定要確保我們的資源性對象已經關閉。
程序中經常會進行查詢資料庫的操作，但是經常會有使用完畢Cursor後沒有關閉的情況。如果我們的查詢結果集比較小，對內存的消耗不容易被發現，只有在常時間大量操作的情況下才會復現內存問題，這樣就會給以後的測試和問題排查帶來困難和風險。
示例代碼：
Cursor cursor = getContentResolver().query(uri...);
if (cursor.moveToNext()) {
... ...
}
修正示例代碼：
Cursor cursor = null;
try {
cursor = getContentResolver().query(uri...);
if (cursor != null &&cursor.moveToNext()) {
... ...
}
} finally {
if (cursor != null) {
try {
cursor.close();
} catch (Exception e) {
//ignore this
}
}
}
2.構造Adapter時，沒有使用緩存的convertView描述：以構造ListView的BaseAdapter為例，在BaseAdapter中提供了方法：
public View getView(int position, ViewconvertView, ViewGroup parent)
來向ListView提供每一個item所需要的view對象。初始時ListView會從BaseAdapter中根據當前的屏幕布局實例化一定數量的 view對象，同時ListView會將這些view對象緩存起來。當向上滾動ListView時，原先位於最上面的list item的view對象會被回收，然後被用來構造新出現的最下面的list item。這個構造過程就是由getView()方法完成的，getView()的第二個形參View convertView就是被緩存起來的list item的view對象(初始化時緩存中沒有view對象則convertView是null)。由此可以看出，如果我們不去使用 convertView，而是每次都在getView()中重新實例化一個View對象的話，即浪費資源也浪費時間，也會使得內存佔用越來越大。 ListView回收list item的view對象的過程可以查看:
android.widget.AbsListView.java --> voidaddScrapView(View scrap) 方法。
示例代碼：
public View getView(int position, ViewconvertView, ViewGroup parent) {
View view = new Xxx(...);
... ...
return view;
}
修正示例代碼：
public View getView(int position, ViewconvertView, ViewGroup parent) {
View view = null;
if (convertView != null) {
view = convertView;
populate(view, getItem(position));
...
} else {
view = new Xxx(...);
...
}
return view;
}
3.Bitmap對象不在使用時調用recycle()釋放內存描述：有時我們會手工的操作Bitmap對象，如果一個Bitmap對象比較占內存，當它不在被使用的時候，可以調用Bitmap.recycle()方法回收此對象的像素所佔用的內存，但這不是必須的，視情況而定。可以看一下代碼中的注釋：
/**
Free up the memory associated with thisbitmap's pixels, and mark the
bitmap as "dead", meaning itwill throw an exception if getPixels() or
setPixels() is called, and will drawnothing. This operation cannot be
reversed, so it should only be called ifyou are sure there are no
further uses for the bitmap. This is anadvanced call, and normally need
not be called, since the normal GCprocess will free up this memory when
there are no more references to thisbitmap.
*/
4.試著使用關於application的context來替代和activity相關的context這是一個很隱晦的內存泄漏的情況。有一種簡單的方法來避免context相關的內存泄漏。最顯著地一個是避免context逃出他自己的范圍之外。使用Application context。這個context的生存周期和你的應用的生存周期一樣長，而不是取決於activity的生存周期。如果你想保持一個長期生存的對象，並且這個對象需要一個context,記得使用application對象。你可以通過調用 Context.getApplicationContext() or Activity.getApplication()來獲得。更多的請看這篇文章如何避免Android內存泄漏。
5.注冊沒取消造成的內存泄漏一些Android程序可能引用我們的Anroid程序的對象(比如注冊機制)。即使我們的Android程序已經結束了，但是別的引用程序仍然還有對我們的Android程序的某個對象的引用，泄漏的內存依然不能被垃圾回收。調用registerReceiver後未調用unregisterReceiver。
比如:假設我們希望在鎖屏界面(LockScreen)中，監聽系統中的電話服務以獲取一些信息(如信號強度等)，則可以在LockScreen中定義一個 PhoneStateListener的對象，同時將它注冊到TelephonyManager服務中。對於LockScreen對象，當需要顯示鎖屏界面的時候就會創建一個LockScreen對象，而當鎖屏界面消失的時候LockScreen對象就會被釋放掉。
但是如果在釋放 LockScreen對象的時候忘記取消我們之前注冊的PhoneStateListener對象，則會導致LockScreen無法被垃圾回收。如果不斷的使鎖屏界面顯示和消失，則最終會由於大量的LockScreen對象沒有辦法被回收而引起OutOfMemory,使得system_process 進程掛掉。
雖然有些系統程序，它本身好像是可以自動取消注冊的(當然不及時)，但是我們還是應該在我們的程序中明確的取消注冊，程序結束時應該把所有的注冊都取消掉。
6.集合中對象沒清理造成的內存泄漏我們通常把一些對象的引用加入到了集合中，當我們不需要該對象時，並沒有把它的引用從集合中清理掉，這樣這個集合就會越來越大。如果這個集合是static的話，那情況就更嚴重了。
G. 如何分析一個Android程序
就像普通的程序一樣，首先你得找到程序的入口，如main函數。但Android中沒有main函數這一說，但也有程序的入口，而這個入口就是AndroidMainfest.xml中的MAIN和LAUNCHER所表示的Activity，這個Activity對應的類代碼就是程序的入口。在安卓中，Avtivity往往採用MVC架構，然後你在Activity中找到相應的V，然後分析組件，再分析組件的事件，有線程的話再分析線程……就這樣一步一步下去就可以把一個安卓程序分析完了。
H. 如何分析android bugreport
一、ChkBugReport介紹
ChkBugReport是一個開源工具，它可以把你得到的bugreprot解析成適合閱讀的html文件。導出的html文件包含了根據bugreport數據得出的圖表和分析結論。
它的源碼中用到了以下開源類庫： jQuery ，jsTree jquery plugin ， tablednd jQuery plugin ， tablesorter jQuery plugin ，js-hotkeys， jquery-cookie 。學習輸出報告文檔型html可以參考源碼。
目前ChkBugReport可以從bugreport數據中抽取出如下信息：
1、Stacktraces ChkBugReport可以從bugreport中解析出輸出bugreport的最後時刻、導致ANR時刻甚至更多時刻的堆棧信息。在例子中你可以看到進程的優先順序和策略都已標示出來，堆棧中耗時的部分顏色是黑紅，一些違反Strict Mode的部分（比如主線程中使用資料庫）顏色標記為亮紅。如果這個線程死鎖，在報告的Errors將會出現。
2、Logs 這部分是對system、main和kernel日誌的分析，在這里你可以看到每個進程內存使用圖、那個程序產生的log最多、Activity的啟動耗時、資料庫操作耗時統計、對象被鎖定時間、AIDL調用時間、Activity和Service的生命周期及其在內存中使用頻率等等，詳見
3、Packages ChkBugReport解析bugreport中存儲的packages.xml並展示一系列的packages、user ids和 permissions。參見
4、Processes 操作app過程中產生的系統事件日誌、內存使用信息等等，參見
5、Battery statistics 電池使用統計信息，參見
6、CPU Frequency statistics CPU頻率統計信息，參見
7、Raw data 被分割成小段的原始數據
同時ChkBugReport也可以檢測到（潛在的）錯誤，這些錯誤在輸出的報告Errors部分中可以找到。你也可以在輸出報告的stacktrace中找到死鎖或一些違反Strict Mode的行為。
二、ChkBugReport使用
使用很簡單：1 java -jar $HOME/Downloads/chkbugreport.jar $HOME/tmp/bugreport.txt
你也可以把chkbugreport.jar加到path下，然後這樣使用1 chkbugreport thebugreport.txt
該工具將根據你的bugreport數據輸出一個分析結果目錄bugreport_out。
你可以使用如下命令取得bugreport：1 adb shell bugreport > bugreport.txt
當然你可以使用ChkBugReport分析bugreport的部分數據比如/data/anr/traces.txt1 chkbugreport -sl:the_system_log.txt -sa:traces.txt mmy
這將輸出分析結果到mmy_out。
你甚至可以使用ChkBugReport分析traceview生成的數據1 chkbugreport -t something.prof
Prof數據生成方法可以參考以下方法：
1、可以使用eclipse插件traceview生成
2、也可以按如下步驟：
a.用adb shell ps列出所有進程並找出你想要trace的進程的PID
b.執行adb shell am profile PID start /data/profile.dat，開始分析
c.操作你的app
d.執行adb shell am profile PID stop ，停止分析
e.導出數據並清除臨時文件：adb pull /data/profile.dat adb shell rm /data/profile.dat
f.使用ChkBugReport進行分析 chkbugreport -t profile.dat
I. 怎麼樣進行Android應用的性能分析
對於手機應用性能可以從兩方面關注:
1.app產品做好之後必須從每個控制項在國內不同的手機品牌和不同系統版本進行兼容性測試，業內也叫遍歷測試，所謂的遍歷測試是可以移動識別應用的控制項從而進行多層次的運行測試，當中包含了安裝測試，啟動測試，控制項遍歷測試，最後是卸載測試！
2.兼容性測試，也就是適配測試完成之後需要開始對網路性能進行測試，這里大概有幾個方面需要進行的:網路性能測試，元素載入性能測試，網路可用性測試等等！
國內現有的測試周期和測試手段都是通過人工化測試，真正實現自動化又節省時間與人力的只有藉助第三方應用性能管理提供商才可以實現！