Android中常见的内存泄漏以及解决方法

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 }
}

这个问题的解决方案是，如果内部类不需要访问外部类成员，可以考虑将其更改为静态类。