在一个 Android 应用程序中，我有两个用户看到的屏幕*，一个用于准备查询，另一个用于显示结果。此处正确的 UI 是在一个屏幕上进行查询准备，然后在第二个屏幕上查看结果。由于此应用针对的是手机用户，因此无需同时显示两者。
传统的 Android 方式是使用两个活动， aQueryPreparationActivity和 a DisplayResultActivity，并在两者之间切换。然而，我听到越来越多的关于 Android UI 如何切换到 Fragment 的消息。我可以将两个屏幕实现为两个片段，并让活动切换它们，但值得麻烦吗？我将基本上复制 Android 已经拥有的 Activity 管理代码。
有理由在这里使用两个片段吗？
*我使用这个词screen，因为它不一定是一个活动......
就个人而言，我总是使用 Fragments 进行开发。
但我可以为您提供使用 Fragments 的最佳理由是，当您为手机和平板设备进行开发时，您会获得很多可重用性。
我知道您已经提到没有必要同时显示两个屏幕。但是稍后说您要为平板设备开发相同的“屏幕”并意识到准备屏幕太贫瘠并且想要同时显示查询准备和显示结果，您将不得不编写一个全新的第三个活动.
如果您使用片段，您将重用您的 1 个活动和 2 个片段，并且该活动应该被编码得足够聪明，以确定屏幕的大小并显示正确的布局。
代码可重用性和灵活性是这里的流行语。
如果您有任何问题，请发表评论，我将扩展我的答案。如果你喜欢我的回答，请点赞并采纳。
引入的片段将 UI 元素和相关行为封装到单个可重用模块中。在片段之前，您必须重新编写 2 个或更多活动共有的大部分相同代码，特别是如果您找不到将 UI/控制代码抽象为超类的好方法。setContentView由于活动只调用一次的限制，这进一步复杂化了。所以在活动之间共享一些代码并不是那么好。
现在，要回答您的问题，这完全取决于您。如果您认为更进一步，您可以使用 QueryPreparation 或 DisplayResult ui 作为模块（其背后的布局和逻辑），然后进行片段实现。它可能是手机横向视图的不同布局，或者如果您决定支持像 nexus 7 这样的小型平板电脑。如果您确定它永远不会发生，那么坚持活动。就个人而言，我在任何地方都使用片段，它们是“未来证明”您的实现以供将来重用的可靠方法。
简而言之，引入 Fragment 是为了适应平板电脑/大屏幕设备的出现，并允许开发人员创建可在各种屏幕尺寸上运行的应用程序，而对代码的更改很少。
更多内容可以在 Android 博客上阅读。该博客还详细介绍了转向 Fragments 的一些更精细的技术细节。Goolge IO 2012 还介绍了 DialogFragments，您应该考虑使用它来代替 Dialogs。这里的另一篇博文描述了它们。
你最好从一开始就习惯使用 Fragments 和 DialogFragments，因为这是 Android 的发展方式。仅当您确实出于测试目的确实需要做一个快速而肮脏的应用程序时，才使用单独的活动。在我看来，片段确实需要更多的代码工作才能整合并初步了解，但值得付出努力。