聊聊 MVP 的缺点

设计 MVP 的目的：

• 解锁 V 层的臃肿

极差体验：

一、继承
继承方式真的太糟糕了，BaseMVPActivity 自己是一种下沉到 lib 的通用类，但上层的业务层须要采用 BaseActivity 的方式来实现基础统计和埋点，意味着，我要么把 BaseMVPActivity 提到业务层，而后继承 BaseActivity，或是把 BaseActivity 下沉到 lib，供 BaseMVPActivity 继承，但个人业务统计就没办法用了。

public abstract class BaseMVPActivity<P extends MVPBasePresenter> extends BaseActivity implements MVPBaseView 复制代码

二、赋予 P 层生命周期感知

private P presenter;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        if (presenter == null) {
            presenter = createPresenter();
        }
        presenter.attach((V) this);
    }
    
    @Override
    protected void onDestroy() {
        presenter.detach();
        super.onDestroy();
    }
复制代码

这种方式优缺点都有：
优势是：V 层在结束页面时，无需关心数据的释放动做
缺点是：P 层在 detach 时操做了 M 层的耗时任务，会直接致使 V 层 ANR

我以为，P 层不该该具备生命周期的感知能力

三、糟糕的接口约束
V 层调用 P 层会制定一层接口来约束当前可调用的方法，P 层在完成任务动做时，也会经过约束接口将数据回调回给 V 层，接口制定以下:

public interface HandleContract {
    interface View extends BaseView {
        void startWayPointSuccess();
        void pauseWayPointSuccess();
        void resumeWayPointSuccess();
        void clearWayPointSuccess();
        void stopWayPointSuccess();
    }
    interface Present extends BasePresenter {
        void startWayPointMission();
        void pauseWayPointMission();
        void resumeWayPointMission();
        void clearWayPointMission();
        void stopWayPointMission();
    }
}
复制代码

以前一直认为，经过接口约束来实现 V 与 P 的调用模板，能够很清晰的明白双方的执行动做，但，在业务的持续变化中，因为某些接口约束已再也不有用，我就须要不停的去修改这个接口模板，修改了模板以后，我还要去修改 V 层实现的方法，P 层实现的方法，而且，当业务量上来以后，整个接口调用层很是乱，为了跟踪一个功能，V 层跳 P ，P 层跳 V，跳了好几层，终于明白了这个功能实现了什么动做。

想法

我一直认为 ViewModel+LiveData+Lifecycles 是一个很是好的解决的方案，ViewModel 在 Framework 层面已经作了 ViewModelStore 的支持，Lifecycles 也在 ComponentActivity 中注册了 LifecycleRegistry，LiveData 在 observe(this,observer) 时持有了 LifecycleOwner，拥有了生命周期的感知能力。

一、第一点: 数据交互

View 层只须要初始化 ViewModel，订阅 ViewModel 中的 LiveData，以观察者的身份观察数据，一旦有数据的变化，就会自动更新到 View 中，而不须要像 V 与 P 的关系，在获取数据时，先触发 P，拿到数据后，P 层再调用 V 来更新数据，相比 ViewModel 的方式，多了一层手动设置数据返回，而为了数据返回，又多了一层接口模板来规范约束，最终，整个代码就是一个饼。

二、第二点：生命周期感知

LiveData 拥有的生命周期感知能力与 Present 仍是有点区别的， 具体区别是在实现层面上：
一、LiveData 的生命周期感知是在 observe 时，将本身 addObserver 到 Lifecycle 中，让 Fragmentwork 层来赋予本身生命周期的感知能力
二、Present 生命周期感知是  BaseMVPActivity 赋予 BaseMVPPresent 的，若是咱们的 Present 具备感知能力，就须要继承 BaseMVPPresent，这一点我在上面的继承中就代表了，这个是极差体验点，咱们能够看下 ViewModel+LiveData 的方式，全部的操做都是在组合，组合的好处是什么呢?固然是为了在业务升级时有利于拆解和组装，而继承，不具备这样的特性

三、第三点：页面重建

屏幕旋转时页面发生重建，咱们须要在在页面销毁时保存数据，重建时恢复，但数据的存储是有容量限制的，而且对象存储必须是序列化对象，苛刻的条件，Present 是没法作到的，然而，ViewModel 倒是能够的，ViewModel 并非经过 Bundle 的方式来实现数据的存储，而是经过 Framework 的支持，存储在 ViewModelStore 中，具体剖析能够查看文章 《ViewModel 凭什么能保存重建数据》

其余想法的话，待补充吧!!!