我正在将使用仪表板模式的 Android 应用程序升级到滑动菜单，并带有jfeinstein 的库。
最初我有一个 DashboardActivity，它有 6 个按钮，每个按钮都可以在点击时启动相应的 Activity。我还有大约 30 项其他活动可以从这些“顶级”活动开始。
现在，我有两种可能的方法：
在查看滑动菜单库的示例时，我认为这可能是最好的方法，因为它使用了切换片段，但我仍然认为 Activity 比片段更适合屏幕。
是否有任何理由对内容使用单个活动和片段？
（改编自互联网和 Glenn Bech 对 SO 的回答）
片段是 Android 创建可重用用户界面的解决方案。您可以使用活动和布局（例如使用包含）来实现一些相同的目的。然而; 片段从 HoneyComb 和更高版本连接到 Android API。
由于 Activity 是主要组件，因此它有很多额外的责任。就像提供上下文等。如果没有这些额外的职责，片段是轻量级的，并且因为你有很多片段而特别有益（当活动被重构为片段时）。我有没有提到它们是轻量级的？
操作栏。如果您希望在那里的选项卡导航您的应用程序，您很快就会看到 ActionBar.TabListener 推断为您提供了 FragmentTransaction 作为 onTabSelected 方法的输入参数。您可能会忽略这一点，并做一些其他聪明的事情，但是您将针对 API 工作，而不是使用它。
FragmentManager 以一种非常聪明的方式为您处理“返回”。Back 并不意味着回到上一个活动，就像常规活动一样。这意味着回到之前的片段状态。这更令人敬畏（是的，它是一个词），因为您可以控制何时以及如何使用 backstack。
你认为好莱坞的所有效果都来自哪里，嗯？您可以使用酷炫的 ViewPager 和 FragentPagerAdapter 来创建滑动界面。FragmentPagerAdapter 代码比常规适配器更简洁，它控制各个片段的实例化。您可以应用到片段的过渡和滑动动画是一些您不能用活动做的事情。
更大的手机？不，它是平板电脑。如果您在尝试为手机和平板电脑创建应用程序时使用 Fragments，您的生活会轻松很多。由于这些片段与 Honeycomb+ API 紧密相关，因此您也希望在手机上使用它们以重用代码。这就是兼容性库派上用场的地方。
您甚至可以并且应该将片段用于仅适用于手机的应用程序。如果您考虑到便携性。我使用 ActionBarSherlock 和兼容性库来创建“看起来像 ICS”的应用程序，这些应用程序在 1.6 版中看起来都一样。您将获得最新的功能，如操作栏、选项卡、溢出、拆分操作栏、viewpager 等。
在 Fragment 之间进行通信的最佳方式是 Intent。当您按下 Fragemnt 中的某个东西时，您通常会调用 StartActivity() 并在其上包含数据。意图将传递给您启动的活动的所有片段。这更容易。
我仍然认为 Activity 比 Fragment 更适合屏幕。
在我看来不是。我承认处理这么多片段可能会有点复杂，但使用片段有其优势。
您可以利用多窗格布局模式使您的应用对平板电脑用户更友好。现在您提到，您的 6 个活动也正在调用其他活动。也许可以通过并排使用多个屏幕（片段）来减少用户在屏幕上单击的次数（如前所述；多窗格布局）。我不知道您的应用程序是关于什么的，但我可以想象，用户必须从列表中选择一些东西，您将根据他决定选择的内容将他重定向到另一个 Activity。在平板电脑上，您可以只使用两个片段并在一个屏幕上显示内容（无需启动新屏幕），而您可以选择只显示一个手机设备上的片段（您可以通过使用动态和静态片段以及使用 layout-sw600 等文件夹来完成所有这些操作）。如果您决定这样做，您将保持良好的用户流并利用平板电脑的屏幕空间。这将使您的应用程序灵活和动态。
以此为参考：
如果您在整个应用程序中选择多个活动而不是使用片段，那么您将需要为所有活动提供 SlidingMenu，因为用户（作为用户自言自语）希望在应用程序中的任何地方使用 SlidingMenu。这将是一个糟糕的用户体验，如果用户必须“向上” Activity backstack，只是为了使用 SlidingMenu。这肯定会破坏用户流量。因此，您必须在每个 Activity 中重新实现菜单。当然，您可以通过创建一个基本 Activity 来做到这一点，但是只使用一个 Activity 并让该 Activity 处理这个问题要容易得多。
我暂时想不出其他优势。但我敢肯定还有很多其他的。
伙计们，我一直在阅读所有的帖子，我认为你很好。一项活动（有许多片段）与多项活动。
一个充满碎片的主要活动不是很好。相信我，如果您的项目有很多屏幕，活动转换、生命周期、片段之间的通信可能会变得一团糟。您可以共享侧边菜单，这是有意这样做的。
另一方面，每个屏幕类型有一个活动，没有片段是另一个问题。您必须为每个活动创建一个侧面菜单。当然，使用基类似乎很容易，但您还必须每次都恢复菜单的状态。
我们目前对这个问题的解决方案是迁移将活动数量减少到最少，并尽可能多地使用碎片。我们会将共享某些功能的片段分组到活动中。当我们引入适当的平板电脑支持时，我们肯定需要使用片段。
最后一条评论。我设法反编译了 googlePlay 商店并查看了层次结构。我真的很好奇它的内部组织。我真的以为谷歌人只会使用一个主要活动和里面的几个片段->错误。他们还使用许多活动。
结论：我们不应该成为极端分子。我认为只有一项活动只适用于小型项目或简单的导航层次结构。同时，使用过多的活动会使导航变得一团糟。