分割或不分割碎片反对活动。 为什么我应该使用多个Activity？
关于是否应该使用Activities或Fragments有很多讨论。 例如：
- 要片段的还是-不以片段
- 一个活动和所有其他碎片
- 多less活动与碎片
- 在Android应用程序中使用Activity或Fragment
我发现的大部分讨论都是在Android 4.2之前发布的。
随着Android 4.2谷歌发明嵌套片段 。
因此，我实际上没有看到任何理由使用多个Activity 。
在Fragments的早期阶段，他们应该被用在应用程序中，同时以舒适的方式支持平板电脑和智能手机 。
因此，例如，你有一个ListView可以打开一个细节View点击一个项目。 在智能手机上，我们将replaceListView并显示详细的View 。 而平板电脑而不是用细节视图replace列表可以同时显示两个Views 。
现在嵌套的Fragments有很多其他的可能性。 如果你想使用一个单一的Activity ，你可以将一般信息存储在Activity ，每个Fragment都可以访问它。
除此之外，嵌套Fragments也可以为孩子的Fragments存储信息。
通过Fragments我可以轻松地重新使用Views ，可以同时显示多个Fragment ，并且可以轻松地形成一个Fragment的对话框。 这一切可能只是一些复制和粘贴操作。
如果我使用“ Activities则必须改变很多才能完成。
我最近实现了一个应用程序 ，我可以轻松地使用两个Fragment-ViewPager使事情变得非常漂亮和dynamic（某种：今天的信息 – 昨天的信息）。 在我看来， Fragments让我们的生活更轻松:)
问题：
- 为什么我应该使用多个
Activity？
你能提供一个很好的例子，其中多个Activities的使用更有意义，而不是使用Fragments ？
- 有什么好的例子，你没有别的select，只能使用
Activities？
我认为大多数更大的框架，如地图 ， YouTube和公司已经支持Fragments 。 所以我们不必依赖Activities 。 在使用Fragments情况下，处理NavigationBar ， TabHosts ， ViewPager ， ActionBar也很容易。
从Udacity：
为什么不总是创build一个有很多碎片的活动？
- 复杂性增加
- 更难的意图处理
- 难以阅读，维护和testing
- 紧密耦合的风险
- 安全问题
首先，我会同意你的看法，只用一个活动和嵌套片段就可以编写一个庞大的应用程序。 这是软件的乐趣 – 您可以使用各种方法实现相同的function。 对我而言，使用多种活动的select取决于我个人对封装，可重用性和可testing性的偏好。
如果我有一个可以在其他应用程序中重用的小部件，我将它作为一个片段。 例如，我的应用程序具有“与服务器同步”button，我创build了一个使用进度条直观显示同步过程的自定义片段。 很容易想象另一个应用程序能够使用这个小部件，所以这就是为什么我开发它作为一个片段。
如果我在应用程序内切换任务，使得新任务在概念上独立于以前的任务，那么我使用新的任务。 例如，我的应用程序的第一页要求您select一个用户。 一旦你点击了一个用户，我会把你发送到该用户的主菜单。 这个用户的主菜单显示在一个新的活动中。
现在让我们想象一个庞大而复杂的应用程序，以及一个被分配开发该应用程序的开发者团队。 如果应用程序可以分成不同的活动，那么在任务划分上在概念上就非常容易。 每个活动都是自己的沙盒，所以并行开发很简单，可以unit testing。 如果有共同的需求，当然，团队仍然应该开发碎片并重用它们。 我应该补充说，在软件开发中，代码重用不会经常发生，但是如果正确的话，应该有很多可重用的碎片。
现在假设是testing应用程序的时候了。 您的testing团队可以将每个活动视为自己的黑匣子。 这比单个巨大的应用程序更容易testing，它依赖于单个活动和大量的嵌套片段。 如果存在错误，这一点尤其重要。 如果存在一个不明显的错误，至less我知道这个错误的范围仅限于一个单独的活动。
总之，我的猜测是，你正在开发你的应用程序作为一个个人，因此你的发展决定不会影响其他人。 如果你正在开发一个更大的团队的应用程序，你的观点可能会改变，我希望我的回答在这方面有很大的意义。
你是对的。 人们可以单独做很多的片段。 但是，根据Activity类 ，一个活动是一个单一的，用户可以做的事情。 我总是倾向于将我的应用程序划分为顶层的活动，并进一步划分为片段。
例如，这是一个多个活动有意义的情况。 我们的应用程序有一定的function，如果用户login，可以扩展。但是，用户在login之前可能仍然会使用这个有限的function。比方说，除了login以外，你不能评论项目。在这种情况下，我们MainActivity可能会显示整个function。 如果用户想要评论，我们要求他通过保存他的请求并启动一个处理login/注册的活动LoginActivity来login，并在完成时设置正确的结果。 在我们的调用Fragment或Activity中，我们检查结果是否为LOGIN_SUCCESS或用户当前是否login并提供未决请求。 我想说的是，Login的行动stream程应该是一个单独的活动。 否则，处理可能会搞砸了。 这样，任何需要login的操作都可以调用startActivityForResult（LOGIN）并将其自身保存为一个pendingAction。 然后在设置结果后，我们可以在super.onActivityResult中实现处理。 这当然都是理论上的，可以毫不费力地在一个片段中实现Login。 但是，代码肯定会变成FUed。
您需要一个活动的另一个情况是当您的活动提供了一个导出的服务。 例如，假设您是“file upload器”的开发人员，并且您收到上传文件的意图。 在这种情况下创build一个可以使用上传文件请求的Activity非常方便。
然而，就目前的更新而言，Fragments的function涵盖了android应用程序的大部分function，因此可以单独使用一个主机活动来满足应用程序的要求。
但是，你的整个“一个单一的活动主机”与数据有相当弱的防守。 活动和紧密片段有整个生命周期，包括通过捆绑包的保存/恢复实例。 单个宿主的活动可以持续很长时间，并且宿主多个可能在其活动的一生中被多次回收的片段。 因此，随着时间的推移，所有这些事件都会超过资源预算。 当数据真正在多个对象之间共享时，开发人员有责任将数据保存在共享的上下文中。 这是这种方法的一个缺点。 在我们的例子中，MainActivity消耗额外的数据字节是没有意义的，因为它在宿主睡眠时托pipe了Login碎片，并且在需要的时候释放了它的内存。
最后，一个好的程序员可以设法做同样的任务。
你是完全正确的！
为什么我应该使用多个Activity？
你能提供一个很好的例子，其中多个活动的使用更有意义，而不是使用碎片？
有什么好的例子，你没有别的select，只能使用活动？
我认为大多数更大的框架，如地图，YouTube和公司已经支持碎片。 所以我们不必依赖活动。 在使用Fragments的情况下，处理NavigationBar，TabHosts，ViewPager，ActionBar也很容易。
总是使用Fragments不利于向UI扩展数据，特别是在这种情况下
-
ConnectionTimeOut （或低互联网），因为它花了很多时间来初始化数据。 所以，有时使用每个活动来膨胀一些数据比每个片段都要好。
-
或者为了更灵活的使用onActivityResult方法，使用活动也比。 防爆。 您可以在您的应用程序中调用FileDialogChooser 。
那是一些情况，
谢谢，
对于你的问题，我只能说，有时，复杂的用户体验或复杂的应用程序，必须使用不同的硬件组件，你需要使用活动，而不是片段。
例如，如果您必须创build具有某种forms的应用程序，才能拍摄照片，然后将此照片用于某些使用内存的工作难记忆任务（例如人脸检测），则需要将此任务与主要任务活动，并个性化清单上的权限，以便仅在此活动中使用更多的内存。
另一个例子是，如果你想使用弱内存活动（在清单中，你可以设置属性来清除活动堆栈，并在活动结束时强制垃圾收集器清理内存）
需要使用更多活动和片段的最可能情况是应用程序的用户体验。 如果您需要包含菜单的右侧抽屉自定义，并且菜单的每个片段都包含一个listView，并且每个列表视图都必须详细说明。 您可以执行很多技巧来隐藏右侧抽屉，并创buildanimation以从片段滑动到细节，但最好和最简单的方法是为细节创build一个新的活动，并使用主要的单独逻辑/生命周期对其进行pipe理与抽屉活动。 我已经在我的两个应用程序中做了这个select：
iMeal – https://play.google.com/store/apps/details?id=it.fullsix.chiccopappe
GGRugby – https://play.google.com/store/apps/details?id=it.f6.template
在这个应用程序的抽屉是在主片段活动，每个菜单改变内容片段。 内容片段中的列表视图用intent更改活动上下文，并进入另一个活动。
最后有一些情况，我认为你应该更多的只有一个fragmentActivity工作…但这是我的工作模式，可能你可以find一个技巧/方式或范围做一些只有一个活动和片段。
我知道我为此太迟了，但Square的片断有意见。 这里是文章的要点：
碎片：经验教训
尽pipe他们有缺点，片段教给我们宝贵的教训，我们现在可以在编写应用程序时重新应用：
- 单一活动界面：不需要为每个屏幕使用一个活动。 我们可以将我们的应用程序拆分成小部件，然后按照我们的要求进行组装。 这使得animation和生命周期变得简单。 我们可以将我们的小部件分解成视图代码和控制器代码。
- 后台不是一个活动的具体概念; 你可以在一个活动中实现一个后台堆栈。
- 不需要新的API; 我们所需要的一切都是从一开始就有的：活动，视图和布局充气器。
您不必使用多个活动，也不必使用片段。 您可以使用自定义视图与演示者。
你可以在这里阅读： https ： //corner.squareup.com/2014/10/advocating-against-android-fragments.html 。
您也可以在这里findSquare的砂浆库： https ： //github.com/square/mortar
