困境：何时使用碎片与活动：

我知道Activities被设计为代表我的应用程序的单个屏幕，而Fragments被设计为可重用的UI布局，其中嵌入了逻辑。

直到不久前，我开发了一个应用程序，因为它说应该开发它们。我创建了一个“活动”来表示我的应用程序的屏幕，并将碎片用于ViewPager或谷歌地图。我很少创建可以多次重用的ListFragment或其他UI。

最近，我偶然发现一个项目只包含两个活动，一个是SettingsActivity，另一个是MainActivity。MainActivity的布局中填充了许多隐藏的全屏UI片段，仅显示一个。在“活动”逻辑中，应用程序的不同屏幕之间有许多FragmentTransition。

我喜欢这种方法的地方是，因为应用程序使用了ActionBar，所以它保持不变，不会随着屏幕切换动画而移动，这就是“活动切换”所发生的情况。这使屏幕转换更加流畅。

所以我想我要问的是分享你当前关于这个主题的开发方式，我知道这看起来可能是一个基于观点的问题，但我将其视为一个Android设计和架构问题。。。并不是一个真正基于观点的人。

更新（2014年5月1日）：以下是来自Square的Eric Burke的演示（我不得不说，这是一个很棒的演示，为android开发人员提供了很多有用的工具。我与Square没有任何关系）

http://www.infoq.com/presentations/Android-Design/

根据过去几个月的个人经验，我发现构建应用程序的最佳方法是创建一组片段，这些片段代表应用程序中的一个流，并在一个活动中呈现所有这些片段。因此，基本上，应用程序中的活动数与流数相同。这样，动作栏在所有流的屏幕上保持不变，但在更改流时会重新创建，这非常有意义。正如埃里克·伯克（Eric Burke）所说，正如我所认识到的那样，使用尽可能少的活动的哲学并不适用于所有情况，因为它在他所谓的“上帝”活动中造成了混乱。

当前回答

好吧，根据谷歌的讲座（也许在这里，我不记得了），你应该考虑尽可能使用碎片，因为它使你的代码更容易维护和控制。

然而，我认为在某些情况下，它可能变得过于复杂，因为承载片段的活动需要在它们之间导航/通信。

我认为你应该自己决定什么最适合你。将活动转换为片段通常并不难，反之亦然。

如果你想进一步阅读，我已经在这里创建了一篇关于这个dillema的帖子。

2013-11-30 22:16:37

其他回答

我做的事情：尽可能减少碎片。不幸的是，这几乎是可能的。所以，我最终得到了很多片段和一些活动。我意识到了一些缺点：

ActionBar&Menu：当2个片段具有不同的标题、菜单时很难处理。示例：当添加新片段时，您可以更改动作栏标题，但当从后台弹出时，无法恢复旧标题。在这个例子中，您可能需要在每个片段中都有一个工具栏，但相信我，这将花费您更多的时间。当我们需要startForResult时，活动有，但片段没有。默认情况下没有过渡动画

我的解决方案是使用“活动”将片段包装在里面。所以我们有单独的动作栏、菜单、startActivityForResult、动画，。。。

2015-11-18 03:01:36

在我看来，这并不重要。要考虑的关键因素是

你多久会重复使用一部分UI（例如菜单），该应用程序也适用于平板电脑吗？

碎片的主要用途是构建多路径活动，这使得它非常适合Tablet/Phone响应应用程序。

2016-03-12 22:41:40

我使用碎片来获得更好的用户体验。例如，如果您有一个按钮，并且希望在单击它时运行Web服务，我会将一个片段附加到父Activity。

if (id == R.id.forecast) {

    ForecastFragment forecastFragment = new ForecastFragment();
    FragmentManager fm = getSupportFragmentManager();
    FragmentTransaction ft = fm.beginTransaction();
    ft.replace(R.id.main_content, forecastFragment);
    ft.addToBackStack("backstack");
    forecastFragment.setArguments(b);
    ft.commit();
}

这样，用户就不必在其他活动中移动。

其次，我更喜欢碎片，因为你可以在旋转过程中轻松处理它们。

2016-05-29 08:37:48

好吧，根据谷歌的讲座（也许在这里，我不记得了），你应该考虑尽可能使用碎片，因为它使你的代码更容易维护和控制。

然而，我认为在某些情况下，它可能变得过于复杂，因为承载片段的活动需要在它们之间导航/通信。

我认为你应该自己决定什么最适合你。将活动转换为片段通常并不难，反之亦然。

如果你想进一步阅读，我已经在这里创建了一篇关于这个dillema的帖子。

2013-11-30 22:16:37

你可以自由使用其中一个。基本上，你必须评估哪一个对你的应用程序最好。考虑如何管理业务流程以及如何存储/管理数据首选项。

想想碎片是如何存储垃圾数据的。当您实现片段时，您有一个活动根来填充片段。因此，如果你试图用太多的片段实现大量活动，你必须考虑应用程序的性能，因为你在操纵（粗略地说）两个上下文生命周期，记住复杂性。

记住：我应该使用碎片吗？为什么我不应该？

当做