APP开发最让人头疼的就是业务逻辑和UI代码混合起来，造成后期APP很难维护，新需求越来越难加入，因为依赖太多了，而且纷繁复杂。后来有人提出MVP模式，
既然业务逻辑要依赖UI，那么为什么不把他们之间用一个接口隔离开呢，让业务逻辑依赖UI更新的接口而不管具体的UI是如何更新的，更新UI的具体代码则交给Activity来做。当我们进行实践的时候，问题来了，我们需要定义大量接口，而且看似架构很严谨的MVP模式在实际应用当中变得过于臃肿。好了，既然出现了这个问题，那就得解决，Presenter臃肿，有人单独提出一个Presenter分开成多个并且按功能模块划分，对于Presenter来说这样划分是很合理的。同理ViewModel。 但是IView层就还是老样子，即使我们缩减接口，并用方法参数代替要更新哪个UI也没有解决接口爆炸的问题。而且还有了新的问题，那就是我更新UI的时候Activity我并不知道是否已经走了onDestory。 MVP的设计模式根本问题在于接口爆炸，要想减少接口，那必须让业务逻辑和UI逻辑不依赖同一个接口，那尝试一下让UI依赖Model吧，也就是说不管我们业务逻辑如何变化，最终更新UI我们只需要更新Model，MVVM诞生了。
我觉得没有必要纠结形式，MVVM其实就是观察者模式，使用观察者代替接口，而被观测的对象就是Model。我们再也不需要在UI需要更新的时候去通知接口了，当需要更新UI的时候直接通知观察者。而观察者保存在Activity当中，并且感知Activity的生命周期变化，这样观察者就可以决定是否要执行UI的更新。
总结，我们仍然可以使用Presenter来划分我们的业务逻辑，然后当需要更新UI的时候通知观察者，即更新Model来驱动，如此Activity依赖ViewModel注册观察者， Presenter依赖ViewModel通知观察者。我认为，这应该才是MVP最佳的实践。由接口爆炸变成了观察者和被观察者爆炸，但是我们不用严格的遵循必须实现那个定死的更新UI的接口了。我们将每个业务过程当做一个状态机，随着业务流程的进行，model的状态会发生改变，这样我们通过观察者来更新UI就成为了可能， 并且这些状态不是零散的，而是随业务逻辑有规则变化的。
demo 参见：
https://github.com/zcwfeng/zcw_android_demo
android_mvp
网友评论