Android中的ART虚拟机是一个托管内存环境。垃圾回收器负责内存分配,并在不再使用该内存时将其释放回堆。当应用程序不再使用对象,但垃圾回收器无法删除它们,因为它们仍在被引用时,就会发生内存泄漏。因此,这些对象被保存在内存中,并且不必要地消耗资源。最终,内存泄漏将导致频繁的垃圾回收和内存不足错误。
在本文中,我们将讨论Android中最常见的一些内存泄漏以及避免它们的方法。
Android中的引用类型
Android(或Java)有4种类型的引用,从强到弱依次是:强、软、弱和虚。强引用和弱引用是最广泛使用的。
强引用
普通引用,默认情况下每次创建新对象时都会创建一个。如果一个对象可以通过一系列强引用链到达,则该对象被归类为强可达对象。强可访问对象没有资格进行垃圾回收,这通常是我们想要的。
然而,在某些情况下,强引用可能会给我们带来问题,因为…它们很强。假设我们有一个图像缓存来避免在不需要的时候重新加载图像,在默认情况下,使用强引用,所有图像都将保存在内存中,占用大量空间。在某些时候,如果缓存继续增长,我们需要释放未使用的映像。我们可以构建某种LRU缓存或手动跟踪缓存中的所有对象,但这是一项非常重要的任务。LRU缓存还有另一个问题:我们必须为缓存设置内存限制,这通常不容易确定。如果我们有一个简单的机制来找出哪些对象不再需要,哪些对象应该被垃圾回收,那就更好了。这就是弱引用发挥作用的时候。
弱引用
弱引用是指引用的强度不足以将对象保留在内存中。如果垃圾回收器发现一个对象是弱可访问的(只能通过弱引用访问),它将立即清除对该对象的弱引用。
其他类型
还有两种类型的引用:软引用和虚引用。
软引用和弱引用基本一样,只是它不太愿意丢弃它所引用的对象。换句话说,软引用仍然会在内存中保留一段时间,直到内存绝对需要为止,而弱引用将立即被收集。
虚引用可用于确定何时从内存中删除对象,这有助于计划内存敏感任务或清理操作。
内存泄漏常见模式
静态场
静态字段将与进程的生存期一样长。如果静态变量引用大量数据,则不会收集这些数据,即使它们可能不再需要。例如,如果你没有清理内存的机制,位图缓存可以很快填满内存。
你也不应该在android的静态对象中保留对活动或上下文的引用。活动或上下文通常包含许多其他对象,泄漏它们会给我们带来麻烦。这里最好的方法就是每次调用时将上下文作为参数传递给函数。但是,如果出于某种原因确实需要将上下文保留在静态对象中,请考虑使用应用程序上下文而不是视图或活动上下文,并记住在不再需要时将其设置为null。
class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
// using application context here, but a better way is not to keep a context as a static field
Utils.context = this.applicationContext
}
override fun onDestroy() {
super.onDestroy()
// clear context reference to avoid memory leaks
Utils.context = null
}
}
object Utils {
// memory leaks can happen here
var context: Context? = null
fun doSomethingWithContext(){
context?.apply {
// doing wonderful things with the context
}
}
}
长期运行任务
Android中的活动和碎片具有相当复杂的生命周期。在错误的时间做这项工作可能会导致内存泄漏。如果活动启动后台任务,并且该任务在活动被销毁时继续运行,则垃圾回收器可能不会收集该活动。如果在异步回调中引用了某些视图,则在任务完成之前无法释放这些视图。这意味着包含视图的活动以及活动中的所有对象都会泄漏。因此,当不再需要长时间运行的任务时,应该取消它。
class MainActivity : AppCompatActivity() {
private lateinit var textView: TextView
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
TaskExecutors.doTask(10, object: (Int) -> Unit {
override fun invoke(result: Int) {
// this may cause memory leaks or even crashes if the task is still running after the activity has been killed
runOnUiThread {
textView.text = result.toString()
}
}
})
}
override fun onDestroy() {
super.onDestroy()
// should cancel running tasks if it is not needed anymore
TaskExecutors.cancelTask()
}
}
object TaskExecutors {
private var job: Job? = null
fun doTask(input: Int, callback: (Int) -> Unit) {
job = GlobalScope.launch {
val result = doHeavyCalculation(input)
callback.invoke(result)
}
}
private suspend fun doHeavyCalculation(input: Int): Int {
delay(10000L)
return input * 10
}
fun cancelTask(){
// find a way to cancel long-running task
}
}
未关闭资源
无论何时创建或打开资源,系统都会为这些资源分配内存。不关闭这些资源会阻塞内存,使它们无法被收集。这些类型的一些示例包括数据库连接、输入流或忘记注销广播接收器。
非静态内部类
内部类的任何实例都包含对其外部类的隐式引用。如果内部类的实例比外部类的生存时间长,则会发生内存泄漏。更具体地说,存在这样一种情况:内部对象是活动的(通过引用),但对包含对象的引用已经从所有其他对象中移除。内部对象仍然保持包含对象的活动状态,因为它始终具有对它的引用。
fun main(args: Array<String>) {
val productContainer = mutableListOf<Factory.Product>()
// need a factory to make product
val factory = Factory()
for (i in 0..10000) {
val newProduct = factory.createProduct()
productContainer.add(newProduct)
}
// create product complete, now we don't need the factory anymore. But...
// ... the factory is still here, because the product has the reference to it.
}
class Factory {
// data to leak
var data = 0
fun createProduct(): Product = Product()
inner class Product { var pId: Int = 0 }
}
这个问题的解决方案是,如果内部类不需要访问外部类成员,可以考虑将其更改为静态类。