Android高性能编码 - 第一篇内存与对象（一）防止内存泄露

最新推荐文章于 2022-09-01 16:53:21 发布

起个昵称那么难

最新推荐文章于 2022-09-01 16:53:21 发布

阅读量314

点赞数 1

分类专栏： Android Performance 文章标签： Android 性能

本文链接：https://blog.csdn.net/qq_16206535/article/details/79476336

版权

Android Performance 专栏收录该内容

12 篇文章 1 订阅

订阅专栏

第一篇内存与对象

内存表现是Android性能的重要指标，影响着应用整体的运行性能，需要我们高度关注。对于开发者来说，我们一方面要防止内存泄露的发生，另一方面则需要不断的优化编码，减少内存占用，提升内存对象的使用效率。

1.1 防止内存泄露

尽管Java运行环境自带了GC回收机制，但实际编码中由于默认的强引用关系，以及Android组件频繁的生命周期转换，资源无法及时释放以致内存泄露的情况屡见不鲜。本篇内容将阐述Android编码中典型的内存泄露点及其良好的改进实践，遵守这些实践规范，将最大限度的避免内存泄露问题。

1.1.1 防止静态变量导致的泄露

如示例注释，此处是比较明显的静态变量持有，而比较难察觉的一种情景为，Activity或其成员变量被传递到另一个类对象的静态变量中持有。

对此，我们要尽可能的避免在静态变量中持有Activity及其成员，如果有特别的需要，一定要在组件Destroy时及时释放。

1.1.2 防止单例模式导致的泄露

单例对象为全局调用提供了方便，但是由于我们往往不会中途销毁单例，导致其生命周期同app一样长，就有可能带来跟静态字段持有类似的引用问题。

此处假设Activity没有在onDestroy中，从TestClass中unRegisterListener，因此Activity对象无法被即时的释放，导致内存泄露。

良好的编码规范要求，对于自定义的register调用，一定要有对称的unRegister调用。这十分类似于Android广播组件的注册和注销配对要求。

1.1.3 防止动画导致的内存泄露

我们经常会应用一些无限循环的动画，如果在Activity中播放此类动画而且没有在onDestory中去停止动画，那么动画会一直播放下去，尽管已经看不到动画效果了。

这个时候Activity的View会被动画持有，而View又持有了Activity无法释放，会泄露当前的Activity。

良好的规范要求及时释放动画资源，解决办法之一是在Activity的onDestory中调用animator.cancel接口；

1.1.4 防止handler的延时消息导致内存泄露

Handler持有对UI主线程消息队列MessageQueue和循环Looper的引用。子线程可以通过Handler将消息发送到UI线程的消息队列MessageQueue中。UI主线程通过Looper循环查询消息队列，当发现有消息存在时会将消息从队列中取出。首先分析消息，通过消息的参数判断该消息对应的Handler，然后将消息分发到指定的Handler进行处理。

一种必现的消息导致泄露的示例：

当Activity结束后，在 Messagequeue 处理这个Message之前，它会持续存活着。这个Message持有Handler的引用，而Handler有持有Activity(SampleActivity)的引用，这个Activity所有的资源，在这个消息处理之前都不能也不会被回收，所以发生了内存泄露。

一种最佳的handler实践如下，结合了static修饰和弱引用关系，具体分析见下一条内部类相关阐述。

1.1.5 防止内部类导致的内存泄露

这是对上述handler对象问题的一个扩展，可以推广到更大范围的内部类，尤其是更普遍的网络请求等耗时相关的线程及其封装内部类。

内部类在Java中是一个很常见的数据结构。它们很受欢迎，因为它们可以以这样的方式来定义：即只有外部类可以实例化它们。很多人可能没有意识到的是这样的类会持有外部类的隐式引用。隐式引用很容易出错，尤其是当两个类具有不同的生命周期，而内部类对象却强引用着外部类对象。以下是常见的Activity内部类定义和应用的写法：

我们第一要务是使用静态类的实现方式来消除指向Activity的引用，但这样我们也不能直接访问textView了。因此我们还需要添加一个构造函数，把textView作为参数传递进来。

第二个问题是，我们无法消除resultTextView绑定的context引用，一种最佳实践的方法是使用WeakReference。我们持有的resultTextView引用是强引用，具有防止GC回收的能力。相反，WeakReference不保证其引用的实例存活。当一个实例最后一个强引用被删除，GC会把其资源回收，而不管这个实例是否有弱引用。

下面是使用WeakReference的最终版本：

1.1.6 防止匿名类对象内存泄露

在内部类的基础上，进一步扩展，我们需要重点关注的包括匿名类对象，特别是耗时请求的回调型匿名类对象。

一个典型的耗时Callback泄露示例如下：

根据在内部类的例子中同样的推理，我们得出一个结论：匿名回调类是内存泄漏的原因。然而，此代码包含两个问题。首先，请求没有取消策略。其次，需要消除对Activity的隐式强引用。规范的解决办法，类似我们在内部类的例子做的同样的事情。

1.1.7 防止调用系统服务时的上下文泄露

这是一类比较隐藏的泄露，由于编码时的方便性，我们很容易直接使用当前组件的上下文来调用一些系统服务，导致context被持有在系统服务中。

一个ConnectivityManager的示例：

经LeakCanary 可以报出

* GC ROOT staticandroid.net.ConnectivityManager.sInstance

* referencesandroid.net.ConnectivityManager.mContext

* leaks top.itmp.jiandan.ui.MainActivityinstance

根据业内的实践反馈，同样的问题还出现在WifiManager ，CameraManager等其他getSystemService() 的实例中。

良好的规范，要求使用getApplicationContext()获取全局上下文来调用该类服务。

1.1.8 防止资源未及时释放导致的泄露

尽管JVM提供了GC回收机制，但是我们不能绝对的依赖它。一方面，其回收策略并不能保证资源的及时释放；另一方面，受制于对象间的引用依赖，GC甚至不作回收。因此，规范要求，应当适时的主动释放待回收资源。

1.1.8.1 主动释放Bitmap资源

当确定这个Bitmap资源不会再被使用的时候(当然这个Bitmap不释放可能会让程序下一次启动或者resume快一些，但是其占用的内存资源太大，可能导致程序在后台的时候被杀掉，反而得不偿失)，我们建议手动调用recycle()方法，释放其Native内存。

if(bitmap != null && !bitmap.isRecycled()){
    bitmap.recycle();
    bitmap = null;
}

①主动释放ImageView的图片资源

由于我们在实际开发中，很多情况是在xml布局文件中设置ImageView的src或者在代码中调用ImageView.setImageResource/setImageURI/setImageDrawable等方法设置图像，下面代码可以回收这个ImageView所对应的资源：

private static void recycleImageViewBitMap(ImageView imageView) {
    if (imageView != null) {
        BitmapDrawable bd = (BitmapDrawable) imageView.getDrawable();
        rceycleBitmapDrawable(bd);
    }
}

private static void rceycleBitmapDrawable(BitmapDrawable bitmapDrawable) {
    if (bitmapDrawable != null) {
        Bitmap bitmap = bitmapDrawable.getBitmap();
        rceycleBitmap(bitmap);
    }
    bitmapDrawable = null;
}

private static void rceycleBitmap(Bitmap bitmap) {
    if (bitmap != null && !bitmap.isRecycled()) {
        bitmap.recycle();
        bitmap = null;
    }
}

②主动释放ImageView的背景资源

如果ImageView是有Background，那么参照下面的代码释放：

public static void recycleBackgroundBitMap(ImageView view) {
    if (view != null) {
        BitmapDrawable bd = (BitmapDrawable) view.getBackground();
        rceycleBitmapDrawable(bd);
    }
}

private static void rceycleBitmapDrawable(BitmapDrawable bitmapDrawable) {
    if (bitmapDrawable != null) {
        Bitmap bitmap = bitmapDrawable.getBitmap();
        rceycleBitmap(bitmap);
    }
    bitmapDrawable = null;
}

private static void rceycleBitmap(Bitmap bitmap) {
    if (bitmap != null && !bitmap.isRecycled()) {
        bitmap.recycle();
        bitmap = null;
    }
}

1.1.8.2 查询数据库主动关闭游标

程序中经常会进行查询数据库的操作，但是经常会有使用完毕Cursor后没有关闭的情况。如果我们的查询结果集比较小，对内存的消耗不容易被发现，只有在常时间大量操作的情况下才会复现内存问题，这样就会给以后的测试和问题排查带来困难和风险。

Cursor cursor = null;
try {
    cursor = getContentResolver().query(uri ...);
    if (cursor != null && cursor.moveToNext()) {
        //... ...
    }
} finally {
    if (cursor != null) {
        try {
            cursor.close();
        } catch (Exception e) {
            //...
        }
    }
}

1.1.8.3 释放对象的引用

一个对象的内存没有被释放是因为他被其他的对象所引用，系统不回去释放这些有GC Root的对象。在Android组件的生命周期之内，如果有一些较重的资源是某个业务临时使用的，使用完成之后，我们希望及时的释放。

示例：

public class DemoActivity extends Activity {
    //... ...
    private Handler mHandler;
    private Object obj;
    public void operation() {
        obj = initObj();
        //...
        //[TODO]
        mHandler.post(new Runnable() {
            public void run() {
                useObj(obj);
            }
        });
    }
}

我们有一个成员变量 obj，在operation()中我们希望能够将处理obj实例的操作post到某个线程的MessageQueue中。在以上的代码中，即便是mHandler所在的线程使用完了obj所引用的对象，但这个对象仍然不会被垃圾回收掉，因为DemoActivity.obj还保有这个对象的引用。所以如果在DemoActivity中不再使用这个对象了，可以在[TODO]的位置释放对象的引用，而代码可以修改为：

public void operation() {
    obj = initObj();
    //...
    final Object o = obj;
    obj = null;
    mHandler.post(new Runnable() {
        public void run() {
            useObj(o);
        }
    }
}

当然，这只是针对需要保留obj为field的场景，特别情况下，如果obj只有此处调用，那么将其重构为local变量即可。

1.1.8.4 在Activity的生命周期中释放资源

在以上各项防止泄露的资源，我们已经讨论过各自的释放方式，而这些资源最后的释放时机，就是在对应的组件生命周期onDestroy()结束之际。具体参考以上对应内容，在此不再细表。

1.1.9 防止try-catch关闭多项资源异常

使用流Stream、游标Cursor等资源需要及时关闭已经不必讨论，这里特别指的是由于close之前发生异常，而导致关闭失败，比如在try和catch块中编写close，是非常不安全的。

良好的规范要求，必须在finally块中进行关闭，如果有多个待关闭资源，需要在finally块中分别判断和关闭，不可集中进行，避免前一个资源关闭失败而导致后一个资源关闭语句未执行。

1.1.10 防止服务闲置

这里的闲置指的是应用之前开启的服务已经执行完设计的任务，但是却没有主动关闭，系统无法回收，处于空闲状态。这属于一种广义上的内存泄露，视服务本身的内存占用情况，可能会对应用和系统造成较大的影响。

因此，我们需要对后台服务进行管理，在执行完设计的任务后，应当及时的释放。

1 主动关闭服务

在服务内部，通过调用stopSelf()接口进行关闭；在外部，则可以使用上下文接口Context.stopService()。

2 使用IntentService

IntentService内部封装了HandlerThread的实现，可以在执行完任务后，自动释放，最大程度地优化了内存使用和防止泄露。

备注：关于IntentService的具体使用，将在异步任务章节详细阐述。

起个昵称那么难

关注

1
点赞
踩
3

收藏

觉得还不错? 一键收藏
0
评论
Android高性能编码 - 第一篇内存与对象（一）防止内存泄露

第一篇内存与对象内存表现是Android性能的重要指标，影响着应用整体的运行性能，需要我们高度关注。对于开发者来说，我们一方面要防止内存泄露的发生，另一方面则需要不断的优化编码，减少内存占用，提升内存对象的使用效率。1.1 防止内存泄露尽管Java运行环境自带了GC回收机制，但实际编码中由于默认的强引用关系，以及Android组件频繁的生命周期转换，资源无法及时释放以致内存泄露的情况屡见不鲜。本篇...
复制链接

扫一扫