共计 6161 个字符，预计需要花费 16 分钟才能阅读完成。
当应用程序为对象分配内存，而对象不再被应用时却没有开释，就会产生内存透露。随着工夫的推移，透露的内存会累积，导致应用程序性能变差，甚至解体。透露可能产生在任何程序战争台上，但因为流动生命周期的复杂性，这种状况在 Android 利用中尤其广泛。最新的 Android 模式，如 ViewModel 和 LifecycleObserver 能够帮忙防止内存透露，但如果你遵循旧的模式或不晓得要留神什么，很容易漏过谬误。
常见例子
援用长期运行的服务
Fragment 援用了一个流动，而该流动援用一个长期运行的服务
在这种状况下，咱们有一个规范设置，流动持有一个长期运行的服务的援用，而后是 Fragment 及其视图持有流动的援用。例如，假如流动以某种形式创立了对其子 Fragment 的援用。而后，只有流动还在，Fragment 也会持续存在。那么在 Fragment 的 onDestroy 和流动的 onDestroy 之间就产生了内存透露。
该 Fragment 永远不会再应用，但它会始终在内存中
长期运行的服务援用了 Fragment 视图
另一方面，如果服务取得了 Fragment 视图的援用呢？
首先，视图当初将在服务的整个持续时间内放弃活动状态。此外，因为视图持有对其父流动的援用，所以该流动当初也会透露。
只有服务存在，FragmentView 和 Activity 都会节约内存
检测内存透露
当初，咱们曾经晓得了内存透露是如何产生的。让咱们探讨下如何检测它们。显然，第一步是查看你的利用是否会因为 OutOfMemoryError 而解体。除非单个屏幕占用的内存比手机可用内存还多，否则必定在某个中央存在内存透露。
这种办法只通知你存在的问题，而不是根本原因。内存透露可能产生在任何中央，记录的解体并不没有指向透露，而是指向最终提醒内存应用超过限度的屏幕。
你能够查看所有的面包屑控件，看看它们是否有一些相似之处，但很可能罪魁祸首并不容易辨认。让咱们钻研下其余选项。
LeakCanary
LeakCanary 是目前最好的工具之一，它是一个用于 Android 的内存透露检测库。咱们只需在构建中增加一个 build.gradle 文件依赖项。下一次，咱们装置和运行咱们的利用时，LeakCanary 将与它一起运行。当咱们在利用中导航时，LeakCanary 会偶然暂停以转储内存，并提供检测到的透露痕迹。
这个工具比咱们之前的办法要好得多。然而这个过程依然是手动的，每个开发人员只有他们集体遇到的内存透露的本地正本。咱们能够做得更好！
LeakCanary 和 Bugsnag
LeakCanary 提供了一个十分不便的代码配方（code recipe），用于将发现的透露上传到 Bugsnag。咱们能够跟踪内存透露，就像咱们在应用程序中跟踪任何其余正告或解体。咱们甚至能够更进一步，应用 Bugsnag Integration 将其连贯到项目管理软件，如 Jira，以取得更好的可见性和问责制。
Bugsnag 连贯到 Jira
LeakCanary 和集成测试
另一种进步自动化的办法是将 LeakCanary 与 CI 测试连接起来。同样，咱们有一个代码配方。以下内容来自官网文件：
LeakCanary 提供了一个专门用于在 UI 测试中检测破绽的构件，它提供了一个运行侦听器，后者会期待测试完结，如果测试胜利，它将查找留存的对象，在须要时触发堆转储并执行剖析。
留神，LeakCanary 会升高测试速度，因为它每次都会在其侦听的测试完结后转储堆。在咱们的例子中，因为咱们的选择性测试和分片设置，额定减少的工夫能够忽略不计。
最终，就像 CI 上的任何其余构建或测试失败一样，内存透露也会被裸露进去，并且破绽跟踪信息也被记录了下来。
在 CI 上运行 LeakCanary 帮忙咱们学到了更好的编码模式，特地是波及到新的库时，在任何代码进入生产环境前。例如，当咱们应用 MvRx 测试时，它发现了这个破绽：
<failure>Test failed because application memory leaks were detected: ==================================== HEAP ANALYSIS RESULT ==================================== 4 APPLICATION LEAKS References underlined with "~~~" are likely causes. Learn more at https://squ.re/leaks. 198449 bytes retained by leaking objects Signature: 6bf2ba80511dcb6ab9697257143e3071fca4 ┬───
│ GC Root: System class
│ ├─ com.airbnb.mvrx.mocking.MockableMavericks class
│ Leaking: NO (a class is never leaking)
│ ↓ static MockableMavericks.mockStateHolder
│ ~~~~~~~~~~~~~~~
├─ com.airbnb.mvrx.mocking.MockStateHolder instance
│ Leaking: UNKNOWN
│ ↓ MockStateHolder.delegateInfoMap
│ ~~~~~~~~~~~~~~~
├─ java.util.LinkedHashMap instance
│ Leaking: UNKNOWN
│ ↓ LinkedHashMap.header
│ ~~~~~~
├─ java.util.LinkedHashMap$LinkedEntry instance
│ Leaking: UNKNOWN
│ ↓ LinkedHashMap$LinkedEntry.prv
│ ~~~
├─ java.util.LinkedHashMap$LinkedEntry instance
│ Leaking: UNKNOWN
│ ↓ LinkedHashMap$LinkedEntry.key
│ ~~~
╰→ com.dropbox.product.android.dbapp.photos.ui.view.PhotosFragment instance
Leaking: YES (ObjectWatcher was watching this because com.dropbox.product.android.dbapp.photos.ui.view.PhotosFragment received Fragment#onDestroy() callback and Fragment#mFragmentManager is null)
key = 391c9051-ad2c-4282-9279-d7df13d205c3
watchDurationMillis = 7304
retainedDurationMillis = 2304 198427 bytes retained by leaking objects
Signature: d1c9f9707034dd15604d8f2e63ff3bf3ecb61f8
事实证明，在编写测试时，咱们没有正确地清理测试。增加几行代码能够防止透露：
@After
fun teardown() {scenario.close()
val holder = MockableMavericks.mockStateHolder
holder.clearAllMocks()}你可能会想：既然这种内存透露只产生在测试中，那么修复它真的那么重要吗？好吧，那就看你了！与代码查看一样，透露检测能够通知你什么时候呈现了代码气息或蹩脚的编码模式。
它能够帮忙工程师编写更强壮的代码——在本例中，咱们晓得了clearAllMocks()。透露的重大水平，以及是否必须修复，都是工程师能够做出的决定。
对于咱们不想运行透露检测的测试，咱们编写了一个简略的注解：
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD, ElementType.TYPE})
public @interface SkipLeakDetection {
/**
* The reason why the test should skip leak detection.
*/
String value();}
咱们的类重写了 LeakCanary 的FailOnLeakRunListener()：
override fun skipLeakDetectionReason(description: Description): String? {
return when {description.getAnnotation(SkipLeakDetection::class.java) != null ->
"is annotated with @SkipLeakDetection"
description.testClass.isAnnotationPresent(SkipLeakDetection::class.java) ->
"class is annotated with @SkipLeakDetection"
else -> null
}
}
单个测试或整个测试类能够应用这个注解跳过透露检测。
修复内存透露
当初，咱们探讨了各种查找和裸露内存透露的办法。上面，咱们讨论一下如何真正了解和修复它们。
LeakCanary 提供的透露跟踪是诊断透露最有用的工具。实质上讲，透露跟踪打印出与透露对象关联的援用链，并解释为什么将其视为透露。
对于如何浏览和应用透露跟踪，LeakCanary 有了很好的 文档，这里无需反复。取而代之，让咱们回顾一下我本人常常要解决的两类内存透露。
视图
咱们常常看到视图被申明为类级变量：private TextView myTextView；或者，当初有更多的 Android 代码正在用 Kotlin 编写：private lateinit var myTextView: textview——十分常见，咱们没有意识到这些都能够导致内存透露。
除非在 Fragment 的 onDestroyView 中打消对这些字段的援用，（对于 lateinit 变量不能这么做），否则对这些视图的援用在 Fragment 的整个生命周期内都会存在，而不是像它们应该的那样在 Fragment 视图的生命周期内存在。
导致内存透露的一个最简略场景是：咱们在 FragmentA 上。咱们导航到 FragmentB，当初 FragmentA 在栈里。FragmentA 没有被销毁，然而 FragmentA 的视图被销毁了。任何绑定到 FragmentA 生命周期的视图当初曾经不须要了，但都还保留在内存中。
在大多数状况下，这些透露很小，不会导致任何性能问题或解体。然而对于保留对象和数据、图像、视图 / 数据绑定等的视图，咱们更有可能遇到麻烦。
所以，如果可能的话，防止在类级变量中存储视图，或者确保在 onDestroyView 中正确地清理它们。
说到视图 / 数据绑定，Android 的视图绑定文档 明确地通知咱们：字段必须被革除以避免透露。他们提供的代码片段倡议咱们做以下工作：
private var _binding: ResultProfileBinding? = null
// This property is only valid between onCreateView and
// onDestroyView.
private val binding get() = _binding!!
override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View? {_binding = ResultProfileBinding.inflate(inflater, container, false)
val view = binding.root
return view
}
override fun onDestroyView() {super.onDestroyView()
_binding = null
}
每个 Fragment 中都有很多样板代码（另外，防止应用 !!，因为如果变量为空，这会抛出KotlinNullPointerException。应用显式空解决来代替。）咱们解决这个问题的办法是创立一个ViewBindingHolder（和DataBindingHolder），Fragment 能够实现为上面这样：
interface ViewBindingHolder<B : ViewBinding> {
var binding: B?
// Only valid between onCreateView and onDestroyView.
fun requireBinding() = checkNotNull(binding)
fun requireBinding(lambda: (B) -> Unit) {
binding?.let {lambda(it)
}}
/**
* Make sure to use this with Fragment.viewLifecycleOwner
*/
fun registerBinding(binding: B, lifecycleOwner: LifecycleOwner) {
this.binding = binding
lifecycleOwner.lifecycle.addObserver(object : DefaultLifecycleObserver {override fun onDestroy(owner: LifecycleOwner) {owner.lifecycle.removeObserver(this)
this@ViewBindingHolder.binding = null
}
})
}
}
interface DataBindingHolder<B : ViewDataBinding> : ViewBindingHolder<B>
这为 Fragment 提供了一种简略而洁净的形式：
- 确保在须要绑定时提供绑定
- 只有在绑定可用时才执行某些代码
- 主动在
onDestroyView上革除绑定
暂时性透露
这些透露只会存在很短时间。特地是，咱们遇到过一个由 EditTextView 异步工作引起的透露。异步工作继续的工夫恰好比 LeakCanary 的默认等待时间长，因而，即便内存很快就被正确地开释了，也会报告一个透露。
如果你狐疑本人遇到了暂时性透露，一个很好的查看办法是应用 Android Studio 的内存分析器。一旦在分析器中启动会话，就能够按步骤重现透露，然而在转储堆并查看之前要期待更长时间。通过这段额定的工夫后，透露可能就隐没了。
Android Studio 的内存分析器显示了清理暂时性透露的成果
常常测试，尽早修复
咱们心愿，通过本文介绍，你能在本人的应用程序中跟踪和解决内存透露！与许多 Bug 和其余问题一样，最好是能常常测试，在蹩脚的模式扎根代码库之前尽早修复。
作为一名开发人员，你肯定要记住，尽管内存透露并不总是会影响利用性能，但低端机型和手机内存小的用户会感谢你为他们所做的工作。
我的库存，须要的小伙伴请点击我的 GitHub 收费支付
