mvp是一個(gè)老生常談的話題了，網(wǎng)上太多講MVP的文章了。但有的文章不是結(jié)合了rxjva，retrofit等開源項(xiàng)目，就是講的太過復(fù)雜。所以我會(huì)寫一個(gè)最簡單的mvp demo。來幫助大家理解mvp的本質(zhì)。

大多數(shù)時(shí)候，問題都可以拆解為，WHTA,WHY,HOW；什么是MVP，為什么使用MVP，如何使用MVP。

WHAT:先說什么是MVP，

20150622212916054.jpg

上面這張圖是網(wǎng)上找的，其實(shí)這張圖已經(jīng)很明顯了，MVP和MVC的區(qū)別，在于以前的View層不僅要和model層交互，還要和controller層交互。而在mvp中，view層只和presenter層交互，而model層也和presenter交互，presenter構(gòu)成了view層和model層的橋梁，也解耦了view層和model層。這一點(diǎn)很關(guān)鍵。我認(rèn)為，這也是mvp的本質(zhì)：

解耦view層和model層，讓view層和model層通過presenter層進(jìn)行通信。換個(gè)說法就是讓諸如網(wǎng)絡(luò)請(qǐng)求，數(shù)據(jù)庫讀寫的邏輯，從activity中剝離出來。activit只負(fù)責(zé)頁面的展示，不關(guān)心model層的邏輯。

WHY:之后來談?wù)劄槭裁匆褂胢vp

如果大家閱讀過github上的一些開源的android項(xiàng)目，例如telegram，一款即時(shí)通訊軟件，如果你對(duì)它不了解，你可以看一下我之前寫的一篇文章在Android Studio上編譯自己的Telegram；或者TweetLanes，一個(gè)第三方的功能完整的Twitter客戶端。這些開源項(xiàng)目都存在一個(gè)問題，就是一個(gè)activity文件中一兩千行，甚至三四千行代碼。當(dāng)然，我想這個(gè)在android項(xiàng)目中并不是一個(gè)奇怪的現(xiàn)象，當(dāng)你的項(xiàng)目足夠復(fù)雜，沒有什么是不可能。在基于傳統(tǒng)android架構(gòu)的mvc模式中。model層很多時(shí)候只是一個(gè)bean類。而view層只是一個(gè)xml文件，controller層也就是activity層幾乎承擔(dān)了諸如網(wǎng)絡(luò)請(qǐng)求，數(shù)據(jù)庫，更新UI等所有的工作，全在activity里完成。這也就導(dǎo)致了activity文件十分龐大臃腫。但是，問題接踵而至。多人維護(hù)這樣的一個(gè)項(xiàng)目是很痛苦的，一個(gè)幾千行的activity，假如某個(gè)人改動(dòng)了其中的一行，可能會(huì)導(dǎo)致其他修改他的人非常痛苦，因?yàn)闋砍短嗟倪壿嬃?。所以，人們開始嘗試把幾千行的代碼，分成很多模塊。網(wǎng)絡(luò)請(qǐng)求放在一個(gè)模塊，UI更新放在一個(gè)模塊，其他的東西放另一個(gè)模塊。之后就有了MVP。

HOW:在android中如何使用MVP模式

這里我新建了一個(gè)項(xiàng)目，項(xiàng)目里有3個(gè)class和一個(gè)interface，這就是最簡單的mvp模式了。

main.png

用到的第三方框架只有常用的okhttp,AndroidManifest里只申請(qǐng)了一個(gè)Internet的權(quán)限，這里就不放出來了。

xml.png

public interface MainCallBack {
    void getMessage(String message);
    void error();
}

之后model層獲取的數(shù)據(jù)，將會(huì)通過接口傳遞到activity中，進(jìn)行展示。從某種意義上來說，接口其實(shí)就是mvp中的view層。因?yàn)閍ctivity只是這個(gè)接口的實(shí)現(xiàn)而已。那么我們接下來看一下model層是怎么寫的。

public class MainModel {
    public Call getData(String url) {
        OkHttpClient client = new OkHttpClient();
        Request request = new Request.Builder().url(url).build();
        return client.newCall(request);
    }
}

同樣很簡單，這個(gè)應(yīng)該只是okhttp的基礎(chǔ)用法。這里我們沒有調(diào)用enqueue方法傳入callback，是為了之后在presenter中使用，當(dāng)然你也可以在這里調(diào)用，不過這樣一來，你又要在model中聲明一個(gè)接口。好了，“view層”和model層都有了，那么最后只要再有presenter層，那么mvp就完成了。

public class MainPresenter {
    private MainCallBack callBack;
    private MainModel model;

    public MainPresenter(MainCallBack callBack) {
        this.callBack = callBack;
        model=new MainModel();
    }

    public void getUrlData(String url){
        model.getData(url).enqueue(new Callback() {
            @Override
            public void onFailure(@NonNull Call call, @NonNull IOException e) {
                callBack.error();
            }

            @Override
            public void onResponse(@NonNull Call call, @NonNull Response response) throws IOException {
                callBack.getMessage(response.body().string());
            }
        });
    }

}

這是一個(gè)典型的mvp模式中的presenter層：接口通過構(gòu)造函數(shù)傳入，model直接在構(gòu)造函數(shù)中實(shí)例化。presenter中調(diào)用model的getdata方法，并傳入對(duì)應(yīng)的參數(shù)，之后在okhttp的回調(diào)中調(diào)用對(duì)應(yīng)的ui接口，那么一次mvp模式下的網(wǎng)絡(luò)請(qǐng)求就完成了。
具體操作可以看一下activity中的代碼：

public class MainActivity extends AppCompatActivity implements MainCallBack {
    private TextView resultTextView;
    private MyHandler handler;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        Button button = findViewById(R.id.btn);
        handler = new MyHandler(this);
        final EditText editText = findViewById(R.id.et_url);
        resultTextView = findViewById(R.id.tv_result);
        final MainPresenter presenter = new MainPresenter(this);
        button.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View view) {
                String url = editText.getText().toString();
                presenter.getUrlData(url);
            }
        });

    }

    @Override
    public void getMessage(String message) {
        Message msg = handler.obtainMessage(0, message);
        handler.sendMessage(msg);
    }

    @Override
    public void error() {
        Message msg = handler.obtainMessage(1, "error");
        handler.sendMessage(msg);
    }

    private static class MyHandler extends Handler {
        private WeakReference<MainActivity> reference;

        private MyHandler(MainActivity activity) {
            reference = new WeakReference<>(activity);
        }

        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            MainActivity activity = reference.get();
            switch (msg.what) {
                case 0:
                    activity.resultTextView.setText(msg.obj.toString());
                    break;
                case 1:
                    activity.resultTextView.setText(msg.obj.toString());
                    break;
            }
        }
    }
}

運(yùn)行結(jié)果如下兩圖：

success.png

error.png

當(dāng)網(wǎng)址錯(cuò)誤的時(shí)候我直接在textview中顯示“error”，當(dāng)然你也可以自由選擇顯示什么。因?yàn)閛khttp的回調(diào)是在子線程完成的，要刷新ui必須在主線程刷新，所以我這里寫了一個(gè)handler。當(dāng)然你也可以在model層進(jìn)行線程調(diào)度。比如一個(gè)基于okhttp的開源框架，okgo就是這么做的

okgo.png

那么，是否所有地方都需要mvp呢？答案是否定的。我認(rèn)為，設(shè)計(jì)模式的關(guān)鍵在于用在正確且合適的地方。我在一個(gè)項(xiàng)目中，可能會(huì)同時(shí)使用mvp，mvc，mvvm。因?yàn)槲抑肋@里應(yīng)該用什么，如果一個(gè)邏輯不具有復(fù)用的可能，同時(shí)也非常簡單，那么使用mvp就是多此一舉。如果一個(gè)頁面，帶有id的view非常多，那么使用mvvm也就是android的databinding特性可以節(jié)約你大量的時(shí)間。

最后給出幾點(diǎn)使用mvp的建議，經(jīng)供參考：

1.因?yàn)閙vp會(huì)存在大量的接口，所以當(dāng)你設(shè)計(jì)接口的時(shí)候，務(wù)必深思熟慮，因?yàn)橐粋€(gè)接口的改動(dòng)，會(huì)導(dǎo)致所有繼承了接口的類都會(huì)發(fā)生變動(dòng)

2.不要在接口中聲明接口，或者在接口中聲明抽象類。你可能會(huì)覺得這樣讓邏輯更緊密，代碼更好讀。但其實(shí)這樣一來反而違背了mvp解耦的本質(zhì)，讓代碼更加復(fù)雜了。你可以把這樣的代碼拆解成多個(gè)接口和多個(gè)model。因?yàn)橐粋€(gè)presenter中可以有多個(gè)model，也可以傳入多個(gè)interface。同樣，一個(gè)activity也可以繼承多個(gè)interface，并聲明多個(gè)presenter來完成多個(gè)邏輯。

3.對(duì)view層的接口，model和presenter都進(jìn)行一定程度的繼承，也就是每個(gè)view的接口，每個(gè)model和presenter都有一個(gè)父類，完成一些基礎(chǔ)邏輯。這樣可以當(dāng)你必須要對(duì)整體進(jìn)行變動(dòng)的時(shí)候，改動(dòng)起來要容易一些。

4.不要為了繼承而繼承，我見過有的人過度架構(gòu)，代碼里面甚至出現(xiàn)了空的接口和空的抽象類，這樣做毫無意義。代碼是為邏輯服務(wù)的，并且是現(xiàn)有的功能邏輯，為了不知道哪個(gè)版本會(huì)產(chǎn)生的改變，而預(yù)留一堆空接口和空抽象類，在我看來毫無意義。

5.適當(dāng)?shù)膮⒖家恍┈F(xiàn)有的成熟的mvp項(xiàng)目，看看別人是如何設(shè)計(jì)接口以及整體邏輯的，這會(huì)有一定的幫助。但完全照搬是不可取的。因?yàn)閙vp是一種十分依賴項(xiàng)目的架構(gòu)，其他項(xiàng)目上的mvp設(shè)計(jì)不一定適合你的項(xiàng)目。