模式“一个活动，多个观点”：优点和缺点
这种模式类似于用于开发Web应用程序的主要Servlet （前端控制器）模式。
这种模式的主要思想是：我们有一个活动pipe理多个视图，这个活动负责表示当前的内容。 并不是所有的观点都需要function性的活动（例如生命周期方法），所以主要的问题是： 如果我可以没有活动，为什么我必须使用它？
我发现使用这种模式的下列缺点：
-
官方来源不build议重载单个活动屏幕，但他们不解释原因。
-
我们不能使用
TabActivity，ListActivity，MapActivity。 但是如果没有他们，还有一些窍门。 - 如果不同的屏幕有不同的菜单，那么没有任何活动就是个问题。
- 有必要自己保留历史。 但是开发并不困难。
我发现使用这种模式的优点如下：
- 改变当前活动的内容比开始另一个活动要快
- 我们可以随心所欲地pipe理历史
- 如果我们只有一个活动上下文，find并解决内存泄漏问题更简单
你对这种模式有什么看法？ 你能提供其他的优点/缺点吗？
我们不能使用TabActivity，ListAcivity，MapActivity。 但是如果没有他们，还有一些窍门。
如果你想使用MapView你必须使用MapActivity 。 如果要使用首选项XML，则必须使用PreferenceActivity 。
有必要自己保留历史。 但是开发并不困难。
pipe理自己的历史很困难，这将取决于历史的发展。 实施一个简单的向导的历史将是相当容易的。 但是，这是一个特别简单的情况。 在Android中有相当数量的历史pipe理代码，您将不得不重写其他任何情况。
你也忘了：
＃5。 你会容易泄漏内存，因为你会忘记清理东西，Android不会清理东西（因为它假设你将使用许多小的活动，他们推荐的方式）。
＃6。 你的状态pipe理configuration变化（旋转，停靠，SIM变化，语言环境变化，多显示，字体缩放）将变得更加复杂，因为现在你还必须弄清楚什么额外的东西（如历史）需要成为国家的一部分，而且你一次性处理所有的事情，而不是一次一个的事情。
＃7。 为您的应用程序提供多个入口点变得更具挑战性（例如，启动器中的多个图标，链接到主应用程序以外的某个活动的应用程序窗口小部件，响应等等）。
改变当前活动的内容比开始另一个活动要快
对于大多数现代的Android设备，速度差异对于大多数用户来说并不重要，恕我直言。
如果我们只有一个活动上下文，find并解决内存泄漏问题更简单
除了你还有更多的“一个活动 – 背景”。 请记住：您的活动（大或小）仍然会被破坏，并在configuration更改时重新创build。
你对这种模式有什么看法？
科斯的“企业性质”理论认为，企业扩张直到内部做事的交易成本高于其他企业做同样事情的交易成本。
墨菲的“活动本质”理论认为，这种活动扩大了，直到内部做事的交易成本高于其他活动做同样事情的交易成本。 Android开发人员往往倾向于一个“用户交易”模式的活动 – 紧密耦合的东西（例如，向导中的步骤）将倾向于在单个活动中处理，而事物几乎没有关系（例如，浏览与searchvs设置vs帮助vs about）将倾向于在不同的活动中处理。
如果稍后添加新的function，这将是可怕的。 我也不确定用户会注意到速度会如此之快。 将组件作为更小的组件更容易更换或更换是绝对要走的路。
