移动端的架构演变

Posted 2023-02-17 Anonymous-OS

 

一、架构设计目的

通过设计使程序模块化，做到模块内部的高聚合和模块之间的低耦合，这样做的好处是使得程序在开发的过程中，开发人员只需要专注于一点，提高程序开发的效率，并且更容易进行后续的测试以及定位问题。

对于不同量级的工程，具体架构的实现方式必然是不同的，所以对于移动端来说，逐渐演变出MCV、MVP、MVVM三种结构模式。

 

二、MVC架构模式

1、工作模块

• View（视图）:界面渲染
• Controller（控制器）: 业务逻辑处理
• Model（模型）:数据提供

2、工作流程

1. View将请求转交给Controller
2. Controller操作Model进行数据更新
3. 数据更新之后，Model通知View数据变化
4. View显示更新之后的数据

3、架构缺陷

MVC看似各施其职，互不干涉，但是互联网发展了很多年了，随着业务不断的迭代，复杂度不断的提高，MVC模式的缺陷也被越来越多的开发者们所诟病。

在android早期开发中使用的是都是MVC架构，这是一种非标准的MVC架构，Controller和View并没有解耦，因为Activity或Fragment既承担Controller的角色，又承担了View的角色。因为UI的更新几乎都是在Activity或Fragment中进行，一旦工程的量级上来，就会导致Controller层变得及其臃肿且难以维护。

 

由于 Controller 和 View 的揉合，回调嵌套太多，代码逻辑不清晰，难以理解且不利于后期维护，各层次模块之间职责不清晰等等。

 

三、MVP架构模式

在2016年，Google 推出了 MVP 架构，MVP是从经典的MVC模式演变而来。在尝试使用的过程中发现这种架构模式能解决现在所面临过的很多问题。

1、工作模块

• View（视图）: 界面渲染
• Presenter（调度器）: 业务逻辑处理
• Model（模型）: 数据提供

2、工作流程

1. View将请求转交给Presenter
2. Presenter操作Model进行数据请求
3. 数据更新之后，Model通知Presenter数据发生变化
4. Presenter更新View的数据

3、设计优势

明显可以看到，MVP和MVC最大的不同之处是View与Model完全隔离，这就意味着，在Android开中，就可以明确的把Activity当作View处理,而不需要多承担Controller的作用，Controller和View完全解耦。如果Model或View中的一方发生变化，只要交互接口不变，另一方就没必要对上述变化做出改变，使得Model层的业务逻辑具有很好的灵活性和可重用性，耦合性降低。对于后期维护来说，特别是项目越来越庞大时，可以很快的梳理出项目结构，很方便的进行管理。

下面通过几段实例代码来体现一下MVP模式的事件流

首先要定义几个事件接口来作为view和presenter之间的契约。

在MVP模式中，View层只负责数据的渲染和展示，所以对于事件的监听，我们统一通过接口的形式交给Presenter进行接管，数据更新的时候，我们又通过接口的形式将数据回调给View层进行更新。

Presenter层则会驱动Model拿到最新的数据，我们也可以通过泛型封装去简化掉Model层，因为我们主要的目的是将Controller和View进行解耦，通过Presenter作为中间桥梁进行通信。当数据更新时，Presenter又会将数据通过接口通知给View，构建了一条简单的MVP模式的数据链路。

4、架构缺陷

尽管这样，MVP模式还是有不足之处。因为Presenter层与View层是通过接口进行交互的，如果好几个Activity都是去实现同一个View接口，这就导致View层可能会有大量的接口，那么不管你是否用到，所有用到的Activity都要去实现该接口的所有方法；如果对Activity去进行实现单一View接口维护的话，每一个View都要去创建对应的Presenter和View接口。会导致出现大量的类，你的工程体系将会变得很庞大，如下图：

另外，对于一些业务比较复杂的界面，你的Presenter需要去实现很多的接口，这样会导致Presenter层太大，逻辑比较复杂，代码臃肿的依然是个问题。

 

四、MVVM架构模式

MVVM架构模式目前广泛的用于移动端和前端的开发，大名鼎鼎的Vue响应式编程用的就是这种设计，其双向绑定更是将观察者模式完美得体现。

1、工作模块:

• View（视图）: 界面渲染
• ViewModel（调度器）: 业务逻辑处理
• Model（模型）: 数据提供

2、工作流程:

1. 在View中来绑定事件和响应事件，进行事件的触发
2. ViewModel操作Model的去获取数据
3. Model去请求数据
4. 服务器或数据库将数据返回到Model层中
5. ViewModel在回调中收到返回的实体类对象
6. 实体类更新，驱动UI更新

3、设计优势

在MVVM中，数据是核心，由于VIewModel与View之间的双向绑定，操作了ViewModel中的数据，就会同步到DOM，我们透过DOM事件监控用户对DOM的改动，也会同步到ViewModel，很好做到数据的一致性。不仅如此，因为双向绑定的存在，View的功能进一步强化，Controller的功能大都移动到了View上处理，大大的简化Controller，业务复杂、代码臃肿的问题得到了解决。

4、架构缺陷

了解MVVM之后，我们会发现双向绑定确实简化了控制层，能够适用于复杂的业务场景，保证了数据的一致性的同时，也大大的增加了Model层。如果长期持有，不释放内存就造成了花费更多的内存，处理不当，就会导致内存溢出或内存泄露的问题出现。

移动端开发最常用的重用是View，但是数据双向绑定技术，让你在一个View都绑定了一个Model，不同模块的Model都不同，就会导致不利于代码重用。

 

五、总结

从 MVC 架构模式到 MVVM， 这几个软件设计模式是一步步演化发展的，从分离展示层到展示模型层，经过这么长时间的发展和演变，MVC 架构模式出现了各式各样的变种，并切在不同的平台上有着自己的表现，下面是对三种架构模式的统一对比：

模式	优势	缺陷
MVC	模块独立，组件重用	1、Controller和View耦合度高 2、逻辑回调和嵌套复杂
MVP	1、Controller和View完全解耦 2、方便大型项目管理	1、接口泛化、难以维护 2、Presenter层代码臃肿
MVVM	双向绑定，简化业务代码	内存溢出和泄露的风险 不利于代码复用

有些Android开发工程师认为为了双向绑定而使用MVVM模式显得很生硬，对于大型项目的协同开发，“MVP+组件化”开发则有着天然的优势，更有人说Google的AAC架构更好用。对此我不做评价，因为没有最好的，只有适合的。每个平台本身往往对应用层有着自己的设计。场景不同，选择不同，但是目的都是一样的，都是为了解决复杂度，提供高性能、高可用、可扩展的应用。

 

《MVP架构搭建》

《MVVM实现组件化架构》