APP架构进化——MVx的演进史

1.APP架构的目的

 APP架构演变：一个文件打天下——>mvc——>mvp——>mvvm。

架构的最终目的是实现APP程序可读、可并行开发、易扩展、易维护。应根据工程的量级，做合适的设计，切勿为了架构而架构。

2.MVC

2.1MVC简介

                                             

• Model（数据）：包括数据+对数据进行的操作（不依赖视图的操作）。

• View（视图）：xml+Activity+Fragment，处理界面的显示结果。

• Controller（逻辑）：包括Activity/Fragment，起到桥梁的作用，用来控制M层和V层通信，达到分离界面展示和业务逻辑层。

View层持有Controller，把事件传递给Controller，Controller由此去触发Model层的事件，Model层更新完数据（网络或本地数据）之后触发View层更新数据。

2.2MCV优缺点

• 优点

       分离了model和Controller，实现了界面、逻辑、数据的分离，在修改界面的同时，不需要修改业务逻辑，降低耦合。

• 缺点

      Activity同时承担着View和Controller的责任，随着界面和逻辑的逐渐增加，activity的职责不断增加，以至于变得臃肿。

3.MVP

3.1MVP简介

      MVP是由MVC演变而来的，与MVC有相似性：Controller/Presenter负责逻辑处理，Model处理数据，View负责显示。

    View持有Presenter的实例，Presenter持有View和Model的接口。Model获取数据后，不直接更新View，而是通过Presenter更新View。

                      

MVP模式里通常包含三个要素（加上View interface是四个）：

• View：负责绘制UI元素，与用户进行交互（Android中的Activity、xml文件）。

• Model：负责文件、数据库、网络的操作（有时也实现一个Model interface降低耦合）。

• Presenter：作为View和Model的中间纽带，负责处理用户交互的逻辑。

• View interface：需要view实现的接口，View通过View interface与Presenter进行交互，降低耦合，方便单元测试。

在MVC基础上，把Activity中复杂的逻辑处理移至Presenter中，Activity只负责初始化UI，加载界面，并且View与Model不直接交互，Model处理数据结果，通过Presenter反馈给View。

3.2MVP优缺点

• 优点

      在MVC的基础上，通过interface彻底分离了View和Model。Activity只剩下了View，Presenter承担了View和Model之间的交互，满足了单一职责原则，界面、逻辑、数据更加。

• 缺点

1. 引入了interface，View和Model都得写接口，接口粒度不好控制，另外增加一个方法要改几个地方。
2. Prenter持有View的引用，更新UI时，需要考虑生命周期，以及Activity引用的处理，防止内存泄漏。

4.MVVM

4.1MVVM简介

MVVM是MVP的升级版，ViewModel和View之间的交互通过DataBinding完成，而DataBinding可以实现双向的交互，这就使得视图和控制层之间的耦合程度进一步降低。

• Model: 数据+对数据进行的操作。

• View: 对应于Activity和XML，负责View的绘制以及与用户交互。

• ViewModel: View的数据模型和Presenter的合体，负责完成View与Model间的交互，以及业务逻辑。                                     

      dataBinding使得Viewmodel能感知View的生命周期，View的声生命周期结束时，会调用ViewModel的onCleared()方法，开发者可在此方法中，进行取消网络请求等操作，减少因View生命周期结束，造成的崩溃及内存泄漏问题。

4.2MVVM优缺点

• 优点

1. View与ViewModel之间，利用databinding框架实现双向绑定，当数据变化的时候UI自动更新，UI上用户操作数据自动更新，很好的做到数据的一致性。
2. xml和activity处理ui操作、model提供数据、vm处理业务逻辑，各个层级分工明确，activity中代码大大减少项目整体结构更加清晰。

• 缺点

      xml中包含代码逻辑。

5.MVx比较

6.APP架构

     APP架构不拘泥于MVx某一种设计思想的实现，需要在MVx的基础上实现层次化、模块化、组件化、控件化。

     控件化，可理解成自定义View。自定义View只负责与自己相关的业务，满足了单一职责原则；所有view的相关操作都在view里面，符合开闭原则。

    层次化维度，一个APP包含业务模块层、Common层、网络层、Base层，如下图：

• 业务模块：

      APP具体业务，各业务模块之间实现组件化（组件化待续……）。

• Common模块：

       包含：公共view、组件化路由、service接口的定义等。

• 网络模块：
• Base模块：

       BaseClass、工具类等。

      定义基类，如BaseActivity、BaseFramgent、BaseModel、BaseViewModel等，通用逻辑在基类中处理，减少派生类业务逻辑。基类中成员变量类型不确定时。灵活使用泛型。