最近，我开始开发一个应用程序，该应用程序具有一个主要 Activity 和多个子 fragment ，这些 fragment 在单个容器中交换进出。
我的问题很简单:是否建议通过调用 getActivity().getSupportFragmentManager().beginTransaction().replaceFragment()...让每个 Fragment 切换到 UI 流中的下一个 fragment...，或者每个 Fragment 是否应该定义一个由主 Activity 实现的接口(interface)并让主 Activity 处理应用程序的导航？
fragment 管理 Activity 的优点
在 fragment 不依赖于单个特定 Activity 并且可以交换进出任意布局的意义上更易于维护。
UI 导航代码集中在一个类中。
fragment 管理 Activity 的缺点
Activity 将不得不实现大量的接口(interface)，使代码变得困惑。必须有比实现 15 个接口(interface)更好的方法，这些接口(interface)都表明 fragment 已完成并准备好进入 UI 的下一阶段。
如果其他人阅读代码，UI 导航就不会那么直观。考虑一个包含名为 A、B 和 C 的三个 fragment 的示例，并假设 fragment A 在某个 Action 上移动到 B，而 B 在某个 Action 上移动到 C。如果每个 fragment 都必须通过中间接口(interface)才能移动到下一个 fragment ，则此流的方向并不明显。
我想出的一个解决方案是拥有一个包含每个 fragment 回调的单一接口(interface)，从而消除对大量单独接口(interface)的需求。不过，我仍然觉得有更好的方法。
最佳答案
这个问题很有趣，我认为没有完美的答案，这取决于很多因素。但根据我的经验:
我尝试主要将 Activity 用作“ Controller ”，而 fragment 代表“ View ”。所以最好让 Activity 来处理导航。这有助于保持模块化并让生活更轻松，例如，当您想要创建平板电脑版本(将几个 fragment 组合在一个页面上)或更改应用程序的流程时。
但是，正如您在“缺点”部分所说，这会导致 Activity 中出现大量代码。如果您的应用中只有一个包含 15 个 fragment 的 Activity，那么 Activity 代码的可读性就不会很好。
所以 - 尝试对您的 fragment 进行分组，并为每个组设置一个 Activity 。例如，您可能有几个屏幕用于“查看用户配置文件”和“编辑用户配置文件”——每个屏幕都可以是 UserActivity 中的一个 fragment 。然后，您可能有一个用于 StoreDetailsFragment 和 StoreMapFragment 的 Activity ，以及另一个用于购买流程的 Activity 。
基本上，在我的书中，Activity 类中的代码最少是一件好事 - 如果某些 Activity 只包含一个 fragment ，我对此没有意见。
关于android - 管理 fragment 到 fragment 的导航，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/25395787/