此模式类似于用于开发 Web 应用程序的模式 Main Servlet（前端控制器）。
这种模式的主要思想：我们有一个 Activity 来管理多个视图，这个 Activity 负责表示当前内容。并非所有视图都需要活动功能（例如生命周期方法），因此主要问题是：如果我可以不使用活动，为什么我必须使用它？
我发现使用这种模式有以下缺点：
官方不推荐给Overload a Single Activity Screen 但他们没有解释原因。
我们不能使用TabActivity、ListActivity、MapActivity。但是没有它们也有一些技巧。
我发现使用这种模式有以下优点：
您如何看待这种模式？你能提供任何其他优点/缺点吗？
【问题讨论】：
标签： android
我们不能使用 TabActivity、ListAcivity、MapActivity。但是没有它们也有一些技巧。
如果你想使用MapView，你必须使用MapActivity。如果你想使用偏好 XML，你必须使用PreferenceActivity。
有必要自己保存历史。但开发起来并没有那么难。
管理您自己的历史记录的难度在很大程度上取决于历史记录需要是什么。为一个简单的向导实现历史记录将相当容易。然而，这是一个特别简单的场景。 Android 中有相当多的历史管理代码，您必须针对任意其他情况进行重写。
你也忘了：
#5。您将容易发生内存泄漏，因为您会忘记清理内容，而 Android 不会清理内容（因为它假定您将使用许多小型活动，按照他们推荐的方式）。
#6。您对配置更改（旋转、停靠、SIM 更改、区域设置更改、多个显示、字体比例）的状态管理将更加复杂，因为现在您还必须弄清楚哪些额外的东西（例如，历史记录）需要成为状态的一部分，并且您一次处理所有这些而不是一次活动。
#7。为您的应用程序设置多个入口点变得更具挑战性（例如，启动器中的多个图标、链接到除主要活动之外的某些活动的应用程序小部件、响应等）。
更改当前活动的内容比开始另一个活动更快
对于大多数现代 Android 设备，速度差异对大多数用户来说并不显着，恕我直言。
如果我们只有一个活动上下文，则更容易发现和解决内存泄漏问题
除非您仍然有多个“一个活动上下文”。请记住：您的活动，无论大小，仍然会在配置更改时被销毁并重新创建。
您如何看待这种模式？
科斯的"nature of the firm" theory 说，企业不断扩张，直到内部做事的交易成本高于让其他公司做同样事情的交易成本。
墨菲的“活动性质”理论认为，活动会不断扩展，直到内部做事的交易成本高于让其他活动做同样事情的交易成本。 Android 开发人员将倾向于为 Activity 使用“用户事务”模型——紧密耦合的事物（例如，向导中的步骤）倾向于在单个 Activity 中处理，而关系不大的事物（例如，浏览与搜索） vs. settings vs. help vs. about) 将倾向于在不同的活动中处理。
【讨论】：
如果以后添加新功能，这将很难维护。 我也不相信用户会注意到它会快得多。 将组件设置为更容易更改或更换的更小部分绝对是可行的方法。
【讨论】：