重写 Activity 或 Fragment 的生命周期方法与向其生命周期对象添加 LifecycleObserver 有什么区别？

Question

我正在阅读developer.android文档（本页）并遇到这样一段话：“不要重写Activity或Fragments中的onResume等生命周期方法。请使用LifecycleObserver。如果应用程序需要在生命周期达到某个特定值时执行工作Lifecycle.State，使用repeatOnLifecycle API。”

我的问题是，重写 Activity 或 Fragment 的生命周期方法与向其生命周期对象添加 LifecycleObserver 之间有什么区别？

是为了让代码更干净、更好还是有一些与性能相关的原因或防止错误和错误等等？

Answer 1

我都用过，它们的工作原理相似。根据我的经验，回调更可靠，有时 onResume 应该在 Activity 或 Fragment 中时却没有被调用。

这也是一个官方网站推荐所以不需要但根据Android，请在有选择时优先选择它。在 Activity.onResume 中，您可以选择 super.onResume 的顺序和代码中的一些回调，这可能会导致一些错误，包括当前状态。

回调的控制较少，但事情是一致的，比如状态。此外，回调可以拥有自己独立的事物和方法，将代码保存在单独的类中，从而使某些代码不那么复杂。您可以通过回调将代码与多个事物重用，但对于 Activity 或 Fragment 则较少。覆盖较旧，但可以在较旧的设备上使用，X E。

Answer 2

从某种意义上说，它们的工作原理相似。至少这是我通过挖掘一些文章和文档发现的。

我总是在我的活动中重写我的生命周期方法，我必须告诉我这对我来说根本不是问题。但正如我发现的，我一直做错了，有点。

我不想听起来很菜鸟，但我不是专家。我只是喜欢读书。因此，让我分享一下我通过搜索到目前为止对差异的理解。

它们根本没有太大区别。使用

LifecycleObserver

而不是覆盖，可以促进“更好的分离”关注点并提高代码的可维护性。简而言之，它们会让你的代码变得混乱。 提高可维护性是什么意思？好吧，提高代码的可维护性会给您带来好处，例如处理

更少的错误

，将生命周期相关逻辑与UI组件分离，更好的测试等。高效的代码，快乐的编码员。 因此总之，我们

应该

避免直接在我们的活动或片段中使用旧的生命周期方法，因为它们会使您的代码难以维护。这些更新的技术可以促进我们的 Android 应用程序更好的组织并减少出现错误的可能性。 希望这些信息对您有用。