为什么要使用片段？ [复制]

Question

使用Fragments 与使用在不同布局中重复使用的自定义Views 相比有什么优势？

在original blog post introducing fragments，Dianne Hackborn 说

[Fragments] 让开发人员更容易编写可扩展的应用程序 跨越各种屏幕尺寸，超越现有设施 在平台上可用。

她继续在为应用程序制作平板电脑布局的上下文中解释片段，该应用程序结合了来自同一应用的手机版本的两个活动的 UI。

但似乎使用自定义视图可以实现相同的重用。片段和视图之间的主要区别似乎是它们具有不同的生命周期......

Fragment 生命周期是：

onAttach(), onCreate(), onCreateView(), onActivityCreated(), onStart(), onResume(), onPause(), onStop(), onDestroyView(), onDestroy(), onDestroy(). >

View 生命周期是：

ctor、onFinishInflate()、onAttachedToWindow()、onMeasure()、onLayout()、onDetatchedFromWindow()

我想听听有编写大型应用程序经验的开发人员介绍他们在使用 Fragment 与自定义 View 将 UI 划分为可重用的部分时看到了哪些好处（如果有的话）。

Answer 1

主要原因是片段比自定义视图更可重用。

有时，您无法仅依靠视图来创建完全封装的 UI 组件。这是因为有些东西你想放入你的视图但不能，因为只有 Activity 可以处理它们，从而迫使 Activity 和视图之间紧密耦合。

这是一个这样的例子。假设您想要创建一个可重用的 UI 组件，其中包括想要捕捉照片并用它做一些事情。传统上，您会触发一个启动相机并返回捕获的图像的意图。

请注意，您的自定义 UI 组件无法完全封装此功能，因为它必须依赖托管 Activity 的 startActivityForResult，因为视图不接受 Activity 结果（它们可以通过上下文间接触发 Intent )。

现在，如果您想在不同的活动中重用您的自定义 UI 组件，您将重复 Activity.startActivityForResult 的代码。

另一方面，片段干净地解决了这个问题。

同样，您的片段可以为您的选项菜单添加项目，传统上只有 Activity 才能做到这一点。如果您的自定义视图的状态决定了菜单中的内容，这可能很重要。

Answer 2

片段不仅仅是一个视图。事实上，它甚至可以完全没有视图。它可以包含各种各样的东西，包括 AsyncTasks、各种监听器、文件和数据库访问等等。

可以将其视为一项小型活动，但您可以在屏幕上显示多个活动并与它们一起工作，包括在它们可见时相互交流。

例如您可以在一个片段中显示购物车列表，并在另一个片段中详细显示当前选择的购物车。你然后例如在详细视图中更改项目的数量，可以通知列表视图并更新列表视图中的总价。您可以完全协调这样的交互，同时例如在较小的屏幕设备上仍然只有其中一个可见。

我已经将一个大型商业应用（>15 个活动）从活动重构为片段，以获得良好的平板电脑支持，我绝不会在没有片段的情况下启动新应用。

2016 年 2 月更新：尽管上述情况仍然成立，但片段的复杂性导致许多人完全避免使用它们。较新的模式（例如使用 MVC 方法和更强大的视图）提供了替代方案。正如他们所说.. YMMV。

Answer 3

一些描述：

把 Activity 想象成一个盛着一个大蛋糕的盘子。 Fragment 是一个将同一个蛋糕切成小块的容器。 每个切片都包含它自己的逻辑（侦听器等）。 总的来说，它们与一个大蛋糕几乎没有什么不同。

好处：

1. 当你盘子不能容纳一个大蛋糕。 （屏幕很小）您可以轻松地使用几个盘子（活动）来容纳每个盘子，而无需将您的逻辑移动到新活动中。

2. 更好的可重用性。我有一些实例可以在另一个应用程序中完全重用一个片段。您可能会声称自定义视图也可以做到这一点。但是参考第 1 点，我可以通过更改几行布局来重用它，但是对于自定义视图，它必须找到一种方法将其插入到布局和代码中。

3. 从某种意义上说，这是一种在 Android 编程中组织 UI 逻辑的更面向对象的方式。当你有一个特性（例如屏幕上的一个新分区）时，你创建一个新的 Fragment 类，对现有的活动类进行少量修改。但是，如果您只使用活动进行编程，则需要添加逻辑并对测试类进行较大的修改。

只有我的 2 美分。 :)

Answer 4

生命周期方法可能是您最大的提示。如果您考虑一下，它们与活动生命周期密切相关（在活动和视图中有一些挂钩）。事实上，在您链接的文章中，Hackborn 说：

在某些方面，您可以将 Fragment 视为迷你 Activity

与软件设计/开发中的许多事情一样，做事情的方法有很多种。您可以在许多不同的地方放置您的代码。是的，您可能可以在视图中投入很多内容，但是将不同的关注点放在不同的类中是一件好事。这方面的经典模式是 MVC，它适用于这种情况。您不想在视图中加入太多控制器逻辑。最好将它保存在类似控制器的类中，这些类是活动，现在是片段。这就是为什么 Fragment 的生命周期更像是 Activity 而不是视图的生命周期——它是为了促进这种组织。

Answer 5

我曾经接触过 Fragments，发现它们不是很有用（参见 this post）。根据我的阅读，片段实际上是一个可以访问活动上下文的对象的花哨词。我喜欢在我的工作中忽略片段，而自己创建这些对象。通过将Activity 传递给构造函数，而不是Context，我创建了非常大、要求非常高的应用程序。然而，使用 Fragments 的一个主要好处是 View 布局系统支持它们 - 因此您可以轻松地将它们添加到 Android xml（如果您将其用于布局）。

Answer 6

自定义视图比仅使用片段代替活动要多得多。如果您决定使用活动和自定义视图，则必须创建自定义视图，然后必须在活动中实现相同的活动生命周期方法（片段使用非常相似的生命周期）。

使用 Fragments 还可以让您将组件分离到它们自己的类（Fragments）中，而不是在单个 Activity 中包含过多的逻辑。让我举个例子：

假设您正在实现一个杂志阅读器应用程序。使用片段，您可以创建一个片段：ArticleList，它显示文章列表，另一个片段：ArticleDisplay，它处理显示内容的逻辑。然后，您可以使用片段工具指定这些片段应如何交互，以便在手机上，您可以使用全屏显示 ArticleDisplay，而在平板电脑上，您可以并排显示片段。

如果您要尝试使用 Activity/自定义视图进行此操作，则您的整体 Activity 中的两个片段都有逻辑，您必须编写自定义视图，并且必须调试这个笨重的怪物.

通常，片段是编写应用程序的一种更复杂、更强大的方式。他们可以做 Activity 可以做的所有事情，甚至更多。如果您不需要额外的功能，默认设置可能会让您到达您需要去的地方，并且工作量更少。