Android内存优化操作方法梳理总结

来自:网络
时间:2022-12-26
阅读:
目录

内存泄露

内存泄漏就是在当前应用周期内不再使用的对象被GC Roots引用,导致不能回收,使实际可使用内存变小,通俗点讲,就是无法回收无用对象。这里总结了实际开发中常见的一些内存泄露的场景示例和解决方案。

非静态内部类创建静态实例

该实例的生命周期和应用一样长,非静态内部类会自动持有外部类的引用,这就导致该静态实例一直持有外部类Activity的引用。

class MemoryActivity : AppCompatActivity() {
    companion object {
        var test: Test? = null
    }
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_memory)
        test = Test()
    }
    inner class Test {
    }
}

解决方案:将非静态内部类改为静态内部类

class MemoryActivity : AppCompatActivity() {
    companion object {
        var test: Test? = null
    }
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_memory)
        test = Test()
    }
     //kotlin的静态内部类
     class Test {
    }
}

注册对象未注销或资源对象未关闭

注册了像BraodcastReceiver,EventBus这种,没有在页面销毁时注销的话,会引发泄露问题,所以应该在Activity销毁时及时注销。

类的静态变量引用耗费资源过多的实例

类的静态变量生命周期等于应用程序的生命周期,若其引用耗资过多的实例,如Context,当引用实例需结束生命周期时,会因静态变量的持有而无法被回收,从而出现内存泄露,这种情况比较常见的有单例持有context。

class SingleTon private constructor(val context: Context) {
    companion object {
        private var instance: SingleTon? = null
        fun getInstance(context: Context) =
            if (instance == null) SingleTon(context) else instance!!
    }
}

当我们在Activity中使用时,当Activity销毁,就会出现内存泄露

class MemoryActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_memory)
        SingleTon.getInstance(this)
    }
}

这种情况可以使用applicationContext,因为Application的生命周期就等于整个应用的生命周期

class SingleTon private constructor(context: Context) {
    private var context: Context
    init {
        this.context = context.applicationContext
    }
    companion object {
        private var instance: SingleTon? = null
        fun getInstance(context: Context) =
            if (instance == null) SingleTon(context) else instance!!
    }
}

Handler引发的内存泄露

class MemoryActivity : AppCompatActivity() {
    private val tag = javaClass.simpleName
    private val handler = object : Handler(Looper.getMainLooper()) {
        override fun handleMessage(msg: Message) {
            Log.i(tag, "handleMessage:$msg")
        }
    }
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_memory)
        thread(start = true) {
            handler.sendEmptyMessageDelayed(1, 10000)
        }
    }
}

当Activity被finish时,延迟发送的消息仍会存活在UI线程的消息队列中,直到10s后才被处理,这个消息持有handler的引用,由于非静态内部类或匿名类会隐式持有外部类的引用,handler隐式持有外部类也就是Activity的引用,这个引用会一直存在直到这个消息被处理,所以垃圾回收机制就没法回收而导致内存泄露。

解决方案:静态内部类+弱引用,静态内部类不会持有外部类的引用,如需handler内调用外部类Activity的方法的话,可以让handler持有外部类Activity的弱引用,这样Activity就不会有泄露风险了。

class MemoryActivity : AppCompatActivity() {
    companion object {
        private const val tag = "uncle"
    }
    private lateinit var handler: Handler
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_memory)
        handler = MyHandler(this)
        thread(start = true) {
            handler.sendEmptyMessageDelayed(1, 10000)
        }
    }
    class MyHandler(activity: Activity) : Handler(Looper.getMainLooper()) {
        private val reference = WeakReference(activity)
        override fun handleMessage(msg: Message) {
            super.handleMessage(msg)
            if (reference.get() != null) {
                Log.i(tag, "handleMessage:$msg")
            }
        }
    }
}

集合引发的内存泄露

先看个例子,我们定义一个栈,装着所有的Activity

class GlobalData {
    companion object {
        val activityStack = Stack<Activity>()
    }
}

然后每启动一个Activity,就把此Activity加进去,这个时候,如果你没有在Activity销毁时清掉集合中对应的引用,就会出现泄露问题。当然,实际开发中我们不会写这么差的代码,这只是简单提个醒,需要注意一下集合中的一些引用,如果会导致泄露的,记得及时在销毁时清掉。

class MemoryActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_memory)
        GlobalData.activityStack.push(this)
    }
}

检测工具

排查内存泄露,需要一些工具的支持,这里主要介绍常用的两个,LeakCanary和Android Studio Profiler。

LeakCanary

一行代码引入

    debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.9.1'

当你测试包安装时,手机上就会有个伴生APP,用来记录内存泄露信息的。

Android内存优化操作方法梳理总结

就拿上面集合引发的泄露例子来说,LeakCanary就会弹出通知并且Leaks APP中显示内存泄露信息,我们以此来定位内存泄露问题。

Android内存优化操作方法梳理总结

Android内存优化操作方法梳理总结

Android内存优化操作方法梳理总结

Android Studio Profiler

同样,我们拿上面集合的泄漏例子来看,首先,我们点击MEMORY

Android内存优化操作方法梳理总结

然后,普通的内存问题选择Capture heap dump就行了

Android内存优化操作方法梳理总结

点击Record,就会抓取一段时间的内存分配信息

Android内存优化操作方法梳理总结

Leaks就是记录内存泄漏的,然后我们点击进去,就可以看到具体类位置了

Android内存优化操作方法梳理总结

再点击进去具体的类,就可以看到泄漏的原因啦

Android内存优化操作方法梳理总结

内存溢出

Android系统中每个应用程序可以向系统申请一定的内存,当申请的内存不够用的时候,就会产生内存溢出,俗称OOM,全称Out Of Memory,就是内存用完了。在实际开发中,出现这种现象通常是因为内存泄露太多或大图加载问题,内存泄露上面已经讲了,那么,下面就主要讲讲图片的优化吧!

Bitmap优化

(1)及时回收Bitmap内存,这时可能有人就要问了,Android有自己的垃圾回收机制,为什么还要我们去回收呢?因为生成Bitmap最终是通过JNI方法实现的,也就是说,Bitmap的加载包含两部分的内存区域,一是Java部分,一是C部分。Java部分会自动回收,但是C部分不会,所以需要调用recycle来释放C部分的内存。那如果不调用就一定会出现泄露吗?那也不是的,Android每个应用都在独立的进程,进程被关掉的话,内存也就都被释放了。

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

(2)捕获异常,Bitmap在使用的时候,最好捕获一下OutOfMemoryError以免crash掉,你还可以设置一个默认的图片。

        var bitmap: Bitmap? = null
        try {
            bitmap = BitmapFactory.decodeFile(filePath)
            imageView.setImageBitmap(bitmap)
        } catch (e: OutOfMemoryError) {
            //捕获异常
        }
        if (bitmap == null) {
            imageView.setImageDrawable(ContextCompat.getDrawable(this, R.drawable.picture))
        }

(3)压缩,对于分辨率比较高的图片,我们应该加载一个缩小版,这里采用的是采样率压缩法。

        val options = BitmapFactory.Options()
        //设置为true可以让解析方法禁止为bitmap分配内存,返回null,同时能获取到长宽值,从而根据情况进行压缩
        options.inJustDecodeBounds = true
        BitmapFactory.decodeResource(resources, R.drawable.large_picture, options)
        val imgHeight = options.outHeight
        val imgWidth = options.outWidth
        //通过改变inSampleSize的值来压缩图片
        var inSampleSize = 1
        //imgWidth为图片的宽,viewWidth为实际控件的宽
        if (imgHeight > viewHeight || imgWidth > viewWidth) {
            val heightRatio = round(imgHeight / viewHeight.toFloat()).toInt()
            val widthRatio = round(imgWidth / viewWidth.toFloat()).toInt()
            //选择最小比率作为inSampleSize的值,可保证最终图片的宽高一定大于等于目标的宽高
            inSampleSize = if (heightRatio < widthRatio) heightRatio else widthRatio
        }
        options.inSampleSize = inSampleSize
        //计算完后inJustDecodeBounds重置为false
        options.inJustDecodeBounds = false
        val bitmap = BitmapFactory.decodeResource(resources, R.drawable.large_picture, options)
        imageView.setImageBitmap(bitmap)

如果程序中的图片是本地资源或者是自己服务器上的,那这个大小我们可以自行调整,只要注意图片不要太大,及时回收Bitmap,就能避免OOM的发生。如果图片来源是外界,这个时候就要特别注意了,可以采用压缩图片或捕获异常,避免OOM的产生而导致程序崩溃。

内存抖动

频繁地创建对象,会导致内存抖动,最终可能会导致卡顿或OOM,因为大量临时对象频繁创建会导致内存碎片,当需要分配内存时,虽然总体上还有剩余内存,但由于这些内存不连续,无法整块分配,系统会视为内存不够,故导致OOM。

常见场景为大循环中创建对象,自定义View的onDraw方法中创建对象,因为屏幕绘制会频繁调用onDraw方法。我们可以将这些操作放在循环外或onDraw方法外,避免频繁创建对象。

返回顶部
顶部