几乎总是使用碎片。如果你知道你正在构建的应用程序仍然很小，那么使用碎片所付出的额外努力可能不值得，因此可以忽略它们。对于更大的应用程序，引入的复杂性被提供的灵活性所抵消，从而更容易证明在项目中使用它们是合理的。有些人非常反对碎片及其生命周期带来的额外复杂性，因此他们从不在项目中使用它们。这种方法的一个问题是，Android中有几个API依赖于片段，例如ViewPager和Jetpack导航库。如果你需要在应用程序中使用这些选项，那么你必须使用片段来获得它们的好处。

节选自：克里斯汀·马西卡诺。《Android编程：大Nerd牧场指南》，第4版，苹果图书。

一些错误的想法：

始终在应用程序中放置一个活动，并使用片段处理不同的屏幕。直接在活动中编写UI代码。通过片段处理屏幕之间的导航（我不是指选项卡，我是指例如全屏视图）。活动可以被碎片替换。

事情是这样的！

片段旨在实现UI的可重用部分，并在应用程序的任何需要的部分中使用它们。它们不是为替代活动而设计的。

我们什么时候必须使用它们？

当我们有一个独立的屏幕，其中有一些不同的UI部分（选项卡、可扩展屏幕、部分屏幕等）时，我们应该使用带有一些片段的活动在同一屏幕中分别实现和处理不同的UI部件。应用程序的每个独立部分实际上是一个概念上不同于其他部分的组件，它需要有一个独立的活动。例如，登录部分可能包含一些不同的场景，如使用用户名密码或使用指纹。每个场景都可以由一个片段实现，所有与登录相关的片段都应该由LoginActivity处理。但例如，应用程序中的订单部分与登录没有概念关系，因此它必须具有不同的活动，当然，它可能包含一些片段，如OrdersFragment、SubmitNewOrderFragment等，所有这些片段都必须由OrdersActivity管理。不要在活动中直接实现UI。始终在片段中实现UI，并在活动中添加这些片段，即使该活动中只有一个片段。它可以帮助您拥有更多可重用的代码，并更容易地更改UI。不要使用片段在应用程序中无限导航，即使您强制用户在后堆栈中有有限数量的片段。事实上，当您将一个新片段添加到后堆栈中并将其移除时，除非父活动被破坏并且它只是不可见，否则它不会从内存中移除。因此，当您使用片段管理器后堆栈时，通过在同一活动中的片段之间多次导航（尤其是在每次导航中创建一个新片段并将其放入后堆栈的情况下），您将在应用程序中获得OutOfMemoryException。

我希望这会有所帮助。

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

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

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

几乎总是使用碎片。如果你知道你正在构建的应用程序仍然很小，那么使用碎片所付出的额外努力可能不值得，因此可以忽略它们。对于更大的应用程序，引入的复杂性被提供的灵活性所抵消，从而更容易证明在项目中使用它们是合理的。有些人非常反对碎片及其生命周期带来的额外复杂性，因此他们从不在项目中使用它们。这种方法的一个问题是，Android中有几个API依赖于片段，例如ViewPager和Jetpack导航库。如果你需要在应用程序中使用这些选项，那么你必须使用片段来获得它们的好处。

节选自：克里斯汀·马西卡诺。《Android编程：大Nerd牧场指南》，第4版，苹果图书。

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

来源

好吧，根据谷歌的讲座（也许在这里，我不记得了），你应该考虑尽可能使用碎片，因为它使你的代码更容易维护和控制。

然而，我认为在某些情况下，它可能变得过于复杂，因为承载片段的活动需要在它们之间导航/通信。

我认为你应该自己决定什么最适合你。将活动转换为片段通常并不难，反之亦然。

如果你想进一步阅读，我已经在这里创建了一篇关于这个dillema的帖子。