Question

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

直到不久前，我开发了一个应用程序，因为它说应该开发它们。我创建了一个Activity来表示我的应用程序的屏幕，并使用了ViewPager或Google Maps的片段。我很少创建一个ListFragment或其他可以多次重复使用的UI。

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

我喜欢这种方法的原因是，因为应用程序使用了ActionBar，所以它保持不变并且不随屏幕切换动画一起移动，这就是Activity切换所发生的情况。这为这些屏幕转换提供了更流畅的感觉。

所以我想我要问的是分享你关于这个主题的当前开发方式，我知道它看起来可能看起来像一个基于意见的问题，但我把它看作是一个Android设计和架构问题......不是基于意见的。

更新（01.05.2014）：来自 Square Eric Burke 的演示文稿，（我不得不说这是一个很棒的演示文稿）为Android开发人员提供了许多有用的工具。而且我与Square没有任何关系）

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

根据我过去几个月的个人经验，我发现构建应用程序的最佳方法是创建一组片段，这些片段代表应用程序中的 flow 并呈现所有这些片段在一个Activity。所以基本上你的应用程序中Activities的数量与流的数量相同。这样，操作栏在所有流程的屏幕上保持完整，但正在重新创建流程，这很有意义。正如埃里克伯克所说，并且我已经认识到，使用尽可能少Activities的哲学并不适用于所有情况，因为它在他所谓的“上帝”活动中造成混乱。

Answer 1

专家会告诉您：“当我看到用户界面时，我会知道是使用Activity还是Fragment”。在一开始这没有任何意义，但是到时候，你实际上能够判断你是否需要Fragment。

我发现有一种很好的做法对我很有帮助。当我试图向女儿解释一些事情时，我突然想到了。

即，想象一个表示屏幕的框。你可以在这个盒子里加载另一个屏幕吗？如果您使用新的盒子，是否需要从第一个盒子中复制多个项目？如果答案为是，那么您应该使用Fragments，因为根Activity可以容纳所有重复的元素以节省您创建它们的时间，并且您可以简单地替换部分框。

但是不要忘记您总是需要一个盒子容器（Activity），否则您的部件将被分散。所以一个盒子内有零件。

注意不要误用盒子。 Android UX专家建议（您可以在YouTube上找到它们）我们应该明确加载另一个Activity，而不是使用Fragment（就像我们处理具有类别的导航抽屉时）。对Fragments感到满意后，您可以观看他们的所有视频。更多它们是强制性材料。

您现在可以查看您的用户界面并确定您是否需要Activity或Fragment？你有新观点吗？我想你做到了。

Answer 2

我的理念是：

仅在完全绝对需要时才创建活动。由于后端堆栈可用于提交一堆片段事务，我尝试在我的应用程序中创建尽可能少的活动。此外，各种片段之间的通信比在活动之间来回发送数据容易得多。

活动过渡很贵，对吗？至少我是这么认为的 - 因为旧活动必须被销毁/暂停/停止，被推入堆栈，然后必须创建/启动/恢复新活动。

自从片段被引入以来，这只是我的哲学。

Answer 3

嗯，根据Google的讲座（也许是here，我不记得了），你应该考虑尽可能使用Fragments，因为这样可以让你的代码更容易维护和控制。

但是，我认为在某些情况下它会变得太复杂，因为托管片段的活动需要在它们之间导航/通信。

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

如果您想进一步阅读，我已经创建了一篇关于此dillema here的帖子。

Answer 4

为什么我喜欢片段而非所有案例中的活动。

活动很昂贵。在Fragment中，视图和属性状态是分开的 - 只要片段在backstack中，它的视图就会被销毁。所以你可以堆积比活动更多的碎片。
Backstack操纵。使用FragmentManager，可以轻松清除所有碎片，插入多个碎片等。但对于Activity来说，操纵这些东西将是一场噩梦。
可预测的生命周期。只要主机Activity不被回收。背板中的碎片不会被回收。因此，可以使用FragmentManager::getFragments()查找特定的片段（不鼓励）。

Answer 5

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

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

片段的主要用途是构建多窗格活动，这使其成为平板电脑/手机响应式应用的完美选择。

Answer 6

不要忘记活动是应用程序的块/组件，可以通过Intent共享和启动！因此，应用程序中的每个活动都应该只解决一种任务。如果您的应用程序中只有一个任务，那么我认为您只需要一个活动和许多片段。当然，您可以在将来的活动中重用碎片来解决其他任务。这种方法将明确和逻辑分离任务。并且您不需要为不同的片段集维护具有不同意图过滤器参数的一个活动。您可以根据需求在开发过程的设计阶段定义任务。

Answer 7

除此之外，您还必须记住，启动的活动不会隐式破坏调用活动。当然，您可以进行设置，以便用户单击按钮转到页面，启动该页面的活动并销毁当前活动。这会导致很多开销。我能给你的最佳指南是：

**只有在主要活动和同一个活动同时打开时才开始新的活动（想想多个窗口）。

Google云端硬盘有多种活动才有意义。主要活动提供了一个文件浏览器。打开文件时，将启动一个新活动以查看该文件。您可以按最近的应用程序按钮，这样您就可以在不关闭打开的文档的情况下返回浏览器，甚至可以打开与第一个文档并行的另一个文档。

Answer 8

自Jetpack起，单活动应用是首选架构。尤其适用于Navigation Architecture Component。

source

Answer 9

我做了：尽可能使用更少的片段。不幸的是，在几乎情况下它是可能的。所以，我最终得到了很多片段和一些活动。我已经意识到的一些缺点：

ActionBar＆amp;菜单：当2个片段有不同的标题，菜单时，即很难处理。例如：添加新片段时，您可以更改操作栏标题，但是当从backstack弹出时，无法恢复旧标题。在这种情况下，您可能需要在每个片段中使用工具栏，但请相信我，这将花费您更多时间。
当我们需要startForResult时，活动有片段但没有。
默认情况下没有过渡动画

我的解决方案是使用一个Activity来包装一个片段。所以我们有单独的操作栏，菜单，startActivityForResult，动画，......

Answer 10

fragment超过活动的一大优势是，用于片段的代码可以用于不同的活动。因此，它提供了代码的可重用性应用程序开发。

Answer 11

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

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

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

问候。

Answer 12

我使用Fragments来获得更好的用户体验。例如，如果您有一个Button并且想要在单击时运行让我们说一个webservice，我会将一个Fragment附加到父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();
}

通过这种方式，用户不必再进行其他活动。

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

Answer 13

为每个应用程序使用一个活动为fragment提供基础使用fragment作为屏幕，与fragments相比，activites 轻量级 片段可重复使用 片段是更适合的应用程序，支持手机和电话平板电脑

Answer 14

这取决于你想要真正构建的内容。例如，navigation drawer使用片段。标签也使用fragments。另一个很好的实现，就是你有listview的地方。旋转手机并单击一行时，活动将显示在屏幕的剩余一半中。就个人而言，我使用fragments和fragment dialogs，因为它更专业。另外，它们在旋转时更容易处理。

Answer 15

几乎总是使用片段。如果您知道您正在构建的应用程序仍然很小，那么使用片段的额外努力可能不值得，因此可以将它们排除在外。对于较大的应用程序，引入的复杂性被片段提供的灵活性所抵消，从而更容易证明在项目中使用它们是合理的。有些人非常反对片段及其生命周期所涉及的额外复杂性，因此他们从不在他们的项目中使用它们。这种方法的一个问题是 Android 中有几个 API 依赖于片段，例如 ViewPager 和 Jetpack Navigation 库。如果您需要在您的应用中使用这些选项，那么您必须使用片段来获得它们的好处。

摘自：克里斯汀·马尔西卡诺。 “Android 编程：大书呆子牧场指南，第 4 版。”苹果图书。

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

15 个答案: