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