我们最近将应用程序从基于多个活动的应用程序转换为具有多个片段的单个活动的应用程序。成为Fragments的活动过去常常包含片段，因此我们使用子片段管理器来托管片段中的片段（我应该添加的这些子片段很小，一次可以在屏幕上有4或5个片段）。
这引起了一些问题，即必须创建并跟踪片段持有者的唯一ID。 （这会在处理Backstack以及任何类型的AdapterViews时引起令人头疼的问题。）
我们正在考虑重写这些组件以扩展某种ViewGroup，可能是FrameLayout或LinearLayout。在某些情况下我们已经这样做了，但是我想知道这样做是否有任何不利之处？（我必须承认，我真的没有看到什么大不了的事关于碎片......你可以用碎片做任何事情，你可以通过创建自定义视图来做。这是错误的吗？）。
答案 0 :(得分：2)
这是一个相反的答案，解释片段使用。通常，您可以使用Activities执行大多数操作，但由于SDK支持片段，因此许多事情将变得更加繁琐（ViewPager是片段使用非常好的示例）。
片段的优点：代码封装，可重用的UI块。
片段的缺点：更多代码（例如FragmentManager，FragmentTransaction）。
你对活动的最初使用是好的，这不是我会切换到片段的情况。
假设我设计了一个包含两个活动的手机应用程序：ContactList和ContactDetails。到目前为止这么好，没有理由使用碎片了。如果我想支持更大的设备，我可以并排显示两个屏幕。这就是片段派上用场的地方。关于如何构建您的活动/片段，这里有一些很好的建议：
https://developer.android.com/guide/practices/tablets-and-handsets.html#Fragments
以下是重点：
多个片段，一个活动：
使用一项活动而不论其中 设备大小，但在运行时决定是否组合片段 布局（创建多窗格设计）或交换片段（创建 单窗格设计）。
或......
多个片段，多个活动：
在平板电脑上，将多个片段放在一个活动中;在手机上， 使用单独的活动来托管每个片段。例如，当 平板电脑设计在活动中使用两个片段，使用相同的活动 对于手机，但提供另一种布局，其中包括 第一个片段。在手机上运行时，您需要切换 片段（例如当用户选择项目时），启动另一个片段 承载第二个片段的活动。
。
您选择的方法 取决于您的设计和个人喜好。第一种选择（一种 活动;交换片段）要求您确定屏幕 运行时的大小，并动态添加每个片段 适当 - 而不是在活动的XML中声明片段 布局 - 因为你不能从活动中删除一个片段 已在XML布局中声明。使用第一种技术时，你 可能还需要每次更新片段时更新操作栏 根据可用的操作或导航模式进行更改 对于每个片段。在某些情况下，这些因素可能不会影响您的 设计，所以使用一个活动和交换片段可能会很好 （特别是如果您的平板电脑设计要求您添加片段 无论如何动态）。但是，其他时候，动态交换 手机设计的碎片可能会使您的代码更复杂， 因为你必须管理所有的片段组合 活动的代码（而不是使用替代布局资源） 定义片段组合）并管理片段的后栈 你自己（而不是允许正常的活动堆栈处理 背导航）。