Android内存泄漏终极解决篇(上)

一、概述
在Android的开发中,经常听到“内存泄漏”这个词。“内存泄漏”就是一个对象已经不需要再使用了,但是因为其它的对象持有该对象的引用,导致它的内存不能被回收。“内存泄漏”的慢慢积累,最终会导致OOM的发生,千里之堤,毁于蚁穴。所以在写代码的过程中,应该要注意规避会导致“内存泄漏”的代码写法,提高软件的健壮性。
本文将从发现问题、解决问题、总结问题的三个角度出发,循序渐进,彻底解决“内存泄漏”的问题。

二、内存泄漏的检查工具Heap

工欲善其事必先利其器,要检测“内存泄漏”的发生,需要借助DDMS中的Heap工具及MAT工具,Heap工具用于大致分析是否存在“内存泄漏”,而MAT工具则用于分析“内存泄漏”发生在哪里。

Heap工具的使用介绍

具体操作

  • 1.在Devices设备列表中,找到你所在的设备,点击你想要监控的进程。
  • 2.点击“Update Heap”按钮更新堆内存的情况。
  • 3.点击“Heap”视图,查看内存的情况。
  • 4.每次在Activity的退出和进入的时候点击“Cause GC”,手动调用GC释放应用的内存。
  • 5.观察data oject那一行,每一次点击“Casue GC”的时候,观察Total Size的值,如果该值不断增加,则说明该应用程序存在“内存泄漏”。

我们先模拟一下内存泄漏,然后通过Heap工具来判断一下是否存在内存泄漏。
上一段存在内存泄漏的代码:

public class LeakAty extends Activity {

 @Override
 protected void onCreate(Bundle savedInstanceState) {
  super.onCreate(savedInstanceState);
  setContentView(R.layout.aty_leak);
  testLeak();

 }

 /**
  * 测试内存泄漏的代码
  */
 private void testLeak() {
  new Thread(new Runnable() {

   @Override
   public void run() {
    while (true) {
     try {
      Thread.sleep(1000);
     } catch (InterruptedException e) {
      e.printStackTrace();
     }
    }
   }
  }).start();
 }

上述的代码存在内存泄漏,new Runnable(){}是一个非静态的匿名内部类,所以它会强引用创建它的外围对象LeakAty,我们来测试一下内存泄漏的过程,开启手机的方向旋转功能,不断地旋转手机,让LeakAty不断地创建新的实例。理论上如果不存在上述泄漏的代码,之前的Activity会在onDestory之后被回收内存。而一旦存在上述泄漏的代码,新创建的Ruannale实例会一直处于运行状态,它不会被回收,而它强引用的LeakAty当然也不会被回收,所以在屏幕不断旋转,之前创建的LeakAty就不会被释放,会导致旋转n次,内存中就存在n+1个的LeakAty实例。
Heap工具第一次按下Cause GC按钮的截图:

上图的data object的Total Size的大小为1.031M。经过多次的旋转屏幕之后,我们再看一下截图

Total Size变成了2.059M,从1.031M到2.059M,每次调用GC的过程中data object的总大小没有回落,所以可以证实上面的代码确实是存在内存泄漏的问题,那么泄漏发生在哪里?答案可以通过MAT工具来分析得到。

三、内存泄漏的分析工具MAT

要通过MAT分析,需要提供一个.hprof文件。我们可以通过”Dump HPROF file”按钮转存当前的堆内存信息。我们将其保存为1.hprof。

导出的1.hprof的格式需要通过..\sdk\tools\目录下的hprof-conv.exe工具进行转换才能被MAT成功导入,我们将其转换成out1.hprof

将out1.hprof导入到MAT工具中,File->Open Heap Dump…

点击左边的标签Overview,Actions->Histogram

在Histogram界面中,因为我们想要知道Activity是否泄漏了,所以输入关键词Activity,然后按下回车键。

之后便可以得到Activity的相关的搜索结果,下图的搜索结果中Activity的实例有7个。点击选中下图标红色框框的地方,右键->Merge Shortest Paths to GC Roots->exclude all phantom/weak/soft etc. references。排除虚引用、弱引用、软引用的实例,剩下的都是强引用实例。

从过滤出来的强引用的列表中,我们可以看到这七个实例都是被Thread所引用了。所以证实上面的代码确实存在内存泄漏。

四、本文总结

内存泄漏检测可以使用Heap工具,内存分析可以使用MAT工具。本文的案例中提到了一种内存泄漏的情况,就是非静态内部类的对象会强引用其外围对象,一旦这个非静态内部类的实例没有释放,它的外围对象也不会释放,所以就会造成内存泄漏。下篇将具体探讨一下,在Android的开发过程中,哪些写法容易造成内存泄漏,该如何解决?请阅读Android内存泄漏终极解决篇(下)。

以上就是本文的全部内容,希望大家喜欢。

(0)

相关推荐

  • Android 内存泄漏的几种可能总结

    Java是垃圾回收语言的一种,其优点是开发者无需特意管理内存分配,降低了应用由于局部故障(segmentation fault)导致崩溃,同时防止未释放的内存把堆栈(heap)挤爆的可能,所以写出来的代码更为安全. 不幸的是,在Java中仍存在很多容易导致内存泄漏的逻辑可能(logical leak).如果不小心,你的Android应用很容易浪费掉未释放的内存,最终导致内存用光的错误抛出(out-of-memory,OOM). 一般内存泄漏(traditional memory leak)的原因

  • Android开发:浅谈MVP模式应用与内存泄漏问题解决

    最近博主开始在项目中实践MVP模式,却意外发现内存泄漏比较严重,但却很少人谈到这个问题,促使了本文的发布,本文假设读者已了解MVP架构. MVP简介 M-Modle,数据,逻辑操作层,数据获取,数据持久化保存.比如网络操作,数据库操作 V-View,界面展示层,Android中的具体体现为Activity,Fragment P-Presenter,中介者,连接Modle,View层,同时持有modle引用和view接口引用 示例代码 Modle层操作 public class TestModle

  • 浅谈Android应用的内存优化及Handler的内存泄漏问题

    一.Android内存基础 物理内存与进程内存 物理内存即移动设备上的RAM,当启动一个Android程序时,会启动一个Dalvik VM进程,系统会给它分配固定的内存空间(16M,32M不定),这块内存空间会映射到RAM上某个区域.然后这个Android程序就会运行在这块空间上.Java里会将这块空间分成Stack栈内存和Heap堆内存.stack里存放对象的引用,heap里存放实际对象数据. 在程序运行中会创建对象,如果未合理管理内存,比如不及时回收无效空间就会造成内存泄露,严重的话可能导致

  • Android 有效的解决内存泄漏的问题实例详解

    Android 有效的解决内存泄漏的问题 Android内存泄漏,我想做Android 应用的时候遇到的话很是头疼,这里是我在网上找的不错的资料,实例详解这个问题的解决方案 前言:最近在研究Handler的知识,其中涉及到一个问题,如何避免Handler带来的内存溢出问题.在网上找了很多资料,有很多都是互相抄的,没有实际的作用. 本文的内存泄漏检测工具是:LeakCanary  github地址:https://github.com/square/leakcanary 什么是内存泄漏? 内存泄漏

  • 使用Android Studio检测内存泄露(LeakCanary)

    内存泄露,是Android开发者最头疼的事.可能一处小小的内存泄露,都可能是毁千里之堤的蚁穴. 怎么才能检测内存泄露呢? AndroidStudio 中Memory控件台(显示器)提供了一个内存监视器.我们可以通过它方便地查看应用程序的性能和内存使用情况,从而也就可以找到需要释放对象,查找内存泄漏等. 熟悉Memory界面 打开日志控制台,有一个标签Memory ,我们可以在这个界面分析当前程序使用的内存情况. 运行要监控的程序(APP)后,打开Android Monitor控制台窗口,可以看到

  • Android内存泄漏终极解决篇(下)

    一.概述 在 Android内存泄漏终极解决篇(上)中我们介绍了如何检查一个App是否存在内存泄漏的问题,本篇将总结典型的内存泄漏的代码,并给出对应的解决方案.内存泄漏的主要问题可以分为以下几种类型: 静态变量引起的内存泄漏 非静态内部类引起的内存泄漏 资源未关闭引起的内存泄漏 二.静态变量引起的内存泄漏 在java中静态变量的生命周期是在类加载时开始,类卸载时结束.换句话说,在android中其生命周期是在进程启动时开始,进程死亡时结束.所以在程序的运行期间,如果进程没有被杀死,静态变量就会一

  • Android内存泄漏排查利器LeakCanary

    本文为大家分享了Android内存泄漏排查利器,供大家参考,具体内容如下 开源地址:https://github.com/square/leakcanary 在 build.gralde 里加上依赖, 然后sync 一下, 添加内容如下 dependencies { .... debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5' releaseCompile 'com.squareup.leakcanary:leakcanar

  • Android性能优化之利用强大的LeakCanary检测内存泄漏及解决办法

    前言: 最近公司C轮融资成功了,移动团队准备扩大一下,需要招聘Android开发工程师,陆陆续续面试了几位Android应聘者,面试过程中聊到性能优化中如何避免内存泄漏问题时,很少有人全面的回答上来.所以决定抽空学习总结一下这方面的知识,以及分享一下我们是如何检测内存泄漏的.我们公司使用开源框架LeakCanary来检测内存泄漏. 什么是内存泄漏? 有些对象只有有限的生命周期.当它们的任务完成之后,它们将被垃圾回收.如果在对象的生命周期本该结束的时候,这个对象还被一系列的引用,这就会导致内存泄漏

  • Android内存泄漏终极解决篇(上)

    一.概述 在Android的开发中,经常听到"内存泄漏"这个词."内存泄漏"就是一个对象已经不需要再使用了,但是因为其它的对象持有该对象的引用,导致它的内存不能被回收."内存泄漏"的慢慢积累,最终会导致OOM的发生,千里之堤,毁于蚁穴.所以在写代码的过程中,应该要注意规避会导致"内存泄漏"的代码写法,提高软件的健壮性. 本文将从发现问题.解决问题.总结问题的三个角度出发,循序渐进,彻底解决"内存泄漏"的问题

  • Android内存泄漏的轻松解决方法

    前言 内存管理的目的就是让我们在开发过程中有效避免我们的应用程序出现内存泄露的问题.内存泄露相信大家都不陌生,我们可以这样理解:「没有用的对象无法回收的现象就是内存泄露」. 如果程序发生了内存泄露,则会带来以下这些问题 应用可用的内存减少,增加了堆内存的压力 降低了应用的性能,比如会触发更频繁的 GC 严重的时候可能会导致内存溢出错误,即 OOM Error 下面我们从基础说起 基础知识 Java 的内存分配简述 方法区(non-heap):编译时就分配好,在程序整个运行期间都存在.它主要存放静

  • Android内存泄漏的原因及解决技巧

    正确的生命周期管理如何防止Android内存泄漏 OutOfMemoryException是一个常见的令人沮丧的错误,也是导致应用程序意外关闭的主要原因之一. "如果应用程序昨天运行良好,为什么现在会发生这种情况?这个问题让Android的开发者和新手都感到困惑. 导致OutOfMemory异常的潜在原因有很多种,但其中最常见的是内存泄漏-应用程序中的内存分配从未释放.本文将解释如何通过有效的生命周期管理(开发过程中一个重要但经常被忽视的部分)来最小化这种风险. 为什么安卓系统会发生内存泄漏?

  • 基于Keras 循环训练模型跑数据时内存泄漏的解决方式

    在使用完模型之后,添加这两行代码即可清空之前model占用的内存: import tensorflow as tf from keras import backend as K K.clear_session() tf.reset_default_graph() 补充知识:keras 多个模型测试阶段速度越来越慢问题的解决方法 问题描述 在实际应用或比赛中,经常会用到交叉验证(10倍或5倍)来提高泛化能力,这样在预测时需要加载多个模型.常用的方法为 mods = [] from keras.ut

  • 详解Android内存泄漏检测与MAT使用

    内存泄漏基本概念 内存检测这部分,相关的知识有JVM虚拟机垃圾收集机制,类加载机制,内存模型等.编写没有内存泄漏的程序,对提高程序稳定性,提高用户体验具有重要的意义.因此,学习Java利用java编写程序的时候,要特别注意内存泄漏相关的问题.虽然JVM提供了自动垃圾回收机制,但是还是有很多情况会导致内存泄漏. 内存泄漏主要原因就是一个生命周期长的对象,持有了一个生命周期短的对象的引用.这样,会导致短的对象在该回收时候无法被回收.Android中比较典型的有:1.静态变量持有Activity的co

  • Android内存泄漏实战解析

    Java是垃圾回收语言的一种,其优点是开发者无需特意管理内存分配,降低了应用由于局部故障(segmentation fault)导致崩溃,同时防止未释放的内存把堆栈(heap)挤爆的可能,所以写出来的代码更为安全. 不幸的是,在Java中仍存在很多容易导致内存泄漏的逻辑可能(logical leak).如果不小心,你的Android应用很容易浪费掉未释放的内存,最终导致内存用光的错误抛出(out-of-memory,OOM). 1.一般内存泄漏(traditional memory leak)的

随机推荐