android內存泄漏測試

『壹』 如何快速定位android app是否存在內存泄露

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內存泄漏簡介
》在內存中查找內存泄露的原因並解決。

『貳』 Android studio如何分析內存泄漏，是否有自帶的分析工具

cpu資源耗盡：估計是機器沒有反應了，鍵盤，滑鼠，以及網路等等。這個在windows上經常看見，特別是中了毒。 進程id耗盡：沒法創建新的進程了，串口或者telnet都沒法創建了。 硬碟耗盡： 機器要死了，交換內存沒法用，日誌也沒法用了，死是很正常的。 內存泄漏或者內存耗盡：新的連接無法創建，free的內存比較少。發生內存泄漏的程序很多，但是要想產生一定的後果，就需要這個進程是無限循環的，是個服務進程。當然，內核也是無限循環的，所以，如果內核發生了內存泄漏，情況就更加不妙。內存泄漏是一種很難定位和跟蹤的錯誤，目前還沒看到有什麼好用的工具（當然，用戶空間有一些工具，有靜態分析的，也會動態分析的，但是找內核的內存泄漏，沒有好的開源工具） 內存泄漏和對象的引用計數有很大的關系，再加上c/c++都沒有自動的垃圾回收機制，如果沒有手動釋放內存，問題就會出現。如果要避免這個問題，還是要從代碼上入手，良好的編碼習慣和規范，是避免錯誤的不二法門。 一般我們常說的內存泄漏是指堆內存的泄漏。 堆內存是指程序從堆中分配的，大小任意的（內存塊的大小可以在程序運行期決定），使用完後必須顯示釋放的內存。 應用程序一般使用malloc，realloc，new等函數從堆中分配到一塊內存，使用完後，程序必須負責相應的調用free或delete釋放該內存塊，否則，這塊內存就不能被再次使用，我們就說這塊內存泄漏了。 (附)部分內存泄漏檢測工具 1.ccmalloc－Linux和Solaris下對C和C++程序的簡單的使用內存泄漏和malloc調試庫。 2.Dmalloc－Debug Malloc Library. 3.Electric Fence－Linux分發版中由Bruce Perens編寫的malloc()調試庫。 4.Leaky－Linux下檢測內存泄漏的程序。 5.LeakTracer－Linux、Solaris和HP-UX下跟蹤和分析C++程序中的內存泄漏。 6.MEMWATCH－由Johan Lindh編寫，是一個開放源代碼C語言內存錯誤檢測工具，主要是通過gcc的precessor來進行。 7.Valgrind－Debugging and profiling Linux programs, aiming at programs written in C and C++. 8.KCachegrind－A visualization tool for the profiling data generated by Cachegrind and Calltree. 9.IBM Rational PurifyPlus－幫助開發人員查明C/C++、託管.NET、Java和VB6代碼中的性能和可靠性錯誤。PurifyPlus 將內存錯誤和泄漏檢測、應用程序性能描述、代碼覆蓋分析等功能組合在一個單一、完整的工具包中。 10.Parasoft Insure++－針對C/C++應用的運行時錯誤自動檢測工具，它能夠自動監測C/C++程序，發現其中存在著的內存破壞、內存泄漏、指針錯誤和I/O等錯誤。並通過使用一系列獨特的技術（SCI技術和變異測試等），徹底的檢查和測試我們的代碼，精確定位錯誤的准確位置並給出詳細的診斷信息。能作為Microsoft Visual C++的一個插件運行。 11.Compuware DevPartner for Visual C++ BoundsChecker Suite－為C++開發者設計的運行錯誤檢測和調試工具軟體。作為Microsoft Visual Studio和C++ 6.0的一個插件運行。 12.Electric Software GlowCode－包括內存泄漏檢查，code profiler，函數調用跟蹤等功能。給C++和.Net開發者提供完整的錯誤診斷，和運行時性能分析工具包。 13.Compuware DevPartner Java Edition－包含Java內存檢測,代碼覆蓋率測試,代碼性能測試,線程死鎖,分布式應用等幾大功能模塊。 14.Quest JProbe－分析Java的內存泄漏。 15.ej-technologies JProfiler－一個全功能的Java剖析工具，專用於分析J2SE和J2EE應用程序。它把CPU、執行緒和內存的剖析組合在一個強大的應用中。 16.BEA JRockit－用來診斷Java內存泄漏並指出根本原因，專門針對Intel平台並得到優化，能在Intel硬體上獲得最高的性能。

『叄』 如何用MAT分析Android應用內存泄露

Android應用內存泄漏的的原因有以下幾個：1查詢資料庫後沒有關閉游標cursor2構造Adapter時，沒有使用convertView重用3Bitmap對象不在使用時調用recycle()釋放內存4對象被生命周期長的對象引用，如activity被靜態集合引用導致activity不能釋放內存泄漏的發現:通過DDMS中的heap工具，去發現是否有內存溢出。內存泄漏如何解決：通過內存分析工具MAT(MemoryAnalyzerTool)，找到內存泄露的對象

『肆』 Android開發中，有哪些好方法可以檢測內存泄露和性能

下面是回答的內容

內存泄露，是Android開發者最頭疼的事。可能一處小小的內存泄露，都可能是毀於千里之堤的蟻穴。怎麼才能檢測內存泄露呢？網上教程非常多，不過很多都是使用Eclipse檢測的, 其實1.3版本以後的Android Studio 檢測內存非常方便, 如果結合上MAT工具,LeakCanary插件,一切就變得so easy了。

熟悉Android Studio界面工欲善其事,必先利其器。

我們接下來先來熟悉下Android Studio的界面

結果

非獨占時間:某函數佔用的CPU時間,包含內部調用其它函數的CPU時間。
獨占時間:某函數佔用CPU時間,但不含內部調用其它函數所佔用的CPU時間。

我們如何判斷可能有問題的方法？

通過方法的調用次數和獨占時間來查看，通常判斷方法是：

如果方法調用次數不多，但每次調用卻需要花費很長的時間的函數，可能會有問題。

如果自身佔用時間不長，但調用卻非常頻繁的函數也可能會有問題。

綜述

上面給大家介紹了若干使用Android Studio檢查程序性能的工具,工具永遠是輔助,不要因為工具耽誤太長時間。如果有問題，歡迎大家糾正。

『伍』 Android用MAT檢測內存泄漏問題。。

Eclipse 有個插件工具MAT(Memory Analyzer Tool)可以幫助定位內存泄漏的對象。
安裝MAT Update site: http://archive.eclipse.org/mat/1.1/update-site/
用DDMS工具Dump出問題App的.hprof文件 比如com.world.test2.hprof Dump之前最好先運行一下GC "Cause GC" , 確保mp出來的是還不能回收的對象等。
用SDK tools下工具hprof-conv.exe 做轉換 hprof-conv com.world.test2.hprof appleak.hprof
用Eclipse 「Open Head Dump」打開新轉換的.hprof 文件--appleak.hprof 查看圖形化界面，一個一個檢查懷疑的點。
總結： MAT tool不會直接告訴你哪裡內存泄漏，但是會列出懷疑的對象，需要你仔細檢查這些對象為什麼沒有被釋放掉。
下面是測試code， 在Android 4.2.2上測試過。 1. 此種情況可以引起Activity無法回收的情況，因為直接用類似private static Activity a0引用創建的Activity,導致Activity無法回收。 2. 此種情況沒有引起Activity 無法回收的情況。 按理說這種情況應該也會導致靜態Drawable 鎖定Activity, 引用關系mBackground1-->Button-->Activity. 待分析
public class MainActivity extends Activity implements Button.OnClickListener{

final private static String TAG = "MainActivity";

private static Drawable mBackground1;

private static Drawable mBackground2;

private static Drawable mBackground3;

private static Drawable mBackground4;

private static Activity a0 ;

private static Activity a1 ;

private static Activity a2 ;

private static Activity a3 ;

private static Activity a4 ;

/*

* Shutdown intent

*/

private final String INTENT_ACTION_REQUEST_SHUTDOWN =

"android.intent.action.ACTION_REQUEST_SHUTDOWN";

@Override

public void onCreate(Bundle savedInstanceState) {

Log.v(TAG, "onCreate Activity="+this);

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_main);

//1

if(false){

if(a0 == null){

a0 = this;

Log.v(TAG, "onCreate Activity a0="+a0);

}

else if(a1 == null){

a1 = this;

Log.v(TAG, "onCreate Activity a1="+a1);

}

else if(a2 == null){

a2 = this;

Log.v(TAG, "onCreate Activity a2="+a2);

}

else if(a3 == null){

a3 = this;

Log.v(TAG, "onCreate Activity a3="+a3);

}

else if(a4 == null){

a4 = this;

Log.v(TAG, "onCreate Activity a4="+a4);

}

}

//set up button listener

Button myButton = (Button)findViewById(R.id.button_poweroff);

myButton.setOnClickListener(this);

myButton = (Button)findViewById(R.id.button_reboot);

myButton.setOnClickListener(this);

//2

if (mBackground1 == null) {

Log.v(TAG, "onCreate mBackground1");

mBackground1 = getResources().getDrawable(R.drawable.adbroot_004);

myButton.setBackgroundDrawable(mBackground1);
}

else if(mBackground2 == null){

Log.v(TAG, "onCreate mBackground2");

mBackground2 = getResources().getDrawable(R.drawable.test002);

myButton.setBackgroundDrawable(mBackground2);

}

else if(mBackground3 == null){

Log.v(TAG, "onCreate mBackground3");

mBackground3 = getResources().getDrawable(R.drawable.test003);

myButton.setBackgroundDrawable(mBackground3);

}

else if(mBackground4 == null){

Log.v(TAG, "onCreate mBackground4");

mBackground4 = getResources().getDrawable(R.drawable.adbroot_003);

myButton.setBackgroundDrawable(mBackground4);

}

}

『陸』 如何檢查android 內存泄漏

1. 查詢資料庫而沒有關閉Cursor 在Android中，Cursor是很常用的一個對象，但在寫代碼是，經常會有人忘記調用close, 或者因為代碼邏輯問題狀況導致close未被調用。 通常，在Activity中，我們可以調用startManagingCursor或直接使用managedQuery讓...

『柒』 如何在Android Studio中使用LeakCanary檢測內存泄露

內存泄露檢測是項目性能優化不可避免的問題，只有解決內存泄露問題才能從根本上解決OOM。在Eclipse中提供Mat工具來檢測內存泄露，但是使用較為麻煩，界面也不是很直觀。對於有耐心，有想法的，也是可以嘗試了解一下。知道Leak的出現，為內存泄露檢測帶來了福音。

1.什麼是LeakCanary

LeakCanary

A memory leak detection library for Android and Java.

LeakCanary是一個Android和Java的內存檢測庫。

2.LeakCanary如何展示內存泄露信息

如果項目存在內存泄露，就會在狀態欄或是一個單獨的Leaks程序中顯示內存泄露信息，提供一個造成內存泄露對象的引用路徑

【錯誤2】：但是有的人沒有相應的圖標，怎麼辦？

因為gradle設置錯誤的原因，上述build分別設置了debugCompile 和 releaseCompile，具體的區別這里不細說了，需要有一定的gradle功底，才能改修完成。這里給出的最簡易的方案，適用於該產品在加入的leakCancy僅僅在測試的時候使用，而在release包中手動去除相應的代碼：【解決當前問題，但是不提倡】
1、debug 和 release 引用相同的lib

dependencies {
debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5'
releaseCompile 'com.squareup.leakcanary:leakcanary-android:1.5'
}
2、使用compile 不再1區分debug 和 release12
dependencies {
compile 'com.squareup.leakcanary:leakcanary-android:1.5'
}

如果存在內存泄露，將會顯示內存泄露的對象的引用路徑。

『捌』 android手機測試中如何查看內存泄露

如何查看內存泄露

主要有2種方法

1. 藉助工具，查看。

2. 藉助adb 命令來查看。

【主要原理】

藉助工具來查看泄露的原因。

詳細實現方式

【工具查看】

常用工具有很多例如：

1.功能強大PC端檢測工具，如MemoryAnalyzer運行在PC端抓取Android手機中的mp文件進行深度分析。

2.小而優的Android端檢測工具，如LeakCanary隨App一起安裝會在Android手機桌面安裝的內存泄露檢測App

詳細的介紹網路裡面非常多這邊不做過多的介紹。

3.還有一種，要求不高的可以通過android studio查看內存變化等

詳細看到界面，視圖等佔用的內存情況。

【最後】

2種方法相互使用，驗證內存泄露原因。

『玖』 如何使用android-studio以及DDMS進行內存泄漏和抖動測試

SDKManager邊上的綠色android機器人圖標，打開androiddevicemonitor就好了。

『拾』 如何快速定位Android內存泄漏位置

LeakCanary
在build.gradle中引入包依賴：
debugCompile 'com.squareup.leakcanary:leakcanary-
android:1.5'
releaseCompile 'com.squareup.leakcanary:leakcanary-
android-no-op:1.5'
testCompile 'com.squareup.leakcanary:leakcanary-
android-no-op:1.5'
在Application中的onCreate方法中增加初始化代碼：
if (LeakCanary.isInAnalyzerProcess(this)) {
// This process is dedicated to LeakCanary for
// heap analysis.
// You should not init your app in this process.
return;
}
LeakCanary.install(this);
集成後什麼都不用做，按照正常測試，當有內存泄漏發生後，應用會通過系統通知欄發出通知，點擊通知就可以進入查看內存泄漏的具體信息。在這里舉個實踐中的例子。把LeakCanary集成到項目中後，等App啟動後一會，系統通知到了，點擊通知，跳轉到泄漏的詳情頁面進行查看：

//去掉static修飾符，避免static對象引起的內存泄漏
private static FrameLayout fLayout;

public MaskHeadView(Context context, AttributeSet attrs) {
super(context, attrs);
this.context=context;
initView(context);
}

private void initView(Context context2) {
view = LayoutInflater.from(context).inflate(R.layout.
mask_head_view, this);
fLayout=(FrameLayout) view.findViewById(R.id.
mask_container);
}