Android优化三：内存泄漏

Android优化一：提纲
Android优化二：性能检测
Android优化三：内存优化
Android优化四：App启动速度优化
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异常。