前言

最近一直在研究ChrisBannes的開源項目Philm，其整體架構是一套MVP的實現，因爲自己也確實沒有遇到過整個項目利用MVP搭建的架構，看到的更多是一些代碼片段，這裏就探討Philm是如何結合Android實際問題來實現一種MVP架構，如有分析不準確的地方，歡迎指出，大家一起探討。

1.簡單談一談MVP

在無任何模式下的開發時，Activity與Model層的關係太緊密了，做了所有的操作，不易維護，擴展性較差。比如我們後期的需求可能不是從數據庫獲取數據了，而是從網絡，又或者有一個版本要對所有的UI進行大改版，（隨着MaterialDesign的出現，我覺得這個還是有可能的），如果所有的邏輯都在Activity中，那麼如此臃腫的代碼，怎麼修改都費勁吧，又或者你要適應多套UI，比如平板，維護起來也很麻煩吧。

1.2 MVP

MVP是MVC的一種衍生，MVP模式中不容許View直接訪問Model，這是MVP與MVC最大的不同之處。View中應該只有UI邏輯，捕捉用戶輸入以及視圖的渲染。這樣將其它複雜的邏輯抽離出來放到Presenter中去，這樣就出現了MVP。這種模式和傳統的軟件工程思想一樣，降低了耦合度，模塊化，更方便維護。Presenter通常是通過定義好的接口與View進行交互，那麼開發的時候，只要寫一個測試類去實現該接口即可模擬用戶的各種操作進行測試，而不需要使用自動化測試工具。甚至可以不用再每次在手機上重新運行應用了，測試也更有效率。

簡單的說，就是將View中的複雜工作抽取到Presenter中，降低了耦合度，便於維護和測試，也增強了複用性。

在MVP模式裏通常包含4個要素
(1) View: 負責繪製UI元素、與用戶進行交互(Activity或Fragment);
(2) View interface: View需要實現的接口，View通過View interface與Presenter進行交互，降低耦合，方便進行單元測試
(3) Model: 負責業務Bean的操作。
(4) Presenter: 作爲View與Model交互的紐帶，承載了大部分的複雜邏輯。

MVP的優點
1、Model與View完全分離，它們通過接口進行交互，便於維護和測試。
2、可以更高效地使用Model，因爲所有對Model的操作都在Presenter內部。
3、我們可以將一個Presener用於多個視圖，只需要在Presenter中爲不同的View定義View Interface即可，具體的View實現自己的View Interface，即可使用Presenter中的Model操作等。

關於MVP的更多資料和討論可以看文章結尾的相關鏈接

2. MVP架構的實現

MVP的具體實現是沒有標準的，因爲一個項目要考慮的因素很多，你可以按照自己的習慣和需求進行具體的實現。下面我們來分析Philm中實現的MVP架構。

2.1 Philm的總體設計

Philm使用了Controller來統一管理Model、View，按照上面的MVP理解以及Controller實際所做的工作，這個Controller其實相當於上面的Presenter，但這個Controller更加複雜，在Controller內部，直接定義了MVP中View與Presenter的交互接口Callback，另外該項目中引入了State的概念（具體見下面的介紹），統一管理了Model和業務中所需的Event，所有的Activity和Fragment的跳轉以及TitleBar和Drawer的管理使用了一個Display來實現。

類關係圖

基本調用流程圖

2.2 核心概念

2.2.1 Controller

控制中心，簡單的可認爲是MVP中的Presenter，但是其更復雜。統一管理界面狀態的初始化和狀態清理，爲所有的UI進行渲染並添加CallBack，統一調度業務相關的後臺任務線程，訂閱State中定義的Event，進行視圖的更新。並統一定義了View與Presenter的View Interface，一個Controller可以爲多個View定義View Interface，因此Controller可以被多個View所共用。

2.2.2 State

保存界面使用到的業Bean，定義業務中所用到Event事件。

每一個界面擁有自己的State接口，ApplicationState負責統一實現所有State接口，ApplicationState扮演了UI和後臺線程的通信者，實現保存業務Bean的分發和事件的分發。

使用Controller進行populate時，會從state中獲取業務Bean，如果State中沒有，Controller則會啓動後臺線程請求數據，成功獲取數據後通過state.set()分發保存到State中，同時會post一個Event通知Controller進行相應的處理。

State中定義的事件類型
異步請求完成的通知、數據變更、NetWork的狀態變化、LoadingProgress的展示與隱藏，這也是State被單獨抽離出來的原因吧，統一存儲了Model並定義了各種State，注意State並不對Model做複雜的操作，只是簡單的Set和Get，複雜的操作全部由Controller處理。

2.2.3 Display

統一控制TitleBar、Drawer以及所有Activity和Fragment跳轉，沒有業務邏輯操作。

3. 核心類分析

3.1 BaseController

3.1.1 核心方法

(1) init()
所有Controller初始化發起的方法，在BasePhilmActivity中通過mMainController.init()發起，所有的Controller由MainCtroller統一控制。

public final void init() {
       Preconditions.checkState(mInited == false, "Already inited");
       mInited = true;
       onInited();
   }

(2) suspend

public final void suspend() {
       Preconditions.checkState(mInited == true, "Not inited");
       onSuspended();
       mInited = false;
}

3.2 BaseUiController

統一定義管理某個界面的所有的UI，事件，接口。
在View(這裏是Activity或Fragment)中使用的時候獲取相應的Controller，然後在onResume中調用getController().attachUI()，爲View設置CallBack，然後進行populate，在onPause中調用 getController().detachUi(this)清空UI的所有CallBack以及其它狀態的清理。

每一個Controller都擁有一個自己的UiCallBacks，以及一個繼承自BaseUiController.Ui的UI。

Controller是可以共用的
在Controller內部也可同時爲不同的View定義相應的UICallBack，因爲不同的View可能會使用到相同的Model，State等事件，不同的View只需實現Controller中定義的與自己相關的CallBack即可。當然該UICallBack需要繼承已實現BaseUiController.Ui的UI，因爲最終都會傳入到BaseUIController中進行setCallbacks(UC)。

3.2.1 重要成員變量

mUis：用於存儲所有的UI
mUnmodifiableUis：mUis的拷貝，但不可修改
UI<UC>接口
所有Controller的子類的UI都需要實現該UI接口，擁有CallBack的能力，在Controller attachUi的時候會爲傳入的UI設置CallBack

public interface Ui<UC> {

       void setCallbacks(UC callbacks);

       boolean isModal();
   }

3.2.2 重要方法

3.2.2.1 attachUi(U ui)

在Activity或者Fragment的onResume中調用，進行添加回調，視圖渲染等工作。
final 類型，不可複寫，只是爲了Controller的實現類進行狀態的管理，如果需要更多的操作，可以實現onUiAttached(UI)方法，該方法會在attachUI中調用。

public synchronized final void attachUi(U ui) {
        Preconditions.checkArgument(ui != null, "ui cannot be null");
        Preconditions.checkState(!mUis.contains(ui), "UI is already attached");

        mUis.add(ui);

        ui.setCallbacks(createUiCallbacks(ui));

        if (isInited()) {
            if (!ui.isModal() && !(ui instanceof SubUi)) {
                updateDisplayTitle(getUiTitle(ui));
            }

            onUiAttached(ui);
            populateUi(ui);
        }
    }

3.2.2.2 detachUI(U ui)

在Activity或者Fragment的onResume中調用，清空CallBack。
final 類型，不可複寫，只是爲了實現類進行狀態的管理，同上如果有更多的操作，可以實現onUiDetached(ui)方法。

public synchronized final void detachUi(U ui) {
       Preconditions.checkArgument(ui != null, "ui cannot be null");
       Preconditions.checkState(mUis.contains(ui), "ui is not attached");
       onUiDetached(ui);
       ui.setCallbacks(null);

       mUis.remove(ui);
   }

3.2.2.3 onInited()

各個Controller進行初始化的時候調用，不用明確的調用，因爲MainController統一管理了所有的Controller，在BasePhilmActivity的onResume中通過調用MainController.init()方法統一初始化。

protected void onInited() {
        if (!mUis.isEmpty()) {
            for (U ui : mUis) {
                onUiAttached(ui);
                populateUi(ui);
            }
        }
    }

各個Controller自身的onInited方法做一些事件的註冊等簡單的初始化。

3.2.2.4 onSuspended()

清理CallBacks並取消所有註冊事件 unregisterForEvents。
也是由MainController統一在BasePhilmActivity的onPause中管理。

@Override
  protected void onPause() {
     mMainController.suspend();        		  
     mMainController.setHostCallbacks(null);
     mMainController.detachDisplay(mDisplay);
     super.onPause();
  }

3.2.2.5 populate(UI)

對View進行渲染。

3.2.2.6 createUiCallbacks(U ui)

abstract類型，用於Controller創建自己的UICallBack，該方法已經在attachUi(U ui)的時候調用ui.setCallbacks(createUiCallbacks(ui))，爲所有UI設置自己的UI回調事件。

3.2.2.7 getId(U ui)

爲每一個後臺線程和Event設置一個ID。當需要渲染的時候，遍歷所有的UI，通過findUi找到目標UI，進行更新。

1
2
3

protected int getId(U ui) {
       return ui.hashCode();
   }

3.2.2.8 findUi(final int id)

與getId(U ui)相對應，獲取後臺線程或者事件的ID。

3.2.2.9 populateUiFromEvent

populateUiFromEvent(BaseState.UiCausedEvent event)
當某些數據更新的時候，需要更新視圖時，調用該方法，發送一個事件，通知Controller進行UI更新。

3.3 MainController

3.3.1 onInited()

對所有Controller的CallBack和狀態進行初始化

@Override
 protected void onInited() {
     super.onInited();
     mState.registerForEvents(this);
     mUserController.init();
     mMovieController.init();
     mAboutController.init();
 }

3.3.2 onSuspended

對所有Controller的CallBack和狀態進行清理

@Override
    protected void onSuspended() {
        mAboutController.suspend();
        mUserController.suspend();
        mMovieController.suspend();
        mDbHelper.close();
        mState.unregisterForEvents(this);

        super.onSuspended();
    }

3.4 BasePhilmActivity

整個項目的MainController的初始化的發起：

3.4.1 重要方法

3.3.1.1 onCreate

1 2	mMainController = PhilmApplication.from(this).getMainController(); AndroidDisplay mDisplay = new AndroidDisplay(this, mDrawerLayout);

3.4.1.2 onResume

初始化所有的狀態

 @Override
   protected void onResume() {
       super.onResume();
       mMainController.attachDisplay(mDisplay);
       mMainController.setHostCallbacks(this);
       mMainController.init();
   }

public void attachDisplay(Display display) {
       Preconditions.checkNotNull(display, "display is null");
       Preconditions.checkState(getDisplay() == null, "we currently have a display");
       setDisplay(display);
   }

 @Override
   protected void setDisplay(Display display) {
       super.setDisplay(display);
       mMovieController.setDisplay(display);
       mUserController.setDisplay(display);
       mAboutController.setDisplay(display);
   }

3.4.1.5 onPause()

清空所有的狀態

@Override
  protected void onPause() {
      mMainController.suspend();
      mMainController.setHostCallbacks(null);
      mMainController.detachDisplay(mDisplay);
      super.onPause();
  }

3.5 實現特定Controller的UI的Fragment

3.5.1 onResume

獲取到自己的Controller進行初始化

@Override
   public void onResume() {
       super.onResume();
       getController().attachUi(this);
   }

3.5.2 onPause

獲取到相應的Controller進行狀態清理

@Override
  public void onPause() {
      saveListViewPosition();
      cancelToast();
      getController().detachUi(this);
      super.onPause();
  }

總結

Philm中實現的MVP的架構，遵循了MVP的關鍵原則：將View和Model隔離。因爲整個項目是基於該架構的，所以考慮的更全面，比如狀態的統一管理，所有Controller的統一管理，統一的CallBack的管理，使用Otto驅動事件實現組件間的解耦等。當你希望自己的整個項目完全使用MVP的架構時，Philm的框架無疑是一種非常值得參考的實現，你也可以根據自己的需求進行擴展。
另外Philm也使用了最新的MaterialDesign設計，有一些自定義的View，也是不錯的學習資料。

http://blog.csdn.net/vector_yi/article/details/24719873

http://antonioleiva.com/mvp-android/
https://github.com/antoniolg/androidmvp

http://fernandocejas.com/2014/09/03/architecting-android-the-clean-way/
https://github.com/android10/Android-CleanArchitecture

http://magenic.com/BlogArchive/AnMVPPatternforAndroid

http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html

http://blog.csdn.net/xijiaohuangcao/article/details/7925641

https://github.com/pedrovgs/EffectiveAndroidUI/

轉自：http://www.lightskystreet.com/2015/02/10/philm_mvp/

開源項目Philm的MVP架構分析

前言