android释放acitity内存,Android 内存泄漏分析与解决方法

在分析Android内存泄漏之前，先了解一下JAVA的一些知识

1. JAVA中的对象的创建

使用new指令生成对象时，堆内存将会为此开辟一份空间存放该对象

垃圾回收器回收非存活的对象，并释放对应的内存空间

2.Java如何判定对象存活或死亡?

引用计数法

1给对象中添加一个引用计数，假如为count

2当引用这个对象时：count++

3当count==0时：对象处于，也就是说没有其它地方在引用这个对象了，对象就处于“死亡”状态，回收对象

可达性分析算法

举个例子：像找人一样，A认识B，B认识C，C认识D，那么A就要吧通过这样的关系认识D，如果能找到D，说明D对象是存活的，不能回收，如果通过所有的关系都找不到D，说明D是“死亡”的，回收D对象。

可达性分析算法的定义：通过一系列的称为 GC

Roots 的对象作为起点,从这些节点开始向下搜索,搜索把走过的路径称为引用链,当一个对象到 GC Roots 没有任何引用链相连(就是从GC Roots 到这个对象不可达)时,则证明此对象是不可用的。如下图，Object5,Object6,Object7就是不可达对象，是要被回收的对象

问：哪些对象可以作为GC Roots对象呢？

1虚拟机栈中引用的对象

2方法区中类静态属性引用的对象

3方法区中常量引用的对象

4本地方法栈中JNI引用的对象

3.引用分类

强引用：只要强引用还存在，垃圾回收器永远不回收强引用的对象.如下Object obj = new Object() //强引用

软引用：在内存溢出异常之前，回收对象String str=new String("123"); // 强引用

SoftReference softRef=new SoftReference(str); // 软引用

弱引用 : 在下一次 GC 时,无论当前内存是否足够,都会回收被引用的对象String str=new String("abc");

WeakReference abcWeakRef = new WeakReference(str);

str=null;

虚引用：虚引用 : 没用，形同虚设，唯一的用处是在对象回收时,会收到一个系统通知

注：JAVA中这4种引用的级别由高到低依次为： 强引用 > 软引用 > 弱引用 > 虚引用

** 4.JAVA中内存分配 **

静态储存区：编译时就分配好，在程序整个运行期间都存在。它主要存放静态数据和常量

栈区：当方法执行时，会在栈区内存中创建方法体内部的局部变量，方法结束后自动释放内存

堆区：通常存放 new 出来的对象。由 Java 垃圾回收器回收。

上面的是JAVA的一些预备知识，下面分析Android内存泄漏相关

** 1 内存泄漏与内存溢出**

内存泄漏：Memory Leak , 无用的对象应该被回收的没有被回收

内存溢出：常说的OOM，没有足够的内存供分配了

** 2 Android内存泄漏分类 **

长期持有(Activity)Context导致的

(1) 单例类持有Activity引用

(2) 长生命周期引用短生命周期

由非静态内部类或者匿名内部类导致的

(1) Handler泄漏

资源使用完忘记释放

(1) Cursor，InputStream/OutputStream 忘记调用close

使用某些系统服务不当

(1) 在6.0系统，获取ConnectivityManager服务，如果第一次使用的是Activity对应的Context去获取这个服务，就会导致内存泄漏

延迟的任务也可能导致内存泄漏

(1) Handler 的消息未处理完，这时如果Handler是在Activity内存类实现的，消息引用Handler，Handler又引用了Activity，这时如果关闭Activity，就会造成内存泄漏

忘记注销监听器或者观察者

(1) 比如 EventBus.unregister() 忘记调用

注：非静态内部类和匿名内部类都会潜在的引用它们所属的外部类，但是静态内部类却不会

** 3 Android内存泄漏分析工具 **

MAT

LeakCanary

Strictmode

Android Memory Monitors

推荐使用LeakCanary，•LeakCanary是一个检测Java和Android内存泄漏的库，集成LeakCanary之后，只需要等待内存泄漏出现就可以了无需认为进行主动检测

** 4 LeakCanary的添加 **

第一步：在build.gradle中添加依赖

compile 'com.squareup.leakcanary:leakcanary-android:1.5.1'

第二步：在Application的onCreate()方法中添加 LeakCanary.install(this);

完成以上两步，就添加了LeakCanary，接下来就正常开发测试就行了，如果有内存泄漏，就会在通知栏中会有相应的通知，点开看就可以了，找到对应的内存泄漏的地方，解决

下面是演示的内存泄漏的几张图，可以看一下：

5 Android内存泄漏的案例

案例一：单例造成的内存泄漏

典型比如context的使用不当造成内存泄漏public class ToastUtils {

private static String oldMsg;

protected static Toast toast = null;

private static long oneTime = 0;

private static long twoTime = 0;

private static long gapTime = 3 * 1000;//3s只显示一次

public static void show(Context context, String s) {

if (context != null && !TextUtils.isEmpty(s)) {

if (toast == null) {

toast = Toast.makeText(context, s, Toast.LENGTH_SHORT);

toast.show();

oneTime = System.currentTimeMillis();

} else {

twoTime = System.currentTimeMillis();

if (s.equals(oldMsg)) {

if (twoTime - oneTime > gapTime) {

toast.show();

}

} else {

oldMsg = s;

toast.setText(s);

toast.show();

}

}

oneTime = twoTime;

}

}

}

在Activity 中使用：

ToastUtils.show(this, "登录成功");

上面的代码就会出现内存泄漏，因为在activity中使用ToastUtils.show(this, "登录成功")的时候，传的第一个参数 this 代表当时的activity，而ToashTuils中的toast变量是一个静态变量，

代码如下

protected static Toast toast = null;

创建toast对象如下代码

toast = Toast.makeText(context, s, Toast.LENGTH_SHORT);

Toast.makeText的第一参数就是上面传的activity，Toast类中有一个变量mContext会保存这个activity，就是强引用，但是toast又是一个静态的变量，静态变量的生命同期是和当前的APP的进程一样长的，所以这时我们如果关闭这个Activity，就会导致Activity被静态变量强引用，垃圾回收永远不会回收这个Activity，所以就会出现内存泄漏。

我们看一下Toast.makeText的源码

上面图中，new一个Toast，把context传给了Toast的构造方法。

所以调用 ToastUtils.show(this, "登录成功");就会导致 activity 被静态的toast变量强引用了，导致内存泄漏。

解决方法

用ApplicationContext替代Activity，如下代码

public static void show(Context context, String s) {

//在这里获取applicationContext,applicationContext的生命周期是和进程一样长

//这样就不会出现内存泄漏了

context = context.getApplicationContext();

if (context != null && !TextUtils.isEmpty(s)) {

if (toast == null) {

toast = Toast.makeText(context, s, Toast.LENGTH_SHORT);

toast.show();

......

}

}

案例二 内部类或者匿名内部类造成的内存泄漏

比如在Activity中使用Handler不当造成的内存泄漏

如下图

上图：在MainActivity中有一个匿名内部类Handler，并且有一个此类的对象 uiHandler。

这时我们如果在MainAcitity 中调用下面代码，就会出现内存泄漏

uiHandle.sendMessageDelayed(uiHandle.obtainMessage(),60 * 1000);

uiHandler.obtainMessage获取的msg 中有一个成员变量 target，target保存的就是uiHandle，而uiHandler又是内部类创建的对象，所以uiHandler隐式的会对当前的外部类，也就是MainActivity会有一个强引用，如下

msg -> uiHandler -> MainActivity

msg 引用了uiHandler，uiHandler引用了MainActivity，然后这个msg需要60s后才被处理完，在处理过程中，如果退出MainActivity，这时候就会导致内存泄漏，MainActivity回收不了。应该被回收的对象没有被回收掉，就是内存泄漏。

注：handler机制不明白的可以先看下handler机制，message,handler,loop的关系

解决方法

可以在MainActivity的onDestroy()方法调用下面代码：uiHandle.removeCallbacksAndMessages(null);

Handler不要用内部类，用静态的内部类，因为静态的内部类不会引用外部类，需要外部类的地方，用弱引用，代码如下：

使用弱引用的时候，需要作一下判断是否为null。

案例三：Activity context的不正确使用

上面的两个案例中其实也是context的使用场景不当造成的内存泄漏，这里不再举例，我们通常使用的两种context是 Acitivty和 Application,只需要注意对context的使用不要超过它的生命同期。部分情况下可以使用applicationContext代替activity的context,因为applicatoinContext会随着应用程序的存在而存在，而不依赖于activity的生命周期。还有要慎重对context使用static关键字。

案例四：一些资源使用完后没有关闭

如数据库的游标 Cursor，输入输出流 InputStream/OutputStream没有close

案例五：注册的监听器没有反注册

如EventBus.register,ButterKnife等没有在activity的onDestroy中反注册或者其它地方反注册

案例六：系统服务的泄漏

在实际项目中发现的，在6.0系统上在activity中第一次如果用的是activity对应的context获取ConnectivityManager服务会造成内存泄漏。

代码对下：/**

* 判断是否有网络连接

* @param context

* @return

*/

public static boolean isNetworkConnected(Context context) {

if (context != null) {

ConnectivityManager cm = (ConnectivityManager)

context.getSystemService(Context.CONNECTIVITY_SERVICE);

NetworkInfo mNetworkInfo = cm.getActiveNetworkInfo();

if (mNetworkInfo != null) {

return mNetworkInfo.isAvailable();

}

}

return false;

}

如果是第一次在activity中调用如下代码，会发现内存泄漏

注：是第一次在activity中调用，如果第一次是在application中调用不会出现内存泄漏，原因请参考下面这篇文章： http://www.jianshu.com/p/7d4b55f7ed9f//注意，这个this 是代表的是当前的activity

isNetworkConnected(this)

简单介绍下：先从Context的getSystemService方法开始，我们知道Activity是从ContextWrapper继承而来的，ContextWrapper中持有一个mBase实例，这个实例指向一个ContextImpl对象，同时ContextImpl对象持有一个OuterContext对象，对于Activity来说，这个OuterContext就是Activity对象。所以调用getSystemService最终会调用到ContextImpl的getSystemService方法。

在6.0上，在6.0上，ConnectivityManager实现为单例,创建这个单例对象的时候，把相应的OuterContext就是Activity对象，保存到了ConnectivityManager中，就造成了一个单例对象强引用了activity对象，从而造成了内存泄漏，如果是第一次用的是application，则保存的不是activity而是application，反而不会出现内存泄漏了。

使用LeakCanary检测 ConnectivityManager 内存泄漏图如下：

解决方法

使用applicationContext去获取服务，不要使用activityContext去获取服务

上面的就是对Android内存泄漏的一些总结，如果有不正确的或者需要补充的地方，请指出，一块学习进步

来源：https://www.cnblogs.com/start1225/p/6903419.html