谈谈Android项目框架的前世今生

嗨，大家好，今天出了大太阳，真是美好的开始。

这篇文章和大家说说Android届流行的三大框架，了解下架构的前世今生，以及我对于这些框架的一些认识和看法。

三大框架区别

MVC

• 架构介绍

Model：数据模型，比如我们从数据库或者网络获取数据

View：视图，也就是我们的xml布局文件

Controller：控制器，也就是我们的Activity

• 模型联系

View --> Controller，也就是反应View的一些用户事件（点击触摸事件）到Activity上。

Controller --> Model, 也就是Activity去读写一些我们需要的数据。

Controller --> View, 也就是Activity在获取数据之后，将更新内容反映到View上。

这样一个完整的项目架构就出来了，也是我们早期进行开发比较常用的项目架构。

• 优缺点

这种缺点还是比较明显的，主要表现就是我们的Activity太重了，经常一写就是几百上千行了。

造成这种问题的原因就是Controller层和View层的关系太过紧密，也就是Activity中有太多操作View的代码了。

但是！但是！其实Android这种并称不上传统的MVC结构，因为Activity又可以叫View层又可以叫Controller层，所以我觉得这种Android默认的开发结构，其实称不上什么MVC项目架构，因为他本身就是Android一开始默认的开发形式，所有东西都往Activity中丢，然后能封装的封装一下，根本分不出来这些层级。当然这是我个人看法，可以都来讨论下。

MVP

• 架构介绍

之前不就是因为Activity中有操作view，又做Controller工作吗。

所以其实MVP架构就是从原来的Activity层把view和Controller区分开，单独抽出来一层Presenter作为原来Controller的职位。

然后最后演化成，将View层写成接口的形式，然后Activity去实现View接口，最后在Presenter类中去实现方法。

Model：数据模型，比如我们从数据库或者网络获取数据。

View：视图，也就是我们的xml布局文件和Activity。

Presenter：主持人，单独的类，只做调度工作。

• 模型联系

View --> Presenter，反应View的一些用户事件到Presenter上。

Presenter --> Model, Presenter去读写操作一些我们需要的数据。

Controller --> View, Presenter在获取数据之后，将更新内容反馈给Activity，进行view更新。

• 优缺点

这种的优点就是确实大大减少了Activity的负担，让Activity主要承担一个更新View的工作，然后把跟Model交互的工作转移给了Presenter，从而由Presenter方来控制和交互Model方以及View方。所以让项目更加明确简单，顺序性思维开发。

缺点也很明显：

首先就是代码量大大增加了，每个页面或者说功能点，都要专门写一个Presenter类，并且由于是面向接口编程，需要增加大量接口，会有大量繁琐的回调。

其次，由于Presenter里持有了Activity对象，所以可能会导致内存泄漏或者view空指针，这也是需要注意的地方。

MVVM

• 架构介绍

MVVM的特点就是双向绑定，并且有Google官方加持，更新了Jetpack中很多架构组件，比如ViewModel，Livedata，DataBinding等等，所以这个是现在的主流框架和官方推崇的框架。

Model：数据模型，比如我们从数据库或者网络获取数据。

View：视图，也就是我们的xml布局文件和Activity。

ViewModel：关联层，将Model和View绑定，使他们之间可以相互绑定实时更新

• 模型联系

View --> ViewModel -->View，双向绑定，数据改动可以反映到界面，界面的修改可以反映到数据。

ViewModel --> Model, 操作一些我们需要的数据。

• 优缺点

优点就是官方大力支持，所以也更新了很多相关库，让MVVM架构更强更好用，而且双向绑定的特点可以让我们省去很多View和Model的交互。也基本解决了上面两个架构的问题。

说说我理解的MVVM

先说说MVVM是怎么解决了其他两个架构所在的缺陷和问题：

• 解决了各个层级之间耦合度太高的问题，也就是更好的完成了解耦。MVP层中，Presenter还是会持有View的引用，但是在MVVM中，View和Model进行双向绑定，从而使viewModel基本只需要处理业务逻辑，无需关系界面相关的元素了。

• 解决了代码量太多，或者模式化代码太多的问题。由于双向绑定，所以UI相关的代码就少了很多，这也是代码量少的关键。而这其中起到比较关键的组件就是DataBinding，使所有的UI变动都交给了被观察的数据模型。

• 解决了可能会有的内存泄漏问题。MVVM架构组件中有一个组件是LiveData，它具有生命周期感知能力，可以感知到Activity等的生命周期，所以就可以在其关联的生命周期遭到销毁后自行清理，就大大减少了内存泄漏问题。

• 解决了因为Activity停止而导致的View空指针问题。在MVVM中使用了LiveData，那么在需要更新View的时候，如果观察者的生命周期处于非活跃状态（如返回栈中的 Activity），则它不会接收任何 LiveData 事件。也就是他会保证在界面可见的时候才会进行响应，这样就解决了空指针问题。

• 解决了生命周期管理问题。这主要得益于Lifecycle组件，它使得一些控件可以对生命周期进行观察，就能随时随地进行生命周期事件。

再说说响应式编程

响应式编程，说白了就是我先构建好事物之间的关系，然后就可以不用管了。他们之间会因为这层关系而互相驱动。

其实也就是我们常说的观察者模式，或者说订阅发布模式。

为什么说这个呢，因为MVVM的本质思想就是类似这种。不管是双向绑定，还是生命周期感知，其实都是一种观察者模式，使所有事物变得可观察，那么我们只需要把这种观察关系给稳定住，那么项目也就稳健了。

最后再说说MVVM为什么这么强大？

我个人觉得，MVVM强大不是因为这个架构本身，而是因为这种响应式编程的优势比较大，再加上Google官方的大力支持，出了这么多支持的组件，来维系MVVM架构，其实也是官方想进行项目架构的统一。

优秀的架构思想+官方支持=强大

拜拜

有一起学习的小伙伴可以关注下️我的公众号——码上积木，每天三问面试真题，详细剖析，助你成为offer收割机。