70

关于是否应该使用Activities或有很多讨论Fragments。例如：

我发现的大多数讨论都是在 Android 4.2 之前发布的。
在 Android 4.2 中，Google 发明了嵌套片段。

因此，我实际上没有理由再使用多个Activity.

在早期阶段，Fragments它们应该在应用程序中用于同时以舒适的方式支持平板电脑和智能手机。

因此，例如，您有一个ListView可以View在单击项目时打开详细信息。在智能手机上，我们将替换ListView并显示详细信息View。而平板电脑而不是用详细视图替换列表可以同时显示两者Views。

现在有了嵌套Fragments，还有很多其他的可能性。如果您想使用单个Activity，您可以将一般信息存储在 中，Activity并且每个Fragment人都可以访问它。

除此之外，Fragments已经嵌套Fragments的，还可以为自己的孩子存储信息Fragments。

通过Fragments我可以轻松地重用 . 文件Views，我可以同时显示多个文件，并且可以轻松地Fragment从Fragment. 这一切可能只需要我进行一些复制和粘贴操作。

如果我改用它Activities，我真的必须做很多改变才能完成这项工作。

我最近实现了一个应用程序，我可以轻松地使用两个Fragment-ViewPager来获得真正美丽和动态的东西（某种：今天的信息 - 昨天的信息）。在我看来Fragments，让我们的生活更轻松:)

问题：

  • 为什么我要使用多个Activity？

您能否提供一个很好的例子，其中使用 multiple比使用Activities更有意义Fragments？

  • 有没有什么好例子让你别无选择，只能使用Activities？

我认为大多数更大的框架，如Maps、YouTube和 co 已经支持Fragments。所以我们不必依赖Activities. 如果您使用NavigationBar, TabHosts, ViewPager,也很容易处理。ActionBarFragments

来自优达学城：

为什么不总是创建一个包含大量 Fragment 的 Activity？

  1. 复杂性增加
  2. 更难的意图处理
  3. 难以阅读、维护和测试
  4. 紧耦合的风险
  5. 安全问题
4

5 回答 5

96

首先，我同意你的观点，可以只使用一个活动和嵌套片段来编写一个巨大的应用程序。这就是软件的乐趣——您可以使用多种方法实现相同的功能。对我来说，选择使用多个活动归结为我个人对封装、可重用性和可测试性的偏好。

如果我有一个可以在其他应用程序中重用的小部件，我将其设为 Fragment。例如，我的应用程序具有“与服务器同步”按钮，并且我创建了一个自定义片段，它使用进度条直观地显示同步过程。很容易想象另一个应用程序能够使用这个小部件，所以这就是我将它开发为片段的原因。

如果我在我的应用程序中切换任务，以便新任务在概念上独立于之前的任务，那么我将使用一个新活动。例如，我的应用程序的第一页要求您选择一个用户。一旦您单击了某个用户，我会将您转到该用户的主菜单。用户的这个主菜单显示在一个新的活动中。

现在让我们想象一个大型、复杂的应用程序，以及一个分配开发该应用程序的开发人员团队。如果应用程序可以划分为单独的活动，那么在概念上划分任务非常容易。每个活动都是自己的沙箱，因此并行开发简单且可进行单元测试。当然，如果有任何共同需求，团队仍然应该开发 Fragments 并重用它们。我应该补充一点，代码重用在软件开发中并不经常发生，但如果做得好，应该有很多可重用的片段。

现在假设是时候测试应用程序了。您的测试团队可以将每个活动视为自己的黑匣子。这比依赖于单个活动和大量嵌套片段的单个大型应用程序更容易测试。如果存在错误，这一点尤其重要。如果存在不明显的错误，至少我知道错误的范围仅限于许多活动中的单个活动。

总而言之，我的猜测是您是作为个人开发您的应用程序，因此您的开发决策不会影响其他任何人。如果您正在与更大的团队一起开发应用程序，您的观点可能会改变，我希望我的回答在这方面很有意义。

于 2013-11-19T18:24:46.000 回答
2

你完全正确！

为什么我应该使用多个活动？

您能否提供一个很好的例子来说明使用多个活动而不是使用片段更有意义？

有没有什么好的例子让你别无选择，只能使用活动？

我认为大多数更大的框架，如 Maps、YouTube 等已经支持 Fragments。所以我们不必依赖活动。如果您使用 Fragments，处理 NavigationBar、TabHosts、ViewPager、ActionBar 是否也很容易。

总是使用 Fragments 不利于将数据膨胀到 UI，尤其是在

  • ConnectionTimeOut（或低互联网），因为初始化数据需要很长时间。因此，有时使用每个活动来膨胀少量数据比每个片段更好。

  • 或者为了更灵活地使用方法onActivityResult，使用activity也比。前任。您可以在应用程序中调用FileDialogChooser 。

那是一些情况，

谢谢，

于 2013-11-19T15:10:29.520 回答
2

你说的对。一个人可以单独使用片段做很多事情。但是，根据Activity 类，活动是用户可以做的单一的、有重点的事情。我总是倾向于将我的应用程序划分为顶层的活动，进而划分为片段。

例如，这里有多个活动有意义的情况。如果用户登录，我们的应用程序具有可以扩展的某些功能。但是，用户在登录之前可能仍然使用这个有限的功能。比如说，除非您登录，否则您不能评论项目。在这种情况下，我们的MainActivity 可能会显示整个功能。如果用户想发表评论，我们通过保存他的请求并启动一个活动 LoginActivity 来要求他登录，该活动处理登录/注册并在他完成后设置正确的结果。在我们调用的 Fragment 或 Activity 中，我们检查结果是否为 LOGIN_SUCCESS 或者用户当前是否已登录并为待处理的请求提供服务。我想说的是，登录的动作流程应该是一个单独的活动。否则，处理可能会一团糟。这样，任何需要登录的操作都可以调用 startActivityForResult(LOGIN) 并将其自身保存为 pendingAction。然后在设置结果之后我们可以在super.onActivityResult中实现处理。当然，这都是理论上的，可以毫无问题地在片段中实现登录。但是，代码肯定会变成 FUed。

您需要 Activity 的另一种情况是您的 Activity 提供导出的服务。例如，假设您是“文件上传器”的开发人员，并且您收到上传文件的意图。在这种情况下创建一个可以消费上传文件请求的Activity是非常方便的。

然而，随着当前的更新，Fragments 的功能涵盖了 Android 应用程序的大部分功能，因此可以单独与单个主机活动一起使用，以满足应用程序的要求。

但是，您的整个“单个活动主机”与数据存在相当薄弱的防御。活动和密切片段具有包括通过包保存/恢复实例的整个生命周期。单个宿主活动可以持续很长时间，并承载多个片段，这些片段可能在其活动的单个生命周期内被多次回收。因此，随着时间的推移，拥有所有这些实例的活动很可能会超出其资源预算。当数据在多个对象之间真正共享时，开发人员有责任将数据保存在共享上下文中。这是这种方法的一个缺点。在我们的示例中，MainActivity 消耗额外的数据字节是没有意义的，因为它托管了登录片段，而它本来可以休眠并在需要时释放其内存。

最后，一个好的程序员也可以设法完成同样的任务。

于 2013-11-19T13:26:38.370 回答
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

在这个应用程序中，抽屉位于 Main Fragment Activity 中，每个菜单都会更改内容片段。内容片段中的列表视图根据意图更改活动上下文并进入另一个活动。

最后，在某些情况下，我认为您应该使用更多的片段活动......但这是我的工作模式，也许您可​​以找到一种技巧/方式或范围来仅使用 Activity 和片段来做某事。

于 2013-11-12T11:32:22.407 回答
0

我知道我为时已晚，但 Square 对碎片有意见。以下是文章的要点：

片段：经验教训

尽管有缺点，但片段教会了我们宝贵的经验教训，我们现在可以在编写应用程序时重新应用：

  • 单一 Activity 接口：无需为每个屏幕使用一个 Activity。我们可以将我们的应用程序拆分为解耦的小部件，然后随意组装它们。这使得动画和生命周期变得容易。我们可以将小部件拆分为视图代码和控制器代码。
  • backstack 不是特定于活动的概念。您可以在活动中实现回栈。
  • 不需要新的 API；我们需要的一切从一开始就在那里：活动、视图和布局充气器。

您不必使用多个活动，也不必使用片段。您可以将自定义视图与他们的演示者一起使用。

你可以在这里阅读：https ://corner.squareup.com/2014/10/advocating-against-android-fragments.html 。

你也可以在这里找到 Square 的迫击炮库：https ://github.com/square/mortar

于 2016-06-14T01:53:17.270 回答