聊聊 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 憑什麼能保存重建數據》

其餘想法的話，待補充吧!!!