我做的事情：尽可能减少碎片。不幸的是，这几乎是可能的。所以，我最终得到了很多片段和一些活动。我意识到了一些缺点：

ActionBar&Menu：当2个片段具有不同的标题、菜单时很难处理。示例：当添加新片段时，您可以更改动作栏标题，但当从后台弹出时，无法恢复旧标题。在这个例子中，您可能需要在每个片段中都有一个工具栏，但相信我，这将花费您更多的时间。当我们需要startForResult时，活动有，但片段没有。默认情况下没有过渡动画

我的解决方案是使用“活动”将片段包装在里面。所以我们有单独的动作栏、菜单、startActivityForResult、动画，。。。

每个应用程序使用一个活动为片段提供基础使用片段进行筛选，与活性物质相比，碎片的重量较轻碎片可重复使用碎片更适合同时支持手机和平板电脑的应用程序

自Jetpack以来，Single Activity应用程序是首选的架构。特别适用于导航体系结构组件。

来源

不要忘记，活动是应用程序的块/组件，可以通过Intent共享和启动！因此，应用程序中的每个活动只能解决一种任务。如果您的应用程序中只有一个任务，那么我认为您只需要一个活动和多个片段（如果需要）。当然，您可以在解决其他任务的未来活动中重用片段。这种方法将明确和合乎逻辑地分离任务。您不需要为不同的片段集维护一个具有不同意图过滤器参数的活动。您可以根据需求在开发过程的设计阶段定义任务。

为什么我在所有情况下都喜欢片段而不是活动。

活动费用高昂。在Fragment中，视图和属性状态是分开的——每当片段处于后台时，其视图都将被销毁。因此，您可以堆叠比“活动”多得多的碎片。回钉操作。使用FragmentManager，可以很容易地清除所有碎片，插入更多的碎片等。但对于Activity来说，操纵这些东西将是一场噩梦。可预测的生命周期。只要不回收主机“活动”。背景中的碎片不会被回收。因此，可以使用FragmentManager:：getFragments（）查找特定的Fragment（不鼓励）。

我的哲学是：

只有在绝对需要时才创建活动。由于后端堆栈可用于提交一堆碎片事务，我尝试在应用程序中创建尽可能少的活动。此外，不同片段之间的通信比在活动之间来回发送数据要容易得多。

活动转换很昂贵，对吧？至少我这么认为——因为旧活动必须被销毁/暂停/停止，推到堆栈上，然后新活动必须被创建/启动/恢复。

自从引入片段以来，这就是我的哲学。