例如，屏幕A显示包含信息的列表。通过单击列表项，应用程序将显示屏幕A1。屏幕A1显示有关先前所选列表项的详细信息。因此，屏幕A1是屏幕A的子屏幕。通过单击后退按钮，应用程序显示屏幕A.
屏幕B还有一个名为B1的子屏幕。其他屏幕是C和D，它们与A和B在同一视图导航层次结构中（但不是A1和B1）。因此，A，B，C和D位于视图导航层次结构的顶部。应用程序将从显示屏幕A开始。在操作栏（或滑动菜单）中，您将找到跳转到屏幕B，C和D的按钮。
我希望你知道我想做什么。通常我会说，每个屏幕都是一个自己的活动。我是片段的忠实粉丝，我通常在任何地方使用它们。事实上，我发现自己实现的活动只包含一个包含主视图布局的片段。而且我可以说这样做绝对没有错（碎片会带来很大的好处......）
但现在我想知道使用单个主要活动并仅更改此活动中的片段是否是个好主意。因此，屏幕A，B，C，D，A1，B1是片段而不是活动。因此，通过从屏幕A导航到C，我只需在主要活动中用片段C替换片段A（而不是启动包含片段C的新活动）。我将实现从屏幕A到子屏幕A1的导航。
到目前为止，我认为这种方法没有任何问题。在我看来，它就像是一个ViewPager，只是没有滑动手势来在屏幕之间导航。
唯一我不确定的事情（这就是我的问题）是内存管理。每当我做一个替换片段事务（片段管理器）从屏幕A导航到B时，片段A应该被销毁，内存应该被垃圾收集（将来的某个地方），对吧？我什么时候实例化片段B？当用户点击按钮导航到B（并重新生成A）？这会带来性能问题（实例化片段的时间）吗？
如果我将所有片段A，B，C，D，A1和B1设置为setRetainInstanceState（true）怎么办？每个屏幕的类成员字段将保留在内存中，直到MainActivity完成为止？
你们中有谁有经验吗？
ViewPage使用某种“预加载”片段并仅加载下一个和上一个片段的视图布局（setOffscreenPageLimit（））
你们认为我必须做类似的事情来避免记忆和表演问题吗？