结构图
各部分组成
MVC
M：model
V: view
C: controller
用户通过V层的交互行为 通知到 C层，然后C层通知到M层，进行相关操作例如数据获取等，在M得导数据后通知V层进行更新
如果单从结构图中，可以得到如上结论，不过实际上，很少有M层通知V层再来进行更新的，即很少有M层去持有V层进行更新。通常都是activity获得数据后直接进行更新，而activity在该模式下，相当于C与V的结合，所以M-V更新的操作，也可以化为C-V更新
MVP
M：model
V: view
C: presenter
用户通过V层的交互行为 通知到P层，然后P层通知到M层，进行相关操作例如数据获取等，在M得导数据后通知P层进行更新，P层通过V的持有进行V的更新
MVC MVP区别
MVC如果单从结构图中，可以得到如上结论，不过实际上，很少有M层通知V层再来进行更新的，通常都是activity获得数据后直接进行更新，而activity在该模式下，相当于C与V的结合，所以M-V更新的操作，也可以化为C-V更新，那么此时，MVC MVP的结构图就非常相近了，也就是如果把C改名为P，那么几乎也就是相同的东西。
通常网上经常会说他们的区别在于M V之间的解耦，但是实际上，很少有M V之间有关系的MVC吧，通常都会是充当V C的activity进行这些操作。所以这并不是其主要区别。还有说的区别在于将activity职责分隔，分隔出职责更符合的P层来进行操作，但是实际上，如果我们不把activity既当作C又当做V的话，也是可以将其职责分隔（将V层单独抽离或者将C层单独抽离都是可以的）。
所以，本质上，MVC MVP并无什么区别，当然是针对正确的MVC（也不能说对错吧，就是mvc的理解上，网上的观点很多），大多数人写MVC就是直接一窝塞。但其实将MVC职责也分隔的很彻底的话，那么MVC MVP几乎一摸一样，就是起的名字不一样吧。。。
MVVM
M：model
V: view
VM: viewmodel
从图中可看到，MVVM相比于MVP，P层变为了VM层，且P层与V层之间的交互，变为了VM与V的双向绑定。双向绑定，也就是为了数据的绑定（表现数据与内存数据互相绑定互相更新），其本质就是数据改变的监听器。MVVM通常还会将内存数据与外部数据（数据库数据）进行关联监听。使这三种数据进行联动。
