安卓 内存泄漏 MemoryAnalyzer

韩梦飞沙 yue31313 韩亚飞 han_meng_fei_sha [email protected]

需要 获取 root 权限

步骤:

1,使用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来分析是哪些操作造成了内存泄漏。

2,点击 按钮,导出 hprof 文件,使用MAT 工具进行分析。具体分析步骤和过程详见下面链接

http://www.ibm.com/developerworks/cn/opensource/os-cn-ecl-ma/index.html

3,打开 MAT 工具,File-->Open Heap Dump... 选择你刚刚保存的 hprof 文件打开

此时,会弹出一个错误,如下图所示:

提示:  Unknown HPROF Version (JavaPROFILE 1.0.3) (java.io.IOException)

哦,不要以为是 MAT 工具版本不对,其实是 Android 的 hprof 文件在这里需要进行转换一下格式才可以使用 MAT 打开,不知道 谷歌在这里

捣了什么鬼,难道是优化?

使用 android sdk 目录下的 tools 中一个工具进行转化一下

4,使用AndrodiSDK/tools/hprof-conv转化hprof文件,

首先,要通过控制台进入到你的 android sdk tools 目录下

例如 hprof-conv input.hprof     out.hprof

再使用MAT工具打开转换后的 hprof 文件,就能看到完整的内存使用分析报告了。

如下所示是 MAT 分析内存使用的主界面:

点击上图中的 Reports -->Leak Suspects 则可以进一步看到更详细的内存泄漏疑点。

在其中怀疑的地方,点击 Details 就可以看到具体的内存使用情况了。

tip1:

有一种比较好的方法是,在内存泄漏开始时抓取一个 hprof 文件,在内存泄漏很厉害时,app 濒临崩溃时再抓取一个hprof 文件。

对比看这两个图,就很容易看出来上面的饼图中哪一块存在内存泄漏。

有的时候能直接看出来多了一块。那么我们就从那一块入手进行分析。比较快能得到结果。

tip2:

看 dominator_tree,可以从列表中 data_object 最多的几项数据入手分析,如下文件所示(136,80对应的两项)

我这边曾经就因为在 onStart 中添加了一个 PhoneStateListener 的监听,而在 onStop 中未设置为空,导致内存泄漏。

这里引用一点别人总结的实例:

原因1:

BraodcastReceiver,ContentObserver,FileObserver,Cursor在Activity onDeatory或者某类声明周期结束之后一定要unregister或者close掉,否则这个Activity类会被system强引用,不会被内存回收。

原因2:

不要直接对Activity进行直接引用作为成员变量,如果不得不这么做,请用private WeakReference mActivity来做,相同的,对于Service等其他有自己声明周期的对象来说,直接引用都需要谨慎考虑是否会存在内存泄露的可能。()

[java] view plaincopy

  1. private static class MyHandler extends Handler {
  2. private WeakReference<GeneralSettings> mStatus;
  3. public MyHandler(GeneralSettings activity) {
  4. mStatus = new WeakReference<GeneralSettings>(activity);
  5. }
  6. @Override
  7. public void handleMessage(Message msg) {
  8. GeneralSettings status = mStatus.get();
  9. if (status == null) {
  10. return;
  11. }
  12. switch (msg.what) {
  13. case EVENT_UPDATE_STATS:
  14. status.updateTimes();
  15. sendEmptyMessageDelayed(EVENT_UPDATE_STATS, 1000);
  16. break;
  17. }
  18. }
  19. }

[java] view plain copy

  1. private static class MyHandler extends Handler {
  2. private WeakReference<GeneralSettings> mStatus;
  3. public MyHandler(GeneralSettings activity) {
  4. mStatus = new WeakReference<GeneralSettings>(activity);
  5. }
  6. @Override
  7. public void handleMessage(Message msg) {
  8. GeneralSettings status = mStatus.get();
  9. if (status == null) {
  10. return;
  11. }
  12. switch (msg.what) {
  13. case EVENT_UPDATE_STATS:
  14. status.updateTimes();
  15. sendEmptyMessageDelayed(EVENT_UPDATE_STATS, 1000);
  16. break;
  17. }
  18. }
  19. }

原因3:

对 Context 保持了一个长生命周期的引用。

[java] view plaincopy

  1. private static Drawable sBackground;
  2. @Override
  3. protected void onCreate(Bundle state) {
  4. super.onCreate(state);
  5. TextView label = new TextView(this);
  6. label.setText("Leaks are bad");
  7. if (sBackground == null) {
  8. sBackground = getDrawable(R.drawable.large_bitmap);
  9. }
  10. label.setBackgroundDrawable(sBackground);
  11. setContentView(label);
  12. }

[java] view plain copy

  1. private static Drawable sBackground;
  2. @Override
  3. protected void onCreate(Bundle state) {
  4. super.onCreate(state);
  5. TextView label = new TextView(this);
  6. label.setText("Leaks are bad");
  7. if (sBackground == null) {
  8. sBackground = getDrawable(R.drawable.large_bitmap);
  9. }
  10. label.setBackgroundDrawable(sBackground);
  11. setContentView(label);
  12. }

sBackground的生命周期比Activity要长,label引用到context,sBackground又把label设为内部成员变量,所以sBackground引用到了context,导致activity结束的时候context还是不能释放,从而引发内存泄露。(不甚理解,还要仔细研究一下)

总结:

1.      对activity的引用应该控制在activity的生命周期之内;

2.      如果不能就考虑使用getApplicationContext或者getApplication;

3.      尽量不要在静态变量或者静态内部类中使用非静态外部成员变量(包括context),即使要使用,也要考虑适时把外部成员变量置空(如上例可以通过把sBackground的callback置空来解决内存泄露的问题);也可以在内部类中使用弱引用来引用外部类的变量;

4.      做到在onDestroy中释放资源,如清空对图片等资源有直接引用或者间接引用的数组(使用array.clear();array = null);

时间: 2024-10-10 02:02:37

安卓 内存泄漏 MemoryAnalyzer的相关文章

安卓 内存 泄漏 工具 LeakCanary 使用

韩梦飞沙 yue31313 韩亚飞 han_meng_fei_sha [email protected] LeakCanary是Square开源了一个内存泄露自动探测神器 .这是项目的github仓库地址:https://github.com/square/leakcanary  .使用非常简单,在build.gradle中引入包依赖: dependencies { debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5' rel

安卓中的内存泄漏

因为安卓是基于java语言的,所以我们先来看一看java中的内存泄漏,然后在此基础上来谈谈安卓中的内存泄漏. 一java中的内存泄漏: java中的内存泄漏主要是指在堆中分配的内存,明明已经不需要的时候,还仍然保留着访问它的引用,导致GC回收不能及时回收(关于GC回收不做过多赘述),导致这种情况出现的最主要原因是长生命周期的对象持有短生命周期对象的引用,导致短生命周期的对象明明已经不需要却无法被GC回收,从而导致内存泄漏.主要包括以下几种情况: 1在一个类中创建了一个非静态内部类的静态实例,如下

eclipse java MemoryAnalyzer 查询内存泄漏 环境配置

简单记录下java用MemoryAnalyzer分析内存泄漏问题! 首先,内存不足的时候,会报错 Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded类似的错误! 这时候会生成java_pid3708.hprof类似的文件,这个文件就是MemoryAnalyzer需要分析的文件! 写个例子,快速生成这个文件! 1 public class TestMain { 2 3 publ

安卓性能测试之应用内存泄漏总结

pre { direction: ltr; color: rgb(0, 0, 10); text-align: left } pre.western { font-family: "Liberation Serif", serif; font-size: 12pt } pre.cjk { font-family: "Droid Sans Fallback"; font-size: 12pt } pre.ctl { font-family: "Droid S

安卓android WebView Memory Leak WebView内存泄漏

Android WebView Memory Leak WebView内存泄漏 在这次开发过程中,需要用到webview展示一些界面,但是加载的页面如果有很多图片就会发现内存占用暴涨,并且在退出该界面后,即使在包含该webview的Activity的destroy()方法中,使用webview.destroy();webview=null;对内存占回收用还是没有任何效果.有人说,一旦在你的xml布局中引用了webview甚至没有使用过,都会阻碍重新进入Application之后对内存的gc.包括

安卓常见引起内存泄漏的五种情况

1,单例引起的内存泄漏----解决办法 将context生命周期和application保持一致 public class SingletonAppliationContext {    private static SingletonAppliationContext instance;    private Context context;    private SingletonAppliationContext(Context context) {        this.context

使用Eclipse Memory Analyzer进行内存泄漏分析三部曲

源地址:http://seanhe.iteye.com/blog/898277 一.准备工作 分析较大的dump文件(根据我自己的经验2G以上的dump文件就需要使用以下介绍的方法,不然mat会出现oom)需要调整虚拟机参数 找个64位的系统在MemoryAnalyzer.ini设置-Xmx2g 如果是32位的xp可以使用下面的方法进行尝试: 安装jrockit 6.0的JDK mat使用jrockit的jdk来启动 Java代码   -vm D:/Program Files/Java/jroc

(转)java内存泄漏的定位与分析

转自:http://blog.csdn.net/x_i_y_u_e/article/details/51137492 1.为什么会发生内存泄漏 java 如何检测内在泄漏呢?我们需要一些工具进行检测,并发现内存泄漏问题,不然很容易发生down机问题. 编写java程序最为方便的地方就是我们不需要管理内存的分配和释放,一切由jvm来进行处理,当java对象不再被应用时,等到堆内存不够用时,jvm会进行垃圾回收,清除这些对象占用的堆内存空间,如果对象一直被应用,jvm无法对其进行回收,创建新的对象时

内存泄漏和内存溢出的优化

内存泄漏: 对象在内存heap堆中中分配的空间, 当不再使用或没有引用指向的情况下, 仍不能被GC正常回收的情况. 多数出现在不合理的编码情况下, 比如在Activity中注册了一个广播接收器, 但是在页面关闭的时候进行unRegister, 就会出现内存溢出的现象. 通常情况下, 大量的内存泄漏会造成OOM. OOM: 即OutOfMemoery, 顾名思义就是指内存溢出了. 内存溢出是指APP向系统申请超过最大阀值的内存请求, 系统不会再分配多余的空间, 就会造成OOM error. 在我们