android - 模式 "One activity, multiple views": Advantages and disadvantages

Question

此模式类似于用于开发 Web 应用程序的模式 Main Servlet(前端 Controller )。

这种模式的主要思想:我们有一个 Activity 来管理多个 View ，这个 Activity 负责表示当前内容。并非所有 View 都需要 Activity 功能(例如生命周期方法)，所以主要问题是:如果我可以不用 Activity ，为什么我必须使用它？

---

我发现使用这种模式有以下缺点:

1. 官方不推荐Overload a Single Activity Screen但他们没有解释原因。

2. 我们不能使用 TabActivity、ListActivity、MapActivity。但是没有它们也有一些技巧。

3. 如果不同的屏幕有不同的菜单，那么在没有 Activity 的情况下制作是个问题。
4. 有必要自己保存历史。但开发起来并没有那么难。

我发现使用这种模式有以下优点:

1. 更改当前 Activity 的内容比开始另一个 Activity 更快
2. 我们可以随意管理历史记录
3. 如果我们只有一个 Activity 上下文，则更容易发现和解决内存泄漏问题

您如何看待这种模式？你能提供任何其他优点/缺点吗？

Answer 1

We cannot use TabActivity, ListAcivity, MapActivity. But there are some tricks to go without them.

如果你想使用MapView，你必须使用MapActivity。如果要使用偏好 XML，则必须使用 PreferenceActivity。

It is necessary to keep history by ourselves. But it's not so difficult to develop.

管理您自己的历史记录的难度在很大程度上取决于历史记录需要是什么。为一个简单的向导实现历史记录将相当容易。然而，这是一个特别简单的场景。 Android 中有相当多的历史管理代码，您必须针对任意其他情况进行重写。

你也忘了:

#5。您将容易发生内存泄漏，因为您会忘记清理内容，而 Android 不会清理内容(因为它假定您将使用许多小型 Activity ，按照他们推荐的方式)。

#6。您对配置更改(旋转、停靠、SIM 更改、区域设置更改、多个显示、字体比例)的状态管理将更加复杂，因为现在您还必须弄清楚哪些额外的东西(例如，历史记录)需要成为状态的一部分，并且您一次处理所有这些而不是一次 Activity 。

#7。为您的应用程序设置多个入口点变得更具挑战性(例如，启动器中的多个图标、链接到除主要 Activity 之外的某些 Activity 的应用小部件、响应等)。

It's faster to change the content of current activity than to start another activity

对于大多数现代 Android 设备，速度差异对大多数用户来说并不显着，恕我直言。

If we have only one activity-context it's simpler to find and solve problems with memory leaks

除非您仍然有多个“一个 Activity 上下文”。请记住:您的 Activity ，无论大小，仍然会在配置更改时被销毁和重新创建。

What do you think about this pattern ?

科斯的"nature of the firm" theory说企业不断扩张，直到内部做事的交易成本高于让其他公司做同样事情的交易成本。

墨菲的“Activity 性质”理论认为， Activity 会不断扩展，直到内部做事的交易成本高于让其他 Activity 做同样事情的交易成本。 Android 开发人员将倾向于为 Activity 使用“用户事务”模型——紧密耦合的事物(例如，向导中的步骤)倾向于在单个 Activity 中处理，而关系不大的事物(例如，浏览与搜索) vs. settings vs. help vs. about) 将倾向于在不同的 Activity 中处理。