重新整理笔记，文章最后没有展开讲，过段时间再来翻新。

MVC vs. MVP vs. MVVM

Android推出DataBinding工具帮助开发者实现MVVM架构，为什么现在需要MVVM架构？这里得从MVC说起。
随着项目越来越大，开发一款App的人数高达百人，MVC项目中C(Activity Fragment)的代码越来越臃肿，C的压力越来越大，代码高度耦合，维护成本高昂容易出现问题。
MVC：

V  <---  C
|        ^
|__> M __|

这个时候我们需要对C进行解耦，这个时候MVP出现了，在MVP中将原来C中与底层数据相关的逻辑代码抽离到P，而抽离之后的C(Activity、Fragment、Dialog)的角色定位也发生了变化，在MVP中他们变成了V，操作数据相关的逻辑被放到了P。
MVP:

  V <=> P <=> M

三者的交互关系发生了变化，由原来的闭环变成了双向。对于V 、 M两个来说想要彼此通信就需要在P中定义接口，比如在P层规定网络访问接口，V层异步调用该接口，当数据返回后需要通知V定义的更新UI的接口。
基于这样的模式，当存在大量访问数据的接口与更新UI的接口，维护接口就是一件高昂的事情。那么有没有更好的方案不需要维护大量的接口？
有的，通过观察者模式我们可以注册数据变化的观察者，当数据发生了变化，就及时的响应更新UI,这样具备观察者模式的对象统称为Observable(或者State)，其聚集地叫做ViewModel，所以演化出了MVVM。
MVVM:

  V <---> VM <=> M

那么对于Android如何实现双向绑定(data binding,View发生变化自动响应Model，Model发生变化自动响应View) ?

这里有两个方案DataBinding vs. Jetpack Compose。

DataBinding

DataBinding工具在编译期会解析layout文件，生成android系统渲染的布局文件以及layout文件中可观察者对应的ViewDataBinding子类。
当Model发生变化，数据流会自下而上发送，更改ViewModel中的Observable数据然后WeakPropertyListener通知ViewDataBinding#requestRebind进行下一帧重绘。
当View层控件与用户发生交互，数据流自上而下传递或者由自己流向其他控件，控件的listener会更新Observable数据，然后响应绑定Observable的其他控件或者底层发送网络请求

这里可以查找模板代码spacecraft-android项目下的PoemView、InfosViewModel实现了双向绑定