Android 内存泄漏

我就是我 2022-12-22 09:37 151阅读 0赞

内存泄漏（Memory Leak）是指程序中已动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃(OOM)等严重后果。

# **一、内存泄漏检查工具LeakCanary** #

[LeakCanary][]是Square公司为Android开发者提供的一个自动检测内存泄漏的工具，LeakCanary本质上是一个基于MAT进行Android应用程序内存泄漏自动化检测的的开源工具，我们可以通过集成LeakCanary提供的jar包到自己的工程中，一旦检测到内存泄漏，LeakCanary就好dump Memory信息，并通过另一个进程分析内存泄漏的信息并展示出来，随时发现和定位内存泄漏问题，而不用每次在开发流程中都抽出专人来进行内存泄漏问题检测，极大地方便了Android应用程序的开发。

LeakCanary显示内存泄漏的页面：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5uYWkxMTAx_size_16_color_FFFFFF_t_70]

#  #

## LeakCanary的Android Studio集成 ##

**一、 在build.gradle中添加LeakCanary的依赖包，截止目前leakcanary的最新版本是1.6.1：**

dependencies {
        debugCompile 'com.squareup.leakcanary:leakcanary-android:1.6.1'
        releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.6.1'
    }

在开发中一般同时集成debug和release版本，其中：

*  com.squareup.leakcanary:leakcanary-android:1.6.1 是debug版本，在你的app编译的是debug版本，加载的是该jar包，一旦出现内存泄漏会在通知栏中通知开发者产生了内存泄漏；
 *  com.squareup.leakcanary:leakcanary-android-no-op:1.6.1 是release版本，如果你的app编译的是release版本时，加载的是该jar包，no-op是指No Operation Performed，代表不会做任何操作，不会干扰正式用户的使用；

**二、 在我们自定义Application的onCreate方法中注册LeakCanary**

@Override
    public void onCreate() {
        super.onCreate();
        if (LeakCanary.isInAnalyzerProcess(this)) {
            // This process is dedicated to LeakCanary for heap analysis.
            // You should not init your app in this process.
            return;
        }
        LeakCanary.install(this);
    }

*  解释一下为什么要先判断`LeakCanary.isInAnalyzerProcess(this)`

在注册之前先判断LeakCanary是否已经运行在手机上，比如你同时有多个APP集成了LeakCanary，其他app已经运行了LeakCanary则不需要重新`install。`

*  正常情况下`Application`调用`LeakCanary.install(this)`后就可以正常监听该app程序的内存泄漏；

## LeakCanary监听指定对象的内存泄漏 ##

如果想让LeakCanary监听指定对象的内存泄漏，我们就需要使用到`RefWatcher`的`watch`功能，使用方式如下：

*  在`Application`的`onCreate`中调用`install`方法，并获取`RefWatcher`对象：

private static RefWatcher sRefWatcher;
    
    @Override
    public void onCreate() {
        super.onCreate();
        sRefWatcher = LeakCanary.install(this);
    }
    
    public static RefWatcher getRefWatcher() {
        return sRefWatcher;
    }

注意：因为这时候需要获取sRefWatcher对象，所以sRefWatcher = LeakCanary.install(this)一定需要执行，不需要判断LeakCanary.isInAnalyzerProcess(this)。

为了方便演示使用LeakCanary获取和解决内存泄漏的问题，我们先写一个内存泄漏的场景，我们知道最常见的内存泄漏是单列模式使用`Activity`的`Context`场景，所以我们也用单列模式来演示：

public class Singleton {
        private static Singleton singleton;
        private Context context;
        private Singleton(Context context) {
            this.context = context;
        }
    
        public static Singleton newInstance(Context context) {
            if (singleton == null) {
                synchronized (Singleton.class) {
                    if (singleton == null){//双重检查锁定
                        singleton = new Singleton(context);
                    }
                }
            }
            return singleton;
        }
    }

在需要监听的对象中调用`RefWatcher`的`watch`方法进行监听，比如我想监听一个`Activity`，我们可以在该`Acitivity`中`onCreate`方法中添加`DemoApp.getRefWatcher().watch(this);`：

@Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        DemoApp.getRefWatcher().watch(this);
        setContentView(R.layout.activity_second);
        Singleton singleton = Singleton.newInstance(this);
    }

## LeakCanary内存泄漏展示页面 ##

同时上面的步骤，当我们在运行app程序的时候，出现内存泄漏后，过一小段时间后就会在通知栏中通知出现内存泄漏的情况：  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5uYWkxMTAx_size_16_color_FFFFFF_t_70 1][]  
同时会在桌面上生成一个Leaks的图标，这个就是展示内存泄漏列表的，内存泄漏列表页面如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5uYWkxMTAx_size_16_color_FFFFFF_t_70 2]  
这是一个内存泄漏的列表，我们可以通过点击进入查看泄漏的内容  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5uYWkxMTAx_size_16_color_FFFFFF_t_70 3]  
还可以通过点击右边的“+”号查看更详细的信息，内容太长就不截图了，内部有详细介绍调用的流程；

# 二、Android发生内存泄漏的常见情况 #

### **1、静态变量** ###

静态变量的生命周期和应用的生命周期一样长。如果静态变量持有某个Activity的context，则会引发对应Activity无法释放，导致内存泄漏。如果持有application的context，就没有问题。

常见的有：

*  单例模式：内部实现是静态变量和方法
 *  静态的View：view默认持有Activity的context
 *  静态Activity

public class MainActivity extends AppCompatActivity {
    
    
    private static Context StaticVarible;
    
    private Handler mHandler;
    
    @Override
    
    protected void onCreate(Bundle savedInstanceState) {
    
    super.onCreate(savedInstanceState);
    
    setContentView(R.layout.activity_main);
    
    btn = (Button)findViewById(R.id.button);
    
    btn.setOnClickListener(new View.OnClickListener() {
    
    @Override
    
    public void onClick(View v) {
    
    MainActivity.this.finish();
    
    }
    
    });
    
    StaticVarible = this;
    
    LeakCanary.install(getApplication());
    
    }
    
    
    }

解决办法：

在Activity Destory时将静态变量置空即可

@Override
    
    protected void onDestroy() {
    
    StaticVarible = null;
    
    super.onDestroy();
    
    }

### **2、匿名内部类或者非静态内部类** ###

非静态的内部类和匿名内部类都会隐式地持有其外部类的引用（否则怎么访问外部类的非静态成员呢？），静态的内部类不会持有外部类的引用。

java允许我们在一个类里面定义静态类。比如内部类（nested class）。把nested class封闭起来的类叫外部类。在java中，我们不能用static修饰顶级类（top level class）。只有内部类可以为static。  
静态内部类和非静态内部类之间到底有什么不同呢？下面是两者间主要的不同。  
（1）内部静态类不需要有指向外部类的引用。但非静态内部类需要持有对外部类的引用。  
（2）非静态内部类能够访问外部类的静态和非静态成员。静态类不能访问外部类的非静态成员。他只能访问外部类的静态成员。  
（3）一个非静态内部类不能脱离外部类实体被创建，一个非静态内部类可以访问外部类的数据和方法，因为他就在外部类里面。

常见的有：

Handler，AsyncTask，TimerTask等，一般在处理多线程任务的时候。

public class Activity6 extends AppCompatActivity {
     
        @Override
        protected void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.activity_6);
     
            findViewById( R.id.finish).setOnClickListener(new View.OnClickListener() {
                @Override
                public void onClick(View v) {
                    finish();
                }
            });
     
            new Thread(new Runnable() {
                @Override
                public void run() {
                    try {<br>                    //模拟耗时操作
                        Thread.sleep( 15000 );
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }
            }).start();
     
        }
    }

运行上面的代码后，点击finish按钮,过一会儿发生了内存泄漏的问题。

![11bfe2c568c58d8e397e79ff2b58298e.png][]

为什么Activity6会发生内存泄漏？

进入Activity6 界面，然后点击finish按钮，Activity6销毁，但是Activity6里面的线程还在运行，匿名内部类Runnable对象引用了Activity6的实例，导致Activity6所占用的内存不能被GC及时回收。

解决办法：

1.使用静态内部类      2.销毁前及时处理非静态内部类

如上面的例子中Runnable改为静态非匿名内部类即可：

public class Activity6 extends AppCompatActivity {
     
        @Override
        protected void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.activity_6);
     
            findViewById( R.id.finish).setOnClickListener(new View.OnClickListener() {
                @Override
                public void onClick(View v) {
                    finish();
                }
            });
     
            new Thread( new MyRunnable()).start();
     
        }
     
        private static class MyRunnable implements Runnable {
     
            @Override
            public void run() {
                try {
                    Thread.sleep( 15000 );
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }
         
    }

上面这个代码已经有效的解决了Handler，Runnable 引用Activity实例从而导致内存泄漏的问题，但是这不够。因为**内存泄漏的核心原因就是这个某个对象应该被系统回收内存的时候，却被其他对象引用，造成该内存无法回收。所以我们在写代码的时候，要始终绷着这个弦**。再回到上面这个问题，当当前Activity调用finish销毁的时候，在这个Activity里面所有线程是不是应该在OnDestory()方法里，取消线程。当然是否取消异步任务，要看项目具体的需求，比如在Activity销毁的时候，启动一个线程，异步写log日志到本地磁盘，针对这个需求却需要在OnDestory()方法里开启线程。所以根据当前环境做出选择才是正解。

所以我们还可以修改代码为：在onDestroy() 里面移除所有的callback 和 Message 。

@Override
        protected void onDestroy() {
            super.onDestroy();
     
           //如果参数为null的话，会将所有的Callbacks和Messages全部清除掉。
            handler.removeCallbacksAndMessages( null );
        }

### **3、 资源未关闭或监听器未移除（注销）** ###

在开发中，如果使用了`BraodcastReceiver`，`ContentObserver`，`File`，`Cursor`，`Stream`，`Bitmap`、`自定义属性attributeattr`、传感器等资源，应该在Activity销毁时及时关闭或者注销，否则这些资源将不会被回收，从而造成内存泄漏。比如：

// 使用传感器等资源，需要注销
    SensorManager sensorManager = getSystemService(SENSOR_SERVICE);
    Sensor sensor = sensorManager.getDefaultSensor(Sensor.TYPE_ALL);
    sensorManager.registerListener(this,sensor,SensorManager.SENSOR_DELAY_FASTEST);
    sensorManager.unregisterListener(listener);
    // 使用BraodcastReceiver，需要注销
    Myreceiver recevier = new Myreceiver();
    intentFilter = new IntentFilter();
    intentFilter.addAction("android.net.conn.CONNECTIVITY_CHANGE");
    registerReceiver(recevier,intentFilter);
    unRegisterReceiver(recevier);
    // 自定义属性，需要recycle
    TypedArray a = context.obtainStyledAttributes(attrs, R.styleable.AttrDeclareView);
    int color = a.getColor(R.styleable.AttrDeclareView_background_color, 0);
    a.recycle();

除了上述常见的内存泄漏外，还有包括`无限循环动画`、`使用ListView`、`使用集合容器`以及`使用WebView`也会造成内存泄漏，其中，**无限循环动画**造成泄漏的原因是没有在Activity的onDestory中停止动画；**使用ListView**造成泄漏的原因是构造Adapter时没有使用缓存的convertView；**使用集合容器**造成泄漏的原因是在不使用相关对象时，没有清理掉集合中存储的对象引用。在优化时，在退出程序之前将集合中的元素(引用)全部清理掉，再置为null；**使用WebView**造成泄漏的原因是在不使用WebView时没有调用其destory方法来销毁它，导致其长期占用内存且不能被回收。在优化时，可以为WebView开启另外一个进程，通过AIDL与主线程进行通信，便于WebVIew所在的进程可以根据业务需要选择合适的时机进行销毁。

[LeakCanary]: https://github.com/square/leakcanary
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5uYWkxMTAx_size_16_color_FFFFFF_t_70]: /images/20221120/04e0112ade2b4a12a6d79145ef8cee53.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5uYWkxMTAx_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20191225174022773.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5uYWkxMTAx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5uYWkxMTAx_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20191225174044994.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5uYWkxMTAx,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5uYWkxMTAx_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20191225174056225.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoZW5uYWkxMTAx,size_16,color_FFFFFF,t_70
[11bfe2c568c58d8e397e79ff2b58298e.png]: https://img-blog.csdnimg.cn/img_convert/11bfe2c568c58d8e397e79ff2b58298e.png