Android 分裂还是不分裂？

随着我开始越来越多地采用片段，但随着片段功能的增加（片段中的片段，MapFragments），我开始需要定义何时将新视图/操作作为片段或活动

活动定义为：

活动是用户可以做的一件专注的事情

但有一部分片段采用了该定义，如文档中所述：

例如，新闻应用程序可以使用一个片段来显示 文章在左边，另一个片段显示文章在左边 对，两个片段都出现在一个活动中

这是用户可以用两个片段在一个活动中完成的两件事

---

因此，我希望获得一些意见/帮助，以确定我应该将一个新的行动/观点作为一个片段还是作为一项活动，最好的方法是什么？

答案取决于您和您的开发实践（或您公司的实践）。然而，我的观点是：至少，如果您认为正在开发的功能可以在多个活动中使用，或者如果它可以在活动中与另一个视图一起使用（如在平板电脑上），那么您应该将其作为一个片段

---

我们最近采用了在所有情况下创建片段的理念。我们的活动现在只是顶级的协调人，基本上是把事情联系在一起的粘合剂。这使得体系结构具有一致性和灵活性。这对我们来说很重要，因为我们有许多工程师在几个地方从事代码工作

我从1.5开始就在安卓系统中开发，所以我一直在开发一些活动和最近的片段

经常有碎片在我嘴里留下酸味。。。例如，我需要一种带有按钮的分页仪表板。为此，我使用了ViewPager+每个按钮1个片段。我遇到了各种各样的问题，因为在Android 4.2之前，片段不能嵌套

另一个问题是碎片的异步功能模式，当碎片需要从一个地方快速移动到另一个地方时，它会有各种各样的错误行为

不要以为一切都不好。。。在更简单的情况下，片段的使用非常有效

因此，在我看来，只要你有一个区域是独立的，不经常在视图上移动，可以在多个屏幕上重复使用，并且你支持平板电脑（或者将来支持my），就使用它

如果您需要嵌套片段、频繁重新排列的视图或不可重用的代码，请不要这样做

活动的定义是：“活动是用户可以做的一件单一的、有重点的事情”

这更像是一个过时文件的问题，而不是其他问题<代码>活动具有相同的定义。。。当我们使用较小的屏幕尺寸时（例如，手机）。当你移动到更大的屏幕上时，一项活动比“一个单一的、专注的事情”更复杂的几率会增加

因此，我希望获得一些输入/帮助，以确定我应该将新的操作/视图作为片段还是作为活动来进行的最佳方法是什么

以下是我的一般启发：

• 如果您预计某个用户界面可能会独立存在于手机大小的屏幕上，但会与平板电脑大小的屏幕上的其他内容一起使用，那么将其作为一个片段

• 如果您期望某个用户界面总是独立存在，只需创建一个简单的活动

• 如果你认为你的预测能力不是很好，那么就错在制造更多的碎片上。例如，你可能会说，“好吧，帮助永远不需要和其他任何东西放在一起”，并使之成为一项活动。然后，如果您意识到其他UI部分可能会从帮助中受益，而不是单独从中受益——因此用户可以阅读文档并同时执行操作——您将后悔没有将帮助变成一个片段，因为您将不得不重新做一些工作

• 如果这样或那样的UI永远不会独立存在——换句话说，如果它更像是一个小部件而不是一个完整的活动——并且您希望在多个项目上使用它，那么将它变成一个小部件，以自定义

  视图

  或

  视图组

  的形式

---

但是，正如jsmith所指出的，没有普遍的正确或错误答案。顺便说一句，AFAIAC，jsmith的答案在这里是正确的，但我会太罗嗦，无法对他的答案发表评论…：-）

介意解释一下新的观点吗？这实际上取决于你将如何使用这个新的视图/操作，比如从一个列表到细节等等。但是假设我们有一个选项卡活动，每个选项卡中都有列表和操作栏项目，这些项目也有要显示的内容。当你将多种类型的视图/功能捆绑在一起时，片段通常很有用。在您的情况下，听起来您希望列表中有一个片段，详细信息中有一个片段。这使您可以灵活地在需要的地方重用片段，将片段放在需要的地方，动态地替换片段。。等等。。有很多好处fragments@dymmeh我同意，这就是我为什么大量采用它的原因。但是我刚刚有一个项目，在许多代码行上都有一个主要活动，除了在片段之间进行通信之外什么都不做，启动/替换片段等等。那么这就是我要走的路吗？还是我遗漏了什么？在所有情况下创建片段也是我的哲学，但有时你会遇到这些巨大的案例，这让你怀疑这是很好的面向对象实践……是的，我们也有。然而，当我需要编辑另一个开发人员代码时，我知道模式，这使得分析代码变得容易。使用这种模式的投资回报率对我们来说很有效。你必须问问它是否对你有用。还有其他的选择可以让你的活动更轻松、更有效