Android：APP内存泄漏分析心得
本文部分内容转载自QQ空间终端开发团队公众号。
前言
对于C++来说，内存泄漏就是new出来的对象没有delete；
对于Java来说，就是new出来的Object 放在Heap上无法被GC回收。
Java中的内存分配
- 静态存储区：编译时就分配好，在程序整个运行期间都存在，主要存放静态数据和常量
- 堆区：通常存放new出来的对象，由Java回收器回收
- 栈区：当方法执行时，会在栈区内存中创建方法体内部的局部变量，方法结束后自动释放
四种引用类型的介绍
- 强引用(StrongReference)：JVM宁可抛出OOM也不会让GC回收具有强引用的对象，一般new出来的对象都是强引用
- 软引用(SoftReference)：只有在内存空间不足时才会被回收的对象
- 弱引用(WeakReference)：在GC时一旦发现了只具有弱引用的对象，不管当前内存空间是否足够，都会回收弱引用对象
- 虚引用(PhantomReference)：任何时候都可以被GC回收，当垃圾回收器准备回收一个对象时如果发现它还有虚引用，就会在回收对象的内存前把这个虚引用加入到与之关联的引用队列中
到底什么是内存泄漏
内存泄漏指因为疏忽或者错误造成程序未能即时释放已经不再使用的内存。内存泄漏发生时的主要表现为内存抖动，可用内存慢慢变少。
常见的内存泄漏案例
case 1：单例造成的内存泄漏
example 泄漏代码片段
private static ScrollHelper mInstance;
private ScrollHelper() {
}
public static ScrollHelper getInstance() {
if (mInstance == null) {
synchronized (ScrollHelper.class) {
if (mInstance == null) {
mInstance = new ScrollHelper();
}
}
}
return mInstance;
}
/**
* 被点击的view
*/
private View mScrolledView = null;
public void setScrolledView(View scrolledView) {
mScrolledView = scrolledView;
}
复制代码Solution：使用WeakReference
private static ScrollHelper mInstance;
private ScrollHelper() {
}
public static ScrollHelper getInstance() {
if (mInstance == null) {
synchronized (ScrollHelper.class) {
if (mInstance == null) {
mInstance = new ScrollHelper();
}
}
}
return mInstance;
}
/**
* 被点击的view
*/
private WeakReference<View> mScrolledViewWeakRef = null;
public void setScrolledView(View scrolledView) {
mScrolledViewWeakRef = new WeakReference<View>(scrolledView);
}
复制代码case 2. InnerClass匿名内部类
Java中非静态内部类会潜在引用它所属的外部类，如果在非静态内部类里面做了一些耗时操作，就可能造成外围对象不会被回收，从而导致内存泄漏。
example：
public class LeakAct extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.aty_leak);
test();
}
//这儿发生泄漏
public void test() {
new Thread(new Runnable() {
@Override
public void run() {
while (true) {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}).start();
}
}复制代码Solution：
public class LeakAct extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.aty_leak);
test();
}
//加上static，变成静态匿名内部类
public static void test() {
new Thread(new Runnable() {
@Override
public void run() {
while (true) {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}).start();
}
}复制代码
case 3. Activity Context 的不正确使用
在Android应用程序中通常可以使用两种Context对象：Activity和Application。当类或方法需要Context对象的时候常见的做法是使用第一个作为Context参数。这样就意味着View对象对整个Activity保持引用，因此也就保持对Activty的所有的引用。
假设一个场景，当应用程序有个比较大的Bitmap类型的图片，每次旋转是都重新加载图片所用的时间较多。为了提高屏幕旋转是Activity的创建速度，最简单的方法时将这个Bitmap对象使用Static修饰。 当一个Drawable绑定在View上，实际上这个View对象就会成为这份Drawable的一个Callback成员变量。而静态变量的生命周期要长于Activity。导致了当旋转屏幕时，Activity无法被回收，而造成内存泄露。
解决方案
- 使用ApplicationContext代替ActivityContext，因为ApplicationContext会随着应用程序的存在而存在，而不依赖于activity的生命周期；
- 对Context的引用不要超过它本身的生命周期，慎重的对Context使用“static”关键字。Context里如果有线程，一定要在onDestroy()里及时停掉。
example：
private static Drawable sBackground;
@Override
protected void onCreate(Bundle state) {
super.onCreate(state);
TextView label = new TextView(this);
label.setText("Leaks are bad");
if (sBackground == null) {
sBackground = getDrawable(R.drawable.large_bitmap);
}
label.setBackgroundDrawable(sBackground);
setContentView(label);
}
复制代码Solution：
private static Drawable sBackground;
@Override
protected void onCreate(Bundle state) {
super.onCreate(state);
TextView label = new TextView(this);
label.setText("Leaks are bad");
if (sBackground == null) {
sBackground = getApplicationContext().getDrawable(R.drawable.large_bitmap);
}
label.setBackgroundDrawable(sBackground);
setContentView(label);
}
复制代码case 4. Handler引起的内存泄漏
当Handler中有延迟的的任务或是等待执行的任务队列过长，由于消息持有对Handler的引用，而Handler又持有对其外部类的潜在引用，这条引用关系会一直保持到消息得到处理，而导致了Activity无法被垃圾回收器回收，而导致了内存泄露。
解决方案：
- 可以把Handler类放在单独的类文件中，或者使用静态内部类便可以避免泄露
- 如果想在Handler内部去调用所在的Activity，那么可以在handler内部使用弱引用的方式使用Static + WeakReference的方式来达到断开Handler与Activity之间存在引用关系。
Solution：
@Override
protected void doOnDestroy() {
super.doOnDestroy();
if (mHandler != null) {
mHandler.removeCallbacksAndMessages(null);
}
mHandler = null;
mRenderCallback = null;
}复制代码case 5. Cursor，Stream没有close，View没有recyle
资源性对象比如(Cursor，File文件等)往往都用了一些缓冲，我们在不使用的时候，应该及时关闭它们，以便它们的缓冲及时回收内存。它们的缓冲不仅存在于 java虚拟机内，还存在于java虚拟机外。如果我们仅仅是把它的引用设置为null,而不关闭它们，往往会造成内存泄漏。因为有些资源性对象，比如SQLiteCursor(在析构函数finalize(),如果我们没有关闭它，它自己会调close()关闭)，如果我们没有关闭它，系统在回收它时也会关闭它，但是这样的效率太低了。因此对于资源性对象在不使用的时候，应该调用它的close()函数，将其关闭掉，然后才置为null. 在我们的程序退出时一定要确保我们的资源性对象已经关闭。
Solution：
调用onRecycled()
@Override
public void onRecycled() {
reset();
mSinglePicArea.onRecycled();
}
复制代码在View中调用reset()
public void reset() {
if (mHasRecyled) {
return;
}
...
SubAreaShell.recycle(mActionBtnShell);
mActionBtnShell = null;
...
mIsDoingAvatartRedPocketAnim = false;
if (mAvatarArea != null) {
mAvatarArea.reset();
}
if (mNickNameArea != null) {
mNickNameArea.reset();
}
}复制代码case 6 集合中对象没清理造成的内存泄漏
我们通常把一些对象的引用加入到了集合容器（比如ArrayList）中，当我们不需要该对象时，并没有把它的引用从集合中清理掉，这样这个集合就会越来越大。如果这个集合是static的话，那情况就更严重了。
所以要在退出程序之前，将集合里的东西clear，然后置为null，再退出程序。
解决方案：
在Activity退出之前，将集合里的东西clear，然后置为null，再退出程序。
Solution
private List<EmotionPanelInfo> data;
public void onDestory() {
if (data != null) {
data.clear();
data = null;
}
}
复制代码case 7. WebView造成的泄露
当我们不要使用WebView对象时，应该调用它的destory()函数来销毁它，并释放其占用的内存，否则其占用的内存长期也不能被回收，从而造成内存泄露。
解决方案：
为webView开启另外一个进程，通过AIDL与主线程进行通信，WebView所在的进程可以根据业务的需要选择合适的时机进行销毁，从而达到内存的完整释放。
case 8. 构造Adapter时，没有使用缓存的ConvertView
初始时ListView会从Adapter中根据当前的屏幕布局实例化一定数量的View对象，同时ListView会将这些View对象 缓存起来。
当向上滚动ListView时，原先位于最上面的List Item的View对象会被回收，然后被用来构造新出现的最下面的List Item。
这个构造过程就是由getView()方法完成的，getView()的第二个形参View ConvertView就是被缓存起来的List Item的View对象(初始化时缓存中没有View对象则ConvertView是null)。
