搜索

Android 内存泄漏总结

程序员Android

共 7267字，需浏览 15分钟

 · 2021-08-01

和你一起终身学习，这里是程序员Android

经典好文推荐，通过阅读本文，您将收获以下知识点:

一、内存泄漏介绍
二、常见内存泄漏场景
1.单例导致内存泄露
2.静态变量导致内存泄漏
3.非静态内部类导致内存泄露
4.未取消注册或回调导致内存泄露
5.Timer和TimerTask导致内存泄露
6.集合中的对象未清理造成内存泄露
7.资源未关闭或释放导致内存泄露
8.属性动画造成内存泄露
9.WebView造成内存泄露
三、总结

一、内存泄漏介绍

不少人认为JAVA程序，因为有垃圾回收机制，应该没有内存泄露。我们已经知道了，如果某个对象，从根节点可到达，也就是存在从根节点到该对象的引用链，那么该对象是不会被 GC 回收的。如果说这个对象已经不会再被使用到了，是无用的，我们依然持有他的引用的话，就会造成内存泄漏，例如 一个长期在后台运行的线程持有 Activity 的引用，这个时 候 Activity 执行了 onDestroy 方法，那么这个 Activity 就是从根节点可到达并且无用的对象， 这个 Activity 对象就是泄漏的对象，给这个对象分配的内存将无法被回收。如果我们的java运行很久,而这种内存泄露不断的发生，最后就没内存可用了。当然java的，内存泄漏和C/C++是不一样的。如果java程序完全结束后，它所有的对象就都不可达了，系统就可以对他们进行垃圾回收，它的内存泄露仅仅限于它本身，而不会影响整个系统的。C/C++的内存泄露就比较糟糕了，它的内存泄露是系统级，即使该C/C++程序退出，它的泄露的内存也无法被系统回收，永远不可用了，除非重启机器。

Android的一个应用程序的内存泄露对别的应用程序影响不大。为了能够使得Android应用程序安全且快速的运行，Android的每个应用程序都会使用一个专有的Dalvik虚拟机实例来运行，它是由Zygote服务进程孵化出来的，也就是说每个应用程序都是在属于自己的进程中运行的。Android为不同类型的进程分配了不同的内存使用上限，如果程序在运行过程中出现了内存泄漏的而造成应用进程使用的内存超过了这个上限，则会被系统视为内存泄漏，从而被kill掉，这使得仅仅自己的进程被kill掉，而不会影响其他进程（如果是system_process等系统进程出问题的话，则会引起系统重启）。

二、常见内存泄漏场景

1.单例导致内存泄露

单例模式在Android开发中会经常用到，但是如果使用不当就会导致内存泄露。因为单例的静态特性使得它的生命周期同应用的生命周期一样长，如果一个对象已经没有用处了，但是单例还持有它的引用，那么在整个应用程序的生命周期它都不能正常被回收，从而导致内存泄露。

public class AppSettings {

    private static volatile AppSettings singleton;
    private Context mContext;
    private AppSettings(Context context) {
        this.mContext = context;
    }

    public static AppSettings getInstance(Context context) {
        if (singleton == null) {
            synchronized (AppSettings.class) {
                if (singleton == null) {
                    singleton = new AppSettings(context);
                }
            }
        }
        return singleton;
    }
}

像上面代码中这样的单例，如果我们在调用getInstance(Context context)方法的时候传入的context参数是Activity、Service等上下文，就会导致内存泄露。以Activity为例，当我们启动一个Activity，并调用getInstance(Context context)方法去获取AppSettings的单例，传入Activity.this作为context，这样AppSettings类的单例sInstance就持有了Activity的引用，当我们退出Activity时，该Activity就没有用了，但是因为sIntance作为静态单例（在应用程序的整个生命周期中存在）会继续持有这个Activity的引用，导致这个Activity对象无法被回收释放，这就造成了内存泄露。
为了避免这样单例导致内存泄露，我们可以将context参数改为全局的上下文：

private AppSettings(Context context) {
        this.mContext = context.getApplicationContext();
}

2.静态变量导致内存泄漏

静态变量存储在方法区，它的生命周期从类加载开始，到整个进程结束。一旦静态变量初始化后，它所持有的引用只有等到进程结束才会释放。比如下面这样的情况，在Activity中为了避免重复的创建info，将sInfo作为静态变量：

public class MainActivity2 extends AppCompatActivity {

    public static Info sInfo;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        sInfo = new Info(this);
    }

    class Info {

        private Context mContext;

        public Info(Context context) {
            this.mContext = context;
        }
    }
}

Info作为Activity的静态成员，并且持有Activity的引用，但是sInfo作为静态变量，生命周期肯定比Activity长。所以当Activity退出后，sInfo仍然引用了Activity，Activity不能被回收，这就导致了内存泄露。

在Android开发中，静态持有很多时候都有可能因为其使用的生命周期不一致而导致内存泄露，所以我们在新建静态持有的变量的时候需要多考虑一下各个成员之间的引用关系，并且尽量少地使用静态持有的变量，以避免发生内存泄露。当然，我们也可以在适当的时候讲静态量重置为null，使其不再持有引用，这样也可以避免内存泄露。

3.非静态内部类导致内存泄露

非静态内部类（包括匿名内部类）默认就会持有外部类的引用，当非静态内部类对象的生命周期比外部类对象的生命周期长时，就会导致内存泄露。非静态内部类导致的内存泄露在Android开发中有一种典型的场景就是使用Handler，很多开发者在使用Handler是这样写的：

public class MainActivity2 extends AppCompatActivity {


    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        start();
    }

    private void start() {
        Message message = Message.obtain();
        message.what = 1;
        mHandler.sendMessage(message);
    }


    private Handler mHandler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            if (msg.what == 1) {
                //doNothing
            }
        }
    };
}

也许有人会说，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开发中如果要使用内部类，但又要规避内存泄露，一般都会采用静态内部类+弱引用的方式。

MyHandler mHandler;

public static class MyHandler extends Handler {

        private WeakReference<Activity> mActivityWeakReference;

        public MyHandler(Activity activity) {
            mActivityWeakReference = new WeakReference<>(activity);
        }

        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);

        }
}
mHandler通过弱引用的方式持有Activity，当GC执行垃圾回收时，遇到Activity就会回收并释放所占据的内存单元。这样就不会发生内存泄露了。上面的做法确实避免了Activity导致的内存泄露，发送的msg不再已经没有持有Activity的引用了，但是msg还是有可能存在消息队列MessageQueue中，所以更好的是在Activity销毁时就将mHandler的回调和发送的消息给移除掉。

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

非静态内部类造成内存泄露还有一种情况就是使用Thread或者AsyncTask。要避免内存泄露的话还是需要像上面Handler一样使用静态内部类+弱应用的方式（代码就不列了，参考上面Hanlder的正确写法）。

4.未取消注册或回调导致内存泄露

比如我们在Activity中注册广播，如果在Activity销毁后不取消注册，那么这个刚播会一直存在系统中，同上面所说的非静态内部类一样持有Activity引用，导致内存泄露。因此注册广播后在Activity销毁后一定要取消注册。在注册观察则模式的时候，如果不及时取消也会造成内存泄露。比如使用Retrofit+RxJava注册网络请求的观察者回调，同样作为匿名内部类持有外部引用，所以需要记得在不用或者销毁的时候取消注册。

5.Timer和TimerTask导致内存泄露

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

private void stopTimer(){
        if(mTimer!=null){
            mTimer.cancel();
            mTimer.purge();
            mTimer = null;
        }
        if(mTimerTask!=null){
            mTimerTask.cancel();
            mTimerTask = null;
        }
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        stopTimer();
    }

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

6.集合中的对象未清理造成内存泄露

这个比较好理解，如果一个对象放入到ArrayList、HashMap等集合中，这个集合就会持有该对象的引用。当我们不再需要这个对象时，也并没有将它从集合中移除，这样只要集合还在使用（而此对象已经无用了），这个对象就造成了内存泄露。并且如果集合被静态引用的话，集合里面那些没有用的对象更会造成内存泄露了。所以在使用集合时要及时将不用的对象从集合remove，或者clear集合，以避免内存泄漏。

7.资源未关闭或释放导致内存泄露

在使用IO、File流或者Sqlite、Cursor等资源时要及时关闭。这些资源在进行读写操作时通常都使用了缓冲，如果不及时关闭，这些缓冲对象就会一直被占用而得不到释放，以致发生内存泄露。因此我们在不需要使用它们的时候就及时关闭，以便缓冲能及时得到释放，从而避免内存泄露。

8.属性动画造成内存泄露

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

9.WebView造成内存泄露

关于WebView的内存泄露，因为WebView在加载网页后会长期占用内存而不能被释放，因此我们在Activity销毁后要调用它的destory()方法来销毁它以释放内存。另外在查阅WebView内存泄露相关资料时看到这种情况：Webview下面的Callback持有Activity引用，造成Webview内存无法释放，即使是调用了Webview.destory()等方法都无法解决问题（Android5.1之后）。最终的解决方案是：在销毁WebView之前需要先将WebView从父容器中移除，然后再销毁WebView。

三、总结

  1. 对于生命周期比Activity长的对象（单例），要避免直接引用Activity的context，可以考虑使用ApplicationContext，静态变量不使用时及时置空；

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

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

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

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

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

  7. 属性动画及时取消，注意webview内存泄漏问题。

参考链接：https://www.jianshu.com/p/f0e47bcb1866

友情推荐：

Android 开发干货集锦

至此，本篇已结束。转载网络的文章，小编觉得很优秀，欢迎点击阅读原文，支持原创作者，如有侵权，恳请联系小编删除，欢迎您的建议与指正。同时期待您的关注，感谢您的阅读，谢谢！

点个在看，方便您使用时快速查找！

浏览 19
点赞
评论
收藏
分享

手机扫一扫分享

举报
评论
图片
表情
推荐
CXL：破解AI时代“内存墙”新途径
AI大模型的快速发展推动“算力”和“存力”需求快速增长，“内存墙”问题由来已久，在 AI 时代表现的愈发明显，“算力”和“运力”之间的差距越来越大。Transformer 类的模型参数的数量呈现指数增长，每两年增加 410 倍，而 GPU 内存仅以每两年 2 倍的速度扩展。1、AI时代“内存墙”问题
架构师技术联盟
0
15种时间序列预测方法总结(包含多种方法代码实现)
向AI转型的程序员都关注了这个号👇👇👇在这篇文章中，我们将深入探讨时间序列预测的基本概念和方法。我们将首先介绍单元预测和多元预测的概念，然后详细介绍各种深度学习和传统机器学习方法如何应用于时间序列预测，包括循环神经网络（RNN）、一维卷积神经网络（1D-CNN）、Transformer、自回归模型（
机器学习AI算法工程
0
APP 安全测试项总结
一、安装包测试　　1.1、关于反编译　　目的是为了保护公司的知识产权和安全方面的考虑等，一些程序开发人员会在源码中硬编码一些敏感信息，如密码。而且若程序内部一些设计欠佳的逻辑，也可能隐含漏洞，一旦源码泄漏，安全隐患巨大。　　为了避免这些问题，除了代码审核外，通常开发的做法是对代码进行混淆，混淆后源代
测试开发技术
0
从原理到实践：掌握DPDK内存池技术
前言：本文整理下之前的学习笔记，基于DPDK17.11版本源码分析。主要分析一下内存管理部分代码。一、概述内存管理是数据面开发套件（DPDK）的一个核心部分，以此为基础，DPDK的其他部分和用户应用得以发挥其最佳性能。本系列文章将详细介绍DPDK提供的各种内存管理的功能。但在此之前，有必要先谈一谈为
开源Linux
0
微服务与领域驱动设计，架构实践总结
来源：知了一笑👉 欢迎加入小哈的星球 ，你将获得: 专属的项目实战 / Java 学习路线 / 一对一提问 / 学习打卡 /  赠书福利全栈前后端分离博客项目 2.0 版本完结啦， 演示链接：http://116.62.199.48/ ，新
小哈学Java
0
【总结】2021- 作为前端，工作中处理过什么复杂的需求？
先说背景，我目前在腾讯IMWeb团队，负责在线教育腾讯课堂的前端研发。都说疫情期间在线教育是风口，我想说，打的赢扛得住也许是机遇，打不赢完全是炮灰。先说流量从春节假期到现在，我们遭遇了前所未有的流量峰值，虽然具体数字不方便透露，但是可以预想得到，那么多所学校在期间强制网络上课，学生加老师的数量是多么
前端自习课
10
得物面试：Redis 内存碎片是什么？如何清理？
JavaGuide官方网站：javaguide.cn这是一道不是特别高频但很重要的 Redis 面试题，属于 Redis 性能优化的范畴。Redis 内存碎片相关的问题在得物、美团、阿里、字节、携程等公司的后端面试中都曾出现过，还是建议认真准备一下。即使不是准备面试，日常开发也是能够用到的！什么是内
JavaGuide
0
【总结】2020- 前端常用的几种请求方式
本文作者系360奇舞团前端开发工程师前端数据请求方式主要包括XMLHttpRequest、Fetch、Axios、WebSocket等。这些请求方式各有特点，适用于不同的场景。本文将从综合性能、优缺点、最佳使用场景以及使用方式的角度对这些数据请求方式进行分析。介绍XMLHttpRequest（XHR
前端自习课
10
【总结】2019- 如何自己开发一个前端监控SDK
原文链接：https://juejin.cn/post/7276814487054450725最近在负责团队前端监控系统搭建的任务。因为我们公司有统一的日志存储平台、日志清洗平台和基于 Grafana 搭建的可视化看板，就剩日志的采集和上报需要自己实现了，所以决定封装一个前端监控 SDK 来完成日志
前端自习课
10
收藏 | 论文画图工具：25个常用Matplotlib图的Python代码总结
点击上方“小白学视觉”，选择加"星标"或“置顶”重磅干货，第一时间送达仅作学术分享，不代表本公众号立场，侵权联系删除转载于：作者丨zsx_yiyiyi来源丨python大本营编辑丨极市平台# !pip install brewer2mplimport nump
小白学视觉
10
点赞
评论
收藏
分享

手机扫一扫分享

举报