我已经为Android开发了一些应用程序，但这个问题始终存在：
我应该如何构造我的UI？我应该在活动后启动活动，然后让手机留下“后退”按钮，还是应该选择更优化但实现起来更复杂的方式，即手动切换视图，然后手动执行“后退”按钮功能？
您认为（或知道）什么是更好的做法？
Answers:
我要说，多次活动几乎总是更有意义。我只是不认为Android是专为不断切换自己的视图而设计的-您会错过很多。您必须自己实现Back，没有任何活动间转换，必须实现很多内部逻辑以使应用程序恢复到正确的状态。如果您不将应用程序划分为“活动”，则以后更改应用程序流程将变得更加困难。它也导致一个大型活动比许多较小的代码更难处理。
我很难想象速度确实是个问题。如果是，则初始化每个活动的方式有问题。例如，我曾经尝试过在Activity之间传递Serializable对象，但事实证明这非常慢。当我切换到一种更快的传递对象的方法时，启动“活动”的速度大大提高了。
另外，我认为这是在告诉Android活动和任务设计指南根本没有提到切换视图。它以“活动即查看”设计为中心。
我想指出一些实例，对于一个具有多个全屏视图的Android应用程序，单个活动可能是更好的设计：
如果应用程序屏幕紧密耦合并共享它们都在其中运行的公共对象。在这种情况下，传递对象可能需要使用捆绑软件，并且容易出错，因为会有对象的副本。一个很好的例子可能是向导。是的，您可以使用static来访问公共对象，但是static在Android中可能很危险（请考虑更改配置！）
如果您想在屏幕之间添加一些非常酷的动画。也许您希望一只鸟在一个屏幕中起飞并降落在另一个屏幕中。当每个屏幕都是活动时，尝试这样做！
另一方面，如果您设计的一个屏幕可以由任意数量的其他应用程序显示，则该屏幕应该是其自己的活动。
2014年3月更新：
此时，问题现在应该包括片段的选择。我认为Views可能是3：Activity，Fragment，View中最不可能的选择。如果要实现利用后退按钮的屏幕，则它应该是Activties或Fragments，因为两者都本地处理后退按钮。片段将需要添加到FragmentManager的后堆栈中，以使后退按钮起作用。但是，管理片段，对话框和后退堆栈可能会有些烦人！
2018年9月更新：
Google的一些开发人员建议使用新的导航体系结构组件的单活动应用程序。
还请记住，使用多个应用程序实施Activities将为用户带来整个平台更一致的体验。部分体验将通过使用内置的Google应用来调整，因此，如果您的应用与手机上已安装的应用具有相似的行为，则用户可能会更轻松地使用您的应用。
我偶然发现，切换视图的问题也是由垃圾收集器引起的。似乎在您离开活动而不是视图时触发了GC。因此，例如，更改带有相当复杂的子视图的选项卡几乎不可避免地会导致堆栈溢出异常。
除非有充分的理由选择，否则我在多次活动布局中遇到了很多问题，因此我强烈不建议这样做。
多项活动的弊端
使用多个活动，很难重构代码以从活动中返回数据。
如果您称为“子”活动，则主要活动可能会被杀死。但是，在像样的设备上进行调试时，您永远不会遇到这种情况，因此，您需要始终处理保存状态并正确恢复状态。真痛苦。想象一下在库（即另一个活动）上调用一个方法，并且必须确保当该方法返回时，您的应用必须能够使用VM中所有对象上的所有字段（即活动）完全重新创建其状态。 restoreIntance）。太疯狂了
反之亦然，当您打开子活动时，自第一次产生该子活动以来，VM可能已被杀死，例如，在显示子活动时最小化了应用程序。
它非常干净，只有一个地方可以存储相关的应用程序状态，就我而言，大多数情况下，如果VM被杀死，我想让用户回到主屏幕，然后让他们再次做自己的事情，因为我不这样做无需花费30-50个小时来编码0.1％的用户将体验的保存/恢复功能。
另类
片段或自己管理活动视图。手动管理视图需要根据需要为活动/片段编码一些视图切换替代方案。
不，这并不意味着一种通用活动（如已接受的答案所示），而不是一种大型应用程序。它只需要对代码库进行更多的设计就可以了，因为管理视图的工作量略多，尽管管理活动状态和其他怪异的工作要少得多。