移动端软件架构

架构设计是分与合的艺术

软件架构描述为计算组件与组件之间的交互，架构=组件+交互；
架构属于设计，涉及的决策，往往对整体质量、并行开发、适应变化等方面有着重大的影响：
模块如何划分；
模块的职责；
模块的接口如何定义；
模块之间的交互机制；
开发技术如何选型；
如何满足约束和质量属性的需求；
如何适应可能发生的变化等；
实际的设计往往分层次依次展开，即对于一个独立的软件系统而言，通常被划分为不同的子系统或分系统，每个部分承担相对独立的功能，各部分之间通过特定的交互机制进行协作；
最后完整的软件是由组件递归组合而成。
对于移动端开发来说，有几种常用的框架：

MVC

模块被分为数据模型（Model），用户界面（View）和控制器（Controller）；
Model（模型）负责业务数据管理和处理，包括增删改查，Model必须提供外部可以操作模型数据的接口，同时在数据发生变化后能够通知外部；
View（视图）用户界面，View需要感知Model的变化，数据变化时，更新用户界面；
Controller（控制器）业务逻辑层，Controller需要感知View的事件，调用Model提供的接口对数据进行操作；
优点：
解耦性好：MVC模式将应用程序分为三个独立的组件，使它们之间的依赖关系降到最低，提高了应用程序的可维护性和可扩展性；
可重用性好：MVC模式中的每个组件都是相对独立的，可以被其他应用程序重复使用，提高了代码的可重用性；
易于维护：MVC模式中的每个组件都具有清晰的职责和功能，使得应用程序变得易于维护；
缺点：
MVC引入了更多概念，增加了项目结构和实现的复杂性，将其应用到中小规模项目通常得不偿失；
Model中的内容都可以从界面获取到，因此，Model的引入增加了内存消耗；
因为实现的复杂性，势必会导致性能降低；

MVP

模块划分为主导地位的Presenter、Model、View；
MVP是由MVC演化而来，Presenter充当Model和View的桥梁，负责两者之间的隔离；
Model通知Presenter业务数据变化，Presenter调用View更新用户界面；
View感知用户操作通知Presenter，Presenter调用Model进行业务处理；
优点：
解耦，视图和模型完全分离，MVC常常会因为V和M的耦合性太强而渐渐导致C失去控制作用；
所有交互都在P中实现，M的设计可以更加灵活，有利于M的高效使用；
缺点：
Presente层与View层是通过接口进行交互的，交互会过于频繁，接口粒度不好控制，粒度太小，就会存在大量接口的情况，使代码太过碎版化;粒度太大，解耦效果不好；
View层与Presenter层还是有一定的耦合度，一旦视图变更了，presenter也要变更；
使用MVP模式去构建项目，会造成类文件和接口文件的过多，代码臃肿，进而增大包的体积。

MVVM

模块划分为业务数据（Model）、用户界面（View）、ViewModel；
ViewModel在界面渲染完成后，将声明绑定到View上的业务数据和View进行双向绑定，同步更新；
相应View的事件，操纵Model实现业务处理；
优点：
解耦更彻底；
开发效率高，产品开发生命周期短；
通过数据双向绑定，不需要手动更新界面，实现了关注点分离，降低了开发的复杂性和工作量；
双向绑定可以通过感知模型数据的变化提前感知界面即将发生的变化，优化该过程，可以提高界面的渲染速度，避免重复渲染；
缺点：
数据绑定会消耗额外资源，占用更多的内存；
数据绑定会导致模型数据的变化变得难以追踪，调试困难；
数据双向绑定不利于代码重用。