关于您是否应该使用Activities或Fragments，有很多讨论。
例如：
我发现的大多数讨论都是在Android 4.2之前发布的 在Android 4.2中，Google发明了nested Fragments。
因此，我实际上看不出任何理由使用多个Activity。
在Fragments的早期阶段，它们应该在应用中用于同时以舒适的方式支持平板电脑和智能手机。
例如，您有一个ListView可以在点击某个项目时打开详细信息View。在智能手机上，我们会替换ListView并显示详细的View。而平板电脑而非使用详细信息视图替换列表可以同时显示Views。
现在有了嵌套的Fragments，还有很多其他的可能性。如果您想使用单个Activity，则可以将常规信息存储在Activity中，并且每个Fragment都可以访问它。
除此之外，嵌套Fragments的{{1}}还可以存储其子Fragments的信息。
使用Fragments我可以轻松地重复使用Fragments，我可以同时显示多个Views，我可以轻松地从Fragment形成一个对话框。这一切都需要我可能不仅仅是一些副本＆amp;粘贴动作。
如果我使用Fragment，我认真地必须改变很多才能完成这项工作。
我最近实现了一个应用程序，我可以轻松地使用两个Activities来获得非常漂亮和动态的东西（某种：今天的信息 - 昨天的信息）。
在我看来Fragment-ViewPager让我们的生活变得更轻松:)
问题：
Fragments？ 您是否可以提供使用多个Activity更有意义而不是使用Activities的任何好例子？
Fragments之外，您有什么选择吗？ 我认为大多数较大的框架，如地图， YouTube 和co已经支持Activities。所以我们不必依赖Fragments。
如果您使用Activities，处理NavigationBar，TabHosts，ViewPager，ActionBar也很容易。
来自Udacity：
为什么不总是创建一个包含大量片段的活动？
答案 0 :(得分：95)
首先，我同意你的意见，只使用一个活动和嵌套片段就可以编写一个巨大的应用程序。这就是软件的乐趣 - 您可以使用各种方法实现相同的功能。对我而言，使用多种活动的选择取决于我个人对封装，可重用性和可测试性的偏好。
如果我有一个可以在其他应用程序中重用的小部件，我会将其设为片段。例如，我的应用程序具有“与服务器同步”按钮，我创建了一个自定义片段，使用进度条可视地显示同步过程。很容易想象另一个应用程序能够使用这个小部件，这就是我将它作为片段开发的原因。
如果我在我的应用程序中切换任务，以便新任务在概念上独立于之前的任务，那么我使用新活动。例如，我的应用程序的第一页要求您选择一个用户。点击用户后，我会将您转到该用户的主菜单。用户的此主菜单显示在新活动中。
现在让我们想象一个庞大而复杂的应用程序，以及一个分配开发该应用程序的开发团队。如果应用程序可以分为单独的活动，则在概念上很容易划分任务。每个活动都是自己的沙箱，因此并行开发很简单，可以进行单元测试。如果有任何共同的需求，团队当然应该开发Fragments并重用它们。我应该补充一点，代码重用在软件开发中并不常见，但如果做得好，应该有很多可重用的片段。
现在假设是时候测试应用了。您的测试团队可以将每个活动视为自己的黑匣子。这比依赖单个活动和大量嵌套片段的单个巨大应用程序更容易测试。如果存在错误，这一点尤为重要。如果存在一个不明显的错误，至少我知道错误的范围仅限于许多错误。
总之，我的猜测是您正在开发个人应用程序，因此您的开发决策不会影响任何其他人。如果您正在开发一个拥有更大团队的应用程序，您的观点可能会发生变化，我希望我的回答在这方面有很大意义。
答案 1 :(得分：2)
你是对的。人们可以单独使用碎片。但是，根据Activity class，活动是用户可以做的一件重点事情。我总是倾向于将我的应用程序划分为顶级活动，并进一步划分为片段。
例如，这是多个活动有意义的情况。我们的应用程序具有某些功能，可以在用户登录时进行扩展。但是，用户可能在登录前仍然使用此有限的功能。比如说，除非您已登录，否则无法对项目发表评论。在这种情况下，我们的MainActivity可能会显示整个功能。如果用户想要评论，我们要求他登录，保存他的请求并启动一个处理登录/注册的活动LoginActivity，并在完成后设置正确的结果。在我们的调用Fragment或Activity中，我们检查结果是否为LOGIN_SUCCESS，或者用户当前是否已登录并提供待处理请求。我想说的是Login的操作流程应该是一个单独的活动。否则，处理可能会搞砸。这样，任何需要登录的操作都可以调用startActivityForResult（LOGIN）并将自己保存为pendingAction。然后在设置结果之后我们可以在super.onActivityResult中实现处理。这当然是理论上的，可以毫不费力地在片段中实现Login。但是，代码肯定会变成FUed。
您需要活动的另一种情况是您的活动提供导出的服务。例如，假设您是“文件上传器”的开发者，并且您收到上传文件的意图。在这种情况下，创建一个可以消耗上传文件请求的Activity非常方便。
然而，通过当前的更新，Fragments的功能涵盖了Android应用程序的大部分功能，因此可以单独使用单个主机活动来满足应用程序的要求。
然而，你的整个“单一活动主持人”的数据相当弱。活动和密切碎片具有整个生命周期，包括通过捆绑包的保存/恢复实例。单个主机活动可以是持久的并且托管多个片段，这些片段可以在其活动的单个生命周期中多次回收。因此，随着时间的推移，持有所有这些实例的活动极有可能超过其资源预算。当开发人员真正在多个对象之间共享数据时，开发人员有责任将数据保存在共享上下文中。这是这种方法的缺点。在我们的示例中，MainActivity消耗额外的数据字节是没有意义的，因为它可以在需要时睡眠并释放其内存时托管Login片段。
最后，一个优秀的程序员可以设法同样完成同样的任务。
答案 2 :(得分：2)
你完全正确！
为什么我要使用多个活动？
您是否可以提供使用多个活动更有意义而不是使用碎片的任何好例子？
是否有任何好的例子，除了使用活动之外别无选择？
我认为像Maps，YouTube和co这样的大型框架已经支持Fragments。所以我们不必依赖活动。如果你使用Fragments，也可以很容易地处理NavigationBar，TabHosts，ViewPager，ActionBar。
始终使用Fragments不利于将数据扩展到UI，尤其是在
的情况下ConnectionTimeOut （或低互联网），因为初始化数据需要很长时间。 因此，有时使用每个活动来膨胀少量数据比每个片段更好。
或者使用方法 onActivityResult 更灵活，使用活动也比使用更好。 实施例。您可以在申请表中致电FileDialogChooser。
在某些情况下，
谢谢，
答案 3 :(得分：1)
对于您的问题，我只能说有时候，使用复杂的用户体验或必须使用不同硬件组件的复杂应用程序，您需要使用活动而不是片段。
例如，如果您必须创建一个具有某个表单的应用程序，该表单具有拍摄照片的步骤，然后将此照片用于使用内存的一些工作硬记忆任务（例如，面部检测），则需要将此任务分开从主任务活动和个性化清单上的权限，以便仅对此活动使用更多内存。
另一个例子是如果你想使用弱内存活动（在清单中你可以设置清除活动堆栈的属性，并强制垃圾收集器在活动完成时清理内存）
最需要使用更多活动和片段的情况是应用程序的用户体验。如果您需要一个包含菜单的右抽屉定制，并且菜单的每个片段都包含一个listView，并且每个列表视图都必须详细说明。您可以做很多技巧来隐藏正确的抽屉并创建动画以从片段滑动到细节，但最好和最简单的方法是为细节创建一个新活动并使用与主要单独的逻辑/生命周期进行管理抽屉活动。我在两个应用程序中选择了这个：
iMeal - https://play.google.com/store/apps/details?id=it.fullsix.chiccopappe
GGRugby - https://play.google.com/store/apps/details?id=it.f6.template
在这个应用程序中，Drawer位于Main Fragment Activity中，每个菜单都会更改内容片段。 内容片段中的列表视图更改了具有intent的活动上下文并进入另一个活动。
最后有一些情况，我认为你应该使用更多只有一个fragmentActivity ...但这是我的工作模式，可能你可以找到一个技巧/方式或范围只做一个活动和片段
答案 4 :(得分：0)
我知道我为此已经太迟了但是Square对片段有了意见。以下是文章的要点：
片段：经验教训
尽管存在缺点，片段教会了我们宝贵的课程，我们现在可以在编写应用时重新申请：
- 单一活动界面：不需要为每个屏幕使用一个活动。我们可以将我们的应用程序拆分为分离的小部件，并按照我们的要求组装它们。这使动画和生命周期变得容易。我们可以将我们的小部件拆分为视图代码和控制器代码。
- 靠背堆不是特定于活动的概念;你可以在活动中实现一个后台。
- 不需要新的API;我们所需要的一切从一开始就是：活动，视图和布局充气。
您不必使用多个活动，也不必使用碎片。您可以将自定义视图与其演示者一起使用。
您可以在此处阅读：https://corner.squareup.com/2014/10/advocating-against-android-fragments.html。
你也可以在这里找到Square的迫击炮库：https://github.com/square/mortar