Android：什么更好 – 多个活动或手动切换视图？
我为Android开发了一些应用程序，这个问题始终保持：
我应该如何构build我的用户界面？ 我是否应该在活动之后启动活动并留下手机以创build“后退”button，还是应该select更优化但更复杂的方式来执行手动切换视图，然后手动执行“后退”buttonfunction？
你认为（或者知道）什么是更好的做法？
我会说，多个活动几乎总是更有意义。 我只是不认为Android是为了不断改变自己的观点而devise的 – 你错过了这么多。 你必须自己实现Back，你不会得到任何活动间转换，你必须实现许多内部逻辑才能以正确的状态恢复应用程序。 如果您不将应用程序划分为“活动”，那么稍后改变应用程序的stream程将变得更加困难。 这也导致了一个巨大的活动，比许多小的代码片段更难处理。
我很难想象速度真的是一个问题， 如果是，那么你初始化每个Activity的方式是有问题的。 例如，我试图在活动之间传递Serializable对象，事实certificate这是非常慢的。 当我转向更快的方法传递对象，发射活动的速度大大增加。
另外，我认为这是说“活动和任务devise”的Android指南根本没有提到切换视图; 它围绕着一个Activity-as-Viewdevise。
我想指出一些情况，当一个活动可能更好地devise一个Android应用程序，有多个全屏查看：
-
如果应用程序屏幕紧密耦合，并共享一个共同的对象，他们都在运行。 在这种情况下，传递Object可能需要一个Bundle，并且可能会出错，因为它会有副本。 一个很好的例子可能是一个巫师 。 是的，你可以使用静态来访问普通的对象，但静态在Android中可能是危险的（想想configuration的变化！）
-
如果你想在屏幕之间做一些非常酷的animation。 也许你想要一只鸟在一个屏幕上起飞，然后降落在另一个屏幕上。 尝试做到这一点，当每个屏幕是一个活动！
另一方面，如果您的屏幕之一被devise为由任何数量的其他应用程序显示，那么该屏幕应该是它自己的活动。
更新2014年3月：
现在这个问题应该包括碎片的select。 我认为Views可能是3：Activity，Fragment，View最不可能的select。 如果要实现使用后退button的屏幕，则应该是“活动”或“片段”，因为它们本身都处理后退button。 碎片将需要被添加到FragmentManager返回堆栈的后退button的工作。 尽pipepipe理片段，对话框和后台堆栈可能有点烦恼！
另外请记住，使用多个Activities来实现您的应用程序将为用户提供一个整体平台的更一致的体验。 部分体验将通过使用内置的Google应用程序进行调整，因此，如果用户的行为与手机上已安装的应用程序的行为类似，那么用户可能会更轻松地使用应用程序。
与其他人不同，我使用两者的混合物，例如，
1.应用程序启动时有一个主菜单
2.你点击search，带你去search活动
3.然后有一个filterbutton，它只是切换视图，并显示filter选项
4.filter视图末尾有两个button，您可以点击“search”或“取消”，然后再次返回search视图（无需切换活动）
5.现在，如果用户点击手机返回button，他会回到主菜单，而不是searchfilter选项。 我猜是正确的行为。
以用户感觉自然的方式使用它。 把所有事情都放在一个活动中会使事情变得复杂。
这一切都取决于应用程序，你想要获得更好的性能，更平滑的用户界面。 恕我直言，我更喜欢手动控制活动的第二种方法，即使它更复杂，正如你所说的。 这是我在我的android选项卡项目中使用的一种方法，也可以看看一个名为ActivityGroup的类（不确定包），它允许你有多个活动，你可以切换，关于这个类的好处是当你切换时你的活动没有被卸载，但坏的是加载你的主应用程序需要更长的时间。
只是我的意见。
切换视图的问题，我偶然发现，也是由垃圾收集器引起的。 似乎GC离开活动而不是视图触发。 所以，用一个相当复杂的子视图改变标签，几乎不可避免地会导致堆栈溢出exception。
我正在一个应用程序，只有一个活动，但我面临着很多问题，特别是与地图fragment.may是我不处理正确的方式片段，但我会build议多个活动的方法是更好的。
