android - 使用许多 fragment 是一种不好的做法吗？

Question

我有一个应用程序，假设有 15 个不同的部分。我使用带有 FrameLayout 的单个 Activity，其中我使用 NavigationDrawer 加载 15 个不同的 fragment 。我在加载滑动选项卡布局的几个父 fragment 下也有子 fragment 。

所以，简而言之，我的应用程序中有很多 fragment 。

问题是，如果我在添加到 FrameLayout 的同时将 fragment 添加到 BackStack，只要我的应用程序存在， fragment 就永远不会被销毁(只有 View 被销毁，这是设计的预期行为)。更糟糕的是，如果用户一直将鼠标悬停在不同的 Fragment 上，BackStack 的大小会不断增加，这可能会导致内存问题。

所以，我开始谷歌搜索并在 SO 中找到了几个线程，其中一些 suggests against using Fragments at all .但是，如果我想使用自己的 Activity 来设计每个部分，我必须将 NavDrawer 添加到每个 Activity(或至少将这些 Activity 扩展到基本 Activity)，我不确定这是否谨慎。

剩下的问题是，在单个 Activity 中包含大量 fragment 是否是一个好的设计？如果没问题，我应该将 fragment 添加到 BackStack 中吗？如果我应该，内存问题怎么办？最后，是否有人在不同的 Activity 中尝试过 NavigationDrawer？有效率吗？

我对一系列问题表示歉意。

编辑:根据目前的回复，我想澄清一下，我知道这是一个通用问题，可能会导致基于不同意见的回复。所以，我想明确表示，我不是在寻找任何决定性的答案(因为可能没有)，而是我想展开讨论以听取不同的观点。

Answer 1

这是一个非常普遍的问题。

使用 Fragments 是经过良好测试的 Android 模式。它们为您提供了一个方便的、小规模的 View Controller ，具有完全托管的生命周期。这很整洁。

但 Fragments 并不总是适合这项工作的工具。

我的经验法则是:每当我需要管理复杂 View 的生命周期、 fragment 动画以及需要非全屏 Activity 时，我都会使用 fragment 。

如果你发现自己有很多 fragment ，那么问问自己你能做什么abstract or generalise .例如:大多数列表 Fragment 看起来和执行起来都是一样的，每一行可能不应该在它自己的 Fragment 中实现。

恕我直言，backstack 是一个UX 工具。它需要以一种在您的应用程序的业务逻辑中有意义的方式进行管理。它是一种允许您的用户自然地浏览您的应用程序的工具。因此，在堆栈中推送超过 4 或 5 个 fragment 是没有意义的，因为您不应该期望用户记住 5 个导航决定。如果您发现自己处于大型后台堆栈情况，您可能需要重新考虑您的用户体验设计。