Android: 什么更好——多个活动还是手动切换视图？

小开

这一切都取决于应用程序，你试图达到更好的性能，更流畅的用户界面。恕我直言，我更喜欢手动控制活动的第二种方法，即使它像您所说的那样更复杂。这是我在我的 android tab 项目中使用的一种方法，你也许想看看一个叫 ActivityGroup (不确定包)的类，它允许你在多个活动之间切换，这个类的好处是当你切换时你的活动不会被卸载，但坏处是加载你的主应用需要更长的时间。

只是我个人的意见。

小开

最佳答案

I would say that multiple Activities almost always makes more sense. I just don't think Android is designed for constantly switching its own views - you miss out on so much. You have to implement Back yourself, you don't get any inter-Activity transitions, you have to implement a lot of internal logic to resume an application in the correct state. If you don't partition your app into Activities, it makes it a lot more difficult later on to change the flow of your application. It also results in one mega-Activity that can be a lot harder to handle than a lot of smaller pieces of code.

I have trouble imagining that speed is really an issue; if it is then there's something wrong with the way you're initializing each Activity. For example, I used try to pass Serializable objects between Activities, and that proved to be incredibly slow; when I switched to a faster method of passing objects, the speed of launching Activities increased immensely.

而且，我认为活动和任务设计的 Android 指南根本没有提到切换视图，它是围绕活动即视图设计展开的。

小开

还要记住，使用多个 Activities实现应用程序将使用户在整个平台上获得更加一致的体验。部分体验将通过使用内置的谷歌应用程序塑造，所以用户可能会更容易使用您的应用程序，如果它的行为类似于那些已经安装在手机上。

小开

我偶然发现的切换视图的问题也是由垃圾收集器引起的。似乎 GC 是在您离开活动而不是视图时触发的。因此，使用相当复杂的子视图更改制表符几乎不可避免地会导致堆栈溢出异常。.

小开

我想指出一些例子，当一个单一的活动可能是更好的设计一个 Android 应用程序，有一个以上的全屏视图:

如果应用程序屏幕是紧密耦合的，并且共享一个共同的 Object，那么它们都在这个对象上进行操作。在这种情况下，传递 Object 可能需要一个 Bundle，并且可能会出错，因为会有它的副本。一个很好的例子可能是巫师。是的，你可以使用 static 来访问通用对象，但是在 Android 中静态可能是危险的(想想配置变化吧!)
如果你想要一些真正酷的动画在屏幕之间。也许你想让一只鸟在一个屏幕上起飞，在另一个屏幕上降落。当每个屏幕都是一个活动时，试着这样做！

另一方面，如果您的一个屏幕被设计为由任意数量的其他应用程序显示，那么该屏幕应该是它自己的活动。

2014年3月更新:

在这一点上，现在的问题应该包括片段的选择。我认为视图可能是3: 活动，片段，视图中最不可能的选择。如果您想要实现使用后退按钮的屏幕，那么应该使用 Activties 或 Fragments，因为它们都本地处理后退按钮。需要将片段添加到 FragmentManager 后退堆栈中，以便后退按钮工作。但是，管理片段、对话框和后台堆栈可能有点烦人！

2018年9月更新:

Some devs at Google are recommending 使用新的导航架构组件的单个活动应用程序.

小开

与其他的不同，我使用两者的混合，例如,
1. There is a main menu when the application starts
2. 点击搜索，进入搜索活动
3. 还有一个过滤器按钮，它可以切换视图并显示过滤选项
4.在过滤器视图的末尾有两个按钮，你点击“搜索”或“取消”，然后再次返回到搜索视图(没有切换活动)
5.现在，如果用户点击电话返回按钮，他将返回到主菜单，而不是搜索过滤选项。我想这是正确的行为。

用户感觉自然的方式使用它，把所有东西放在一个活动中会使它变得复杂。

小开

I've experienced so many problems with multiple activity layout that I strongly discourage it, unless there's good reason to pick it.

多重活动的缺点

Using multiple activities it is much hard to refactor code to return data from activity.

如果你称一个子活动为“子活动”，那么主活动可能会被杀死。但是在一个像样的设备上进行调试时，您永远不会遇到这种情况，因此您需要处理始终保存状态和正确恢复状态。真是痛苦。想象一下在库上调用一个方法(即。另一个活动) ，并且您必须确保当该方法返回时，您的应用程序必须能够使用 VM 中所有对象上的所有字段完全重新创建其状态(即。Activity.restoreInstance).太疯狂了。

另一方面，当您打开一个子活动时，虚拟机可能已经被杀死，因为子活动是首次产生的，例如当应用程序最小化时，子活动显示。

只有一个地方存储相关的应用程序状态要干净得多，在我的例子中，大多数情况下，如果虚拟机被关闭，我想让用户回到主屏幕，让他们再次做他们的事情，因为我不会花30-50小时编写保存/恢复功能，0.1% 的用户将永远体验。

另一种选择

Fragments or just manage you activity views yourself. Managing views manually, requires coding some view-switching alternative to activities/fragments with transitions if desired.

不，它并不意味着一个大型活动，正如公认的答案所暗示的那样，除了它的一个大型应用程序以外，还有其他任何方式。它只是需要对代码库进行更多的设计，以适应不同的情况，因为管理视图的工作稍微多一些，但是管理活动状态和其他奇怪的事情的工作要少得多。

Possibly relevant: Reddit: 这是官方的: 谷歌官方推荐单一活动应用程序架构