何谓MVC、MVP、MVVM

Model（数据层）：负责处理数据逻辑。
View（视图层）：负责处理视图显示，在Android中使用xml描述视图。
Controller（控制层）：在Android中的Activity和Fragment承担此层的重任，负责处理业务逻辑。
这里要注意的是，Activity和Fragment并非是标准的Controller，因为它们不仅要负责处理业务逻辑，还要去控制界面显示，这样导致的结果是随着业务的复杂度不断提高，Activity和Fragment会变得非常臃肿，不利于代码的维护。

MVP（Model-View-Presenter）是MVC进一步演化出来的，由Microsoft的Martin Fowler提出。

Model（数据层）：负责处理数据逻辑。
View（视图层）：负责处理视图显示，在Android中使用xml或者Java/Kotlin代码去实现视图，Activity和Fragment承担了此层的责任。
Presenter：负责连接Model层和View层，是这两层的中间纽带，负责处理业务逻辑。
在MVP中，Model层和View层之间不能有交互，要通过Presenter层进行交互，其中View层和Presenter层是通过接口进行交互，可以定义Contract（契约）接口来指定View层和Presenter之间的契约。官网示例:

interface AddEditTaskContract {

  interface View : BaseView<Presenter> {

      var isActive: Boolean

      fun showEmptyTaskError()

      fun showTasksList()

      fun setTitle(title: String)

      fun setDescription(description: String)

      }

      interface Presenter : BasePresenter {

      var isDataMissing: Boolean

      fun saveTask(title: String, description: String)

      fun populateTask()

      }

    }

在MVP中，View层不会部署任何的业务逻辑，从而比较薄，它被称为被动视图（Passive View），意思是它没有任何的主动性，而且这样的设计也方便做单元测试，但是也会有如下问题：

尽管减少了View层的代码，但是随着业务的复杂度不断提高，Presenter层的代码也会变得越来越臃肿。
View层和Presenter层是通过接口交互的，随着业务的复杂度不断提高，接口数量会大量增加。
如果View层更新的话，就像UI的输入和数据的变化，都需要主动去调用Presenter层的代码，缺乏自动性和监听性。
MVP是以UI和事件为驱动的传统模型，更新UI需要保证能持有控件的引用，而且更新UI需要考虑Activity或者Fragment的生命周期，防止内存泄漏。

MVVM（Model-View-ViewModel）是MVP进一步演化出来的，它也是由Microsoft的Martin Fowler提出。

Model（数据层）：负责处理数据逻辑。
View（视图层）：负责处理视图显示，在Android中使用xml或者Java/Kotlin代码去实现视图，Activity和Fragment承担了此层的责任。
ViewModel：负责连接Model层和View层，是这两层的中间纽带，负责处理业务逻辑，View层和ViewModel层是双向绑定的，View层的变动会自动反映在ViewModel层，ViewModel层的变动也会自动反映在View层。
使用MVVM后，每一层的职责也更加清晰了，也方便做单元测试，同时因为View层和ViewModel层是双向绑定，开发者不需要再去主动处理部分逻辑了，减少了不少胶水代码，如果使用了一些数据绑定的库，例如在Android中的DataBinding，可以减少更加多的胶水代码。