androidmvvm框架

① 如何構建Android MVVM 應用框架

我們先來看看什麼是MVVM，然後再一步一步來設計整個MVVM框架。
MVC、MVP、MVVM
首先，我們先大致了解下Android開發中常見的模式。
MVC
View：XML布局文件。
Model：實體模型（數據的獲取、存儲、數據狀態變化）。
Controllor：對應於Activity，處理數據、業務和UI。
從上面這個結構來看，Android本身的設計還是符合MVC架構的，但是Android中純粹作為View的XML視圖功能太弱，我們大量處理View的邏輯只能寫在Activity中，這樣Activity就充當了View和Controller兩個角色，直接導致Activity中的代碼大爆炸。相信大多數Android開發者都遇到過一個Acitivty數以千行的代碼情況吧！所以，更貼切的說法是，這個MVC結構最終其實只是一個Model-View（Activity:View&Controller）的結構。
MVP
View:對應於Activity和XML，負責View的繪制以及與用戶的交互。
Model:依然是實體模型。
Presenter:負責完成View與Model間的交互和業務邏輯。
前面我們說，Activity充當了View和Controller兩個角色，MVP就能很好地解決這個問題，其核心理念是通過一個抽象的View介面（不是真正的View層）將Presenter與真正的View層進行解耦。Persenter持有該View介面，對該介面進行操作，而不是直接操作View層。這樣就可以把視圖操作和業務邏輯解耦，從而讓Activity成為真正的View層。
但MVP也存在一些弊端：
Presenter（以下簡稱P）層與View（以下簡稱V）層是通過介面進行交互的，介面粒度不好控制。粒度太小，就會存在大量介面的情況，使代碼太過碎版化；粒度太大，解耦效果不好。同時對於UI的輸入和數據的變化，需要手動調用V層或者P層相關的介面，相對來說缺乏自動性、監聽性。如果數據的變化能自動響應到UI、UI的輸入能自動更新到數據，那該多好！
MVP是以UI為驅動的模型，更新UI都需要保證能獲取到控制項的引用，同時更新UI的時候要考慮當前是否是UI線程，也要考慮Activity的生命周期（是否已經銷毀等）。
MVP是以UI和事件為驅動的傳統模型，數據都是被動地通過UI控制項做展示，但是由於數據的時變性，我們更希望數據能轉被動為主動，希望數據能更有活性，由數據來驅動UI。
V層與P層還是有一定的耦合度。一旦V層某個UI元素更改，那麼對應的介面就必須得改，數據如何映射到UI上、事件監聽介面這些都需要轉變，牽一發而動全身。如果這一層也能解耦就更好了。
復雜的業務同時也可能會導致P層太大，代碼臃腫的問題依然不能解決。
MVVM
View:對應於Activity和XML，負責View的繪制以及與用戶交互。
Model:實體模型。
ViewModel:負責完成View與Model間的交互，負責業務邏輯。
MVVM的目標和思想與MVP類似，利用數據綁定(Data Binding)、依賴屬性(Dependency Property)、命令(Command)、路由事件(Routed Event)等新特性，打造了一個更加靈活高效的架構。
數據驅動
在常規的開發模式中，數據變化需要更新UI的時候，需要先獲取UI控制項的引用，然後再更新UI。獲取用戶的輸入和操作也需要通過UI控制項的引用。在MVVM中，這些都是通過數據驅動來自動完成的，數據變化後會自動更新UI，UI的改變也能自動反饋到數據層，數據成為主導因素。這樣MVVM層在業務邏輯處理中只要關心數據，不需要直接和UI打交道，在業務處理過程中簡單方便很多。
低耦合度
MVVM模式中，數據是獨立於UI的。
數據和業務邏輯處於一個獨立的ViewModel中，ViewModel只需要關注數據和業務邏輯，不需要和UI或者控制項打交道。UI想怎麼處理數據都由UI自己決定，ViewModel不涉及任何和UI相關的事，也不持有UI控制項的引用。即便是控制項改變了（比如：TextView換成EditText），ViewModel也幾乎不需要更改任何代碼。它非常完美的解耦了View層和ViewModel，解決了上面我們所說的MVP的痛點。
更新UI
在MVVM中，數據發生變化後，我們在工作線程直接修改（在數據是線程安全的情況下）ViewModel的數據即可，不用再考慮要切到主線程更新UI了，這些事情相關框架都幫我們做了。
團隊協作
MVVM的分工是非常明顯的，由於View和ViewModel之間是鬆散耦合的：一個是處理業務和數據、一個是專門的UI處理。所以，完全由兩個人分工來做，一個做UI（XML和Activity）一個寫ViewModel，效率更高。
可復用性
一個ViewModel可以復用到多個View中。同樣的一份數據，可以提供給不同的UI去做展示。對於版本迭代中頻繁的UI改動，更新或新增一套View即可。如果想在UI上做A/B Testing，那MVVM是你不二選擇。
單元測試
有些同學一看到單元測試，可能腦袋都大。是啊，寫成一團漿糊的代碼怎麼可能做單元測試？如果你們以代碼太爛無法寫單元測試而逃避，那可真是不好的消息了。這時候，你需要MVVM來拯救。
我們前面說過了，ViewModel層做的事是數據處理和業務邏輯，View層中關注的是UI，兩者完全沒有依賴。不管是UI的單元測試還是業務邏輯的單元測試，都是低耦合的。在MVVM中數據是直接綁定到UI控制項上的（部分數據是可以直接反映出UI上的內容），那麼我們就可以直接通過修改綁定的數據源來間接做一些Android UI上的測試。
通過上面的簡述以及模式的對比，我們可以發現MVVM的優勢還是非常明顯的。雖然目前Android開發中可能真正在使用MVVM的很少，但是值得我們去做一些探討和調研。
如何構建MVVM應用框架
如何分工
構建MVVM框架首先要具體了解各個模塊的分工。接下來我們來講解View、ViewModel、Model它們各自的職責所在。
View
View層做的就是和UI相關的工作，我們只在XML、Activity和Fragment寫View層的代碼，View層不做和業務相關的事，也就是我們在Activity不寫業務邏輯和業務數據相關的代碼，更新UI通過數據綁定實現，盡量在ViewModel裡面做（更新綁定的數據源即可），Activity要做的事就是初始化一些控制項（如控制項的顏色，添加RecyclerView的分割線），View層可以提供更新UI的介面（但是我們更傾向所有的UI元素都是通過數據來驅動更改UI），View層可以處理事件（但是我們更希望UI事件通過Command來綁定）。 簡單地說：View層不做任何業務邏輯、不涉及操作數據、不處理數據，UI和數據嚴格的分開。
ViewModel
ViewModel層做的事情剛好和View層相反，ViewModel只做和業務邏輯和業務數據相關的事，不做任何和UI相關的事情，ViewModel 層不會持有任何控制項的引用，更不會在ViewModel中通過UI控制項的引用去做更新UI的事情。ViewModel就是專注於業務的邏輯處理，做的事情也都只是對數據的操作（這些數據綁定在相應的控制項上會自動去更改UI）。同時DataBinding框架已經支持雙向綁定，讓我們可以通過雙向綁定獲取View層反饋給ViewModel層的數據，並對這些數據上進行操作。關於對UI控制項事件的處理，我們也希望能把這些事件處理綁定到控制項上，並把這些事件的處理統一化，為此我們通過BindingAdapter對一些常用的事件做了封裝，把一個個事件封裝成一個個Command，對於每個事件我們用一個ReplyCommand 去處理就行了，ReplyCommand 會把你可能需要的數據帶給你，這使得我們在Vie，具體見 MVVM Light Toolkit 使用指南的 Command 部分 。再強調一遍：ViewModel 不做和UI相關的事。
Model
Model層最大的特點是被賦予了數據獲取的職責，與我們平常Model層只定義實體對象的行為截然不同。實例中，數據的獲取、存儲、數據狀態變化都是Model層的任務。Model包括實體模型（Bean）、Retrofit的Service ，獲取網路數據介面，本地存儲（增刪改查）介面，數據變化監聽等。Model提供數據獲取介面供ViewModel調用，經數據轉換和操作並最終映射綁定到View層某個UI元素的屬性上。
如何協作
關於協作，我們先來看下面的一張圖：

上圖反應了MVVM框架中各個模塊的聯系和數據流的走向，我們從每個模塊一一拆分來看。那麼我們重點就是下面的三個協作。
ViewModel與View的協作 。
ViewModel與Model的協作 。
ViewModel與ViewModel的協作 。
ViewModel與View的協作

圖2中ViewModel和View是通過綁定的方式連接在一起的，綁定分成兩種：一種是數據綁定，一種是命令綁定。數據的綁定DataBinding已經提供好了，簡單地定義一些ObservableField就能把數據和控制項綁定在一起了（如TextView的text屬性），但是DataBinding框架提供的不夠全面，比如說如何讓一個URL綁定到一個ImageView，讓這個ImageView能自動去載入url指定的圖片，如何把數據源和布局模板綁定到一個ListView，讓ListView可以不需要去寫Adapter和ViewHolder相關的東西？這些就需要我們做一些工作和簡單的封裝。MVVM Light Toolkit 已經幫我們做了一部分的工作,關於事件綁定也是一樣，MVVM Light Toolkit 做了簡單的封裝，對於每個事件我們用一個ReplyCommand去處理就行了，ReplyCommand 會把可能需要的數據帶給你，這樣我們處理事件的時候也只關心處理數據就行了.
由 圖 1 中ViewModel的模塊中我們可以看出ViewModel類下面一般包含下面5個部分：
Context （上下文）
Model (數據源 java Bean)
Data Field （數據綁定）
Command （命令綁定）
Child ViewModel （子ViewModel）
我們先來看下示例代碼，然後再一一講解5個部分是幹嘛用的：
//context
private Activity context;
//model（數據源 Java Bean）
private NewsService.News news;
private TopNewsService.News topNews;
//數據綁定，綁定到UI的欄位（data field）
public final ObservableField<String> imageUrl = new ObservableField<>();
public final ObservableField<String> html = new ObservableField<>();
public final ObservableField<String> title = new ObservableField<>();
// 一個變數包含了所有關於View Style 相關的欄位
public final ViewStyle viewStyle = new ViewStyle();
//命令綁定（command）
public final ReplyCommand onRefreshCommand = new ReplyCommand<>(() -> {

})
public final ReplyCommand<Integer> onLoadMoreCommand = new ReplyCommand<>((itemCount) -> {

});

//Child ViewModel
public final ObservableList<NewItemViewModel> itemViewModel = new ObservableArrayList<>();

/** * ViewStyle 關於控制項的一些屬性和業務數據無關的Style 可以做一個包裹，這樣代碼比較美觀，
ViewModel 頁面也不會有太多太雜的欄位。 **/
public static class ViewStyle {
public final ObservableBoolean isRefreshing = new ObservableBoolean(true);
public final ObservableBoolean progressRefreshing = new ObservableBoolean(true);
}

Context
Context是幹嘛用的呢，為什麼每個ViewModel都最好需要持了一個Context的引用呢？ViewModel不處理和UI相關的事也不操作控制項，更不更新UI，那為什麼要有Context呢？原因
Model是什麼呢？其實就是數據源，可以簡單理解是我們用JSON轉過來的Bean。ViewModel要把數據映射到UI中可能需要大量對Model的數據拷貝和操作，拿Model的欄位去生成對應的ObservableField然後綁定到UI（我們不會直接拿Model的數據去做綁定展示），這里是有必要在一個ViewModel保留原始的Model引用，這對於我們是非常有用的，因為可能用戶的某些操作和輸入需要我們去改變數據源，可能我們需要把一個Bean在列表頁點擊後傳給詳情頁，可能我們需要把這個Model當做表單提交到伺服器。這些都需要我們的ViewModel持有相應的Model（數據源）。
Data Field（數據綁定）
Data Field就是需要綁定到控制項上的ObservableField欄位，這是ViewModel的必需品，這個沒有什麼好說。但是這邊有一個建議：
這些欄位是可以稍微做一下分類和包裹的。比如說可能一些欄位是綁定到控制項的一些Style屬性上（如長度、顏色、大小），對於這類針對View Style的的欄位可以聲明一個ViewStyle類包裹起來，這樣整個代碼邏輯會更清晰一些，不然ViewModel裡面可能欄位泛濫，不易管理和閱讀性較差。而對於其他一些欄位，比如說title、imageUrl、name這些屬於數據源類型的欄位，這些欄位也叫數據欄位，是和業務數據和邏輯息息相關的，這些欄位可以放在一塊。
Command（命令綁定）
Command（命令綁定）簡言之就是對事件的處理（下拉刷新、載入更多、點擊、滑動等事件處理）。我們之前處理事件是拿到UI控制項的引用，然後設置Listener，這些Listener其實就是Command。但是考慮到在一個ViewModel寫各種Listener並不美觀，可能實現一個Listener就需要實現多個方法，但是我們可能只想要其中一個有用的方法實現就好了。更重要一點是實現一個Listener可能需要寫一些UI邏輯才能最終獲取我們想要的。簡單舉個例子，比如你想要監聽ListView滑到最底部然後觸發載入更多的事件，這時候就要在ViewModel裡面寫一個OnScrollListener，然後在裡面的onScroll方法中做計算，計算什麼時候ListView滑動底部了。其實ViewModel的工作並不想去處理這些事件，它專注做的應該是業務邏輯和數據處理，如果有一個東西不需要你自己去計算是否滑到底部，而是在滑動底部自動觸發一個Command，同時把當前列表的總共的item數量返回給你，方便你通過 page=itemCount/LIMIT+1去計算出應該請求伺服器哪一頁的數據那該多好啊。MVVM Light Toolkit 幫你實現了這一點：
public final ReplyCommand<Integer> onLoadMoreCommand = new ReplyCommand<>((itemCount) -> {
int page=itemCount/LIMIT+1;
loadData(page.LIMIT)
});

接著在XML布局文件中通過bind:onLoadMoreCommand綁定上去就行了。
<android.support.v7.widget.RecyclerView
android:layout_width="match_parent"
android:layout_height="match_parent"
bind:onLoadMoreCommand="@{viewModel.loadMoreCommand}"/>
x

當然Command並不是必須的，你完全可以依照自己的習慣和喜好在ViewModel寫Listener，不過使用Command可以使ViewModel更簡潔易讀。你也可以自己定義更多的、其他功能的Command，那麼ViewModel的事件處理都是託管ReplyCommand 來處理，這樣的代碼看起來會比較美觀和清晰。Command只是對UI事件的一層隔離UI層的封裝，在事件觸發時把ViewModel層可能需要的數據傳給ViewModel層，對事件的處理做了統一化，是否使用的話，還是看你個人喜好了。
Child ViewModel（子ViewModel）
子ViewModel的概念就是在ViewModel裡面嵌套其他的ViewModel，這種場景還是很常見的。比如說你一個Activity裡面有兩個Fragment，ViewModel是以業務劃分的，兩個Fragment做的業務不一樣，自然是由兩個ViewModel來處理，這時候Activity對應的ViewModel裡面可能包含了兩個Fragment各自的ViewModel，這就是嵌套的子ViewModel。還有另外一種就是對於AdapterView，如ListView RecyclerView、ViewPager等。
//Child ViewModelpublic final
ObservableList<ItemViewModel> itemViewModel = new ObservableArrayList<>();

它們的每個Item其實就對應於一個ViewModel，然後在當前的ViewModel通過ObservableList 持有引用（如上述代碼），這也是很常見的嵌套的子ViewModel。我們其實還建議，如果一個頁面業務非常復雜，不要把所有邏輯都寫在一個ViewModel，可以把頁面做業務劃分，把不同的業務放到不同的ViewModel，然後整合到一個總的ViewModel，這樣做起來可以使我們的代碼業務清晰、簡短意賅，也方便後人的維護。
總的來說，ViewModel和View之前僅僅只有綁定的關系，View層需要的屬性和事件處理都是在XML裡面綁定好了，ViewModel層不會去操作UI，只是根據業務要求處理數據，這些數據自動映射到View層控制項的屬性上。關於ViewModel類中包含哪些模塊和欄位，這個需要開發者自己去衡量，我們建議ViewModel不要引入太多的成員變數，成員變數最好只有上面的提到的5種（context、model……），能不引入其他類型的變數就盡量不要引進來，太多的成員變數對於整個代碼結構破壞很大，後面維護的人要時刻關心成員變數什麼時候被初始化、什麼時候被清掉、什麼時候被賦值或者改變，一個細節不小心可能就出現潛在的Bug。太多不清晰定義的成員變數又沒有注釋的代碼是很難維護的。
另外，我們會把UI控制項的屬性和事件都通過XML（如bind：text=@{...}）綁定。如果一個業務邏輯要彈一個Dialog，但是你又不想在ViewModel裡面做彈窗的事（ViewModel不希望做UI相關的事）或者說改變ActionBar上面的圖標的顏色，改變ActionBar按鈕是否可點擊，這些都不是寫在XML裡面（都是用Java代碼初始化的），如何對這些控制項的屬性做綁定呢？我們先來看下代碼：
public class MainViewModel implements ViewModel {
....
//true的時候彈出Dialog，false的時候關掉dialog
public final ObservableBoolean isShowDialog = new ObservableBoolean();
....
.....
}
// 在View層做一個對isShowDialog改變的監聽
public class MainActivity extends RxBasePmsActivity {

private MainViewModel mainViewModel;

@Override
protected void onCreate(Bundle savedInstanceState) {
.....
mainViewModel.isShowDialog.addOnPropertyChangedCallback(new android.databinding.Observable.OnPropertyChangedCallback() {
@Override
public void onPropertyChanged(android.databinding.Observable sender, int propertyId) {
if (mainViewModel.isShowDialog.get()) {
dialog.show();
} else {
dialog.dismiss();
}
}
});
}
...
}

簡單地說你可以對任意的ObservableField做監聽，然後根據數據的變化做相應UI的改變，業務層ViewModel只要根據業務處理數據就行，以數據來驅動UI。

② 前端mvvm框架有哪些

MVVM框架：angularjs emberjs react vue等
https://segmentfault.com/q/1010000000307033

③ 安卓studio 怎麼搭建mvvm

如何分工
構建MVVM框架首先要具體了解各個模塊的分工，接下來我們來講解View，ViewModel，Model 的它們各自的職責所在。
View
View層做的就是和UI相關的工作，我們只在XML和Activity或Fragment寫View層的代碼，View層不做和業務相關的事，也就是我們的Activity 不寫和業務邏輯相關代碼，也不寫需要根據業務邏輯來更新UI的代碼，因為更新UI通過Binding實現，更新UI在ViewModel裡面做（更新綁定的數據源即可），Activity 要做的事就是初始化一些控制項（如控制項的顏色，添加 RecyclerView 的分割線），Activity可以更新UI，但是更新的UI必須和業務邏輯和數據是沒有關系的，只是單純的根據點擊或者滑動等事件更新UI(如 根據滑動顏色漸變、根據點擊隱藏等單純UI邏輯)，Activity（View層）是可以處理UI事件，但是處理的只是處理UI自己的事情，View層只處理View層的事。簡單的說：View層不做任何業務邏輯、不涉及操作數據、不處理數據、UI和數據嚴格的分開。
ViewModel
ViewModel層做的事情剛好和View層相反，ViewModel 只做和業務邏輯和業務數據相關的事，不做任何和UI、控制項相關的事，ViewModel 層不會持有任何控制項的引用，更不會在ViewModel中通過UI控制項的引用去做更新UI的事情。ViewModel就是專注於業務的邏輯處理，操作的也都是對數據進行操作，這些個數據源綁定在相應的控制項上會自動去更改UI，開發者不需要關心更新UI的事情。DataBinding 框架已經支持雙向綁定，這使得我們在可以通過雙向綁定獲取View層反饋給ViewModel層的數據，並進行操作。關於對UI控制項事件的處理，我們也希望能把這些事件處理綁定到控制項上，並把這些事件統一化，方便ViewModel對事件的處理和代碼的美觀。為此我們通過BindingAdapter 對一些常用的事件做了封裝，把一個個事件封裝成一個個Command，對於每個事件我們用一個ReplyCommand<T>去處理就行了,ReplyCommand<T>會把可能你需要的數據帶給你，這使得我們處理事件的時候也只關心處理數據就行了，具體見MVVM Light Toolkit 使用指南的 Command 部分。再強調一遍ViewModel 不做和UI相關的事。
Model
Model 的職責很簡單，基本就是實體模型（Bean）同時包括Retrofit 的Service ，ViewModel 可以根據Model 獲取一個Bean的Observable<Bean>( RxJava ),然後做一些數據轉換操作和映射到ViewModel 中的一些欄位，最後把這些欄位綁定到View層上。
總得來說ViewModel 和View 之前僅僅只有綁定的關系，View層需要的屬性和事件處理都是在xml裡面綁定好了，ViewModel層不會去操作UI，只會操作數據，ViewModel只是根據業務要求處理數據，這些數據自動映射到View層控制項的屬性上。關於ViewModel類中包含哪些模塊和欄位，這個需要開發者自己去衡量，這邊建議ViewModel 不要引入太多的成員變數，成員變數最好只有上面的提到的5種（context、model、…），能不進入其他類型的變數就盡量不要引進來，太多的成員變數對於整個代碼結構破壞很大，後面維護的人要時刻關心成員變數什麼時候被初始化，什麼時候被清掉，什麼時候被賦值或者改變，一個細節不小心可能就出現潛在的Bug。太多不清晰定義的成員變數又沒有注釋的代碼是很難維護
Model 是通過Retrofit 去獲取網路數據的，返回的數據是一個Observable<Bean>( RxJava ),Model 層其實做的就是這些。那麼ViewModel 做的就是通過傳參數到Model層獲取到網路數據（資料庫同理）然後把Model的部分數據映射到ViewModel的一些欄位（ObservableField），並在ViewModel 保留這個Model的引用,我們來看下這一塊的大致代碼(代碼涉及到簡單RxJava，如看不懂可以查閱入門一下.

④ android mvp mvvm怎麼選擇 簡書

1.MVC
傳統的Android App其實都是基於MVC的，Activity，Fragment相當於C,布局相當於V,數據邏輯相當於M
隨著業務的增長Controller里的代碼會越來越臃腫，因為它不只要負責業務邏輯，還要控制View的展示。也就是說Activity、Fragment雜糅了Controller和View，耦合變大。並不能算作真正意義上的MVC。
這也是為什麼後面的MVP會引起很多開發者興趣的原因了。
2.MVP
MVP架構其實可以說與MVC的架構還是有很大的差別的，數據邏輯相當於M，Activity（負責View的繪制以及與用戶交互）相當於V ，View於Model間的交互則為P
理論上感覺區別有點抽象，可以通過下面的圖來看一看其中的區別

⑤ 為什麼Android MVVM框架沒有流行開

快，比如我要做一個列表，要求上拉刷新，下來載入你自己搞，一星期不見得搞得定，並且bug滿天飛但是你可以去github上下載一個開源的庫，幾分鍾功能就完成了。雖然不知道人家是如何實現的，但是至少你完成了你的功能

⑥ 有沒有比較成熟的Android開源MVC框架

Android的MVC框架有不少，但是不能成為主流。
Android開發並不像企業及JAVA一樣有主流的SSH，
畢竟企業JAVA 是WEB開發，而Android是客戶端開發，客戶端的代碼別人是可以進行破解反編譯的。
一般經理的要求是，框架寫得越復雜。讓別人反編譯越難越好。
若大家都採用統一的MVC框架，那客戶端的代碼安全性就降低了。

⑦ 如何構建Android MVVM 應用框架

概述
說到Android MVVM，相信大家都會想到Google 2015年推出的DataBinding框架。然而兩者的概念是不一樣的，不能混為一談。MVVM是一種架構模式，而DataBinding是一個實現數據和UI綁定的框架，是構建MVVM模式的一個工具。
之前看過很多關於Android MVVM的博客，但大多數提到的都是DataBinding的基本用法，很少有文章仔細講解在Android中是如何通過DataBinding去構建MVVM的應用框架的。View、ViewModel、Model每一層的職責如何?它們之間聯系怎樣、分工如何、代碼應該如何設計?這是我寫這篇文章的初衷。
接下來，我們先來看看什麼是MVVM，然後再一步一步來設計整個MVVM框架。
MVC、MVP、MVVM
首先，我們先大致了解下Android開發中常見的模式。
MVC
View：XML布局文件。
Model：實體模型(數據的獲取、存儲、數據狀態變化)。
Controllor：對應於Activity，處理數據、業務和UI。
從上面這個結構來看，Android本身的設計還是符合MVC架構的，但是Android中純粹作為View的XML視圖功能太弱，我們大量處理View的邏輯只能寫在Activity中，這樣Activity就充當了View和Controller兩個角色，直接導致Activity中的代碼大爆炸。相信大多數Android開發者都遇到過一個Acitivty數以千行的代碼情況吧!所以，更貼切的說法是，這個MVC結構最終其實只是一個Model-View(Activity:View&Controller)的結構。
MVP
View: 對應於Activity和XML，負責View的繪制以及與用戶的交互。
Model: 依然是實體模型。
Presenter: 負責完成View與Model間的交互和業務邏輯。
前面我們說，Activity充當了View和Controller兩個角色，MVP就能很好地解決這個問題，其核心理念是通過一個抽象的View介面(不是真正的View層)將Presenter與真正的View層進行解耦。Persenter持有該View介面，對該介面進行操作，而不是直接操作View層。這樣就可以把視圖操作和業務邏輯解耦，從而讓Activity成為真正的View層。
但MVP也存在一些弊端：
Presenter(以下簡稱P)層與View(以下簡稱V)層是通過介面進行交互的，介面粒度不好控制。粒度太小，就會存在大量介面的情況，使代碼太過碎版化;粒度太大，解耦效果不好。同時對於UI的輸入和數據的變化，需要手動調用V層或者P層相關的介面，相對來說缺乏自動性、監聽性。如果數據的變化能自動響應到UI、UI的輸入能自動更新到數據，那該多好!
MVP是以UI為驅動的模型，更新UI都需要保證能獲取到控制項的引用，同時更新UI的時候要考慮當前是否是UI線程，也要考慮Activity的生命周期(是否已經銷毀等)。
MVP是以UI和事件為驅動的傳統模型，數據都是被動地通過UI控制項做展示，但是由於數據的時變性，我們更希望數據能轉被動為主動，希望數據能更有活性，由數據來驅動UI。
V層與P層還是有一定的耦合度。一旦V層某個UI元素更改，那麼對應的介面就必須得改，數據如何映射到UI上、事件監聽介面這些都需要轉變，牽一發而動全身。如果這一層也能解耦就更好了。
復雜的業務同時也可能會導致P層太大，代碼臃腫的問題依然不能解決。
MVVM
View: 對應於Activity和XML，負責View的繪制以及與用戶交互。
Model: 實體模型。
ViewModel: 負責完成View與Model間的交互，負責業務邏輯。
MVVM的目標和思想與MVP類似，利用數據綁定(Data Binding)、依賴屬性(Dependency Property)、命令(Command)、路由事件(Routed Event)等新特性，打造了一個更加靈活高效的架構。
數據驅動
在常規的開發模式中，數據變化需要更新UI的時候，需要先獲取UI控制項的引用，然後再更新UI。獲取用戶的輸入和操作也需要通過UI控制項的引用。在MVVM中，這些都是通過數據驅動來自動完成的，數據變化後會自動更新UI，UI的改變也能自動反饋到數據層，數據成為主導因素。這樣MVVM層在業務邏輯處理中只要關心數據，不需要直接和UI打交道，在業務處理過程中簡單方便很多。
低耦合度
MVVM模式中，數據是獨立於UI的。
數據和業務邏輯處於一個獨立的ViewModel中，ViewModel只需要關注數據和業務邏輯，不需要和UI或者控制項打交道。UI想怎麼處理數據都由UI自己決定，ViewModel不涉及任何和UI相關的事，也不持有UI控制項的引用。即便是控制項改變了(比如：TextView換成EditText)，ViewModel也幾乎不需要更改任何代碼。它非常完美的解耦了View層和ViewModel，解決了上面我們所說的MVP的痛點。
更新UI
在MVVM中，數據發生變化後，我們在工作線程直接修改(在數據是線程安全的情況下)ViewModel的數據即可，不用再考慮要切到主線程更新UI了，這些事情相關框架都幫我們做了。
團隊協作
MVVM的分工是非常明顯的，由於View和ViewModel之間是鬆散耦合的：一個是處理業務和數據、一個是專門的UI處理。所以，完全由兩個人分工來做，一個做UI(XML和Activity)一個寫ViewModel，效率更高。
可復用性
一個ViewModel可以復用到多個View中。同樣的一份數據，可以提供給不同的UI去做展示。對於版本迭代中頻繁的UI改動，更新或新增一套View即可。如果想在UI上做A/B Testing，那MVVM是你不二選擇。
單元測試
有些同學一看到單元測試，可能腦袋都大。是啊，寫成一團漿糊的代碼怎麼可能做單元測試?如果你們以代碼太爛無法寫單元測試而逃避，那可真是不好的消息了。這時候，你需要MVVM來拯救。
我們前面說過了，ViewModel層做的事是數據處理和業務邏輯，View層中關注的是UI，兩者完全沒有依賴。不管是UI的單元測試還是業務邏輯的單元測試，都是低耦合的。在MVVM中數據是直接綁定到UI控制項上的(部分數據是可以直接反映出UI上的內容)，那麼我們就可以直接通過修改綁定的數據源來間接做一些Android UI上的測試。
通過上面的簡述以及模式的對比，我們可以發現MVVM的優勢還是非常明顯的。雖然目前Android開發中可能真正在使用MVVM的很少，但是值得我們去做一些探討和調研。
如何構建MVVM應用框架
如何分工
構建MVVM框架首先要具體了解各個模塊的分工。接下來我們來講解View、ViewModel、Model它們各自的職責所在。
View
View層做的就是和UI相關的工作，我們只在XML、Activity和Fragment寫View層的代碼，View層不做和業務相關的事，也就是我們在Activity不寫業務邏輯和業務數據相關的代碼，更新UI通過數據綁定實現，盡量在ViewModel裡面做(更新綁定的數據源即可)，Activity要做的事就是初始化一些控制項(如控制項的顏色，添加RecyclerView的分割線)，View層可以提供更新UI的介面(但是我們更傾向所有的UI元素都是通過數據來驅動更改UI)，View層可以處理事件(但是我們更希望UI事件通過Command來綁定)。簡單地說：View層不做任何業務邏輯、不涉及操作數據、不處理數據，UI和數據嚴格的分開。
ViewModel
ViewModel層做的事情剛好和View層相反，ViewModel只做和業務邏輯和業務數據相關的事，不做任何和UI相關的事情，ViewModel 層不會持有任何控制項的引用，更不會在ViewModel中通過UI控制項的引用去做更新UI的事情。ViewModel就是專注於業務的邏輯處理，做的事情也都只是對數據的操作(這些數據綁定在相應的控制項上會自動去更改UI)。同時DataBinding框架已經支持雙向綁定，讓我們可以通過雙向綁定獲取View層反饋給ViewModel層的數據，並對這些數據上進行操作。關於對UI控制項事件的處理，我們也希望能把這些事件處理綁定到控制項上，並把這些事件的處理統一化，為此我們通過BindingAdapter對一些常用的事件做了封裝，把一個個事件封裝成一個個Command，對於每個事件我們用一個ReplyCommand去處理就行了，ReplyCommand會把你可能需要的數據帶給你，這使得我們在ViewModel層處理事件的時候只需要關心處理數據就行了，具體見MVVM Light Toolkit 使用指南的 Command 部分。再強調一遍：ViewModel 不做和UI相關的事。
Model
Model層最大的特點是被賦予了數據獲取的職責，與我們平常Model層只定義實體對象的行為截然不同。實例中，數據的獲取、存儲、數據狀態變化都是Model層的任務。Model包括實體模型(Bean)、Retrofit的Service ，獲取網路數據介面，本地存儲(增刪改查)介面，數據變化監聽等。Model提供數據獲取介面供ViewModel調用，經數據轉換和操作並最終映射綁定到View層某個UI元素的屬性上。
如何協作
關於協作，我們先來看下面的一張圖：

上圖反映了MVVM框架中各個模塊的聯系和數據流的走向，我們從每個模塊一一拆分來看。那麼我們重點就是下面的三個協作。
ViewModel與View的協作。
ViewModel與Model的協作。
ViewModel與ViewModel的協作。
ViewModel與View的協作

圖2中ViewModel和View是通過綁定的方式連接在一起的，綁定分成兩種：一種是數據綁定，一種是命令綁定。數據的綁定DataBinding已經提供好了，簡單地定義一些ObservableField就能把數據和控制項綁定在一起了(如TextView的text屬性)，但是DataBinding框架提供的不夠全面，比如說如何讓一個URL綁定到一個ImageView，讓這個ImageView能自動去載入url指定的圖片，如何把數據源和布局模板綁定到一個ListView，讓ListView可以不需要去寫Adapter和ViewHolder相關的東西?這些就需要我們做一些工作和簡單的封裝。MVVM Light Toolkit 已經幫我們做了一部分的工作，詳情可以查看MVVM Light Toolkit 使用指南。關於事件綁定也是一樣，MVVM Light Toolkit 做了簡單的封裝，對於每個事件我們用一個ReplyCommand去處理就行了，ReplyCommand會把可能需要的數據帶給你，這樣我們處理事件的時候也只關心處理數據就行了。
由圖1中ViewModel的模塊中我們可以看出ViewModel類下面一般包含下面5個部分：
Context (上下文)
Model (數據源 Java Bean)
Data Field (數據綁定)
Command (命令綁定)
Child ViewModel (子ViewModel)
我們先來看下示例代碼，然後再一一講解5個部分是幹嘛用的：
//contextprivate Activity context;//model（數據源 Java Bean）private NewsService.News news;private TopNewsService.News topNews;//數據綁定，綁定到UI的欄位（data field）public final ObservableField<String> imageUrl = new ObservableField<>();public final ObservableField<String> html = new ObservableField<>();public final ObservableField<String> title = new ObservableField<>();// 一個變數包含了所有關於View Style 相關的欄位public final ViewStyle viewStyle = new ViewStyle();//命令綁定（command）public final ReplyCommand onRefreshCommand = new ReplyCommand<>(() -> {

})public final ReplyCommand<Integer> onLoadMoreCommand = new ReplyCommand<>((itemCount) -> {

});//Child ViewModelpublic final ObservableList<NewItemViewModel> itemViewModel = new ObservableArrayList<>();/** * ViewStyle 關於控制項的一些屬性和業務數據無關的Style 可以做一個包裹，這樣代碼比較美觀，
ViewModel 頁面也不會有太多太雜的欄位。 **/public static class ViewStyle {
public final ObservableBoolean isRefreshing = new ObservableBoolean(true);
public final ObservableBoolean progressRefreshing = new ObservableBoolean(true);
}
Context

⑧ 如何構建Android MVVM 應用框架

最近挺流行RESTFUL webservice + MVVM框架去實現web應用，好像.net 常用的的web api + knockout js， java常用spring mvc restful + angular（或其他）。 ​但是感覺使用mvvm框架會把頁面操作的代碼暴露了出來，別人知道了頁面操作的js文件，就會看到那些修改、刪除、添加的url，然後使用fiddler等工具，就可以跳過你的應用去修改數據了。

⑨ 如何構建Android MVVM 應用框架

Databinding 是一種框架，MVVM是一種模式，兩者的概念是不一樣的。我的理解DataBinding是一個實現數據和UI綁定的框架，只是一個實現MVVM模式的工具。ViewModel和View可以通過DataBinding來實現單向綁定和雙向綁定，這套UI和數據之間的動態監聽和動態更新的框架Google已經幫我們做好了。在MVVM模式中ViewModel和View是用綁定關系來實現的，所以有了DataBinding 使我們構建Android MVVM 應用程序成為可能。
之前看了很多關於DataBinding的博客和相關的一些Demo，大多數就是往xml布局文件傳入一些數據，然後把這些數據綁定到控制項上( 如TextView binding:text=「@{user.name} )，接著在這些控制項上（如Button binding:setOnClickListener=」@{user.listener}」) 設置一些事件到控制項上，基本講述都是DataBinding的基本用法。但是並沒有人告訴你把一個onClickListener 寫到一個類並把這個listener綁定到xml裡面上是不是不太好，也沒有人告訴你這個和xml布局綁定的ViewModel類應該放哪些數據，應該做什麼事？應該如何設計？更是很少有博文來告訴你在Android 中如何通過Data Binding 去構建MVVM 的應用框架。這也就是是本篇文章的重點。接下來，我們先來看看什麼是MVVM，然後在一步一步來設計整個應用程序框架。

⑩ 如何構建Android MVVM應用框架

Databinding 是一種框架，MVVM是一種模式，兩者的概念是不一樣的。我的理解DataBinding是一個實現數據和UI綁定的框架，只是一個實現MVVM模式的工具。ViewModel和View可以通過DataBinding來實現單向綁定和雙向綁定，這套UI和數據之間的動態監聽和動態更新的框架Google已經幫我們做好了。在MVVM模式中ViewModel和View是用綁定關系來實現的，所以有了DataBinding 使我們構建Android MVVM 應用程序成為可能。