Android开发

Android studio分析内存泄漏

2016-07-14  本文已影响1102人  云华兄

在使用java语音之前总听人家说java是面向对象的,内存只需要要申请不用释放,当我开始做Android用上java后我才知道java的回收其实是这样的:

闲话不多说,我们来个栗子:

我直接从项目中抽取部分代码来说明,代码中涉及到三个Activity:LoadingActivity、MainActivity和SettingsActivity,三个Activity均包含一个大背景图。LoadingActivity加载资源后启动MainActivity并finish掉自己,MainActivity点击按钮后跳转到SettingsActivity。

三个Activity打开一遍,按回退键返回到桌面,然后执行两次GC(第一次释放Activity对象,第二次释放Activity对象引用的背景图)后在Android studio中Monitors的Memory占用情况:

剩下的约35M内存怎么GC都无法回收,重新启动app,在MainActivity中不打开SettingsActivity直接回退到桌面然后执行GC,看到内存占用是这样的:

可以看出内存占用不到20M了,证明SettingsActivity存在内存泄漏了。

在Activity中添加打印也可以看到SettingsActivity调用了onDestroy()但在GC时并没有被释放(finalize()方法没被调用)

插个题外话,这个app占用内存这么大是因为使用图片背景,有人推荐用imege-loader,我也尝试用了一下,使用默认设置内存占用是小了那么一点点(大概10m左右吧)不过我这项目占用主要就是三个大的背景图,况且在调用释放缓存后实际上内存也并没有立刻被回收,而且使用imege-loader就要在原本的布局上再嵌套一层放一个match_parent的ImageView我感觉这样并没有优化我app的性能(貌似更严重了,多绘制一层的样子),这些都是题外话,看官选择性跳过就行。

我们在打开SettingsActivity后返回到桌面,执行完GC后点击Dump Java Heap:

这里我们可以看出来SettingsActivity之所以没被释放是因为其内部类DbUpdateListener有实例化对象(非静态内部类对象会持有父类的引用,Reference Tree第二行)没有被回收。DbUpdateListener对象又被DatabaseUpdate的listener和SettingsActivity的dbUpdateListener引用,我们现在来看看代码(代码是从我项目中截取出关键部分):

public class SettingsActivity extends Activity{

        private DatabaseUpdate dbUpdate;

        private DbUpdateListener dbUpdateListener;

        @Override

        protected void onCreate(Bundle savedInstanceState) {

                dbUpdate=DatabaseUpdate.get();

                dbUpdateListener=newDbUpdateListener();

                dbUpdate.setListener(dbUpdateListener);

        }

        @Override

        protected void onDestroy() {

                super.onDestroy();

                //findViewById(R.id.activity_settings).setBackgroundResource(0);

                Log.d(TAG,"onDestroy "+this);

        }

        private class DbUpdateListener implements DatabaseUpdateListener {

                ...

        }

        @Override

        protected voidfinalize()throwsThrowable {

                super.finalize();

                Log.d(TAG,"finalize "+this);

        }

}

public class DatabaseUpdate {

        private static DatabaseUpdateinstance;

        privateDatabaseUpdateListenerlistener;

        public staticDatabaseUpdate get(){

                if(null==instance){

                        synchronized(DatabaseUpdate.class) {

                                if(null==instance)

                                        instance=new DatabaseUpdate();

                        }

                }

                return instance;

        }

}

从代码中可以看出在SettingsActivity的onCreate方法中实例化了一个内部类对象DbUpdateListener,将其注册给了DatabaseUpdate对象,而DatabaseUpdate是一个单例,从而造成了SettingsActivity无法被回收的问题。在onDestroy()中将DbUpdateListener注销掉后再试,内存可以正常被回收了,Heap中SettingsActivity也没有被引用了:

结尾再补个题外话,这个app内存泄漏问题主要就是大背景图的资源无法释放,如果要加一个保险机制的话就在onDestroy()中将背景设置为空(findViewById(R.id.activity_settings).setBackgroundResource(0)),这样即使Activity没被回收背景资源的回收也不会受影响。在程序中我尝试过移除资源的引用后调用System.gc()并不能触发GC(小米4 Android6.0),所以这个我感觉没必要手动调用。

为何要降低内存消耗?其一是用户使用会卡,其二就是系统优先杀掉占用内存大的。

上一篇下一篇

猜你喜欢

热点阅读