热门标签
热门文章
- 1初始&安装RabbitMQ
- 2c语言 printf_[每日C语言」printf()函数的修饰符和返回值
- 3【mqtt】client测试工具使用_mqttfx-1.7.1-windows-x64
- 4Python函数（三）：闭包、装饰器_下面定义了一个使用多个装饰器修饰的函数,具体如下: @wrap_three @wrap_two @w
- 5鸿蒙(HarmonyOS)应用开发——应用程序入口UIAbility(题目答案)_harmonyos3.0应用开发系列课答案
- 6虹科Workshop丨2月29日与南高齿开展风电齿轮箱技术交流会，共拓风电行业未来！
- 7简单实现视频直播_直播服务器地址
- 8美团最新！FastPillars：基于Pillar的最强3D检测落地方案
- 9堆排序（向下调整法，向上调整法详解）
- 10论文《Graph Neural Networks for Social Recommendation》阅读_graphrec
当前位置: article > 正文
android常见内存泄漏主要有以下几类：_集合类泄漏 android
作者：我家自动化 | 2024-03-15 11:12:40
赞
踩
集合类泄漏 android
一、Handler 引起的内存泄漏。
在Android开发中，我们经常会使用Handler来控制主线程UI程序的界面变化，使用非常简单方便，但是稍不注意，很容易引发内存泄漏。
我们知道，Handler、Message、MessageQueue是相互关联在一起的，Handler通过发送消息Message与主线程进行交互，如果Handler发送的消息Message尚未被处理，该Message及发送它的Handler对象将被MessageQueue一直持有，这样就可能会导致Handler无法被回收。
请看下面的代码：
SecondActivity代码中有一个延迟1秒执行的消息Message，当界面从SecondActivity跳转到ThirdActivity时，SecondActivity自动进入后台，此时如果系统资源紧张（或者打开设置里面的“不保留活动”选项），SecondActivity将会被finish。但问题来了，由于SecondActivity的Handler对象mHandler为非静态匿名内部类对象，它会自动持有外部类SecondActivity的引用，从而导致SecondActivity无法被回收，造成内存泄漏。解决办法：将Handler声明为静态内部类，就不会持有外部类SecondActivity的引用，其生命周期就和外部类无关，如果Handler里面需要context的话，可以通过弱引用方式引用外部类。参考代码如下：
通过上面的方法，创建一个静态Handler内部类，其持有的对象context使用弱引用，可以避免SecondActivity内存泄漏，但是Looper线程的消息队列中可能还有待处理的消息，所以在Activity的onDestroy方法中，还要记住移除消息队列中待处理的消息。参考代码如下：
Hander提供了如下方法移除消息队列中的消息。
二、单例模式引起的内存泄漏
由于单例的生命周期是和app的生命周期一致的，如果使用不当很容易引发内存泄漏。如下代码：
这是一个单例模式的标准写法，表面上看没有任何问题，但是细心的同学会发现，构建该单例的一个实例时需要传入一个Context，此时传入的Context就非常关键，如果此时传入的是Activity，由于Context会被创建的实例一直持有，当Activity进入后台或者开启设置里面的不保留活动时，Activity会被销毁，但是单例持有它的Context引用，Activity又没法销毁，导致了内存泄漏。
如果此时传入的Context是ApplicationContext，由于ApplicationContext的生命周期是和app一致的，不会导致内存泄漏。但是我们不能指望使用这个单例的用户始终传入期望的Context，因此需要对这个单例设计进行调整，可以在构造函数中对mContext赋值改为 this.mContext = context.getApplicationContext;当然，也可以直接不让用户传入context。
参考解决办法：
1、一般在我们开发的应用中，都会实现Application，在里面做一些全局性的事情。可以在该实现里面对外提供一个单例，通过此实例来获取ApplicationContext。代码如下：
2、重构Singleton，把构建单例时的context去掉，避免外面使用的人传入错误参数，代码如下：
三、非静态内部类创建静态实例引起的内存泄漏
请看下面的代码：
app的生命周期是一致的。在某些场景，如Activity需要频繁切换，需要不断加载大量图片的场合，是会出现上述代码的，每次Activity启动之后都会使用该单例，避免重复一些有压力的操作。但是这样会引起内存泄漏，因为非静态的内部类InnerClass会自动持有外部类SecondActivity2的引用，创建的静态实例mInner就会一直持有SecondActivity2的引用，导致SecondActivity2需要销毁的时候没法正常销毁。
怎么知道静态实例mInner持有SecondActivity2的引用呢？debug程序之后你会清晰的发现静态实例mInner确实持有外部类SecondActivity2的引用，见下图：
上述代码的正确做法是把内部类InnerClass修改为静态的就可以避免内存泄漏了，因为静态内部类InnerClass不在持有外部类SecondActivity2的引用了。见下图：
当然，也可以把InnerClass单独抽出来作为一个内，写成单例模式，完成同样的功能，同时也可以避免内存泄漏。
四、非静态匿名内部类引起的内存泄漏
在android开发中，相信大家都会不知不觉地用到大量匿名内部类，如接受广播、点击事件、Handler消息处理等等。但是要注意，如果匿名内部类被异步线程使用，可能会引起内存泄漏。请看如下代码：
上述代码中，mRunnable 是非静态匿名内部类，会自动持有外部类SecondActivity3的引用，但是mRunnable被异步线程Thread使用，这样就会导致SecondActivity3在销毁的时候没法正常销毁，从而引起内存泄漏。
正确的做法应该是把mRunnable设置为静态的，这样就不会自动持有外部类SecondActivity3的引用，也就不会引起内存泄漏了。
五、注册/反注册未成对使用引起的内存泄漏
在andorid开发中，我们经常会在Activity的onCreate中注册广播接受器、EventBus等，如果忘记成对的使用反注册，可能会引起内存泄漏。开发过程中应该养成良好的相关，在onCreate或onResume中注册，要记得相应的在onDestroy或onPause中反注册。
六、资源对象没有关闭引起的内存泄漏
在android中，资源性对象比如Cursor、File、Bitmap、视频等，系统都用了一些缓冲技术，在使用这些资源的时候，如果我们确保自己不再使用这些资源了，要及时关闭，否则可能引起内存泄漏。因为有些操作不仅仅只是涉及到Dalvik虚拟机，还涉及到底层C/C++等的内存管理，不能完全寄希望虚拟机帮我们完成内存管理。
在这些资源不使用的时候，记得调用相应的类似close（）、destroy（）、recycler（）、release（）等函数，这些函数往往会通过jni调用底层C/C++的相应函数，完成相关的内存释放。
七、集合对象没有及时清理引起的内存泄漏
我们通常会把一些对象装入到集合中，当不使用的时候一定要记得及时清理集合，让相关对象不再被引用。如果集合是static、不断的往里面添加东西、又忘记去清理，肯定会引起内存泄漏。
使用 LeakCanary 检测 Android 的内存泄漏
内存泄漏防不胜防，通过LeakCanary工具，我们能在开发测试阶段发现绝大多数的内存泄漏。这个工具是开源的，使用也非常方便，而且能够相对准确定位出是哪里出现内存泄漏。
下面以AndroidStudio为例介绍LeakCanary的使用：
1、在build.gradle中配置leakcanary的引用
compile 'com.squareup.leakcanary:leakcanary-android:1.4-beta2'
2、使用RefWatcher监测本该被回收的对象。
LeakCanary.install() 会返回一个预定义的 RefWatcher，同时也会启用一个 ActivityRefWatcher，用于自动监控调用 Activity.onDestroy() 之后泄露的 activity。
在自己的Application中添加如下代码：
只需要上述两个步骤之后，LeakCanary就会自动监测内存泄漏，如果有内存泄漏在手机上面会提示，通知栏也会有通知，点击进去之后可以看到具体内存泄露的地方。debug的话，在控制台也会有相关的log输出。
总结：
1、Handler持有的引用最好使用弱引用，在Activity被释放的时候要记得清空Message，取消Handler对象的Runnable；
2、非静态内部类、非静态匿名内部类会自动持有外部类的引用，为避免内存泄露，可以考虑把内部类声明为静态的；
3、对于生命周期比Activity长的对象，要避免直接引用Activity的context，可以考虑使用ApplicationContext；
4、广播接收器、EventBus等的使用过程中，注册/反注册应该成对使用；
5、不再使用的资源对象Cursor、File、Bitmap等要记住正确关闭；
6、集合里面的东西、有加入就应该对应有相应的删除。
在Android开发中，我们经常会使用Handler来控制主线程UI程序的界面变化，使用非常简单方便，但是稍不注意，很容易引发内存泄漏。
我们知道，Handler、Message、MessageQueue是相互关联在一起的，Handler通过发送消息Message与主线程进行交互，如果Handler发送的消息Message尚未被处理，该Message及发送它的Handler对象将被MessageQueue一直持有，这样就可能会导致Handler无法被回收。
请看下面的代码：
SecondActivity代码中有一个延迟1秒执行的消息Message，当界面从SecondActivity跳转到ThirdActivity时，SecondActivity自动进入后台，此时如果系统资源紧张（或者打开设置里面的“不保留活动”选项），SecondActivity将会被finish。但问题来了，由于SecondActivity的Handler对象mHandler为非静态匿名内部类对象，它会自动持有外部类SecondActivity的引用，从而导致SecondActivity无法被回收，造成内存泄漏。解决办法：将Handler声明为静态内部类，就不会持有外部类SecondActivity的引用，其生命周期就和外部类无关，如果Handler里面需要context的话，可以通过弱引用方式引用外部类。参考代码如下：
通过上面的方法，创建一个静态Handler内部类，其持有的对象context使用弱引用，可以避免SecondActivity内存泄漏，但是Looper线程的消息队列中可能还有待处理的消息，所以在Activity的onDestroy方法中，还要记住移除消息队列中待处理的消息。参考代码如下：
Hander提供了如下方法移除消息队列中的消息。
public final void removeCallbacks(Runnable r)；
public final void removeCallbacks(Runnable r, Objecttoken)；
public final void removeMessages(int what)；
public final void removeMessages(int what, Object object)；
public final void removeCallbacksAndMessages(Object token)
；
二、单例模式引起的内存泄漏
由于单例的生命周期是和app的生命周期一致的，如果使用不当很容易引发内存泄漏。如下代码：
这是一个单例模式的标准写法，表面上看没有任何问题，但是细心的同学会发现，构建该单例的一个实例时需要传入一个Context，此时传入的Context就非常关键，如果此时传入的是Activity，由于Context会被创建的实例一直持有，当Activity进入后台或者开启设置里面的不保留活动时，Activity会被销毁，但是单例持有它的Context引用，Activity又没法销毁，导致了内存泄漏。
如果此时传入的Context是ApplicationContext，由于ApplicationContext的生命周期是和app一致的，不会导致内存泄漏。但是我们不能指望使用这个单例的用户始终传入期望的Context，因此需要对这个单例设计进行调整，可以在构造函数中对mContext赋值改为 this.mContext = context.getApplicationContext;当然，也可以直接不让用户传入context。
参考解决办法：
1、一般在我们开发的应用中，都会实现Application，在里面做一些全局性的事情。可以在该实现里面对外提供一个单例，通过此实例来获取ApplicationContext。代码如下：
2、重构Singleton，把构建单例时的context去掉，避免外面使用的人传入错误参数，代码如下：
三、非静态内部类创建静态实例引起的内存泄漏
请看下面的代码：
app的生命周期是一致的。在某些场景，如Activity需要频繁切换，需要不断加载大量图片的场合，是会出现上述代码的，每次Activity启动之后都会使用该单例，避免重复一些有压力的操作。但是这样会引起内存泄漏，因为非静态的内部类InnerClass会自动持有外部类SecondActivity2的引用，创建的静态实例mInner就会一直持有SecondActivity2的引用，导致SecondActivity2需要销毁的时候没法正常销毁。
怎么知道静态实例mInner持有SecondActivity2的引用呢？debug程序之后你会清晰的发现静态实例mInner确实持有外部类SecondActivity2的引用，见下图：
上述代码的正确做法是把内部类InnerClass修改为静态的就可以避免内存泄漏了，因为静态内部类InnerClass不在持有外部类SecondActivity2的引用了。见下图：
当然，也可以把InnerClass单独抽出来作为一个内，写成单例模式，完成同样的功能，同时也可以避免内存泄漏。
四、非静态匿名内部类引起的内存泄漏
在android开发中，相信大家都会不知不觉地用到大量匿名内部类，如接受广播、点击事件、Handler消息处理等等。但是要注意，如果匿名内部类被异步线程使用，可能会引起内存泄漏。请看如下代码：
上述代码中，mRunnable 是非静态匿名内部类，会自动持有外部类SecondActivity3的引用，但是mRunnable被异步线程Thread使用，这样就会导致SecondActivity3在销毁的时候没法正常销毁，从而引起内存泄漏。
正确的做法应该是把mRunnable设置为静态的，这样就不会自动持有外部类SecondActivity3的引用，也就不会引起内存泄漏了。
五、注册/反注册未成对使用引起的内存泄漏
在andorid开发中，我们经常会在Activity的onCreate中注册广播接受器、EventBus等，如果忘记成对的使用反注册，可能会引起内存泄漏。开发过程中应该养成良好的相关，在onCreate或onResume中注册，要记得相应的在onDestroy或onPause中反注册。
六、资源对象没有关闭引起的内存泄漏
在android中，资源性对象比如Cursor、File、Bitmap、视频等，系统都用了一些缓冲技术，在使用这些资源的时候，如果我们确保自己不再使用这些资源了，要及时关闭，否则可能引起内存泄漏。因为有些操作不仅仅只是涉及到Dalvik虚拟机，还涉及到底层C/C++等的内存管理，不能完全寄希望虚拟机帮我们完成内存管理。
在这些资源不使用的时候，记得调用相应的类似close（）、destroy（）、recycler（）、release（）等函数，这些函数往往会通过jni调用底层C/C++的相应函数，完成相关的内存释放。
七、集合对象没有及时清理引起的内存泄漏
我们通常会把一些对象装入到集合中，当不使用的时候一定要记得及时清理集合，让相关对象不再被引用。如果集合是static、不断的往里面添加东西、又忘记去清理，肯定会引起内存泄漏。
使用 LeakCanary 检测 Android 的内存泄漏
内存泄漏防不胜防，通过LeakCanary工具，我们能在开发测试阶段发现绝大多数的内存泄漏。这个工具是开源的，使用也非常方便，而且能够相对准确定位出是哪里出现内存泄漏。
下面以AndroidStudio为例介绍LeakCanary的使用：
1、在build.gradle中配置leakcanary的引用
compile 'com.squareup.leakcanary:leakcanary-android:1.4-beta2'
2、使用RefWatcher监测本该被回收的对象。
LeakCanary.install() 会返回一个预定义的 RefWatcher，同时也会启用一个 ActivityRefWatcher，用于自动监控调用 Activity.onDestroy() 之后泄露的 activity。
在自己的Application中添加如下代码：
只需要上述两个步骤之后，LeakCanary就会自动监测内存泄漏，如果有内存泄漏在手机上面会提示，通知栏也会有通知，点击进去之后可以看到具体内存泄露的地方。debug的话，在控制台也会有相关的log输出。
总结：
1、Handler持有的引用最好使用弱引用，在Activity被释放的时候要记得清空Message，取消Handler对象的Runnable；
2、非静态内部类、非静态匿名内部类会自动持有外部类的引用，为避免内存泄露，可以考虑把内部类声明为静态的；
3、对于生命周期比Activity长的对象，要避免直接引用Activity的context，可以考虑使用ApplicationContext；
4、广播接收器、EventBus等的使用过程中，注册/反注册应该成对使用；
5、不再使用的资源对象Cursor、File、Bitmap等要记住正确关闭；
6、集合里面的东西、有加入就应该对应有相应的删除。
声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/我家自动化/article/detail/240229
推荐阅读
相关标签
