（提前为冗长的答案表示歉意）
我认为没有什么可以阻止你这样做。
话虽如此，我如何看待活动是一个可以定义当前过渡的整个 UI 屏幕应如何显示的地方：它应包含哪些片段以及这些片段应如何并排放置，更重要的是，应用程序流程有效。
我的活动中的片段应该一起构成一个有意义的屏幕，具有我期望的功能并且应该可重复使用，但它们不应该知道其他片段的存在。这就是活动的工作。事实上，我强烈遵守这样的规则：一个片段永远不应该知道另一个片段的存在（尽管现在您可以将片段包含在片段中，这有点违背了这一点）。如果我需要转换到一组完全不同的用例，我更喜欢使用活动来处理转换以及要使用的新布局和片段集。
我必须这样做吗？不。我可以在一个主要活动中完成这一切，并自己完成这些“准活动片段”之间的转换，但是当已经有一个框架可以为我完成这件事时，我为什么要这样做呢？使用意图来初始化活动（转换）比手动编写自己的引擎要简单得多，也更干净，该引擎可以跟踪所有片段的状态并决定启动哪些片段以及删除哪些片段。
同样，使用活动中的内置功能处理不同的方向和设备尺寸比您自己处理更容易，但同样，没有什么可以阻止您这样做。
在一个例子中更容易解释这一点：
想象一下这个用例：我需要编写一个显示歌曲和电影列表的应用程序。当我单击其中一首歌曲时，它应该打开一个媒体播放器并在单独的屏幕中播放，当我单击一部电影时，它应该打开一个视频播放器并播放视频。这里有明显的过渡：从主列表到音频播放器或视频播放器并返回。
仅使用一个活动和 3 个片段来执行此操作，我必须用适当的媒体播放器片段（视频/音频）替换列表片段，并在用户单击列表项时自行删除列表片段（以保留内存） 。这一切都很好而且很容易做到，但是如果我还必须添加一种向歌曲/电影添加评论的方法会发生什么？现在我必须修改我的主要（也是唯一）活动，以了解如果有人正在播放歌曲并单击评论按钮的行为，我需要再次转换到另一个片段并允许该片段捕获/显示评论。
正如您可能想象的那样，每次添加新功能时，我都必须修改我的主要活动来处理转换，因为片段并不意味着彼此了解并且意味着彼此独立。
如果我只有一个活动，我最终要做的就是创建一个 God 类（我的主要活动），其中定义了我的应用程序的整个流程。随着应用程序变得复杂，维护这个流程也会变得越来越复杂。同样，这是按照具有独立片段的原则进行的。如果你不关心你的片段彼此了解，那是完全不同的，但在我看来，你做错了:)
我将如何使用活动来做到这一点？我仍然会有 3 个碎片，但也会有3 个活动，其唯一作用是维持与其他活动之间的转换并定义应使用哪个片段。从列表活动到歌曲活动之间的转换是一个简单的意图，并且释放内存是为我完成的。现在，如果歌曲活动需要转换为评论活动，那么这只是歌曲活动到评论活动的另一个意图。我根本不必更改列表活动，事实上，列表活动永远不会知道此评论活动的存在。
我知道这是一个非常简单的示例，但随着您的应用程序变得越来越复杂，并且随着您添加越来越多的用例，您会发现拥有多个活动是有意义的。您不想自己维护片段之间的转换，否则您最终会得到一个非常复杂的框架，该框架将慢慢变得难以维护。
根据屏幕的方向和大小，相同的逻辑将适用于具有不同的片段/布局。同样，无论如何，您可以在唯一的活动中自己处理这些问题，但问题是：为什么？
