写点什么

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

  • 2021-05-24
  • 本文字数:4802 字

    阅读完需:约 16 分钟

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

本文最初发布于 Dropbox 技术博客,经原作者授权由 InfoQ 中文站翻译并分享。


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

常见例子

引用长期运行的服务



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 和其他问题一样,最好是能经常测试,在糟糕的模式扎根代码库之前尽早修复。


作为一名开发人员,你一定要记住,虽然内存泄漏并不总是会影响应用性能,但低端机型和手机内存小的用户会感激你为他们所做的工作。


原文链接:


https://dropbox.tech/mobile/detecting-memory-leaks-in-android-applications?fileGuid=dg5RuSiDPDkmicBU

2021-05-24 16:591580
用户头像

发布了 596 篇内容, 共 294.2 次阅读, 收获喜欢 1382 次。

关注

评论

发布
暂无评论
发现更多内容

第1周 架构方法-作业

SuGeek

第二周作业

Griffenliu

架构师训练营 - 作业 - 第六周

Max2012

架构师训练营 W02 作业

Geek_f06ede

架构师训练

前端不得不懂的架构知识(上)

执鸢者

架构 大前端

架构师训练营第六周课后练习

薛凯

Double Kill!! 数据联邦修炼之路

脑极体

架构师训练营第二期 - 第二周作业

john_zhang

极客大学架构师训练营

渣渣2本学历CRUD一年半,决定改变现状,努力学习两个月成功拿到美团30k offer

Java架构之路

Java 程序员 架构 面试 编程语言

架构师训练营第二周作业

邢永春

第五周作业

icydolphin

极客大学架构师训练营

第六周

等燕归

架构作业 -- CAP原理

Nick~毓

怎么样让自己的博客被谷歌和百度收录!

java金融

百度 SEO 博客收录 谷歌收录

RabbitMQ之路由和通配符模式,附源码注释讲解

小Q

Java 学习 架构 面试 RabbitMQ

第六周作业

alpha

极客大学架构师训练营

架构师训练营第二周学习总结

邢永春

第二周总结

Griffenliu

Week2 - 框架设计

evildracula

学习 架构

第六周总结

alpha

极客大学架构师训练营

十八般武艺玩转GaussDB(DWS)性能调优(二):坏味道SQL识别

华为云开发者联盟

数据库 sql 性能调优 GaussDB 算子

全网首发,做第一人纯源码讲解RabbitMQ实践,收藏吧

小Q

Java 学习 架构 面试 RabbitMQ

架构师训练营 W02 总结

Geek_f06ede

架构师训练

数据库JDBC:Statement查询

正向成长

JDBC sql查询 SQL光标

一个90后码农的真实经历,希望大家可以不留遗憾;

Java架构师迁哥

LeetCode题解:78. 子集,迭代,JavaScript,详细注释

Lee Chen

算法 大前端 LeetCode

阿里五位MySQL封神大佬耗17个月总结出53章性能优化法则

996小迁

Java MySQL 大数据 架构 面试

云小课|云数据库RDS实例连接失败了?送你7大妙招轻松应对

华为云开发者联盟

数据库 网络 ssl RDS实例 端口

【Java】变量声明在循环体内还是循环体外你选哪一个咧?

java金融

Java 变量声明

架构师训练营 1 期第 6 周:技术选型(二) - 作业

piercebn

极客大学架构师训练营

【分布式事务】面试官问我:MySQL中的XA事务崩溃了如何恢复??

冰河

MySQL 分布式事务 一致性 XA

Dropbox 如何解决Android App的内存泄漏问题?_前端_Lily Chen_InfoQ精选文章