java性能优化内存泄露-如何优化数据库性能

内存，是Android应用的生命线，一旦在内存上出现问题，轻者内存泄漏，重者直接crash，因此一个应用保持健壮，内存这块的工作是持久战，而且从写代码这块就需要注意合理性，所以想要了解内存优化如何去做，要先从基础知识开始。

在开始之前需要先搞明白一个问题，为什么要做内存优化？或者说做内存优化的目的是什么？

为什么要做内存优化？

我们知道，手机的内存是有限的，如果应用内存占用过大，轻则引起卡顿，重则导致应用崩溃或被系统强制杀掉，更严重的情况下会影响应用的留存率。因此，内存优化是性能优化中非常重要的一部分。

目的

做内存优化的目的是降低 Crash 率、让应用运行更流畅、让应用存活时间更长。

Crash 率

Android应用崩溃的原因有很多，内存优化可以帮助我们的应用避免内存问题导致的崩溃内存问题导致崩溃的具体表现就是内存溢出导致的异常OOMOOM的原因有很多，后面会更详细的介绍。

运行更流畅

Android出现界面卡顿的原因有很多，内存问题是其中一个原因内存问题会因为垃圾回收影响界面流畅度（垃圾收集）在GC中java性能优化内存泄露，所有线程都应该停止，包括主线程当GC和画图接口操作同时触发时，画图执行会被搁置，导致丢帧，即接口卡住。

存活时间长

Android会根据特定的机制清理进程清理进程时，优先清理后台进程如果某个应用程序在后台运行并占用更多内存，它将首先被清理清理进程的机制是低杀，后面会更详细的介绍。如果用户小张想在我们的电子商务应用程序中购买一个产品，并且在煞费苦心之后找到了一个他喜欢的产品，当他准备购买时，小张 的妻子让他给孩子换尿布当小张再次打开应用时，发现产品页面已经关闭，也就是应用被干掉了，这时小张又想起了孩子的奶粉钱，可能就放弃这次购买了。

用户在移动设备上使用应用的过程中被打断是很常见的，如果我们的应用不能活到用户回来的时候，要用户再次进行操作的体验就会很差。

优化工具

Memory Profiler

Memoryprofiler是Androidstudio自带的一个内存检测工具它通过实时图表显示内存信息，可以识别内存泄漏内存抖动等现象，并可以转储捕获的内存信息、能够执行垃圾收集并跟踪内存分配。

Memory Analyzer (MAT)

比Memory Profiler更强大的java Heap分析工具，可以准确查找内存泄露以及内存占用情况，还可以生成整体报告，用来分析问题等。

MAT一般用来线下结合Memory Profiler分析问题使用，Memory Profiler可以直观看出内存抖动，然后生成的hdprof文件，通过MAT深入分析及定位内存泄露问题。

LeakCannary

Leak Cannary是一个能自动监测内存泄露的线下监测工具。

关于以上优化工具的使用方法，可参考App性能优化手册。

Android内存优化操作方法内存泄漏

内存泄漏就是在当前应用周期内不再使用的对象被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销毁时清掉集合中对应的引用，就会出现泄露问题。当然，实际开发中我们不会写这么差的代码，这只是简单提个醒，需要注意一下集合中的一些引用，如果会导致泄露的，记得及时在销毁时清掉。

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

内存溢出

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

Bitmap优化

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

fcf6efa89ee21ec6914323fe27b04ccb

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的产生而导致程序崩溃。

内存抖动

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

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

到此这篇关于Android内存优化方法详解的文章就介绍到这了。如果觉得本篇文章有用的可以点赞收藏，谢谢支持！

相关文章：

Android性能优化之启动优化方式详解