[摘]Android性能优化篇之内存优化--内存泄漏

SHUI知道

这篇文章对Android性能优化篇之内存优化--内存泄漏总结得很到位，基本上涵盖了。感谢感谢。

什么是内存泄漏

当一个对象已经不需要在使用了，本应该被回收，而另一个正在使用的对象持有它的引用，导致对象不能被回收。因为不能被及时回收的本该被回收的内存，就产生了内存泄漏。如果内存泄漏太多会导致程序没有办法申请内存，最后出现内存溢出的错误。

android中导致内存泄漏的主要几个点

android开发中经常出现的点，我有只有了解了，才能更好的避免。

1. 使用单例模式
2. 使用匿名内部类
3. 使用异步事件处理机制Handler
4. 使用静态变量
5. 资源未关闭
6. 设置监听未取消
7. 使用AsyncTask
8. 使用Bitmap

上面就是我列出的几个常出现内存泄漏的几个点，下面我们将一一解读。

java虚拟机内存管理

java虚拟机内存分为虚拟机栈，本地方法栈，程序计数器，堆，方法区这几个模块，下面我们就来分析下各个模块。

一、虚拟机栈

• 虚拟机栈主要的作用就是为执行java方法服务的，是Java方法执行的动态内存模型。
• 会导致栈内存溢出(StackOverFlowError)

二、本地方法栈

为执行native方法服务的，其他和虚拟机栈一样

三、程序计数器

• 是当前线程执行的字节码行号指示器
• 处于线程独占区
• 如果是执行的是java代码,当前值为字节码指令的地址，如果是Native，值为undefined

四、堆

• 存放对象的实例
• 垃圾收集器管理的主要区域
• 分代管理对象
• 会导致内存溢出(OutOfMemoryError)

五、方法区

• 存放虚拟机加载的类信息，常量，静态变量，编译后的代码和数据
• GC主要对方法区进行常量回收和类卸载
• 会出现内存溢出(OutOfMemoryError)

java内存几种分配策略？

可以结合上面的内存分配模型，能很好的理解。

一、.静态的

静态存储区：内存在程序编译期间就已经分配完成，一般来说，这个区域在程序运行期间一直处在

它主要储存静态数据，全局静态数据和常量

二、.栈式的

执行方法时，存储局部变量(编译期间，已经确定占用内存大小)，操作数，动态链接，方法出口

三、.堆式的

也叫动态内存分配，主要存储对象实例，以及已经被加载类的Class对象(用于反射)

垃圾收集器是如何判断对象是否可回收？

我们知道内存泄漏的原因是应该被回收的对象，不能被及时回收，那么GC是如何来判断对象是否为垃圾对象呢？

判断的方式有两个：

• 引用计数 对象被引用，引用计数器加1，反之减一，只有引用计数为0,那么这个对象为垃圾对象
• 可达性 从GCRoot节点对象开始，看是否可以访问到此对象，如果没有访问到则为垃圾对象

可以作为GCRoot对象有以下几种：

1. 虚拟机栈中的局部变量
2. 本地方法栈中的引用对象
3. 方法区中的常量引用对象
4. 方法区中的类属性引用对象

在native层和早期的虚拟机一般使用引用计数，但是现在的java虚拟机大多使用的是可达性。

什么是内存抖动？

堆内存都有一定的大小，能容纳的数据是有限制的，当Java堆的大小太大时，垃圾收集会启动停止堆中不再应用的对象，来释放内存。当在极短时间内分配给对象和回收对象的过程就是内存抖动。

内存抖动产生的原因？

从术语上来讲就是极短时间内分配给对象和回收对象的过程。 一般多是在循环语句中创建临时对象，在绘制时配置大量对象或者执行动画时创建大量临时对象。

内存抖动会带来UI的卡顿，因为大量的对象创建，会很快消耗剩余内存，导致GC回收，GC会占用大量的帧绘制时间，从而导致UI卡顿，关于UI卡顿会在后面章节讲到。

android中4种引用

1. StrongReference强引用

从不被回收，java虚拟机停止时，才终止

2. SoftReference软引用

当内存不足时，会主动回收，使用SoftReference使用结合ReferenceQueue构造有效期短

3. WeakReference弱引用

每次垃圾回收时，被回收

4. PhatomReference虚引用

每次垃圾回收时，被回收.结合ReferenceQueue来跟踪对象被垃圾回收器回收的活动。

常见的导致内存泄漏的示例

一、使用单例模式

private static ComonUtil mInstance = null;
    private Context mContext = null;

    public ComonUtil(Context context) {
        mContext = context;
    }

    public static ComonUtil getInstance(Context context) {
        if (mInstance == null) {
            mInstance = new ComonUtil(context);
        }
        return mInstance;
    }

ComonUtil mComonUtil = ComonUtil.getInstance(this);

我们看到上面的代码就是我们平时使用的单例模式，当然这里没有考虑线程安全，请忽略。

当我们传递进来的是Context，那么当前对象就会持有第一次实例化的Context，如果Context是Activity对象，那么就会产生内存泄漏。

因为当前对象ComonUtil是静态的，生命周期和应用是一样的，只有应用退出才会释放，导致Activity不能及时释放，带来内存泄漏。

怎么解决呢？

常见的有两种方式，

第一就是传入ApplicationContext，

第二CommonUtil中取context.getApplicationContext()。

使用非静态内部类

/**
     * 非静态内部类
     */
    public void createNonStaticInnerClass(){
        CustomThread mCustomThread = new CustomThread();
        mCustomThread.start();
    }

    public class CustomThread extends Thread{
        @Override
        public void run() {
            super.run();
            while (true){
                try {
                    Thread.sleep(5000);
                    Log.i(TAG,"CustomThread ------- 打印");
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }
    }

我们就以线程为例，当Activity调用了createNonStaticInnerClass方法，然后退出当前Activity时，因为线程还在后台执行且当前线程持有Activity引用，只有等到线程执行完毕，Activitiy才能得到释放，导致内存泄漏。

常用的解决方法有很多，

第一把线程类声明为静态的类，如果要用到Activity对象，那么就作为参数传入且为WeakReference,

第二在Activity的onDestroy时，停止线程的执行。

  public static class CustomThread extends Thread{
        private WeakReference<MainActivity> mActivity;
        public CustomThread(MainActivity activity){
            mActivity = new WeakReference<MainActivity>(activity)
        }
    }

使用异步事件处理机制Handler

    /**
     * 异步消息处理机制  -- handler机制
     */
    public void createHandler(){
        mHandler.sendEmptyMessage(0);
    }
    public Handler mHandler = new Handler(new Handler.Callback() {
        @Override
        public boolean handleMessage(Message msg) {
            //处理耗时操作
            return false;
        }
    });

这个应该是我们平时使用最多的一种方式，如果当handler中处理的是耗时操作，或者当前消息队列中消息很多时，那当Activity退出时，当前message中持有handler的引用，handler又持有Activity的引用，导致Activity不能及时的释放，引起内存泄漏的问题。 解决handler引起的内存泄漏问题常用的两种方式：

1. 和上面解决Thread的方式一样，
2. 在onDestroy中调用mHandler.removeCallbacksAndMessages(null)

 @Override
    protected void onDestroy() {
        super.onDestroy();
        mHandler.removeCallbacksAndMessages(null);
    }

使用静态变量

同单例引起的内存泄漏。

资源未关闭

常见的就是数据库游标没有关闭，对象文件流没有关闭

主要记得关闭就OK了。

设置监听

常见的是在观察者模式中出现，我们在退出Acviity时没有取消监听，导致被观察者还持有当前Activity的引用，从而引起内存泄漏。

常见的解决方法就是在onPause或者onDestory中注消监听

使用AsyncTask

    public AsyncTask<Object, Object, Object> mTask = new AsyncTask<Object, Object, Object>() {

        @Override
        protected Object doInBackground(Object... params) {
            //耗时操作
            return null;
        }

        @Override
        protected void onPostExecute(Object o) {

        }
    };

和上面同样的道理，匿名内部类持有外部类的引用，AsyncTask耗时操作导致Activity不能及时释放，引起内存泄漏。 解决方法同上:

1. 声明为静态类，
2. 在onPause中取消任务

使用Bitmap

我们知道当bitmap对象没有被使用(引用)，gc会回收bitmap的占用内存，当时这边的内存指的是java层的，那么本地内存的释放呢？我们可以通过调用bitmap.recycle()来释放C层上的内存，防止本地内存泄漏。

摘抄

1. 《Android性能优化篇之内存优化--内存泄漏》