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议多个活动的方法是更好的。