我使用碎片来获得更好的用户体验。例如，如果您有一个按钮，并且希望在单击它时运行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();
}

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

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

我的哲学是：

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

活动转换很昂贵，对吧？至少我这么认为——因为旧活动必须被销毁/暂停/停止，推到堆栈上，然后新活动必须被创建/启动/恢复。

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

这比你意识到的要多，你必须记住，启动的活动不会隐式地破坏调用活动。当然，您可以将其设置为用户单击某个按钮转到某个页面，然后启动该页面的活动并销毁当前页面。这会导致大量开销。我能给你最好的指导是：

**只有当主活动和此活动同时打开（考虑多个窗口）才有意义时，才能开始新活动。

Google Drive就是一个很好的例子，它说明了多个活动是有意义的。主要活动提供文件资源管理器。打开文件后，将启动一个新活动来查看该文件。您可以按下最近的应用程序按钮，这将允许您在不关闭打开的文档的情况下返回浏览器，然后甚至可以打开与第一个文档并行的另一个文档。

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

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

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

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

自Jetpack以来，Single Activity应用程序是首选的架构。特别适用于导航体系结构组件。

来源