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