我已经为Android开发了一些应用程序，这个问题始终存在：
我应该如何构建我的UI？我应该在活动后启动活动并离开手机以制作“后退”按钮，还是应该选择更优化但实施起来更复杂的方式，手动切换视图然后手动执行“后退”按钮功能？
您认为（或知道）更好的做法是什么？
答案 0 :(得分：98)
我想说多项活动几乎总是更有意义。我只是不认为Android是专为不断切换自己的观点而设计的 - 你错过了这么多。你必须自己实现Back，你没有得到任何inter-Activity转换，你必须实现很多内部逻辑来恢复正确状态的应用程序。如果不将应用程序划分为“活动”，则以后更改应用程序的流程会变得更加困难。它还导致一个mega-Activity比很多较小的代码要难得多。
我很难想象速度确实是一个问题;如果它是，那么你初始化每个Activity的方式有问题。例如，我曾经尝试在Activities之间传递Serializable对象，这被证明是非常慢的;当我切换到更快的传递对象的方法时，启动活动的速度大大增加。
此外，我认为它告诉the Android guidelines for Activity and Task Design根本没有提到切换视图;它以Activity-as-View设计为中心。
答案 1 :(得分：20)
我想指出一些实例，当一个活动可能更好地设计一个具有多个全屏的Android应用程序时查看：
如果应用程序屏幕紧密耦合并共享一个共同的对象，它们都在运行。在这种情况下，传递Object可能需要Bundle并且可能容易出错，因为它会有副本。一个很好的例子可能是wizard。是的，您可以使用静态来访问公共对象，但静态在Android中可能很危险（想想配置更改！）
如果您想在屏幕之间使用一些非常酷的动画。也许你想要一只鸟在一个屏幕上起飞并降落在另一个屏幕上。当每个屏幕都是活动时尝试这样做！
另一方面，如果您的某个屏幕被设计为由任意数量的其他应用程序显示，那么该屏幕应该是它自己的活动。
2014年3月更新：
此时此问题现在应该包括片段的选择。我认为视图可能是3：Activity，Fragment，View中最不可能的选择。如果你想实现使用后退按钮的屏幕，那么它应该是Activties或Fragments，因为它们本身都处理后退按钮。需要将片段添加到FragmentManager后台堆栈以使后退按钮起作用。管理片段，对话框和后台堆栈虽然有点烦人！
2018年9月更新：
Google的一些开发人员推荐single activity apps using the new navigation architecture component。
答案 2 :(得分：11)
另请注意，使用多个Activities实施您的应用将为用户提供整体平台更一致的体验。部分体验将通过使用内置的Google应用程序来塑造，因此如果用户的行为与手机上已安装的应用程序类似，则用户可能会更轻松地使用您的应用程序。
答案 3 :(得分：4)
与其他人不同，我使用两者的混合物，例如，
1.申请开始时有一个主菜单
2.点击搜索，带您搜索活动
3.然后是一个过滤按钮，只需切换视图并显示过滤选项
4.过滤器视图末尾有两个按钮，您点击“搜索”或“取消”，然后您又回到搜索视图（没有切换活动）
5.现在，如果用户点击手机后退按钮，他将返回主菜单而不是搜索过滤器选项。我猜这是正确的行为。
以用户感觉自然的方式使用它。将所有内容保存在一个活动中会使其变得复杂。
答案 4 :(得分：3)
这一切都取决于应用程序，你想要实现更好的性能，更流畅的UI。恕我直言，我更喜欢手动控制活动的第二种方法，即使它已经说明它更复杂。这是我在android选项卡项目中使用的一种方法，你也可以看看一个名为ActivityGroup的类（不确定包）它允许你有多个活动可以切换，这个类的好处是你在切换时没有卸载你的活动，但是加载主应用程序需要更长的时间。
只是我的意见。
答案 5 :(得分：1)
我偶然发现切换视图的问题也是由垃圾收集器引起的。似乎在您离开活动而不是视图时触发了GC。因此，例如，使用相当复杂的子视图更改选项卡几乎不可避免地会导致堆栈溢出异常。
答案 6 :(得分：0)
我在多次活动布局中遇到了很多问题，因此强烈建议不要这样做，除非有充分的理由选择它。
多项活动的缺点
使用多个活动，很难重构代码以从活动中返回数据。
如果您调用“子”活动，则主要活动可能会被杀死。但是，在像样的设备上进行调试时，您永远都不会遇到这种情况，因此，您需要始终处理保存状态并正确恢复状态。真痛苦。想象一下在库（即另一个活动）上调用一个方法，并且必须确保该方法返回时，您的应用程序必须能够使用VM中所有对象上的所有字段（即活动）完全重新创建其状态。 restoreIntance）。太疯狂了
反之亦然，当您打开子活动时，自第一次产生该子活动以来，VM可能已被杀死，例如，在显示子活动时将应用程序最小化时。
只有一个地方可以存储相关的应用程序状态，这非常干净，就我而言，大多数情况下，如果VM被杀死，我想让用户返回主屏幕，然后让他们再次执行操作，因为我不会花30-50个小时编码保存/恢复功能，而0.1％的用户会体验到。
替代
片段或自己管理活动视图。手动管理视图需要根据需要为活动/片段编码一些视图切换替代方案。
不，这并不意味着一种公认的答案中所建议的一项大型活动，而不是一种大型应用程序。它只需要对代码库进行更多的设计就可以了，因为管理视图的工作量略多，尽管管理活动状态和其他怪异的工作要少得多。
可能相关：Reddit: It's official : Google officially recommends single activity app architecture