Android：什么更好 - 多个活动或手动切换视图？

Android: What is better - multiple activities or switching views manually?

提问by Danail

I have developed some apps for Android, and this questions stays always:

我为 Android 开发了一些应用程序，这个问题始终存在：

How should I structure my UI? Should I launch activity after activity and leave the phone to make the "back" button, or should I choose more optimized, but more complex to implement, way with switching manually Views and then manually doing the "Back" button functionality?

我应该如何构建我的用户界面？我应该在活动后启动活动并离开手机来制作“后退”按钮，还是应该选择更优化但实施起来更复杂的方式，手动切换视图然后手动执行“后退”按钮功能？

What do you think (or know) is the better practice?

你认为（或知道）什么是更好的做法？

采纳答案by Dan Lew

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.

我会说多个活动几乎总是更有意义。我只是不认为 Android 是为不断切换自己的视图而设计的——你错过了很多。你必须自己实现 Back，你不会得到任何 Activity 间的转换，你必须实现很多内部逻辑才能在正确的状态下恢复应用程序。如果您不将应用程序划分为活动，那么稍后更改应用程序的流程就会变得更加困难。它还导致一个大型活动比许多较小的代码段更难处理。

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.

我很难想象速度真的是一个问题；如果是，那么您初始化每个活动的方式有问题。例如，我曾经尝试在活动之间传递 Serializable 对象，但事实证明这非常慢；当我切换到更快的传递对象的方法时，启动活动的速度大大增加。

Also, I think it's telling that the Android guidelines for Activity and Task Designdon't mention switching Views at all; it's centered around an Activity-as-View design.

另外，我认为Android 的活动和任务设计指南根本没有提到切换视图；它以 Activity-as-View 设计为中心。

回答by satur9nine

I'd like to point out some instances when a single activity might be better design for an Android application that has more than one full screen View:

我想指出一些实例，对于具有多个全屏视图的 Android 应用程序，单个 Activity 可能是更好的设计：

• If the application screens are tightly coupled and share a common Object that they are all operating on. In this case passing around the Object may require a Bundle and can be error prone since there will be copies of it. A good example might be a wizard. Yes you could use static's to access the common Object but static can be dangerous in Android (think configuration changes!)

• If you want some really cool animations in between screens. Maybe you want a bird to take off in one screen and land in another screen. Try doing that when each screen is an activity!

• 如果应用程序屏幕紧密耦合并共享它们都在操作的公共对象。在这种情况下，传递对象可能需要一个 Bundle 并且可能容易出错，因为会有它的副本。一个很好的例子可能是一个向导。是的，您可以使用静态访问公共对象，但静态在 Android 中可能很危险（想想配置更改！）

• 如果您想在屏幕之间播放一些非常酷的动画。也许您希望一只鸟在一个屏幕上起飞并在另一个屏幕上降落。当每个屏幕都是一个活动时尝试这样做！

On the other hand if one of your screens is designed to be shown by any number of other applications then that screen should be its own Activity.

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

UPDATE March 2014:

2014 年 3 月更新：

At this point the question should now include the choice of Fragments. I think that Views are probably the least likely choice of the 3: Activity, Fragment, View. If you want to implement screens that make use of the back button then it should be either Activties or Fragments because both handle the back button natively. Fragments will need to be added to the FragmentManager back stack for the back button to work. Managing fragments, dialogs and the back stack can be a bit of an annoyance though!

在这一点上，问题现在应该包括 Fragments 的选择。我认为 Views 可能是 3 个中最不可能的选择：Activity、Fragment、View。如果您想实现使用后退按钮的屏幕，那么它应该是 Activties 或 Fragments，因为两者都本机处理后退按钮。需要将 Fragment 添加到 FragmentManager 后退堆栈中，后退按钮才能工作。不过，管理片段、对话框和后台堆栈可能有点麻烦！

UPDATE Sept 2018:

2018 年 9 月更新：

Some devs at Google are recommending single activity apps using the new navigation architecture component.

Google 的一些开发人员正在推荐使用新导航架构组件的单一活动应用程序。

回答by Erich Douglass

Also keep in mind that implementing your app with multiple Activitieswill give the user a more coherent experience with the platform as a whole. Part of the experience will be shaped by using the built-in Google apps, so users will probably have an easier time using your application if it behaves similarly to the ones that are already installed on the phone.

还要记住，使用多个实现您的应用程序Activities将使用户对整个平台有更一致的体验。部分体验将通过使用内置的 Google 应用程序来塑造，因此如果您的应用程序的行为与手机上已安装的应用程序类似，则用户可能会更轻松地使用您的应用程序。

回答by happyhardik

Different from others I use a mixture of both, for example,
1. There is a main menu when the application starts
2. You click on search, takes you to search activity
3. Then there's a filter button, which just switches view and shows you filter options
4. There are two buttons at the end of the filter view, You hit "Search" or "Cancel" and you are back to the Search View again (without switching activity)
5. Now if the user hits the phone back button he's taken back to the main menu instead of the search filter options. Which I guess is the correct behavior.

与其他人不同，我混合使用两者，例如，
1. 应用程序启动时有一个主菜单
2. 您单击搜索，带您进入搜索活动
3. 然后是一个过滤器按钮，它只是切换视图并显示您过滤选项
4. 过滤视图的末尾有两个按钮，您点击“搜索”或“取消”，您将再次返回搜索视图（无需切换活动）
5. 现在，如果用户回拨电话按钮他被带回主菜单而不是搜索过滤器选项。我猜这是正确的行为。

Use it the way user will feel natural. And keeping everything in one activity will make it complex.

以用户感觉自然的方式使用它。将所有内容都放在一项活动中会使其变得复杂。

回答by Greg

It all depends on application, what are you trying to achieve better performance, smoother UI. IMHO I prefer the second approach of controlling the Activities manually even that it is more complex as you have stated. This is a approach I have used in my android tabs project, also you might want to take a look at a class called ActivityGroup (not sure the package) it allows you to have multiple activities that you can switch between, good thing about this class is that your activities are not unloaded when you switch but a bad thing is it takes longer to load your main app.

这一切都取决于应用程序，您想要获得更好的性能、更流畅的 UI。恕我直言，我更喜欢手动控制活动的第二种方法，即使它如您所说的更复杂。这是我在我的 android tabs 项目中使用的一种方法，您可能还想看看一个名为 ActivityGroup 的类（不确定包）它允许您拥有多个可以在之间切换的活动，这个类的好处是当你切换时你的活动没有被卸载，但不好的是加载你的主应用程序需要更长的时间。

Just my opinion.

只是我的观点。

回答by zorglub76

The problem with switching views, that I stumbled upon, is also caused by garbage collector. Seems that GC is triggered when you leave activity and not the view. So, changing tabs with a fairly complex children views, for instance, will almost inevitably lead to stack overflow exception..

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

回答by arberg

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

我在多活动布局方面遇到了很多问题，我强烈反对它，除非有充分的理由选择它。

Disadvantage of multiple activities

多个活动的缺点

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

使用多个活动很难重构代码以从活动中返回数据。

If you call a 'sub'-activity then the main activity may be killed. But you never experience that while debugging on a decent device, hence you need to handle always saving state and correctly recovering state. That is a pain. Imagine calling a method on a library (ie. another activity), and you would have to be ensure that when that method returns your app must be able to recreate its state completely with all fields on all objects in the VM (ie. activity.restoreIntance). Its insane.

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

Also the other way round, when you open a subactivity the VM might have been killed since the subactivity was first spawned, such as when app is minimized while subactivity is displayed.

反之亦然，当您打开一个子活动时，VM 可能会因为子活动第一次产生而被杀死，例如在显示子活动时最小化应用程序。

Its so much cleaner to just have one place to store the relevant app-state, and in my case, most often if VM is killed, I want to return user to main-screen, and let them do their stuff again, because I don't spend 30-50 hours coding save/resume functionality that 0.1% of users will ever experience.

只有一个地方来存储相关的应用程序状态非常干净，在我的情况下，最常见的是如果 VM 被杀死，我想让用户返回主屏幕，让他们再次做他们的事情，因为我不不要花费 30-50 个小时来编写 0.1% 的用户会体验到的保存/恢复功能。

Alternative

选择

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

片段或只是自己管理您的活动视图。如果需要，手动管理视图需要编码一些视图切换替代活动/片段的转换。

And no it does not mean one mega-activity, as suggested in the accepted answer, in any other way than its one mega-app. It just requires a bit more design of the codebase into fitting pieces, because there's slightly more work managing views, though much less work managing activity-state and other weirdness.

不，这并不意味着一项大型活动，正如已接受的答案中所建议的那样，除了它的一个大型应用程序之外，还有其他任何方式。它只需要更多的代码库设计到合适的部分，因为管理视图的工作稍微多一些，尽管管理活动状态和其他奇怪的工作要少得多。

Possibly relevant: Reddit: It's official : Google officially recommends single activity app architecture

可能相关：Reddit：官方：Google 正式推荐单一活动应用架构