MVVM MVP MVC总结与对比

  在安卓项目中使用到了MVVM架构，正好来总结分析一下MVVM架构，并且与MVP，MVC做个对比，也是我一个深入学习的过程。其实这些架构的主旨只是一个，降低耦合度，便于维护。如果一股脑的写好了一个项目，没有这些架构的约束，维护的困难程度可想而知。

  从MVC架构说起:
        官方原话是:经典MVC模式中，M是指模型，V是视图，C则是控制器，使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。

        MVC架构在很多项目中都有体现，网页，早期的app等等。M是model的意思，是用来存储数据的，比如一些类等都可以归于model。V是view的意思，是界面，ui的一些代码。C是control的意思，是用来控制model的代码。

但是mvc架构更多的内存消耗。Model中的内容都可以从界面获取到，因此，Model的引入增加了内存消耗。MVP架构随即出现。

MVP：

MVP是由MVC演变而来的。在MVC的基础上，MVP强调Model与View之间的隔离，两者互不感知。MVP的架构图如下：

        MVP架构了解不多，个人感觉是让presenter层持有model和view，相互监听控制。

MVVM：

        MVVM（Model-View-ViewModel）也是MVC的演变而来。由微软公司提出并在WPF上大量应用。MVVM强调数据绑定，从而省去了模型数据改变后通知数据更新的步骤。MVVM的架构图如下：

        在项目中我用到了mvvm架构，我展开讲一下我的理解和一些架构的细节。

        view，model和前两个架构大同小异，主要是: viewmode

        ViewModel是Android Jetpack的一个状态容器，他存在于一个activity里。viewmodel持有model层，进行业务逻辑的处理。view层持有viewmodel，viewmodel最大的优势是可以在一个activity里持有所有数据，在多个fragment切换时也可以保存数据状态。另外,viewmodel层解决了MVP中Presenter持有view的引用的这种情况。他可以将数据通过观察者模式进行感知，当相应的数据发生变化时，view也随之改变。相对于MVP来说 去除view的引用是很有必要的，因为如果进行一些耗时操作，相应的操作没有做完时，应用退出，就容易造成内存泄漏。MVVM自动的就规避了这个问题。app销毁时，也会自动的解除数据监听。