最近，我开始研究一个具有一个主要活动和几个子片段的应用程序，这些子片段可以交换进一个容器中。
我的问题很简单：是否建议让每个Fragment通过调用getActivity().getSupportFragmentManager().beginTransaction().replaceFragment()...切换到UI流程中的下一个片段，或者每个Fragment是否应定义主要活动实现的接口并让主活动处理应用程序的导航？
活动管理碎片的优点
在片段不依赖于单个特定活动并且可以交换进出任意布局的意义上更易于维护。
UI导航代码集中在一个类中。
管理碎片的活动缺点
Activity必须实现大量的接口，使代码变得混乱。必须有一种比实现15个接口更好的方法，这些接口都表明片段已经完成并准备好移动到UI的下一个阶段。
如果其他人读取代码，则UI导航不那么直观。考虑一个带有三个片段A，B和C的例子，并假设片段A在某个动作上移动到B，B在某个动作上移动到C.如果每个片段必须通过中间接口才能移动到下一个片段，则此流程的方向不明显。
我提出的一个解决方案是拥有一个包含每个片段回调的接口，无需大量单独的接口。不过，我仍然觉得有更好的办法。
答案 0 :(得分：1)
有趣的问题我不认为有一个完美的答案，这取决于很多事情。但根据我的经验：
我尝试主要将活动用作“控制器”，而片段代表“视图”。所以最好让活动处理导航。这有助于保持模块化并使生活更轻松，例如您想要创建平板电脑版本（在一个页面上将几个片段组合在一起），或者更改应用程序的流程。
但是，正如您在“cons”部分中所说，这导致了Activity中的大量代码。如果您的应用中只有一个活动包含15个片段，则活动代码不会非常易读。
所以 - 尝试对片段进行分组，并为每个组分配一个Activity。例如，您可能有几个屏幕来“查看用户配置文件”和“编辑用户配置文件” - 这些屏幕中的每一个都可能是UserActivity中的一个片段。那么你可能有一个Activity表示StoreDetailsFragment和StoreMapFragment，另一个Activity表示购买流程。
基本上，在我的书中使用Activity类中的最少代码是一件好事 - 如果某些活动只包含一个片段，我就可以了。
答案 1 :(得分：0)
我写了一个项目，可以让Fragment to Fragment Navigation变得容易：
答案 2 :(得分：0)
我在Kotlin中创建了用于片段导航的库。可以使用堆栈或寻呼机或两者。用法非常简单。经过测试并在生产代码中使用。文档尚未准备好，但您可以在设备上运行示例项目并查看代码。