2024年Android最全收藏。Dropbox 是如何解决 Android App 的内存泄漏问题的？，2024年最新面试字节跳动的Android工程师该怎么准备

最新推荐文章于 2024-08-14 03:30:11 发布

2401_84538278

最新推荐文章于 2024-08-14 03:30:11 发布

阅读量779

点赞数 10

分类专栏：程序员文章标签： android 面试学习

本文链接：https://blog.csdn.net/2401_84538278/article/details/138832061

版权

程序员专栏收录该内容

213 篇文章 0 订阅

订阅专栏

最后

在这里我和身边一些朋友特意整理了一份快速进阶为Android高级工程师的系统且全面的学习资料。涵盖了Android初级——Android高级架构师进阶必备的一些学习技能。

附上：我们之前因为秋招收集的二十套一二线互联网公司Android面试真题（含BAT、小米、华为、美团、滴滴）和我自己整理Android复习笔记（包含Android基础知识点、Android扩展知识点、Android源码解析、设计模式汇总、Gradle知识点、常见算法题汇总。）

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

│ ↓ 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 {

var binding: B?

// Only valid between onCreateView and onDestroyView.

fun requireBinding() = checkNotNull(binding)

fun requireBinding(lambda: (B) -> Unit) {

binding?.let {

lambda(it)

}}

/**