當前位置：首頁 > 编程资源 > 综合教程 >内容正文

综合教程

MVC---Android App的设计架构：MVC,MVP,MVVM与架构经验谈

發布時間：2023/12/15 综合教程 42 生活家

生活随笔收集整理的這篇文章主要介紹了 MVC---Android App的设计架构：MVC,MVP,MVVM与架构经验谈小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

轉載自:

http://www.tianmaying.com/tutorial/AndroidMVC

1.架構設計的目的

通過設計使程序模塊化，做到模塊內部的高聚合和模塊之間的低耦合。這樣做的好處是使得程序在開發的過程中，開發人員只需要專注于一點，提高程序開發的效率，并且更容易進行后續的測試以及定位問題。但設計不能違背目的，對于不同量級的工程，具體架構的實現方式必然是不同的，切忌犯為了設計而設計，為了架構而架構的毛病。

舉個簡單的例子：

一個Android App如果只有3個Java文件，那只需要做點模塊和層次的劃分就可以，引入框架或者架構反而提高了工作量，降低了生產力；

但如果當前開發的App最終代碼量在10W行以上，本地需要進行復雜操作，同時也需要考慮到與其余的Android開發者以及后臺開發人員之間的同步配合，那就需要在架構上進行一些思考！

2.MVC設計架構

MVC概念

MVC全名是Model View Controller，是模型(model)－視圖(view)－控制器(controller)的縮寫，一種軟件設計典范，用一種業務邏輯、數據、界面顯示分離的方法組織代碼，將業務邏輯聚集到一個部件里面，在改進和個性化定制界面及用戶交互的同時，不需要重新編寫業務邏輯。其中M層處理數據，業務邏輯等；V層處理界面的顯示結果；C層起到橋梁的作用，來控制V層和M層通信以此來達到分離視圖顯示和業務邏輯層。說了這么多，聽著感覺很抽象，廢話不多說，我們來看看MVC在Android開發中是怎么應用的吧！

MVC for Android

在Android開發中，比較流行的開發框架模式采用的是MVC框架模式，采用MVC模式的好處是便于UI界面部分的顯示和業務邏輯，數據處理分開。那么Android項目中哪些代碼來充當M,V,C角色呢？

M層：適合做一些業務邏輯處理，比如數據庫存取操作，網絡操作，復雜的算法，耗時的任務等都在model層處理。 V層：應用層中處理數據顯示的部分，XML布局可以視為V層，顯示Model層的數據結果。 C層：在Android中，Activity處理用戶交互問題，因此可以認為Activity是控制器，Activity讀取V視圖層的數據（eg.讀取當前EditText控件的數據），控制用戶輸入（eg.EditText控件數據的輸入），并向Model發送數據請求（eg.發起網絡請求等）。

接下來我們通過一個獲取天氣預報數據的小項目來解讀 MVC for Android。先上一個界面圖：

Controller控制器

public class MainActivity extends ActionBarActivity implements OnWeatherListener, View.OnClickListener {

    private WeatherModel weatherModel;
    private EditText cityNOInput;
    private TextView city;
    ...

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        weatherModel = new WeatherModelImpl();
        initView();
    }

    //初始化View
    private void initView() {
        cityNOInput = findView(R.id.et_city_no);
        city = findView(R.id.tv_city);
        ...
        findView(R.id.btn_go).setOnClickListener(this);
    }

    //顯示結果
    public void displayResult(Weather weather) {
        WeatherInfo weatherInfo = weather.getWeatherinfo();
        city.setText(weatherInfo.getCity());
        ...
    }

    @Override
    public void onClick(View v) {
        switch (v.getId()) {
            case R.id.btn_go:
                weatherModel.getWeather(cityNOInput.getText().toString().trim(), this);
                break;
        }
    }

    @Override
    public void onSuccess(Weather weather) {
        displayResult(weather);
    }

    @Override
    public void onError() {
        Toast.makeText(this, 獲取天氣信息失敗, Toast.LENGTH_SHORT).show();
    }

    private T findView(int id) {
        return (T) findViewById(id);
    }
}

從上面代碼可以看到，Activity持有了WeatherModel模型的對象，當用戶有點擊Button交互的時候，Activity作為Controller控制層讀取View視圖層EditTextView的數據，然后向Model模型發起數據請求，也就是調用WeatherModel對象的方法 getWeathre（）方法。當Model模型處理數據結束后，通過接口OnWeatherListener通知View視圖層數據處理完畢，View視圖層該更新界面UI了。然后View視圖層調用displayResult（）方法更新UI。至此，整個MVC框架流程就在Activity中體現出來了。

Model模型

來看看WeatherModelImpl代碼實現

public interface WeatherModel {
    void getWeather(String cityNumber, OnWeatherListener listener);
}

................

public class WeatherModelImpl implements WeatherModel {
    /*這部分代碼范例有問題，網絡訪問不應該在Model中，應該把網絡訪問換成從數據庫讀取*/
    @Override
    public void getWeather(String cityNumber, final OnWeatherListener listener) {

        /*數據層操作*/
        VolleyRequest.newInstance().newGsonRequest(http://www.weather.com.cn/data/sk/ + cityNumber + .html,
                Weather.class, new Response.Listener<weather>() {
                    @Override
                    public void onResponse(Weather weather) {
                        if (weather != null) {
                            listener.onSuccess(weather);
                        } else {
                            listener.onError();
                        }
                    }
                }, new Response.ErrorListener() {
                    @Override
                    public void onErrorResponse(VolleyError error) {
                        listener.onError();
                    }
                });
    }
}

以上代碼看出，這里設計了一個WeatherModel模型接口，然后實現了接口WeatherModelImpl類。controller控制器activity調用WeatherModelImpl類中的方法發起網絡請求，然后通過實現OnWeatherListener接口來獲得網絡請求的結果通知View視圖層更新UI 。至此，Activity就將View視圖顯示和Model模型數據處理隔離開了。activity擔當contronller完成了model和view之間的協調作用。

至于這里為什么不直接設計成類里面的一個getWeather（）方法直接請求網絡數據？你考慮下這種情況：現在代碼中的網絡請求是使用Volley框架來實現的，如果哪天老板非要你使用Afinal框架實現網絡請求，你怎么解決問題？難道是修改 getWeather（）方法的實現？ no no no，這樣修改不僅破壞了以前的代碼，而且還不利于維護，考慮到以后代碼的擴展和維護性，我們選擇設計接口的方式來解決著一個問題，我們實現另外一個WeatherModelWithAfinalImpl類，繼承自WeatherModel，重寫里面的方法，這樣不僅保留了以前的WeatherModelImpl類請求網絡方式，還增加了WeatherModelWithAfinalImpl類的請求方式。Activity調用代碼無需要任何修改。

MVC使用總結

利用MVC設計模式，使得這個天氣預報小項目有了很好的可擴展和維護性，當需要改變UI顯示的時候，無需修改Contronller（控制器）Activity的代碼和Model（模型）WeatherModel模型中的業務邏輯代碼，很好的將業務邏輯和界面顯示分離。

在Android項目中，業務邏輯，數據處理等擔任了Model（模型）角色，XML界面顯示等擔任了View（視圖）角色，Activity擔任了Contronller（控制器）角色。contronller（控制器）是一個中間橋梁的作用，通過接口通信來協同 View（視圖）和Model（模型）工作，起到了兩者之間的通信作用。

什么時候適合使用MVC設計模式？當然一個小的項目且無需頻繁修改需求就不用MVC框架來設計了，那樣反而覺得代碼過度設計，代碼臃腫。一般在大的項目中，且業務邏輯處理復雜，頁面顯示比較多，需要模塊化設計的項目使用MVC就有足夠的優勢了。

4.在MVC模式中我們發現，其實控制器Activity主要是起到解耦作用，將View視圖和Model模型分離，雖然Activity起到交互作用，但是找Activity中有很多關于視圖UI的顯示代碼，因此View視圖和Activity控制器并不是完全分離的，也就是說一部分View視圖和Contronller控制器Activity是綁定在一個類中的。

MVC的優點：

(1)耦合性低。所謂耦合性就是模塊代碼之間的關聯程度。利用MVC框架使得View（視圖）層和Model（模型）層可以很好的分離，這樣就達到了解耦的目的，所以耦合性低，減少模塊代碼之間的相互影響。

(2)可擴展性好。由于耦合性低，添加需求，擴展代碼就可以減少修改之前的代碼，降低bug的出現率。

(3)模塊職責劃分明確。主要劃分層M,V,C三個模塊，利于代碼的維護。

3.MVP設計架構

在App開發過程中，經常出現的問題就是某一部分的代碼量過大，雖然做了模塊劃分和接口隔離，但也很難完全避免。從實踐中看到，這更多的出現在UI部分，也就是Activity里。想象一下，一個2000+行以上基本不帶注釋的Activity，我的第一反應就是想吐。Activity內容過多的原因其實很好解釋，因為Activity本身需要擔負與用戶之間的操作交互，界面的展示，不是單純的Controller或View。而且現在大部分的Activity還對整個App起到類似IOS中的【ViewController】的作用，這又帶入了大量的邏輯代碼，造成Activity的臃腫。為了解決這個問題，讓我們引入MVP框架。

MVC的缺點

在Android開發中，Activity并不是一個標準的MVC模式中的Controller，它的首要職責是加載應用的布局和初始化用戶界面，并接受并處理來自用戶的操作請求，進而作出響應。隨著界面及其邏輯的復雜度不斷提升，Activity類的職責不斷增加，以致變得龐大臃腫。

什么是MVP?

MVP從更早的MVC框架演變過來，與MVC有一定的相似性：Controller/Presenter負責邏輯的處理，Model提供數據，View負責顯示。

MVP框架由3部分組成：View負責顯示，Presenter負責邏輯處理，Model提供數據。在MVP模式里通常包含3個要素（加上View interface是4個）：

View:負責繪制UI元素、與用戶進行交互(在Android中體現為Activity)

Model:負責存儲、檢索、操縱數據(有時也實現一個Model interface用來降低耦合)

Presenter:作為View與Model交互的中間紐帶，處理與用戶交互的負責邏輯。

*View interface:需要View實現的接口，View通過View interface與Presenter進行交互，降低耦合，方便進行單元測試

Tips：*View interface的必要性

回想一下你在開發Android應用時是如何對代碼邏輯進行單元測試的？是否每次都要將應用部署到Android模擬器或真機上，然后通過模擬用戶操作進行測試？然而由于Android平臺的特性，每次部署都耗費了大量的時間，這直接導致開發效率的降低。而在MVP模式中，處理復雜邏輯的Presenter是通過interface與View(Activity)進行交互的，這說明我們可以通過自定義類實現這個interface來模擬Activity的行為對Presenter進行單元測試，省去了大量的部署及測試的時間。

MVC → MVP

當我們將Activity復雜的邏輯處理移至另外的一個類（Presenter）中時，Activity其實就是MVP模式中的View，它負責UI元素的初始化，建立UI元素與Presenter的關聯（Listener之類），同時自己也會處理一些簡單的邏輯（復雜的邏輯交由 Presenter處理）。

MVP的Presenter是框架的控制者，承擔了大量的邏輯操作，而MVC的Controller更多時候承擔一種轉發的作用。因此在App中引入MVP的原因，是為了將此前在Activty中包含的大量邏輯操作放到控制層中，避免Activity的臃腫。

兩種模式的主要區別：

（最主要區別）View與Model并不直接交互，而是通過與Presenter交互來與Model間接交互。而在MVC中View可以與Model直接交互通常View與Presenter是一對一的，但復雜的View可能綁定多個Presenter來處理邏輯。而Controller是基于行為的，并且可以被多個View共享，Controller可以負責決定顯示哪個ViewPresenter與View的交互是通過接口來進行的，更有利于添加單元測試。

因此我們可以發現MVP的優點如下：

1、模型與視圖完全分離，我們可以修改視圖而不影響模型；

2、可以更高效地使用模型，因為所有的交互都發生在一個地方——Presenter內部；

3、我們可以將一個Presenter用于多個視圖，而不需要改變Presenter的邏輯。這個特性非常的有用，因為視圖的變化總是比模型的變化頻繁；

4、如果我們把邏輯放在Presenter中，那么我們就可以脫離用戶接口來測試這些邏輯（單元測試）。

具體到Android App中，一般可以將App根據程序的結構進行縱向劃分，根據MVP可以將App分別為模型層(M)，UI層(V)和邏輯層(P)。

UI層一般包括Activity，Fragment，Adapter等直接和UI相關的類，UI層的Activity在啟動之后實例化相應的Presenter，App的控制權后移，由UI轉移到Presenter，兩者之間的通信通過BroadCast、Handler或者接口完成，只傳遞事件和結果。

舉個簡單的例子，UI層通知邏輯層（Presenter）用戶點擊了一個Button，邏輯層（Presenter）自己決定應該用什么行為進行響應，該找哪個模型（Model）去做這件事，最后邏輯層（Presenter）將完成的結果更新到UI層。

**MVP的變種：Passive View

MVP的變種有很多，其中使用最廣泛的是Passive View模式，即被動視圖。在這種模式下，View和Model之間不能直接交互，View通過Presenter與Model打交道。Presenter接受View的UI請求，完成簡單的UI處理邏輯，并調用Model進行業務處理，并調用View將相應的結果反映出來。View直接依賴Presenter，但是Presenter間接依賴View，它直接依賴的是View實現的接口。

相對于View的被動，那Presenter就是主動的一方。對于Presenter的主動，有如下的理解：

Presenter是整個MVP體系的控制中心，而不是單純的處理View請求的人；View僅僅是用戶交互請求的匯報者，對于響應用戶交互相關的邏輯和流程，View不參與決策，真正的決策者是Presenter；View向Presenter發送用戶交互請求應該采用這樣的口吻：“我現在將用戶交互請求發送給你，你看著辦，需要我的時候我會協助你”，不應該是這樣：“我現在處理用戶交互請求了，我知道該怎么辦，但是我需要你的支持，因為實現業務邏輯的Model只信任你”；對于綁定到View上的數據，不應該是View從Presenter上“拉”回來的，應該是Presenter主動“推”給View的；View盡可能不維護數據狀態，因為其本身僅僅實現單純的、獨立的UI操作；Presenter才是整個體系的協調者，它根據處理用于交互的邏輯給View和Model安排工作。

MVP架構存在的問題與解決辦法

加入模板方法（Template Method）

轉移邏輯操作之后可能部分較為復雜的Activity內代碼量還是不少，于是需要在分層的基礎上再加入模板方法（Template Method）。

具體做法是在Activity內部分層。其中最頂層為BaseActivity，不做具體顯示，而是提供一些基礎樣式，Dialog，ActionBar在內的內容，展現給用戶的Activity繼承BaseActivity，重寫BaseActivity預留的方法。如有必要再進行二次繼承，App中Activity之間的繼承次數最多不超過3次。

Model內部分層

模型層（Model）中的整體代碼量是最大的，一般由大量的Package組成，針對這部分需要做的就是在程序設計的過程中，做好模塊的劃分，進行接口隔離，在內部進行分層。

強化Presenter

強化Presenter的作用，將所有邏輯操作都放在Presenter內也容易造成Presenter內的代碼量過大，對于這點，有一個方法是在UI層和Presenter之間設置中介者Mediator，將例如數據校驗、組裝在內的輕量級邏輯操作放在Mediator中；在Presenter和Model之間使用代理Proxy；通過上述兩者分擔一部分Presenter的邏輯操作，但整體框架的控制權還是在Presenter手中。Mediator和Proxy不是必須的，只在Presenter負擔過大時才建議使用。

最終的架構如下圖所示：

MVP代碼實例

我們來看看MVP在Android開發中是怎么應用的吧！！

我們用另一個例子來解釋。

先來看包結構圖

建立Bean

public class UserBean {
  private String mFirstName;
  private String mLastName;
  public UserBean(String firstName, String lastName) {
      this. mFirstName = firstName;
      this. mLastName = lastName;
  }
  public String getFirstName() {
      return mFirstName;
  }
  public String getLastName() {
      return mLastName;
  }
}

建立Model

（處理業務邏輯，這里指數據讀寫），先寫接口，后寫實現

public interface IUserModel {
     void setID(int id);

     void setFirstName(String firstName);

     void setLastName(String lastName);

     int getID();

     UserBean load(int id);// 通過id讀取user信息,返回一個UserBean
}

實現不在這里寫了

Presenter控制器

建立presenter（主導器，通過iView和iModel接口操作model和view），activity可以把所有邏輯給presenter處理，這樣java邏輯就從手機的activity中分離出來。

public class UserPresenter {
     private IUserView mUserView;
     private IUserModel mUserModel;

     public UserPresenter(IUserView view) {
            mUserView = view;
            mUserModel = new UserModel();
     }

     public void saveUser( int id, String firstName, String lastName) {
            mUserModel.setID(id);
            mUserModel.setFirstName(firstName);
            mUserModel.setLastName(lastName);
     }

     public void loadUser( int id) {
           UserBean user = mUserModel.load(id);
            mUserView.setFirstName(user.getFirstName()); // 通過調用IUserView的方法來更新顯示
            mUserView.setLastName(user.getLastName());
     }
}

View視圖

建立view（更新ui中的view狀態），這里列出需要操作當前view的方法，也是接口

public interface IUserView {
     int getID();

     String getFristName();

     String getLastName();

     void setFirstName(String firstName);

     void setLastName(String lastName);
}

activity中實現iview接口，在其中操作view，實例化一個presenter變量。

public class MainActivity extends Activity implements OnClickListener,IUserView {

     UserPresenter presenter;
     EditText id,first,last;
     @Override
     protected void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
           setContentView(R.layout. activity_main);
           
           findViewById(R.id. save).setOnClickListener( this);
           findViewById(R.id. load).setOnClickListener( this);
            id = (EditText) findViewById(R.id. id);
            first = (EditText) findViewById(R.id. first);
            last = (EditText) findViewById(R.id. last);
           
            presenter = new UserPresenter( this);
     }

     @Override
     public void onClick(View v) {
            switch (v.getId()) {
            case R.id. save:
                 presenter.saveUser(getID(), getFristName(), getLastName());
                 break;
            case R.id. load:
                 presenter.loadUser(getID());
                 break;
            default:
                 break;
           }
     }

     @Override
     public int getID() {
            return new Integer( id.getText().toString());
     }

     @Override
     public String getFristName() {
            return first.getText().toString();
     }

     @Override
     public String getLastName() {
            return last.getText().toString();
     }

     @Override
     public void setFirstName(String firstName) {
            first.setText(firstName);
     }

     @Override
     public void setLastName(String lastName) {
            last.setText(lastName);
     }

}

因此，Activity及從MVC中的Controller中解放出來了，這會Activity主要做顯示View的作用和用戶交互。每個Activity可以根據自己顯示View的不同實現View視圖接口IUserView。

通過對比同一實例的MVC與MVP的代碼，可以證實MVP模式的一些優點：

在MVP中，Activity的代碼不臃腫；在MVP中，Model(IUserModel的實現類)的改動不會影響Activity(View)，兩者也互不干涉，而在MVC中會；在MVP中，IUserView這個接口可以實現方便地對Presenter的測試；在MVP中，UserPresenter可以用于多個視圖，但是在MVC中的Activity就不行。

4.MVC、MVP與MVVM的關系

首先介紹下MVVM。

MVVM

MVVM可以算是MVP的升級版，其中的VM是ViewModel的縮寫，ViewModel可以理解成是View的數據模型和Presenter的合體，ViewModel和View之間的交互通過Data Binding完成，而Data Binding可以實現雙向的交互，這就使得視圖和控制層之間的耦合程度進一步降低，關注點分離更為徹底，同時減輕了Activity的壓力。

在比較之前，先從圖上看看三者的異同。

剛開始理解這些概念的時候認為這幾種模式雖然都是要將view和model解耦，但是非此即彼，沒有關系，一個應用只會用一種模式。后來慢慢發現世界絕對不是只有黑白兩面，中間最大的一塊其實是灰色地帶，同樣，這幾種模式的邊界并非那么明顯，可能你在自己的應用中都會用到。實際上也根本沒必要去糾結自己到底用的是MVC、MVP還是MVVP，不管黑貓白貓，捉住老鼠就是好貓。

MVC->MVP->MVVM演進過程

MVC -> MVP -> MVVM 這幾個軟件設計模式是一步步演化發展的，MVVM 是從 MVP 的進一步發展與規范，MVP 隔離了MVC中的 M 與 V 的直接聯系后，靠 Presenter 來中轉，所以使用 MVP 時 P 是直接調用 View 的接口來實現對視圖的操作的，這個 View 接口的東西一般來說是 showData、showLoading等等。M 與 V已經隔離了，方便測試了，但代碼還不夠優雅簡潔，所以 MVVM 就彌補了這些缺陷。在 MVVM 中就出現的 Data Binding 這個概念，意思就是
View 接口的 showData 這些實現方法可以不寫了，通過 Binding 來實現。

同

如果把這三者放在一起比較，先說一下三者的共同點，也就是Model和View：

Model：數據對象，同時，提供本應用外部對應用程序數據的操作的接口，也可能在數據變化時發出變更通知。Model不依賴于View的實現，只要外部程序調用Model的接口就能夠實現對數據的增刪改查。

View：UI層，提供對最終用戶的交互操作功能，包括UI展現代碼及一些相關的界面邏輯代碼。

異

三者的差異在于如何粘合View和Model，實現用戶的交互操作以及變更通知

Controller

Controller接收View的操作事件，根據事件不同，或者調用Model的接口進行數據操作，或者進行View的跳轉，從而也意味著一個Controller可以對應多個View。Controller對View的實現不太關心，只會被動地接收，Model的數據變更不通過Controller直接通知View，通常View采用觀察者模式監聽Model的變化。

Presenter

Presenter與Controller一樣，接收View的命令，對Model進行操作；與Controller不同的是Presenter會反作用于View，Model的變更通知首先被Presenter獲得，然后Presenter再去更新View。一個Presenter只對應于一個View。根據Presenter和View對邏輯代碼分擔的程度不同，這種模式又有兩種情況：Passive View和Supervisor Controller。

ViewModel

注意這里的“Model”指的是View的Model，跟MVVM中的一個Model不是一回事。所謂View的Model就是包含View的一些數據屬性和操作的這么一個東東，這種模式的關鍵技術就是數據綁定（data binding），View的變化會直接影響ViewModel，ViewModel的變化或者內容也會直接體現在View上。這種模式實際上是框架替應用開發者做了一些工作，開發者只需要較少的代碼就能實現比較復雜的交互。

一點心得

MVP和MVVM完全隔離了Model和View，但是在有些情況下，數據從Model到ViewModel或者Presenter的拷貝開銷很大，可能也會結合MVC的方式，Model直接通知View進行變更。在實際的應用中很有可能你已經在不知不覺中將幾種模式融合在一起，但是為了代碼的可擴展、可測試性，必須做到模塊的解耦，不相關的代碼不要放在一起。網上有一個故事講，一個人在一家公司做一個新產品時，一名外包公司的新員工直接在View中做了數據庫持久化操作，而且一個hibernate代碼展開后發現竟然有幾百行的SQL語句，搞得他們驚訝不已，一時成為笑談。

個人理解，在廣義地談論MVC架構時，并非指本文中嚴格定義的MVC，而是指的MV*，也就是視圖和模型的分離，只要一個框架提供了視圖和模型分離的功能，我們就可以認為它是一個MVC框架。在開發深入之后，可以再體會用到的框架到底是MVC、MVP還是MVVM。

5. 基于AOP的框架設計

AOP(Aspect-Oriented Programming, 面向切面編程)，誕生于上個世紀90年代，是對OOP(Object-Oriented Programming, 面向對象編程)的補充和完善。OOP引入封裝、繼承和多態性等概念來建立一種對象層次結構，用以模擬公共行為的一個集合。當我們需要為分散的對象引入公共行為的時候，OOP則顯得無能為力。也就是說，OOP允許你定義從上到下的關系，但并不適合定義從左到右的關系。例如日志功能。日志代碼往往水平地散布在所有對象層次中，而與它所散布到的對象的核心功能毫無關系。對于其他類型的代碼，如安全性、異常處理和透明的持續性也是如此。這種散布在各處的無關的代碼被稱為橫切（Cross-Cutting）代碼，在OOP設計中，它導致了大量代碼的重復，而不利于各個模塊的重用。而AOP技術則恰恰相反，它利用一種稱為“橫切”的技術，剖解開封裝的對象內部，并將那些影響了多個類的公共行為封裝到一個可重用模塊，并將其名為“Aspect”，即方面。所謂“方面”，簡單地說，就是將那些與業務無關，卻為業務模塊所共同調用的邏輯或責任封裝起來，便于減少系統的重復代碼，降低模塊間的耦合度，并有利于未來的可操作性和可維護性。

5.1 AOP在Android中的使用

AOP把軟件系統分為兩個部分：核心關注點和橫切關注點。業務處理的主要流程是核心關注點，與之關系不大的部分是橫切關注點。橫切關注點的一個特點是，他們經常發生在核心關注點的多處，而各處都基本相似。AOP的作用在于分離系統中的各種關注點，將核心關注點和橫切關注點分離開來。在Android App中，哪些是我們需要的橫切關注點？個人認為主要包括以下幾個方面：Http, SharedPreferences, Json, Xml, File, Device, System, Log, 格式轉換等。Android App的需求差別很大，不同的需求橫切關注點必然是不一樣的。一般的App工程中應該有一個Util
Package來存放相關的切面操作，在項目多了之后可以將其中使用較多的Util封裝為一個Jar包供工程調用。

在使用MVP和AOP對App進行縱向和橫向的切割之后，能夠使得App整體的結構更清晰合理，避免局部的代碼臃腫，方便開發、測試以及后續的維護。

6. 干貨：AndroidApp架構的設計經驗

首先是作者最最喜歡的一句話，也是對創業公司特別適用的一句話，也是對不要過度設計的一種詮釋：

先實現，再重構吧。直接考慮代碼不臃腫得話，不知道什么時候才能寫好了

（重要的事情說三遍）

6.1 整體架構

代碼和文檔規范，根據需求進行模塊劃分，確定交互方式，形成接口文檔，這些較為通用的內容不再細說。做Android App時，一般將App進行縱向和橫向的劃分。縱向的App由UI層，邏輯層和模型層構成，整體結構基于MVP思想(圖片來自網絡)。

UI層內部多用模板方法，以Activity為例一般有BaseActivity，提供包括一些基礎樣式，Dialog，ActionBar在內的內容，展現的Activity都會繼承BaseActivity并實現預留的接口，Activity之間的繼承不超過3次；為避免Activity內代碼過多，將App的整體控制權后移，也借鑒了IOC做法，大量的邏輯操作放在邏輯層中，邏輯層和UI層通過接口或者Broadcast等實現通信，只傳遞結果。一般Activity里的代碼量都很大，通過這兩種方式一般我寫的單個Activity內代碼量不超過400行。

邏輯層實現的是絕大部分的邏輯操作，由UI層啟動，在內部通過接口調用模型層的方法，在邏輯層內大量使用了代理。打個比方，UI層告訴邏輯層我需要做的事，邏輯層去找相應的人(模型層)去做，最后只告訴UI這件事做的結果。

模型層沒什么好說的，這部分一般由大量的Package組成，代碼量是三層中最大的，需要在內部進行分層。

橫向的分割依據AOP面向切面的思想，主要是提取出共用方法作為一個單獨的Util，這些Util會在App整體中穿插使用。很多人的App都會引入自己封裝的Jar包，封裝了包括文件、JSON、SharedPreference等在內的常用操作，自己寫的用起來順手，也大幅度降低了重復作業。

這樣縱，橫兩次對于App代碼的分割已經能使得程序不會過多堆積在一個Java文件里，但靠一次開發過程就寫出高質量的代碼是很困難的，趁著項目的間歇期，對代碼進行重構很有必要。

6.2 類庫的使用

現在有很多幫助快速開發的類庫，活用這些類庫也是避免代碼臃腫和混亂的好方法，下面給題主推薦幾個常用類庫。

減少Activity代碼量的依賴注入框架ButterKnife:

https://github.com/JakeWharton/butterknife

簡化對于SQlite操作的對象關系映射框架OrmLite:

https://github.com/j256/ormlite-android

圖片緩存類庫Fresco(by facebook):

https://github.com/facebook/fresco

能用第三方庫就用第三方庫。別管是否穩定，是否被持續維護，因為，任何第三方庫的作者，都能碾壓剛入門的菜鳥，你絕對寫不出比別人更好的代碼了。

最后附上知乎上面點贊次數很高的一段話：

如果“從零開始”，用什么設計架構的問題屬于想得太多做得太少的問題。

從零開始意味著一個項目的主要技術難點是基本功能實現。當每一個功能都需要考慮如何做到的時候，我覺得一般人都沒辦法考慮如何做好。

因為，所有的優化都是站在最上層進行統籌規劃。在這之前，你必須對下層的每一個模塊都非常熟悉，進而提煉可復用的代碼、規劃邏輯流程。

所以，如果真的是從零開始，別想太多了

參考文獻：

1、http://blog.csdn.net/luyi325xyz/article/details/43085409

2、http://blog.csdn.net/napolunyishi/article/details/22722345

3、https://www.zhihu.com/question/27645587/answer/37579829

4、http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0202/2397.html

5、http://www.tuicool.com/articles/VJZrYb

6、https://www.zhihu.com/question/27645587

7、http://blog.csdn.net/luyi325xyz/article/details/43482123

8、https://www.zhihu.com/question/30976423

9、http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0313/2599.html

10、http://www.2cto.com/kf/201506/405766.html

11、https://www.zhihu.com/question/19766132

12、http://www.cnblogs.com/artech/archive/2010/03/25/1696205.html

13、https://segmentfault.com/a/1190000003927200

14、http://blog.csdn.net/knxw0001/article/details/39637273

總結

以上是生活随笔為你收集整理的MVC---Android App的设计架构：MVC,MVP,MVVM与架构经验谈的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇： python获取屏幕文字_详解：四种方法
下一篇： mysql存储blob限制