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

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

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

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

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

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

当做

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

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

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

专家会告诉你：“当我看到UI时，我会知道是使用活动还是片段”。在一开始，这将没有任何意义，但随着时间的推移，你将能够知道你是否需要Fragment。

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

也就是说，想象一个代表屏幕的盒子。你能在这个盒子里再装一个屏幕吗？如果使用新框，是否必须从第一个框复制多个项目？如果答案是Yes，那么您应该使用Fragments，因为根Activity可以保存所有重复的元素，以节省创建它们的时间，并且您可以简单地替换方框的部分。

但别忘了，你总是需要一个盒子容器（Activity），否则你的零件会被分散。所以一个盒子里面有零件。

小心不要误用箱子。Android用户体验专家建议（你可以在YouTube上找到他们），何时我们应该显式加载另一个“活动”，而不是使用“片段”（比如当我们处理有类别的导航抽屉时）。一旦你对碎片感到舒适，你就可以观看他们的所有视频。更重要的是，它们是强制性材料。

你现在能看看你的UI并确定你是否需要一个活动或片段吗？你有新的视角吗？我想你做到了。

我的哲学是：

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

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

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

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