Android：单个活动，多个视图

Question

我不是Android专家，虽然我开发了一个包含50多个活动的应用程序，这使得应用程序非常庞大。经过8周的开发，现在存在导致应用程序难以维护和升级的问题。 我正在处理的主要是

1. 我无法将对象引用传递给活动的构造函数。事实上，我发现startActivityForResult - Intent - onActivityResult的机制确实受到限制，导致每个活动的动作和很多switch {{1}的许多常量的脏代码这很难跟随app的流程。

2. 另一个问题是我不知道如何管理整个应用程序的生命周期，因为每个活动都有自己的生命周期。

我有LWUIT和J2ME – polish的成功经验，忽略了J2ME MIDlets（类似于android活动）并实现了自己的架构和窗口系统，只有一个MIDlet作为应用程序的入口。我为android提出了同样的想法。

为了澄清，我正在考虑一个只有一个主要case的应用程序和其他活动实现为扩展Activity对象的对象，这些视图可以动态添加到主要活动{{1}并相互堆叠。活动的逻辑可以在这些类中实现，我甚至找到了以这种方式实现对话框的方法。 业务和状态对象可以传递给它们的构造函数，听起来很好，忽略了编写更多代码的副作用。这种方式也可以将侦听器传递给视图的构造函数，从而使应用程序UI切换和流程管理更加容易。

但问题是：

• 这是一个好习惯吗？
• 这不会导致我遇到性能或内存问题吗？

我也知道

• Android: What is better - multiple activities or switching views manually?
• Don't Overload a Single Activity Screen
• Pattern one activity, multiple views. Advantages and disadvantages

这些都没有明确地用合理的证据或文件参考来解决有关表现或实践的问题

请有人帮我这个

Answer 1

市场上有流行的应用只有一个或几个活动。他们使用片段并切换它们。我更喜欢你的方法片段。虽然我认为片段对于许多目的而言过于复杂，但对于您的用例来说，这将是一个很好的解决方案。您的UI行为应该是片段，您的活动是控制器部分在片段之间传输数据。碎片也有自己的生命周期。

我也不喜欢startActivityForResult。如果我有一组活动 - 都提供数据 - 而且我不知道它们将被调用的顺序，我更喜欢使用单例类，然后使用意图在活动之间进行数据传输。但是你必须分析你的问题以获得一个好的解决方案。

Answer 2

已经构建了一个MVC框架，PureMVC library。