我有一个应用程序，有15个不同的部分。我使用一个带有FrameLayout的Activity，我使用NavigationDrawer加载15个不同的Fragment。我还在少数父片段下面有子片段，我加载了滑动Tab布局。
因此，简而言之，我的应用程序中有很多碎片。
问题是，如果我在添加到FrameLayout时将片段添加到BackStack，只要我的应用程序存在，片段就不会被破坏（只有View被破坏，这是设计的预期行为）。更糟糕的是，如果用户继续悬停到不同的片段，BackStack的大小会不断增加，这可能会导致内存问题。
所以，我开始谷歌搜索并在SO中找到了几个suggests against using Fragments at all的线程。但是如果我想使用自己的Activity设计每个部分，我必须将NavDrawer添加到每个活动（或者至少将这些活动扩展到基础活动），我不确定是否谨慎。
这就留下了一个问题，在一个活动中拥有大量片段是一个好的设计吗？如果没问题，我应该将碎片添加到BackStack吗？如果我应该，那么内存问题呢？最后，有没有人在不同的活动中尝试过NavigationDrawer？它有效吗？
我为一系列问题道歉。
编辑：根据目前为止的回复，我想澄清一点，我知道这是一般性问题，可以产生不同的基于意见的回复。所以，我想说清楚，我不是在寻找任何决定性的答案（因为可能没有任何答案），而是我想开展讨论，听取不同的观点。
答案 0 :(得分：1)
这是一个非常普遍的问题。
使用Fragments是经过良好测试的Android模式。它们为您提供了一个方便的小型View Controller，具有完全托管的生命周期。那很好。
但碎片并不总是适合这项工作的工具。
我的经验法则是：无论何时我需要管理复杂的View生命周期，Fragment动画以及每当我需要一个非全屏的Activity时，我都会使用Fragments。
如果你发现自己有很多碎片，那么问问自己你能做什么abstract or generalise。例如：大多数列表片段看起来和执行相同，并且每行可能不应该在它自己的片段中实现。
背靠背是恕我直言， UX 工具。它需要以在应用程序的业务逻辑中有意义的方式进行管理。它是一个允许用户自然导航您的应用程序的工具。因此，在堆栈中推送超过4或5个碎片是没有意义的，因为您不应该期望用户记住5个导航决策。如果您发现自己处于大型后台堆叠状态，您可能需要重新考虑您的UX设计。