Android中常见的那些内存泄漏——【问题分析+方案】

作者: 谁动了我的代码 | 来源:发表于2022-11-24 20:43 被阅读0次

1.静态Activity(Activity上下文Context)和View

静态变量Activity和View会导致内存泄漏，在下面代码中对Activity的Context和TextView设置为静态对象，从而产生内存泄漏；

public class MemoryTestActivity extends AppCompatActivity {
 
    private static Context context;
    private static TextView textView;
 
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_memory_test);
        context = this;
        textView = new TextView(this);
    }
}
12345678910111213

因为context和textView的实例的生命周和应用的生命一样，而他们持有当前Activity(MemoryTestActivity)的引用，一旦MemoryTestActivity销毁，而他的引用一直持有，就不会被回收，所以产生内存泄漏了；

1.1借助Android Profiler分析内存泄漏

测试页面关闭以后MemoryTestActivity实例是否全部销毁：

借助Android Profiler可以查看MemoryTestActivity实例有三个(Alloc Count实例数量为3)-不断打开关闭MemoryTestActivity页面，由于关闭MemoryTestActivity不会垃圾回收不会立即执行，为了测试点击强制垃圾回收，我们发现会有一个MemoryTestActivity(@318435616))没有被回收，因为context和textview一直持有MemoryTestActivity(@318435616))实例的引用；

点击Dump Java heap导出堆分配

点击Force Garbage Collection 强制垃圾回收

点击Dump Java heap 导出堆分配

2.单例造成的内存泄漏

Android的单例模式是开发中经常使用的模式，使用不恰当可能导致内存泄漏；单例的生命周期和应用的生命周期一样，也就是单例持有必须是和应用生命周期一样的对象，不能持有和应用生命周期不一致的对象例如：Activity(Context)上下文：

public class TestManager {
 
    private static TestManager manager;
    private Context context;
 
    private TestManager(Context context) {
        this.context = context;
    }
 
    /**
     * 如果传入的context是activity,service的上下文，会导致内存泄漏
     * 原因是我们的manger是一个static的静态对象，这个对象的生命周期和整个app的生命周期一样长
     * 当activity销毁的时候，我们的这个manger仍然持有者这个activity的context，就会导致activity对象无法被释放回收，就导致了内存泄漏
     */
    public static TestManager getInstance(Context context) {
        if (manager == null) {
            manager = new TestManager(context);
        }
        return manager;
    }
}
123456789101112131415161718192021

2.1借助Android Profiler分析内存泄漏

测试反复打开关闭MemoryTestActivity页面，最终停留在MemoryTestActivity页面是否只保留一个实例：

测试步骤：

a.打开MemoryTestActivity，然后关闭；

b.打开MemoryTestActivity，然后停留在MemoryTestActivity页面；

点击Force Garbage Collection 强制垃圾回收

点击Dump Java heap 导出堆分配

会发现第一次打开MemoryTestActivity时创建的实例没有销毁，由于TestManager单例持有MemoryTestActivity引用，TestManager单例生命周期和应用的生命周期一样，所以直到应用的生命周期结束时，TestManager单例持有MemoryTestActivity引用才会被销毁，下图是TestManager单例持有MemoryTestActivity引用；

2.2解决方法

修改TestManager单例模式使用的上下文Context，TestManager单例模式引用ApplicationContext，TestManager单例模式和应用生命周期一样，ApplicationContext和应用的生命周期是一样，这样不会出现内存泄漏；

public class TestManager {
 
    private static TestManager manager;
    private Context context;
 
    private TestManager(Context context) {
        this.context = context;
    }
    //正确写法
    public static TestManager getInstance(Context context) {
        if (manager == null) {
            manager = new TestManager(context.getApplicationContext());
        }
        return manager;
    }
 
}
1234567891011121314151617

3.线程造成的内存泄漏

匿名线程内部类会隐式引用Activity，当执行耗时任务时，一直隐式引用Activity，当Activity关闭时，由于匿名线程内部类会隐式引用Activity无法及时回收；

public class MemoryTestActivity extends AppCompatActivity {
 
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_memory_test);
 
        anonymousInnerClass();
    }
    
    //匿名内部类持有MemoryTestActivity实例引用
    public void anonymousInnerClass(){
        new Thread(){
            @Override
            public void run() {
                //执行异步处理
                SystemClock.sleep(120000);
            }
        }.start();
 
//        new AsyncTask<Void, Void, Void>(){
//            @Override
//            protected Void doInBackground(Void... voids) {
//                //执行异步处理
//                SystemClock.sleep(120000);
//                return null;
//            }
//        }.execute();
    }
}
123456789101112131415161718192021222324252627282930

3.1借助Android Profiler分析内存泄漏

测试MemoryTestActivity实例由于耗时匿名线程内部类引用导致Activity一直无法回收，看如下图Activity打开以后一直无法回收；

当耗时匿名线程内部类执行完成以后MemoryTestActivity实例才会回收；

3.2解决方法

修改Thread和AsyncTask匿名内部类为静态类，解除Activity隐式引用，MemoryTestActivity销毁时要及时取消异步任务staticAsyncTask.cancel(true)，防止异步任务执行完成更新销毁MemoryTestActivity实例的UI;

public class MemoryTestActivity extends AppCompatActivity {
 
    private StaticThread staticThread;
    private StaticAsyncTask staticAsyncTask;
    
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_memory_test);
 
//       staticThread = new StaticThread();
//       staticThread.start();
       
       staticAsyncTask = new StaticAsyncTask(this);
       staticAsyncTask.execute();
    }
 
    private static class StaticThread  extends Thread{
        @Override
        public void run() {
            //执行异步处理
            SystemClock.sleep(120000);
        }
    }
 
    private static class StaticAsyncTask extends AsyncTask<Void, Void, Void>{
        private WeakReference<Context> weakReference;
 
        public StaticAsyncTask(Context context){
            weakReference = new WeakReference<Context>(context);
        }
 
        @Override
        protected Void doInBackground(Void... voids) {
            //执行异步处理
            SystemClock.sleep(120000);
            return null;
        }
 
        @Override
        protected void onPostExecute(Void aVoid) {
            super.onPostExecute(aVoid);
 
            MemoryTestActivity activity = (MemoryTestActivity)weakReference.get();
            if(activity != null){
                //异步任务执行完成，执行UI处理
            }
        }
    }
 
    @Override
    protected void onDestroy() {
        super.onDestroy();
        staticAsyncTask.cancel(true);
    }
}
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556

借助Android Profiler可以查看返回打开关闭MemoryTestActivity页面，看MemoryTestActivity实例是否销毁：

可以参考匿名线程引用类的测试图对比一下，不存在MemoryTestActivity实例，MemoryTestActivity实例正常被销毁了，没有因为静态异步线程类执行耗时操作而导致MemoryTestActivity不销毁出现内存泄漏的问题；

4.非静态内部类创建静态实例造成的内存泄漏

有时候我们可能频繁启动Activity，为了避免重复创建相同的资源呢，会出现如下写法：

public class MemoryTestActivity extends AppCompatActivity {
 
 
    private static TestResource testResource;
 
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_memory_test);
 
        testResource = new TestResource();
    }
 
    class TestResource{
       //资源类
    }
 
}
123456789101112131415161718

这样就在Activity内部创建了一个非静态内部类的单例，每次启动Activity时都会使用该单例的数据，这样虽然避免重复创建，不过这种写法会造成内存泄漏，因为非静态内部类默认会持有外部类的引用，而又使用了该非静态内部类创建了一个静态实例，该实例的生命周期和应用一样长，这就导致了该静态实例一直持有该Activity的引用，导致Activity的内存资源不能正常回收；

4.1借助Android Profiler分析内存泄漏

测试打开关闭MemoryTestActivity页面，MemoryTestActivity实例是否正常销毁；

4.2解决方法

将该内部类设为静态内部类或将内部类抽象出来封装一个单例，如果需要使用Context，请使用ApplicationContext；

5.Handler造成的内存泄漏

Handler的使用造成的内存泄漏问题是比较常见的，平时处理网络任务或者封装一些请求回调等api都应该会借助Handler处理，对于Handler的使用代码不规范可能会造成内存泄漏，如下示例：

public class MemoryTestActivity extends AppCompatActivity {
 
 
    private Handler mHandler = new Handler(){
        @Override
        public void handleMessage(Message msg) {
            //处理UI显示
        }
    };
 
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_memory_test);
 
        loadData();
    }
 
    //loadData()方法在子线程中执行
    private void loadData() {
        //子线程执行网络请求request
        Message message = Message.obtain();
        //模拟线程延迟120秒发送Message
        mHandler.sendMessageDelayed(message, 120000);
//        mHandler.sendMessage(message);
    }
 
 
}
1234567891011121314151617181920212223242526272829

这种创建Handler的方式可能造成内存泄漏，由于mHandler是Handler的非静态匿名内部类的实例，所以它持有外部类Activity引用，我们知道消息队列是在一个Looper线程中不断轮询处理消息，那么当这个Activity退出时，消息队列还有未处理的消息或者正在处理的消息（例如上面的例子，子线程中处理耗时任务，还没有执行完毕，activity就退出销毁），而消息队列中Message持有mHandler实例引用，mHander又持有Activity的引用，所以导致Activity的内存无法及时回收，引发内存泄漏；

5.1借助Android Profiler分析内存泄漏

借助Android Profiler可以查看返回打开关闭MemoryTestActivity页面，看MemoryTestActivity实例是否销毁：

通过Android Profiler可以发现打开关闭MemoryTestActivity页面，发现MemoryTestActivity实例由于mHandler一直持有外部类Activity引用没有销毁；

5.2解决方法

public class MemoryTestActivity extends AppCompatActivity {
 
    private Handler handler = new StaticHandler(this);
 
    private static class StaticHandler extends Handler{
 
        WeakReference<Context> weakReference =  null;
 
        public StaticHandler(Context context){
            weakReference = new WeakReference<Context>(context);
        }
 
        @Override
        public void handleMessage(Message msg) {
            //处理UI显示
            MemoryTestActivity  activity =(MemoryTestActivity)weakReference.get();
            if(activity !=  null){
 
            }
        }
    }
 
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_memory_test);
 
        loadData();
    }
 
    //loadData()方法在子线程中执行
    private void loadData() {
        //子线程执行网络请求request
        Message message = Message.obtain();
        //模拟线程延迟120秒发送Message
        handler.sendMessageDelayed(message, 120000);
//        mHandler.sendMessage(message);
    }
 
    @Override
    protected void onDestroy() {
        super.onDestroy();
        handler.removeCallbacksAndMessages(null);
//        handler.removeCallbacks();
//        handler.removeMessages();
    }
}
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647

创建一个静态Handler内部类，然后对Handler持有的对象使用弱应用，这样在回收时也可以回收Handler持有的对象，这样避免了Activity泄漏，如果Handler被delay(延迟执行)，在Activity的Destroy或者Stop时应该移除消息队列中的消息；

handler.removeCallbacksAndMessages(null);移除消息队列中所有的消息和线程； handler.removeCallbacks();移除消息队列中指定的线程； handler.removeMessages();移除消息队列中指定的消息；

解决方案总结：

1.通过程序逻辑来进行维护

a.在关闭Activity的时候停掉后台线程；线程停掉相当于切断了Handler和外部连接线，Activity自然会被在合适的时候回收；

b.如果Handler被delay延迟的Message持有了引用，那么使用相应的Handler的removeCallbacks()方法，把消息对象从消息队列移除就行；

2.将Handler声明为静态类

a.在Java中，非静态的内部类和匿名内部类都会隐式持有其外部类的引用，静态内部类不会持有外部类的引用。静态类不持有外部类的对象，所以你的Activity可以随意被回收；由于Handler不在持有外部类的对象的引用，导致程序不允许你在Handler中操作Activity中的对象了，所以你需要在Handler中增加一个对Activity的弱引用(WeakReference);

6.动画

在属性动画中有一类无限循环动画，如果在Activity中播放这类动画并且在onDestroy()中没有去停止动画，那么动画会一直播放下去，这时候Activity会被View所持有，从而导致Activity无法被释放。解决此类问题要在onDestroy()方法中去调用objectAnimator.cancel()来停止动画；

public class MemoryTestActivity extends AppCompatActivity {
 
    private TextView textView;
    private ObjectAnimator objectAnimator;
 
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_memory_test);
 
        textView = (TextView)this.findViewById(R.id.textView2);
        objectAnimator = ObjectAnimator.ofFloat(textView, "rotation", 0, 360);
        objectAnimator.setRepeatCount(ValueAnimator.INFINITE);
        objectAnimator.start();
    }
 
    @Override
    protected void onDestroy() {
        super.onDestroy();
 
    }
}
12345678910111213141516171819202122

6.1借助Android Profiler分析内存泄漏

借助Android Profiler可以查看返回打开关闭MemoryTestActivity页面，看MemoryTestActivity实例是否销毁：

由于未在onDestroy()方法中去调用objectAnimator.cancel()来停止动画，执行动画的View一直引用Activity，导致Activity无法销毁；

6.2解决办法

在onDestroy()方法中去调用objectAnimator.cancel()来停止动画；

7.第三方库使用不当

对于EventBus，RxJava等一些第三方开源框架的使用，若是Activity销毁之前没有进行解除订阅会导致内存泄漏；

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

对于使用了BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等资源的使用，应该在Activity销毁时及时关闭或者注销，否则这些资源将不会被回收，造成内存泄漏。

9.Java内存监测工具

9.1Android Profiler

在Android Studio中View-Tool Windows-Android Profiler可以查看工具自带的内存分析工具；

9.2leakcanary

在app的build.gradle中添加如下代码，不需要其他处理；

dependencies {
    // debugImplementation because LeakCanary should only run in debug builds.
    debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.4'
}
1234

查看LogCat控制台，输出如下日志则说明leakcanary已经启动：

D LeakCanary: LeakCanary is running and ready to detect leaks

 11

添加好了依赖后，当有内存泄漏出现时，在通知栏会有提示，点击进入后，就会看到具体的报错点。leakcanary 的基本情况是，他在debug下，是会去检测你的应用内存泄漏情况，而在release版下，不会去检测的。

以上就是Android开发中比较常见的内存泄漏问题以及解决方法；如果想要更加深入学习Android的性能优化，或者Android技术进阶大家可以参考《Android核心技术手册》这个资料文件。里面记录了大部分的Android开发技术点，供你学习参考！

文末

1、Handler持有的引用最好使用弱引用，在Activity被释放的时候要记得清空Message，取消Handler对象的Runnable；

2、非静态内部类、非静态匿名内部类会自动持有外部类的引用，为避免内存泄露，可以考虑把内部类声明为静态的；

3、对于生命周期比Activity长的对象，要避免直接引用Activity的context，可以考虑使用ApplicationContext；

4、广播接收器、EventBus等的使用过程中，注册/反注册应该成对使用；

5、不再使用的资源对象Cursor、File、Bitmap等要记住正确关闭；

6、集合里面的东西、有加入就应该对应有相应的删除。

Android中常见的那些内存泄漏——【问题分析+方案】

1.静态Activity(Activity上下文Context)和View

1.1借助Android Profiler分析内存泄漏

2.单例造成的内存泄漏

2.1借助Android Profiler分析内存泄漏

2.2解决方法

3.线程造成的内存泄漏

3.1借助Android Profiler分析内存泄漏

3.2解决方法

4.非静态内部类创建静态实例造成的内存泄漏

4.1借助Android Profiler分析内存泄漏

4.2解决方法

5.Handler造成的内存泄漏

5.1借助Android Profiler分析内存泄漏

5.2解决方法

6.动画

6.1借助Android Profiler分析内存泄漏

6.2解决办法

7.第三方库使用不当

9.Java内存监测工具

9.1Android Profiler

9.2leakcanary

文末

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

Android开发

Android开发

Android技术知识

Android开发经验谈