MVX演进史

        一般我们开发都会用到架构，MVC MVP MVVM，或者直接不用。

1、M： Model 数据/模型：数据的获取以及对数据进行的不依赖view的操作

2、V： View 视图：在不同架构中，充当的角色也不一样；xml/composable/kolin

3、C/P/VM Controller/ViewModel/Presenter 逻辑：模型与视图之间的交互及数据

一、不用任何架构编写代码：

会导致一个文件包含所有代码，导致后面的代码越来越臃肿；这种一般适用于功能简单、需求不怎么变化，比如：关于页面、隐私条款、用户协议、帮众中心等。

二、MVC

M： Model 数据/模型：数据的获取以及对数据进行的不依赖view的操作

V： View 视图：xml

C: Controller：Activity/Fragment

应用场景，设置页面，只需剥离model的页面，适用于简单逻辑交互

优点：将model进行了剥离

缺点：作为Controller的Activity里面包含了很多的View代码，随着需求的变化，因为Activity可以同时操作view和model，权利很多，大家很容易把越来越多的代码放到Activity中，导致后期Activity越来越臃肿

三、MVP

M： Model 数据/模型：数据的获取以及对数据进行的不依赖view的操作

V： View 视图：xml/activity/fragment/view的interface

P: Presenter：view和model的交互和数据

为什么V中会包含view的interface呢，因为如果不这样，Presenter的权利太大了，拥有activity或者fragment的引用，到时候Presenter后期会变的越来越臃肿

应用场景：需求多变、主页面、重要的页面

优点：充分解耦、逻辑清晰、可读性、可维护

缺点：增加了接口，每次修改或者添加一个功能时，需要修改多个文件

四、MVVM

M： Model 数据/模型：数据的获取以及对数据进行的不依赖view的操作

V： View 视图：xml/activity/fragment，去掉了MVP中View的interface，改为双向的数据绑定，比如Google的databinding

ViewModel：变量，注册register observer

        注意：databinding的开关需要在使用module和APP中同时打开

        ViewBinding：是DataBinding的缩水版，一般用于老代码中增加功能

        DataBinding：Android中Google的databinding比viewBinding早出来几年。

应用场景：需求多变、主页面、重要的页面

优点：充分解耦、逻辑清晰、可读性、可维护、没有了view的interface

缺点：XML中有代码，容易报错、编译慢、一来databinding