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

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

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

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

我的哲学是：

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

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

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

专家会告诉你：“当我看到UI时，我会知道是使用活动还是片段”。在一开始，这将没有任何意义，但随着时间的推移，你将能够知道你是否需要Fragment。

我发现有一个很好的做法对我很有帮助。当我试图向女儿解释一些事情时，我突然想到了这一点。

也就是说，想象一个代表屏幕的盒子。你能在这个盒子里再装一个屏幕吗？如果使用新框，是否必须从第一个框复制多个项目？如果答案是Yes，那么您应该使用Fragments，因为根Activity可以保存所有重复的元素，以节省创建它们的时间，并且您可以简单地替换方框的部分。

但别忘了，你总是需要一个盒子容器（Activity），否则你的零件会被分散。所以一个盒子里面有零件。

小心不要误用箱子。Android用户体验专家建议（你可以在YouTube上找到他们），何时我们应该显式加载另一个“活动”，而不是使用“片段”（比如当我们处理有类别的导航抽屉时）。一旦你对碎片感到舒适，你就可以观看他们的所有视频。更重要的是，它们是强制性材料。

你现在能看看你的UI并确定你是否需要一个活动或片段吗？你有新的视角吗？我想你做到了。

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

这比你意识到的要多，你必须记住，启动的活动不会隐式地破坏调用活动。当然，您可以将其设置为用户单击某个按钮转到某个页面，然后启动该页面的活动并销毁当前页面。这会导致大量开销。我能给你最好的指导是：

**只有当主活动和此活动同时打开（考虑多个窗口）才有意义时，才能开始新活动。

Google Drive就是一个很好的例子，它说明了多个活动是有意义的。主要活动提供文件资源管理器。打开文件后，将启动一个新活动来查看该文件。您可以按下最近的应用程序按钮，这将允许您在不关闭打开的文档的情况下返回浏览器，然后甚至可以打开与第一个文档并行的另一个文档。

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

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

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

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

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

在我看来，这并不重要。要考虑的关键因素是

你多久会重复使用一部分UI（例如菜单），该应用程序也适用于平板电脑吗？

碎片的主要用途是构建多路径活动，这使得它非常适合Tablet/Phone响应应用程序。

我使用碎片来获得更好的用户体验。例如，如果您有一个按钮，并且希望在单击它时运行Web服务，我会将一个片段附加到父Activity。

if (id == R.id.forecast) {

    ForecastFragment forecastFragment = new ForecastFragment();
    FragmentManager fm = getSupportFragmentManager();
    FragmentTransaction ft = fm.beginTransaction();
    ft.replace(R.id.main_content, forecastFragment);
    ft.addToBackStack("backstack");
    forecastFragment.setArguments(b);
    ft.commit();
}

这样，用户就不必在其他活动中移动。

其次，我更喜欢碎片，因为你可以在旋转过程中轻松处理它们。

片段相对于活动的一大优势是，用于片段的代码可以用于不同的活动。因此，它提供了应用程序开发中代码的可重用性。

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

这取决于你真正想要构建什么。例如，导航抽屉使用片段。选项卡也使用片段。另一个很好的实现是你有一个列表视图。当您旋转手机并单击一行时，活动将显示在屏幕的另一半。就我个人而言，我使用片段和片段对话框，因为它更专业。此外，它们在旋转时更容易处理。

你可以自由使用其中一个。基本上，你必须评估哪一个对你的应用程序最好。考虑如何管理业务流程以及如何存储/管理数据首选项。

想想碎片是如何存储垃圾数据的。当您实现片段时，您有一个活动根来填充片段。因此，如果你试图用太多的片段实现大量活动，你必须考虑应用程序的性能，因为你在操纵（粗略地说）两个上下文生命周期，记住复杂性。

记住：我应该使用碎片吗？为什么我不应该？

当做

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

来源

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

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

一些错误的想法：

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

事情是这样的！

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

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

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

我希望这会有所帮助。

这个问题需要重新评估，因为Jetpack Compose已经达到稳定。

Jetpack Compose是Android推荐的用于构建本机UI。从…起https://developer.android.com/jetpack/compose

典型的喷气背包组合结构是：单个活动，多个可组合，通过喷气背包导航粘合在一起。注意，不再需要碎片了。

有关示例，请参见Android中的Now。