俗话说,无规矩不成方圆,对于项目也是这样,必须有统一的架构体系才能让项目更加稳健,开放,和快速。今天就来谈谈吧:
这个问题大家就真实回答就好,重点是要说完后提出对自己项目架构的认同或不认同的观点,也就是要有自己的思考和想法。
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中丢,然后能封装的封装一下,根本分不出来这些层级。当然这是我个人看法
,可以都来讨论下。
之前不就是因为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
的特点就是双向绑定,并且有Google官方加持,更新了Jetpack中很多架构组件,比如ViewModel,Livedata,DataBinding
等等,所以这个是现在的主流框架和官方推崇的框架。
Model
:数据模型,比如我们从数据库或者网络获取数据。View
:视图,也就是我们的xml布局文件和Activity。ViewModel
:关联层,将Model和View绑定,使他们之间可以相互绑定实时更新
View --> ViewModel -->View
,双向绑定,数据改动可以反映到界面,界面的修改可以反映到数据。ViewModel --> Model
, 操作一些我们需要的数据。
优点就是官方大力支持,所以也更新了很多相关库,让MVVM
架构更强更好用,而且双向绑定的特点可以让我们省去很多View和Model的交互。也基本解决了上面两个架构的问题。
1)先说说MVVM是怎么解决了其他两个架构所在的缺陷和问题:
解决了各个层级之间耦合度太高的问题
,也就是更好的完成了解耦。MVP层中,Presenter还是会持有View的引用,但是在MVVM中,View和Model进行双向绑定,从而使viewModel基本只需要处理业务逻辑,无需关系界面相关的元素了。解决了代码量太多,或者模式化代码太多的问题
。由于双向绑定,所以UI相关的代码就少了很多,这也是代码量少的关键。而这其中起到比较关键的组件就是DataBinding,使所有的UI变动都交给了被观察的数据模型。解决了可能会有的内存泄漏问题
。MVVM架构组件中有一个组件是LiveData,它具有生命周期感知能力,可以感知到Activity等的生命周期,所以就可以在其关联的生命周期遭到销毁后自行清理,就大大减少了内存泄漏问题。解决了因为Activity停止而导致的View空指针问题
。在MVVM中使用了LiveData,那么在需要更新View的时候,如果观察者的生命周期处于非活跃状态(如返回栈中的 Activity),则它不会接收任何 LiveData 事件。也就是他会保证在界面可见的时候才会进行响应,这样就解决了空指针问题。解决了生命周期管理问题
。这主要得益于Lifecycle组件,它使得一些控件可以对生命周期进行观察,就能随时随地进行生命周期事件。2)再说说响应式编程
响应式编程
,说白了就是我先构建好事物之间的关系,然后就可以不用管了。他们之间会因为这层关系而互相驱动。其实也就是我们常说的观察者模式,或者说订阅发布模式。
为什么说这个呢,因为MVVM
的本质思想就是类似这种。不管是双向绑定,还是生命周期感知,其实都是一种观察者模式,使所有事物变得可观察,那么我们只需要把这种观察关系给稳定住,那么项目也就稳健了。
3)最后再说说MVVM为什么这么强大?
我个人觉得,MVVM
强大不是因为这个架构本身,而是因为这种响应式编程的优势比较大,再加上Google
官方的大力支持,出了这么多支持的组件,来维系MVVM架构,其实也是官方想进行项目架构的统一。
优秀的架构思想+官方支持=强大