Android内存优化11 内存泄漏常见情况2 内部类泄漏

线程持久化

Java中的Thread有一个特点就是她们都是直接被GC Root所引用，也就是说Dalvik虚拟机对所有被激活状态的线程都是持有强引用，导致GC永远都无法回收掉这些线程对象，除非线程被手动停止并置为null或者用户直接kill进程操作。所以当使用线程时，一定要考虑在Activity退出时，及时将线程也停止并释放掉

内存泄漏1：`AsyncTask`

void startAsyncTask() {

    new AsyncTask<Void, Void, Void>() {

        @Override protected Void doInBackground(Void... params) {

            while(true);

        }

    }.execute();

}

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_main);

View aicButton = findViewById(R.id.at_button);

aicButton.setOnClickListener(new View.OnClickListener() {

    @Override public void onClick(View v) {

        startAsyncTask();

        nextActivity();

    }

});

使用LeakCanary检测到的内存泄漏：

为什么？
上面代码在activity中创建了一个匿名类AsyncTask，匿名类和非静态内部类相同，会持有外部类对象，这里也就是activity，因此如果你在Activity里声明且实例化一个匿名的AsyncTask对象，则可能会发生内存泄漏，如果这个线程在Activity销毁后还一直在后台执行，那这个线程会继续持有这个Activity的引用从而不会被GC回收，直到线程执行完成。

怎么解决？
自定义静态AsyncTask类，并且让AsyncTask的周期和Activity周期保持一致，也就是在Activity生命周期结束时要将AsyncTask cancel掉。

内存泄漏2：Handler

非静态内部类导致的内存泄露在Android开发中有一种典型的场景就是使用Handler，很多开发者在使用Handler是这样写的：

public class MainActivity extends AppCompatActivity {

    @Override

    protected void onCreate(Bundle savedInstanceState) {

        super.onCreate(savedInstanceState);

        setContentView(R.layout.activity_main);

        start();

    }

    private void start() {

        Message msg = Message.obtain();

        msg.what = 1;

        mHandler.sendMessageDelayed(msg,1000);

    }

    private Handler mHandler = new Handler() {

        @Override

        public void handleMessage(Message msg) {

            if (msg.what == 1) {

                // 做相应逻辑

            }

        }

    };

}

也许有人会说，mHandler并未作为静态变量持有Activity引用，生命周期可能不会比Activity长，应该不一定会导致内存泄露呢，显然不是这样的！

熟悉Handler消息机制的都知道，mHandler会作为成员变量保存在发送的消息msg中，即msg持有mHandler的引用，而mHandler是Activity的非静态内部类实例，即mHandler持有Activity的引用，那么我们就可以理解为msg间接持有Activity的引用。msg被发送后先放到消息队列MessageQueue中，然后等待Looper的轮询处理（MessageQueue和Looper都是与线程相关联的，MessageQueue是Looper引用的成员变量，而Looper是保存在ThreadLocal中的）。那么当Activity退出后，msg可能仍然存在于消息对列MessageQueue中未处理或者正在处理，那么这样就会导致Activity无法被回收，以致发生Activity的内存泄露。

通常在Android开发中如果要使用内部类，但又要规避内存泄露，一般都会采用静态内部类+弱引用的方式。

public class MainActivity extends AppCompatActivity {

    private Handler mHandler;

    @Override

    protected void onCreate(Bundle savedInstanceState) {

        super.onCreate(savedInstanceState);

        setContentView(R.layout.activity_main);

        mHandler = new MyHandler(this);

        start();

    }

    private void start() {

        Message msg = Message.obtain();

        msg.what = 1;

        mHandler.sendMessage(msg);

    }

    private static class MyHandler extends Handler {

        private WeakReference<MainActivity> activityWeakReference;

        public MyHandler(MainActivity activity) {

            activityWeakReference = new WeakReference<>(activity);

        }

        @Override

        public void handleMessage(Message msg) {

            MainActivity activity = activityWeakReference.get();

            if (activity != null) {

                if (msg.what == 1) {

                    // 做相应逻辑

                }

            }

        }

    }

}

mHandler通过弱引用的方式持有Activity，当GC执行垃圾回收时，遇到Activity就会回收并释放所占据的内存单元。这样就不会发生内存泄露了。

上面的做法确实避免了Activity导致的内存泄露，发送的msg不再已经没有持有Activity的引用了，但是msg还是有可能存在消息队列MessageQueue中，所以更好的是在Activity销毁时就将mHandler的回调和发送的消息给移除掉。

@Override

protected void onDestroy() {

    super.onDestroy();

    mHandler.removeCallbacksAndMessages(null);

}

为什么？

创建的Handler对象为匿名类，匿名类默认持有外部类activity， Handler通过发送Message与主线程交互，Message发出之后是存储在MessageQueue中的，有些Message也不是马上就被处理的。这时activity被handler持有
handler被message持有，message被messagequeue持有，message queue被loop持有，主线程的loop是全局存在的，这时就造成activity被临时性持久化，造成临时性内存泄漏

怎么解决？
可以由上面的结论看出，产生泄漏的根源在于匿名类持有Activity的引用，因此可以自定义Handler和Runnable类并声明成静态的内部类，来解除和Activity的引用。或者在activity 结束时，将发送的Message移除

内存泄漏3：Thread

代码如下：
MainActivity.java

void spawnThread() {

    new Thread() {

        @Override public void run() {

            while(true);

        }

    }.start();

}

View tButton = findViewById(R.id.t_button);

tButton.setOnClickListener(new View.OnClickListener() {

  @Override public void onClick(View v) {

      spawnThread();

      nextActivity();

  }

});

为什么？
Java中的Thread有一个特点就是她们都是直接被GC Root所引用，也就是说Dalvik虚拟机对所有被激活状态的线程都是持有强引用，导致GC永远都无法回收掉这些线程对象，除非线程被手动停止并置为null或者用户直接kill进程操作。看到这相信你应该也是心中有答案了吧 : 我在每一个MainActivity中都创建了一个线程，此线程会持有MainActivity的引用，即使退出Activity当前线程因为是直接被GC Root引用所以不会被回收掉，导致MainActivity也无法被GC回收

怎么解决？
当使用线程时，一定要考虑在Activity退出时，及时将线程也停止并释放掉

内存泄漏4：Timer Tasks

Timer和TimerTask在Android中通常会被用来做一些计时或循环任务，比如实现无限轮播的ViewPager：

public class MainActivity extends AppCompatActivity {

    private ViewPager mViewPager;

    private PagerAdapter mAdapter;

    private Timer mTimer;

    private TimerTask mTimerTask;

    @Override

    protected void onCreate(Bundle savedInstanceState) {

        super.onCreate(savedInstanceState);

        setContentView(R.layout.activity_main);

        init();

        mTimer.schedule(mTimerTask, 3000, 3000);

    }

    private void init() {

        mViewPager = (ViewPager) findViewById(R.id.view_pager);

        mAdapter = new ViewPagerAdapter();

        mViewPager.setAdapter(mAdapter);

        mTimer = new Timer();

        mTimerTask = new TimerTask() {

            @Override

            public void run() {

                MainActivity.this.runOnUiThread(new Runnable() {

                    @Override

                    public void run() {

                        loopViewpager();

                    }

                });

            }

        };

    }

    private void loopViewpager() {

        if (mAdapter.getCount() > 0) {

            int curPos = mViewPager.getCurrentItem();

            curPos = (++curPos) % mAdapter.getCount();

            mViewPager.setCurrentItem(curPos);

        }

    }

    private void stopLoopViewPager() {

        if (mTimer != null) {

            mTimer.cancel();

            mTimer.purge();

            mTimer = null;

        }

        if (mTimerTask != null) {

            mTimerTask.cancel();

            mTimerTask = null;

        }

    }

    @Override

    protected void onDestroy() {

        super.onDestroy();

        stopLoopViewPager();

    }

}

当我们Activity销毁的时，有可能Timer还在继续等待执行TimerTask，它持有Activity的引用不能被回收，因此当我们Activity销毁的时候要立即cancel掉Timer和TimerTask，以避免发生内存泄漏。

为什么？
这里内存泄漏在于Timer和TimerTask没有进行Cancel，从而导致Timer和TimerTask一直引用外部类Activity。

怎么解决？
在适当的时机进行Cancel。

内存泄漏5：属性动画造成内存泄露

动画同样是一个耗时任务，比如在Activity中启动了属性动画（ObjectAnimator），但是在销毁的时候，没有调用cancle方法，虽然我们看不到动画了，但是这个动画依然会不断地播放下去，动画引用所在的控件，所在的控件引用Activity，这就造成Activity无法正常释放。因此同样要在Activity销毁的时候cancel掉属性动画，避免发生内存泄漏。

@Override

protected void onDestroy() {

    super.onDestroy();

    mAnimator.cancel();

}

巴特西

Android内存优化11 内存泄漏常见情况2 内部类泄漏

内存泄漏1：`AsyncTask`

内存泄漏2：Handler

内存泄漏3：Thread

内存泄漏4：Timer Tasks

内存泄漏5：属性动画造成内存泄露

最新文章

热门文章

巴特西

Android内存优化11 内存泄漏常见情况2 内部类泄漏

内存泄漏1：AsyncTask

内存泄漏2：Handler

内存泄漏3：Thread

内存泄漏4：Timer Tasks

内存泄漏5：属性动画造成内存泄露

最新文章

热门文章

内存泄漏1：`AsyncTask`