什么'；Android开发中的设计模式原则？

我是一名JaveEE开发者。最近我加入了一个Android开发团队。安卓的结构让我很困惑。MVC设计模式似乎不适合Android开发。那么Android开发的设计模式原则是什么？我的意思是，关于如何编写一个干净、易读、有效的Android代码，有什么提示吗

Android中的操作、视图和活动是使用Android UI的烘焙方式，是模型-视图-模型模式的实现，该模式在结构上与模型-视图-控制器类似（与模型-视图-控制器在同一系列中）

就我所知，没有办法打破这种模式。这可能是可以做到的，但是您可能会失去现有模型所具有的所有好处，并且必须重写自己的UI层以使其正常工作

您可以在以下内容中找到MVC:

• 您可以通过分辨率/硬件等在各种XML文件中定义
• 您可以通过语言环境等在各种XML文件中定义您的语言
• 如果将数据存储在/assets/文件夹中或自定义数据存储在/assets/文件夹中，请阅读有关
• 您可以像这样扩展类，并通过
• 您可以为您的模型创建任意多的类，并拥有自己的包，这些包将充当结构
• 已经为你写了很多。数据库工具、Html、

没有一种MVC模式可以遵循。MVC只是或多或少地声明您不应该将数据和视图混为一谈，因此视图负责保存数据，或者处理数据的类直接影响视图

但是，尽管如此，Android处理类和资源的方式有时甚至迫使您遵循MVC模式。在我看来，更复杂的是那些有时对视图负责但同时又充当控制器的活动

---

如果您在xml文件中定义视图和布局，从res文件夹加载资源，如果您或多或少避免在代码中混入这些内容，那么您仍然遵循MVC模式。

我的印象是android编程模型与MS WPF非常相似。 XML布局定义，始终绑定到其中一个定义的代码。。。 因此，如果您想改进当前或正在开发的android项目而询问设计模式，那么您可能应该看看WPF实践和模式，以改进体系结构，比如MVVM

查看以下链接：

有一个小项目已经在尝试类似的事情：

---

cheers

Android开发主要是GUI开发，与Java中的Swing/AWT一样，它由许多匿名内部类组成，这些类对GUI事件做出反应。这正是让我远离Swing的原因之一……但我有一部Android手机，所以我会咬紧牙关克服它，就像许多苹果粉丝所说的天线问题一样

一开始，安卓的架构让我很恼火，但我开始发现一种方法可以解决他们的疯狂。android文档对此解释得很糟糕。我最大的抱怨一直是，很难像普通应用程序一样，用活动共享的对象建立一个集中的数据模型。安卓似乎想让我成为一名游牧者，因为我只能在我的活动之间共享原语。在数据库中丢弃垃圾不是一个模型，因为它不包含任何行为。因此，正如大多数人一样，我的业务逻辑最终都会出现在我的活动中，这使得我很难在其他活动中共享业务逻辑

我是来发现我遗漏了一些关键的拼图。Android是MVC。然而，它与视图的耦合程度相当高

活动==控制器

Model==应用程序的子类

任何将View==View子类化的内容

有趣的是，您可以创建应用程序的一个子类并在清单文件中声明它，而Android将创建该对象的一个实例，该实例在您的应用程序中一直存在，无论销毁或创建了什么活动。这意味着您可以在那里构建一个所有活动都可以访问的集中式数据模型

在我看来，这类似于一个基本的Spring容器，您可以初始化对象并解决它们之间的依赖关系。这样，您就可以将应用程序的模型部分与活动本身分离。只需让活动对模型进行调用，并手动回调以接收结果，这样它就可以更新UI

安卓系统的问题在于，它严重混合了控制器和视图。例如，TabActivity、ListActivity等子类暗示正在使用某个视图。因此，交换视图非常复杂。此外，即使您使用“活动”，控制器也会对视图内容做出非常具体的假设。他包含对诸如TextView等UI对象的直接引用，并注册诸如点击、键盘等低级事件

如果Activity可以注册更多高级事件（如“登录”、“更新帐户余额”等），视图将发送这些事件以响应一系列单击、键盘和触摸事件，这会更好。这样，控制器在您可能描述功能而不是设计功能的级别上工作

---

我认为，随着我们更好地理解并提出更好的工具和技术，我们最终将达到这种类型的设计。Android似乎具有实现这一点的可扩展性，但这取决于社区。Android做出了将控制器和视图作为单个类的典型决策。这会鼓励在同一个地方放太多东西。一个活动对应一个屏幕，每个视图对应一个屏幕区域（有时是整个屏幕），每个控制器对应该屏幕区域的用户手势，模型就是模型，