android 内存泄漏分析与优化（二）
内存抖动、内存溢出、内存泄漏
- 内存抖动
在极短的时间内，分配大量的内存，然后又释放它，这种现象就会造成内存抖动。典型地，在 View 控件的 onDraw 方法里分配大量内存，又释放大量内存，这种做法极易引起内存抖动，从而导致性能下降。因为 onDraw 里的大量内存分配和释放会给系统堆空间造成压力，触发 GC 工作去释放更多可用内存，而 GC 工作起来时，又会吃掉宝贵的帧时间 (帧时间是 16ms) ，最终导致性能问题。GC工作是发生在主线程中的，因为频繁的触发GC导致掉帧就是内存抖动。 - 内存溢出
个Android应用程序都执行在自己的虚拟机中，每个虚拟机必定会有堆内存阈值限制（值得一提的是这个阈值一般都由厂商依据硬件配置及设备特性自己设定，没有统一标准，可以为64M，也可以为128M等；它的配置是在Android的属性系统的/system/build.prop中配置dalvik.vm.heapsize=128m即可，若存在dalvik.vm.heapstartsize则表示初始申请大小，也可以通过ActivityManager.getMemoryClass()获得这个值），也即一个应用进程同时存在的对象必须小于阈值规定的内存大小才可以正常运行，否则则会报oom（OutOfMemoryError）。产生的原因最直接的原因是一下子申请大量的内存超出阈值直接崩溃，还有原因是因为错误的程序导致内存泄漏，即使申请一小段内存也会直接崩溃。 - 内存泄漏
内存泄漏是本该由GC回收的内存因为某些原因得不到回收而导致的，通俗的讲是本应该被回收的对象被比它生命周期还有长的对象持有，导致不可回收，就产生了内存泄漏。
举个例子一（单例最常见的内存泄漏）：
public final class MainActivity extends Activity
{
private DbManager mDbManager;
@Override
protected void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
//DbManager是一个单例模式类，这样就持有了
//MainActivity引用，导致泄露
mDbManager = DbManager.getInstance(this);
}
}
分析：由于单例的静态特性使得它的生命周期比较长，又因为它持有activity，所以当activity退出时，此activity得不到GC回收从而导致了内存泄漏。
举例二：集合中
Vector v = new Vector(10);
for (int i = 1; i < 100; i++)
{
Object o = new Object();
v.add(o);
o = null;
}
分析：
在这个例子中，我们循环申请Object对象，并将所申请的对象放入一个 Vector 中，如果我们仅仅释放引用本身，那么 Vector 仍然引用该对象，所以这个对象对 GC 来说是不可回收的。因此，如果对象加入到Vector 后，还必须从 Vector 中删除，最简单的方法就是将 Vector 对象设置为 null。
Android中常见的内存泄漏汇总以及相应的解决办法
- 集合类
如果仅仅有添加元素的方法，而没有相应的删除机制，导致内存被占用。如果这个集合类是全局性的变量 (比如类中的静态属性，全局性的 map 等即有静态引用或 final 一直指向它)，那么没有相应的删除机制，很可能导致集合所占用的内存只增不减。比如上面的典型例子就是其中一种情况。 - 单例造成的内存泄漏
由于单例的静态特性使得其生命周期跟应用的生命周期一样长，所以如果使用不恰当的话，很容易造成内存泄漏。比如上面的典型例子就是其中一种情况。它的单例一般是这样
public class AppManager
{
private static AppManager instance;
private Context context;
private AppManager(Context context)
{
this.context = context;
}
public static AppManager getInstance(Context context)
{
if (instance == null)
{
instance = new AppManager(context);
}
return instance;
}
}
分析：这是一个普通的单例模式，当创建这个单例的时候，由于需要传入一个Context，所以这个Context的生命周期的长短至关重要，如果此时传入的是 Application 的 Context，因为Application 的生命周期就是整个应用的生命周期，所以这将没有任何问题。如果此时传入的是 Activity 的 Context，当这个 Context 所对应的 Activity 退出时，由于该 Context 的引用被单例对象所持有，其生命周期等于整个应用程序的生命周期，所以当前 Activity 退出时它的内存并不会被回收，这就造成泄漏了。
正确的方式应该改为下面这种方式：
public class AppManager
{
private static AppManager instance;
private Context context;
private AppManager(Context context)
{
this.context = context.getApplicationContext();
}
public static AppManager getInstance(Context context)
{
if (instance == null)
{
instance = new AppManager(context);
}
return instance;
}
}
- 匿名内部类/非静态内部类和异步线程
举个例子
public class MainActivity extends Activity
{
...
Runnable ref1 = new MyRunable();
Runnable ref2 = new Runnable()
{
@Override
public void run()
{
}
};
...
}
分析：匿名内部类是默认持有外部的引用，因此容易造成内存泄漏。
- Handler 使用不当造成的内存泄漏
Handler 的使用造成的内存泄漏问题应该说是最为常见了，很多时候我们为了避免 ANR 而不在主线程进行耗时操作，在处理网络任务或者封装一些请求回调等api都借助Handler来处理，但 Handler 不是万能的，对于 Handler 的使用代码编写一不规范即有可能造成内存泄漏。另外，我们知道 Handler、Message 和 MessageQueue 都是相互关联在一起的，万一 Handler 发送的 Message 尚未被处理，则该 Message 及发送它的 Handler 对象将被线程 MessageQueue 一直持有。 由于 Handler 属于 TLS(Thread Local Storage) 变量, 生命周期和 Activity 是不一致的。因此这种实现方式一般很难保证跟 View 或者 Activity 的生命周期保持一致，故很容易导致无法正确释放。
举个栗子：
public class SampleActivity extends Activity
{
private final Handler mLeakyHandler = new Handler()
{
@Override
public void handleMessage(Message msg)
{
// ...
}
}
@Override
protected void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState); // Post a message and delay its execution for 10 minutes.
mLeakyHandler.postDelayed(new Runnable()
{
@Override
public void run()
{
/* ... */
}
}, 1000 * 60 * 10); // Go back to the previous Activity.
finish();
}
}
分析：
在该 SampleActivity 中声明了一个延迟10分钟执行的消息 Message，mLeakyHandler 将其 push 进了消息队列 MessageQueue 里。当该 Activity 被 finish() 掉时，延迟执行任务的 Message 还会继续存在于主线程中，它持有该 Activity 的 Handler 引用，所以此时 finish() 掉的 Activity 就不会被回收了从而造成内存泄漏（因 Handler 为非静态内部类，它会持有外部类的引用，在这里就是指 SampleActivity）。
修复方法：
在 Activity 中避免使用非静态内部类，比如上面我们将 Handler 声明为静态的，则其存活期跟 Activity 的生命周期就无关了。同时通过弱引用的方式引入 Activity，避免直接将 Activity 作为 context 传进去，见下面代码：
public class SampleActivity extends Activity
{
/** * Instances of static inner classes do not hold an implicit * reference to their outer class. */
private static class MyHandler extends Handler
{
private final WeakReference<SampleActivity> mActivity;
public MyHandler(SampleActivity activity)
{
mActivity = new WeakReference<SampleActivity>(activity);
}
@Override
public void handleMessage(Message msg)
{
SampleActivity activity = mActivity.get();
if (activity != null)
{
// ...
}
}
}
private final MyHandler mHandler = new MyHandler(this);
/** * Instances of anonymous classes do not hold an implicit * reference to their outer class when they are "static". */
private static final Runnable sRunnable = new Runnable()
{
@Override
public void run()
{
/* ... */
}
};
@Override
protected void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState); // Post a message and delay its execution for 10 minutes.
mHandler.postDelayed(sRunnable, 1000 * 60 * 10); // Go back to the previous Activity.
finish();
}
}
综述，即推荐使用静态内部类 + WeakReference 这种方式。每次使用前注意判空。
资源未关闭造成的内存泄漏
对于使用了BraodcastReceiver，ContentObserver，File，游标 Cursor，Stream，Bitmap等资源的使用，应该在Activity销毁时及时关闭或者注销，否则这些资源将不会被回收，造成内存泄漏。一些不良代码造成的内存压力
比如：
1 、Bitmap 没调用 recycle()方法，对于 Bitmap 对象在不使用时,我们应该先调用 recycle() 释放内存，然后才它设置为 null. 因为加载 Bitmap 对象的内存空间，一部分是 java 的，一部分 C 的（因为 Bitmap 分配的底层是通过 JNI 调用的 )。 而这个 recyle() 就是针对 C 部分的内存释放。
2 、构造 Adapter 时，没有使用缓存的 convertView ,每次都在创建新的 converView。这里推荐使用 ViewHolder