Dropbox 如何解决 Android App 的内存泄漏问题？-

沙海

3185
文章

2
评论

2021年6月2日04:36:34Java评论41字数 6532阅读21分46秒阅读模式

摘要

智能摘要

智能摘要文章源自JAVA秀-https://www.javaxiu.com/28715.html

视图持有对其父活动的引用，所以该活动现在也会泄漏。内存泄漏可能发生在任何地方，记录的崩溃并不没有指向泄漏，而是指向最终提示内存使用超过限制的屏幕。既然这种内存泄漏只发生在测试中，那么修复它真的那么重要吗?单个测试或整个测试类可以使用这个注解跳过泄漏检测。的默认等待时间长，即使内存很快就被正确地释放了，也会报告一个泄漏。文章源自JAVA秀-https://www.javaxiu.com/28715.html

原文约 2824 字 | 图片 8 张 | 建议阅读 6 分钟 | 评价反馈文章源自JAVA秀-https://www.javaxiu.com/28715.html

Dropbox 如何解决 Android App 的内存泄漏问题？

Lily Chen 前端之巅文章源自JAVA秀-https://www.javaxiu.com/28715.html

Dropbox 如何解决 Android App 的内存泄漏问题？文章源自JAVA秀-https://www.javaxiu.com/28715.html

作者 | Lily Chen文章源自JAVA秀-https://www.javaxiu.com/28715.html

译者 | 平川文章源自JAVA秀-https://www.javaxiu.com/28715.html

策划 | 万佳文章源自JAVA秀-https://www.javaxiu.com/28715.html

本文最初发布于 Dropbox 技术博客，经原作者授权由 InfoQ 中文站翻译并分享。文章源自JAVA秀-https://www.javaxiu.com/28715.html

当应用程序为对象分配内存，而对象不再被使用时却没有释放，就会发生内存泄漏。随着时间的推移，泄漏的内存会累积，导致应用程序性能变差，甚至崩溃。泄漏可能发生在任何程序和平台上，但由于活动生命周期的复杂性，这种情况在 Android 应用中尤其普遍。最新的 Android 模式，如 ViewModel 和 LifecycleObserver 可以帮助避免内存泄漏，但如果你遵循旧的模式或不知道要注意什么，很容易漏过错误。文章源自JAVA秀-https://www.javaxiu.com/28715.html

常见例子文章源自JAVA秀-https://www.javaxiu.com/28715.html

引用长期运行的服务文章源自JAVA秀-https://www.javaxiu.com/28715.html

Dropbox 如何解决 Android App 的内存泄漏问题？文章源自JAVA秀-https://www.javaxiu.com/28715.html

Fragment 引用了一个活动，而该活动引用一个长期运行的服务文章源自JAVA秀-https://www.javaxiu.com/28715.html

在这种情况下，我们有一个标准设置，活动持有一个长期运行的服务的引用，然后是 Fragment 及其视图持有活动的引用。例如，假设活动以某种方式创建了对其子 Fragment 的引用。然后，只要活动还在，Fragment 也会继续存在。那么在 Fragment 的onDestroy和活动的onDestroy之间就发生了内存泄漏。文章源自JAVA秀-https://www.javaxiu.com/28715.html

Dropbox 如何解决 Android App 的内存泄漏问题？文章源自JAVA秀-https://www.javaxiu.com/28715.html

该 Fragment 永远不会再使用，但它会一直在内存中文章源自JAVA秀-https://www.javaxiu.com/28715.html

长期运行的服务引用了 Fragment 视图文章源自JAVA秀-https://www.javaxiu.com/28715.html

另一方面，如果服务获得了 Fragment 视图的引用呢？文章源自JAVA秀-https://www.javaxiu.com/28715.html

首先，视图现在将在服务的整个持续时间内保持活动状态。此外，因为视图持有对其父活动的引用，所以该活动现在也会泄漏。文章源自JAVA秀-https://www.javaxiu.com/28715.html

Dropbox 如何解决 Android App 的内存泄漏问题？文章源自JAVA秀-https://www.javaxiu.com/28715.html

只要服务存在，FragmentView 和 Activity 都会浪费内存文章源自JAVA秀-https://www.javaxiu.com/28715.html

检测内存泄漏文章源自JAVA秀-https://www.javaxiu.com/28715.html

现在，我们已经知道了内存泄漏是如何发生的。让我们讨论下如何检测它们。显然，第一步是检查你的应用是否会因为OutOfMemoryError而崩溃。除非单个屏幕占用的内存比手机可用内存还多，否则肯定在某个地方存在内存泄漏。文章源自JAVA秀-https://www.javaxiu.com/28715.html

Dropbox 如何解决 Android App 的内存泄漏问题？文章源自JAVA秀-https://www.javaxiu.com/28715.html

这种方法只告诉你存在的问题，而不是根本原因。内存泄漏可能发生在任何地方，记录的崩溃并不没有指向泄漏，而是指向最终提示内存使用超过限制的屏幕。文章源自JAVA秀-https://www.javaxiu.com/28715.html

你可以检查所有的面包屑控件，看看它们是否有一些相似之处，但很可能罪魁祸首并不容易识别。让我们研究下其他选项。文章源自JAVA秀-https://www.javaxiu.com/28715.html

LeakCanary文章源自JAVA秀-https://www.javaxiu.com/28715.html

LeakCanary 是目前最好的工具之一，它是一个用于 Android 的内存泄漏检测库。我们只需在构建中添加一个 build.gradle 文件依赖项。下一次，我们安装和运行我们的应用时，LeakCanary 将与它一起运行。当我们在应用中导航时，LeakCanary 会偶尔暂停以转储内存，并提供检测到的泄漏痕迹。文章源自JAVA秀-https://www.javaxiu.com/28715.html

这个工具比我们之前的方法要好得多。但是这个过程仍然是手动的，每个开发人员只有他们个人遇到的内存泄漏的本地副本。我们可以做得更好！文章源自JAVA秀-https://www.javaxiu.com/28715.html

LeakCanary 和 Bugsnag文章源自JAVA秀-https://www.javaxiu.com/28715.html

LeakCanary 提供了一个非常方便的代码配方（code recipe），用于将发现的泄漏上传到 Bugsnag。我们可以跟踪内存泄漏，就像我们在应用程序中跟踪任何其他警告或崩溃。我们甚至可以更进一步，使用 Bugsnag Integration 将其连接到项目管理软件，如 Jira，以获得更好的可见性和问责制。文章源自JAVA秀-https://www.javaxiu.com/28715.html

Dropbox 如何解决 Android App 的内存泄漏问题？文章源自JAVA秀-https://www.javaxiu.com/28715.html

Bugsnag 连接到 Jira文章源自JAVA秀-https://www.javaxiu.com/28715.html

LeakCanary 和集成测试文章源自JAVA秀-https://www.javaxiu.com/28715.html

另一种提高自动化的方法是将 LeakCanary 与 CI 测试连接起来。同样，我们有一个代码配方。以下内容来自官方文件：文章源自JAVA秀-https://www.javaxiu.com/28715.html

LeakCanary 提供了一个专门用于在 UI 测试中检测漏洞的构件，它提供了一个运行侦听器，后者会等待测试结束，如果测试成功，它将查找留存的对象，在需要时触发堆转储并执行分析。文章源自JAVA秀-https://www.javaxiu.com/28715.html
文章源自JAVA秀-https://www.javaxiu.com/28715.html

注意，LeakCanary 会降低测试速度，因为它每次都会在其侦听的测试结束后转储堆。在我们的例子中，由于我们的选择性测试和分片设置，额外增加的时间可以忽略不计。文章源自JAVA秀-https://www.javaxiu.com/28715.html

最终，就像 CI 上的任何其他构建或测试失败一样，内存泄漏也会被暴露出来，并且漏洞跟踪信息也被记录了下来。文章源自JAVA秀-https://www.javaxiu.com/28715.html

在 CI 上运行 LeakCanary 帮助我们学到了更好的编码模式，特别是涉及到新的库时，在任何代码进入生产环境前。例如，当我们使用 MvRx 测试时，它发现了这个漏洞：文章源自JAVA秀-https://www.javaxiu.com/28715.html

<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

事实证明，在编写测试时，我们没有正确地清理测试。添加几行代码可以避免泄漏：文章源自JAVA秀-https://www.javaxiu.com/28715.html

 @After fun teardown() { scenario.close() val holder = MockableMavericks.mockStateHolder holder.clearAllMocks() }

你可能会想：既然这种内存泄漏只发生在测试中，那么修复它真的那么重要吗？好吧，那就看你了！与代码检查一样，泄漏检测可以告诉你什么时候出现了代码气味或糟糕的编码模式。文章源自JAVA秀-https://www.javaxiu.com/28715.html

它可以帮助工程师编写更健壮的代码——在本例中，我们知道了clearAllMocks()。泄漏的严重程度，以及是否必须修复，都是工程师可以做出的决定。文章源自JAVA秀-https://www.javaxiu.com/28715.html

对于我们不想运行泄漏检测的测试，我们编写了一个简单的注解：文章源自JAVA秀-https://www.javaxiu.com/28715.html

@Retention(RetentionPolicy.RUNTIME)@Target({ElementType.METHOD, ElementType.TYPE})public @interface SkipLeakDetection { /** * The reason why the test should skip leak detection. */ String value();}

我们的类重写了 LeakCanary 的FailOnLeakRunListener()：文章源自JAVA秀-https://www.javaxiu.com/28715.html

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

单个测试或整个测试类可以使用这个注解跳过泄漏检测。文章源自JAVA秀-https://www.javaxiu.com/28715.html

修复内存泄漏文章源自JAVA秀-https://www.javaxiu.com/28715.html

现在，我们讨论了各种查找和暴露内存泄漏的方法。下面，我们讨论一下如何真正理解和修复它们。文章源自JAVA秀-https://www.javaxiu.com/28715.html

LeakCanary 提供的泄漏跟踪是诊断泄漏最有用的工具。本质上讲，泄漏跟踪打印出与泄漏对象关联的引用链，并解释为什么将其视为泄漏。文章源自JAVA秀-https://www.javaxiu.com/28715.html

关于如何阅读和使用泄漏跟踪，LeakCanary 有了很好的文档，这里无需重复。取而代之，让我们回顾一下我自己经常要处理的两类内存泄漏。文章源自JAVA秀-https://www.javaxiu.com/28715.html

视图文章源自JAVA秀-https://www.javaxiu.com/28715.html

我们经常看到视图被声明为类级变量：private TextView myTextView；或者，现在有更多的 Android 代码正在用 Kotlin 编写：private lateinit var myTextView: textview——非常常见，我们没有意识到这些都可以导致内存泄漏。文章源自JAVA秀-https://www.javaxiu.com/28715.html

除非在 Fragment 的onDestroyView中消除对这些字段的引用，（对于lateinit变量不能这么做），否则对这些视图的引用在 Fragment 的整个生命周期内都会存在，而不是像它们应该的那样在 Fragment 视图的生命周期内存在。文章源自JAVA秀-https://www.javaxiu.com/28715.html

导致内存泄漏的一个最简单场景是：我们在 FragmentA 上。我们导航到 FragmentB，现在 FragmentA 在栈里。FragmentA 没有被销毁，但是 FragmentA 的视图被销毁了。任何绑定到 FragmentA 生命周期的视图现在已经不需要了，但都还保留在内存中。文章源自JAVA秀-https://www.javaxiu.com/28715.html
文章源自JAVA秀-https://www.javaxiu.com/28715.html

在大多数情况下，这些泄漏很小，不会导致任何性能问题或崩溃。但是对于保存对象和数据、图像、视图 / 数据绑定等的视图，我们更有可能遇到麻烦。文章源自JAVA秀-https://www.javaxiu.com/28715.html

所以，如果可能的话，避免在类级变量中存储视图，或者确保在onDestroyView中正确地清理它们。文章源自JAVA秀-https://www.javaxiu.com/28715.html

说到视图 / 数据绑定，Android 的视图绑定文档明确地告诉我们：字段必须被清除以防止泄漏。他们提供的代码片段建议我们做以下工作：文章源自JAVA秀-https://www.javaxiu.com/28715.html

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 可以实现为下面这样：文章源自JAVA秀-https://www.javaxiu.com/28715.html

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 提供了一种简单而干净的方式：文章源自JAVA秀-https://www.javaxiu.com/28715.html

确保在需要绑定时提供绑定文章源自JAVA秀-https://www.javaxiu.com/28715.html
只有在绑定可用时才执行某些代码文章源自JAVA秀-https://www.javaxiu.com/28715.html
自动在onDestroyView上清除绑定文章源自JAVA秀-https://www.javaxiu.com/28715.html

暂时性泄漏文章源自JAVA秀-https://www.javaxiu.com/28715.html

这些泄漏只会存在很短时间。特别是，我们遇到过一个由EditTextView异步任务引起的泄漏。异步任务持续的时间恰好比 LeakCanary 的默认等待时间长，因此，即使内存很快就被正确地释放了，也会报告一个泄漏。文章源自JAVA秀-https://www.javaxiu.com/28715.html

如果你怀疑自己遇到了暂时性泄漏，一个很好的检查方法是使用 Android Studio 的内存分析器。一旦在分析器中启动会话，就可以按步骤重现泄漏，但是在转储堆并检查之前要等待更长时间。经过这段额外的时间后，泄漏可能就消失了。文章源自JAVA秀-https://www.javaxiu.com/28715.html

Dropbox 如何解决 Android App 的内存泄漏问题？文章源自JAVA秀-https://www.javaxiu.com/28715.html