android内存优化郭霖,Android优化三：内存泄漏

什么是内存泄漏？

根据 Java 内存回收机制的“可达性分析法”，如果这些对象是可达的，但是这些对象是无用的，就会导致内存泄漏，内存泄漏的积累最终导致内存溢出。

分类

Android中内存溢出主要分为四类：

①集合类泄漏

②单例/静态变量造成的内存泄漏

③匿名内部类/非静态内部类

④资源未关闭造成的内存泄漏

Q：单例为什么会导致内存泄漏？

其实单例本身跟内存泄漏是没什么关系的，只有在单例使用不恰单才会导致内存泄漏。

单例导致内存泄漏主要的原因是：单例的静态特性使得单例的生命周期跟整个应用的生命周期一样长。

如果我们在单例中传入的 Context 是 Activity 的 context，当这个 Context 所对应的 Activity 退出时，由于该 Context 的引用被单例对象所持有，其生命周期等于整个应用程序的生命周期，所以当前 Activity 退出时它的内存并不会被回收，这就造成泄漏了。

同理被 static 修饰的成员变量也是如此，其生命周期将与整个app进程生命周期一样。

Q：handler 和非静态内部类为什么会导致内存泄漏？

非静态内部类默认会持有外部类的引用，handler 的生命周期与 Activity 的生命周期不一致，

如果 Activity 销毁了但是 Handler 里面有未处理完的延时消息，导致 Activity 不能被 GC 回收。

OOM异常

可以通过getMemoryClass( )来获取App的可用堆内存，如果申请的内存超过这个值，就会造成OOM异常。

可以在AndroidManifest.xml文件中可以设置 android:largeHeap="true"活的更大的堆内存。

具体细节

1、Bitmap图片过大

解决办法：

BitmapFactory.Options options = new BitmapFactory.Options();

options.inSampleSize = 2;

图片宽高都为原来的二分之一，即图片为原来的四分之一。

bitmap.get().recycle();

在用完Bitmap时，要及时的recycle掉。recycle并不能确定立即就会将Bitmap释放掉，但是会给虚拟机一个暗示：“该图片可以释放了”。

软引用(SoftRefrence)

我们使用Bitmap后没有保留对它的引用，因此就无法调用Recycle函数。这时候巧妙的运用软引用，可以使Bitmap在内存快不足时得到有效的释放 。

但是是现在已经不再推荐使用这种方式了，因为从 Android 2.3 (API Level 9)开始，垃圾回收器会更倾向于回收持有软引用或弱引用的对象，这让软引用和弱引用变得不再可靠。另外，Android 3.0 (API Level 11)中，图片的数据会存储在本地的内存当中，因而无法用一种可预见的方式将其释放，这就有潜在的风险造成应用程序的内存溢出并崩溃。

From 郭霖的博客

建议使用成熟的Glide、Picasso、Fresco框架来加载图片。

2、界面切换

看页面布局有没有大的图片，比如背景图之类的。

直接把XML配置成view再放到一个容器里面，避免重复加载。

在页面切换时尽可能少地重复使用一些代码。

3、资源未关闭

BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等资源的使用没有注销导致。

在Activity销毁时及时关闭或者注销。

4、ListView没有使用缓存

使用的convertView进行缓存

建议使用5.0出来的RecycleView替代Listview。

5、Handler导致

应该申明为静态对象， 并在其内部类中保存一个对外部类的弱引用。

在Activity销毁时及时关闭或者注销

@Override

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_main);

//handler导致内存泄漏;

//当Activity销毁时，匿名内部类一直持有Activity的引用，无法释放。

Handler handler = new Handler();

handler.postDelayed(new Runnable() {

@Override

public void run() {

//执行逻辑

}

}, 10000L);

}

6、 线程导致

线程产生内存泄露的主要原因在于线程生命周期的不可控。

将线程的内部类，改为静态内部类。

采用线程池, 避免程序中存在大量的Thread。

7、尽量使用9path图片

.9图片可以任意调整大小，进行拉伸。

8、使用单例造成

当调用getInstance时，如果传入的context是Activity的context。只要这个单例没有被释放，那么这个Activity也不会被释放一直到进程退出才会释放。

使用Application的Context。

9、非静态内部类创建静态实例

将非静态内部类修改为静态内部类。(静态内部类不会隐式持有外部类)

Context尽量使用Application Context，因为Application的Context的生命周期比较长。

10、使用了静态的Activity和View

private static View sView;

应该及时将静态的应用 置为null，而且一般不建议将View及Activity设置为静态。

11、属性动画导致的内存泄漏

属性动画有一类无限循环的动画, 如果在Activity中播放此类动画且没有在Activity退出的时候没有停止动画. 尽管无法界面上看到效果, 但是创建这个动画所关联的View被动画所持有, 而View又持有了Activity, 最终Activity无法释放.

解决方案是在onDestroy()中调用动画的cancel()来停止动画.

12、帧动画导致

帧动画使用的图片过大过多导致

终极大招：LeakCanary

LeakCanary 是一个开源的在debug版本中检测内存泄漏的java库。

LeakCanary 中文使用说明

平时写代码稍微注意点，再用这个检测基本能搞定所有oom异常。