Anfroid性能优化之内存泄露篇

首先看看内存泄露与内存溢出的概念：

1、内存泄漏：

当出现对Activity、View或drawable等类的对象长期持有无用的引用，就会造成被引用的对象无法在GC时回收，而是长期占用堆空间，此时就会发生内存泄漏。

简单来说，就是保留下来却永远不再使用的对象引用。

2、内存溢出：

如果应用程序在消耗光了所有的可用堆空间(16M到48M），那么再试图在堆上分配新对象时就会引起OOM(Out Of Memory Error)异常，此时应用程序就会崩溃退出。

3、两者的区别：

简单的说，就是内存溢出是占用内存太大，超过了其可以承受的范围；

内存泄漏是回收不及时甚至是没有被回收，而在推空间中产生的许多无用的引用。

于是过多的内存泄漏就会导致内存溢出，从而迫使程序崩溃退出。

下面重点来谈谈android中有关内存泄露的问题。

虽然Java有专门的GC来回收不再使用的对象，但是我们不能完全依靠GC来彻底回收对象，在编码的过程中如不遵守一定的规则就会造成内存泄露。主要有以下三种：

1，静态变量持有对象，特别是生命周期比整个应用短的对象

2，非静态内部类隐式持有外部类对象，特别是内部类生命周期比外部类长

3，资源打开未关闭，如文件，数据库等

一， 静态变量持有对象，特别是生命周期比整个应用短的对象

泄漏 activity 最简单的方法就是在 activity 类中定义一个 static 变量，并且将其指向一个运行中的 activity 实例。如果在 activity 的生命周期结束之前，没有清除这个引用，那它就会泄漏了。这是因为activity（例如 MainActivity） 的类对象是静态的，一旦加载，就会在 APP 运行时一直常驻内存，因此如果类对象不卸载，其静态成员就不会被垃圾回收。

二非静态内部类隐式持有外部类对象，特别是内部类生命周期比外部类长。

1 handler内存泄露

最常见的就是在actvity中使用handler。创建非静态内部的时候，该内部类默认会持有外部类的引用，如果外部类的生命周期比较短，那么内部类就不会释放外部类对象的引用，这就造成了内存泄露。

public class HandlerActivity extends Activity{
private final Handler mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
// ...
}
};

@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mHandler.sendMessageDelayed(Message.obtain(), 1000);
finish();
}

原因分析：

1. Handler
的生命周期与Activity
不一致。当Android应用启动的时候，会先创建一个UI主线程的Looper对象，Looper实现了一个简单的消息队列，一个一个的处理里面的Message对象。主线程Looper对象在整个应用生命周期中存在。

2. handler
引用 Activity
阻止了GC对Acivity的回收。

当Activity finish后，meaasge会继续存在UI线程的messagequeue中，。而该消息引用了Activity的Handler对象，然后这个Handler又引用了这个Activity。这些引用对象会保持到该消息被处理完，这样就导致该Activity对象无法被回收，从而导致了上面说的Activity泄露。

publicboolean sendMessageAtTime(Message msg, long uptimeMillis) {
MessageQueue queue = mQueue;
if (queue == null) {
RuntimeException e = newRuntimeException(
this + "sendMessageAtTime() called with no mQueue");
Log.w("Looper",e.getMessage(), e);
return false;
}
return enqueueMessage(queue, msg,uptimeMillis);
}

修改方法：

· 使用显形的引用，1.静态内部类。 2.
外部类
· 使用弱引用 2.WeakReference

static class ExerciseHandler extends Handler{
private SoftReference<ExerciseActivity> exerciseActivitySoftReference = null;

public ExerciseHandler(ExerciseActivity exerciseActivity){
exerciseActivitySoftReference = new SoftReference<ExerciseActivity>(exerciseActivity);
}

@Override
public void handleMessage(Message msg) {
ExerciseActivity exerciseActivity = exerciseActivitySoftReference.get();
if(null != exerciseActivity){
super.handleMessage(msg);
switch (msg.what) {
case MSG_XX:
exerciseActivity.***;
break；
default:
break;
}
}
} public void onDestroy() {
mHandler.removeMessages(MESSAGE_1);
mHandler.removeMessages(MESSAGE_2);
mHandler.removeMessages(MESSAGE_3);

// ... ...

mHandler.removeCallbacks(mRunnable);

// ... ...
}

三．资源打开未关闭，如文件，数据库等

IO操作后，没有关闭文件导致的内存泄露，比如Cursor、FileInputStream、FileOutputStream使用完后没有关闭，这种问题在Android Studio 2.0中能够通过静态代码分析检查出来，直接改善就可以了；

自定义View中使用TypedArray后，没有recycle，这种问题也可以在Android Studio 2.0中能够通过静态代码分析检查出来，直接改善就可以了

四 Context
内存泄露
某些地方使用了四大组件的context，在离开这些组件后仍然持有其context导致的内存泄露，这种问题属于共识，在编写代码的过程中就应该按照规则来，使用Application的Context就可以解决这类内存泄露的问题了。
常见的解决办法：
通过工具检查程序运行后的内存泄露
通过上面的步骤，应用中的大部分内存泄露问题都能够得到解决，还有一些内存泄露，需要运行程序，分析运行后的内存快照来解决，比如注册之后没有反注册、类中的静态成员变量导致的内存泄露、SDK中的内存泄露等。解决这类问题可以分两步进行：

通过内存泄露检测工具先定位是哪有问题，内存泄露的检测有两种比较便捷的方式：1、一种是使用开源项目Leakcanary，需要添加到代码中，运行后生成分析结果；2、另一种方式是使用adb shell dumpsys meminfo packagename -d命令，在进入一个界面之前查看一遍Activity和View的数量，在退出这个界面之后再查看一遍Activity和View的数量，对比进入前和进入后Activity和View数量的变化情况，如果有差异，则说明存在内存泄露（在使用命令查看Activity和View的数量之前，记得手动触发GC）。