这个问题在这里已有答案：
使用 Fragment s比使用在不同布局中重用的自定义 View 有什么好处？
在original blog post introducing fragments中，Dianne Hackborn说
[Fragments]使开发人员可以更轻松地编写可扩展到各种屏幕大小的应用程序，超出平台中已有的功能 .
她继续在为应用程序制作平板电脑布局的背景下解释片段，该应用程序结合了同一应用程序的电话版本中两个活动的UI .
但似乎可以使用自定义视图实现相同的重用 . 碎片和视图之间的主要区别似乎是它们具有不同的生命周期......
Fragment 生命周期是：
onAttach() ， onCreate() ，_ onCreateView() ， onActivityCreated() ，_ 987760， onResume() ， onPause() ，_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
View 生命周期是：
ctor ， onFinishInflate() ， onAttachedToWindow() ， onMeasure() ， onLayout() ， onDetatchedFromWindow()
我想听听开发人员在编写大型应用程序方面的经验，这些应用程序讲述了他们在使用Fragments和自定义视图时将UI划分为可重用部分的好处（如果有的话） .
6 回答
主要原因是 fragments are more reusable than custom views.
有时，您无法仅依靠视图创建完全封装的UI组件 . 这是因为有些东西你想放在你的视图中但不能，因为只有一个Activity可以处理它们，从而迫使Activity和View之间紧密耦合 .
这是一个这样的例子 . 假设您想创建一个可重用的UI组件，在许多方面，它想要捕获照片并使用它执行某些操作 . 传统上，您会触发启动相机的意图并返回捕获的图像 .
请注意，您的自定义UI组件可以't fully encapsulate this functionality because it will have to rely on hosting Activity' s startActivityForResult 因为视图不接受活动结果（它们可以通过上下文间接触发意图） .
现在，如果您想在不同的活动中重用自定义UI组件，那么您将重复Activity.startActivityForResult的代码 .
另一方面片段干净地解决了这个问题 .
同样，您的片段可以为您的选项菜单提供项目，传统上只有活动可以做 . 如果您的自定义视图的状态指示菜单中的内容，这可能很重要 .
片段不仅仅是一个视图 . 事实上，它甚至可以完全没有视野 . 它可以包含各种各样的东西，包括AsyncTasks，各种监听器，文件和数据库访问等等 .
可以把它想象成一个小活动，但你可以在屏幕上有多个它们，并与它们一起工作，包括在它们可见时相互通信 .
例如 . 您可以在一个片段中显示购物车列表，在另一个片段中详细显示当前选定的购物车 . 你那么，例如更改详细视图中项目的数量，可以通知列表视图，并在列表视图中更新总价格 . 你可以完全协调这样的交互，例如仍然只有一个在较小的屏幕设备上可见 .
我已经重构了一个大型业务应用程序（> 15个活动），从活动到片段，以获得良好的平板电脑支持，我永远不会开始没有片段的新应用程序 .
Update Feb 2016 ：虽然上述情况仍然适用，但片段的复杂性导致许多人完全避免使用它们 . 较新的模式，如MVC方法的使用和更强大的视图提供了替代方案 . 正如他们所说.. YMMV .
一些描述：
想象活动作为一个盛有一块大蛋糕的盘子 . 片段将是将相同的蛋糕切成片的容器 . 每个切片都包含自己的逻辑（侦听器等） . 总的来说，它们与一个大蛋糕几乎没有什么不同 .
好处：
当你盘子不能抱一个大蛋糕 . （屏幕很小）您可以轻松使用几个板（活动）来保存每个板，而无需将逻辑移动到新活动中 .
更好的可重用性 . 我有一些实例可以在另一个App中完全重用一个片段 . 您可能声称自定义视图也可以这样做 . 但是参考第1点，我只需要几行布局更改就可以重复使用它，但是对于自定义视图，它必须找到一种方法将它插入布局和代码中 .
在某种意义上，它是在Android编程中组织UI逻辑的更多OO方式 . 当您具有某个功能（例如，屏幕上的新分区）时，您将创建一个新的Fragment类，并对现有活动类进行少量修改 . 但是，如果您只使用活动进行编程，则需要添加逻辑并对测试类进行大修改 .
只需2美分 . :)
生命周期方法可能是您最大的暗示 . 如果你考虑一下，它们会与活动生命周期紧密相关（有一些与活动和视图挂钩） . 在事实上，在你链接的文章中，哈克伯恩说：
与软件设计/开发中的许多事情一样，有很多方法可以做 . 您可以将许多不同的地方放在代码中 . 是的，你可能会在视图中投入很多，但是在不同的类中保持不同的关注是一件好事 . 这种经典模式是MVC，它适用于这种情况 . 您不希望在视图中烘焙太多控制器逻辑 . 最好将它保存在类似控制器的类中，这些类是活动，现在是片段 . 这就是为什么片段的生命周期更像是活动而不是视图 - 它是为了促进这种组织 .
自定义视图比使用片段代替您的活动要多得多 . 如果您决定使用“活动”和“自定义视图”，则必须创建自定义视图，然后必须在活动中实现相同的活动生命周期方法（片段使用非常相似的生命周期） .
使用Fragments还允许您将组件分离到它们自己的类（Fragments）中，而不是在单个Activity中具有太多逻辑 . 让我以一个例子为基础：
假设您正在实施杂志阅读器应用程序 . 使用片段，您可以创建一个片段：ArticleList，它显示一个文章列表，另一个片段：ArticleDisplay，它处理显示内容的逻辑 . 然后，您可以使用片段工具指定这些片段应如何交互，这样在手机上，您可以使用ArticleDisplay的全屏空间，而在平板电脑上，您可以并排显示片段 .
如果您使用活动/自定义视图尝试此操作，您将在单片活动中拥有两个片段的逻辑，您必须编写自定义视图，并且您必须调试这个笨重的怪物 .
通常，片段是编写应用程序的更复杂和强大的方式 . 他们可以完成活动可以做的所有事情，甚至更多 . 如果您不需要额外的功能，默认设置可能会让您到达需要的地方，而且工作量更少 .
我曾经碰过Fragments，发现它们不是很有用（见this post） . 从我所读到的， A Fragment is really a fancy word for an Object with access to Activity Context . 我喜欢忽略我工作中的碎片，只是自己创建这些对象 . 我通过将
Activity传递给构造函数而不是Context来创建非常大，非常苛刻的应用程序 . 但是，使用Fragments的一个主要好处是View布局系统支持它们 - 因此您可以轻松地将它们添加到Android xml（如果您将它用于布局） .