mvcforandroid

A. Android開發有MVC的框架嗎Android 開發該怎麼分包

現在都使用mvp進行android開發。
詳細例子請參考android學習手冊，360手機助手中可以下載，裡面有108個android例子，源碼文檔都可在裡面看，裡面有詳細介紹這個的框架。
MVP模式是什麼？MVP 是從經典的模式MVC演變而來，它們的基本思想有相通的地方：Controller/Presenter負責邏輯的處理，Model提供數據，View負責顯示。
MVC和MVP的區別？
為什麼會出現MVP模式呢？這是因為原有的MVC模式有一些短板。比如在android開發中，activity充當著MVC中Controller的角色，但是在實際開發中處理view的邏輯和角色。當業務界面復雜時我的activity會顯得很龐大。於是出現了MVP模式，它新增了一個Presenter角色用於處理數據和界面的模型以及邏輯，Activity僅僅用於展示界面和用戶交互，這樣就解決了MVC中角色不清的局面。
所以，MVP與MVC的重大區別：在MVP中View並不直接使用Model，它們之間的通信是通過Presenter (MVC中的Controller)來進行的，所有的交互都發生在Presenter內部，而在MVC中View會直接從Model中讀取數據而不是通過 Controller。
在MVC里，View是可以直接訪問Model的！從而，View里會包含Model信息，不可避免的還要包括一些業務邏輯。 在MVC模型里，更關注的Model的不變，而同時有多個對Model的不同顯示，即View。所以，在MVC模型里，Model不依賴於View，但是View是依賴於Model的。不僅如此，因為有一些業務邏輯在View里實現了，導致要更改View也是比較困難的，至少那些業務邏輯是無法重用的。
MVC模式結構
Model 業務邏輯和實體模型
Controller 對應Activity
View 視圖以及布局文件

MVP模式結構
Model： 業務邏輯和實體模型
View：用戶交互和視圖顯示，在android中對應activity
Presenter： 負責完成View於Model間的邏輯和交互
小節：MVP模式相當於在MVC模式中又加了一個Presenter用於處理模型和邏輯，將View和Model完全獨立開，在android開發中的體現就是activity僅用於顯示界面和交互，activity不參與模型結構和邏輯，
####實戰
谷歌官網給了我們一個MVP模式實戰的例子，它是一個類似記事本的app，源碼地址在：https://github.com/googlesamples/android-architecture
官方案例的框架圖如下：

B. android mvc什麼時候出來的

很久了、
mvc是model、view、controller的縮寫。android 鼓勵弱耦合和組件的重用，android 中mvc的具體體現如下：
模型（model）：是應用程序的主題部分，所有的業務邏輯都應在該層（對資料庫的操作、對網路等的操作都應該在model裡面處理，當然對計算等操作也是必須放在該層的）。
視圖層（view）：是應用程序中負責生成用戶界面的部分。也是整個mvc架構中用戶唯一可以看到的一層，接收用戶的輸入，顯示用戶的處理結果。一般用xml文件進行界面的描述，使用的時候可以非常方便的引入。
控制層（controller）：是根據用戶的輸入，控制用戶界面數據顯示及更i新model對象狀態的部分。android的控制層的重任通常落在了眾多activity的肩上，這句話也就暗含了不要在activity中寫過多代碼，要通過activity交割model業務邏輯處理層處理，這樣做的另外一個原因是android中的activity的響應時間是5秒，如果耗時的操作放在這里，程序很容易被回收掉。

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

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

D. 說說mvc模式的原理，它在android中的運用

千鋒扣丁學堂Android開發為您解答：
mvc是model,view,controller的縮寫，mvc包含三個部分：

l模型（model）對象：是應用程序的主體部分，所有的業務邏輯都應該寫在該層。

l視圖（view）對象：是應用程序中負責生成用戶界面的部分。也是在整個mvc架構中用戶唯一可以看到的一層，接收用戶的輸入，顯示處理結果。

l控制器（control）對象：是根據用戶的輸入，控制用戶界面數據顯示及更新model對象狀態的部分，控制器更重要的一種導航功能，想用用戶出發的相關事件，交給m哦得了處理。

android鼓勵弱耦合和組件的重用，在android中mvc的具體體現如下：

1)視圖層（view）：一般採用xml文件進行界面的描述，使用的時候可以非常方便的引入，當然，如何你對android了解的比較的多了話，就一定可以想到在android中也可以使用javascript+html等的方式作為view層，當然這里需要進行java和javascript之間的通信，幸運的是，android提供了它們之間非常方便的通信實現。

2)控制層（controller）：android的控制層的重任通常落在了眾多的acitvity的肩上，這句話也就暗含了不要在acitivity中寫代碼，要通過activity交割model業務邏輯層處理，這樣做的另外一個原因是android中的acitivity的響應時間是5s，如果耗時的操作放在這里，程序就很容易被回收掉。

3)模型層（model）：對資料庫的操作、對網路等的操作都應該在model裡面處理，當然對業務計算等操作也是必須放在的該層的。

E. android mvc構架怎麼做

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.發起網路請求等）。

F. 如何使用mvc做android後台

可以，使用webservice就行 不過大多返回的不是html html需要瀏覽器解析 而android開發應該是請求一些數據返回就行，然後將數據放入相應的控制項中 具體是需要返回json 還是xml 或者是其它類型 需要伺服器開發者和android客戶端開發者共同協商完成

G. android和ios的mvc模式的區別

在學習 iOS 應用程序開發時，需對Cocoa Touch 的幾種設計模式有所了解。 談到設計模式，有人會覺得這是紙上談兵，故作玄虛。我們這里不談設計模式有多麼多麼神奇， 只對iOS Framework 已經用到的設計模式，逐一剖析。
學習iOS 開發，以下幾種設計模式，是不可不知的：
Target Action Design Pattern;
Notification Pattern
MVC Pattern
KVO （Key-Value Observing）
Singleton Pattern
Delegate Pattern

MVC 設計模式
相信你對 MVC 設計模式 並不陌生。從字面意思來理解， Modal , View , Controller ，其用意在於將數據與視圖分離開來。 在iOS cocoa touch 編程中， MVC機制被發揮得淋漓盡致。 MVC 示意圖如下。 只有充分理解了MVC，才能在編寫出優雅的iOS app。為充分理解 MVC， 相關的概念（比如： Delegate、 Protocol、 Notification 等）也要瞭然於胸。
MVC 約定， Model 不允許與View 打交道。 Model 是管理數據的， 當Model中的數據發生變化時，與之對應的視圖應更新。 這就需要一種機制來支持。為此 iOS 框架提供了兩種支持機制： Notification 和KVO （Key-Value Observing）。 KVO 可簡單理解為，為你所關注的 Key 對象注冊一個監聽器。 當有數據發生變化時，就會發出廣播給所有的監聽器。
MVC 也約定， View 不允許直接引用Modal， 它只能被Controller 所控制。 Controller 控制 View 顯示什麼數據。我們知道，View 所要顯示的數據是來源於 Modal， View 上產生的事件 （ 比如 Touch事件）需要通知 Controller。 既然MVC 不允許直接打交道，就需要提供一種機制。
不錯， iOS 確實提供了一種機制， 名曰： Delegate。 Delegate 這個詞， 有人將它譯為「委託」，也有人將它譯為「代理」。名稱上的差異沒有什麼，重要的是如何理解 Delegate。 Delegate設計模式的引入，就是為了解決UIView與Controller松耦合互動問題。
為便於理解， 這里截取一張來iOS MVC 示意圖：

我們在詳細介紹下這張圖的內涵：
1. 圖中，綠色的箭頭表示直接引用。 對View 的直接引用體現在 IBOutlet 上。 當引用一個View 時，比如Button。 需要在ViewController
中聲明一個 IBOutlet UIButton * btn；
2. 然後，我們看View 是怎麼向 Controller 通信的。對於這個， iOS 有三種常見的模式：
設置View對應的Action Target。如設置UIButton的Touch up inside的Action Target。
設置View的Delegate，如UIAlertViewDelegate, UIActionSheetDelegate，UITextFieldDelegate等。
設置View的data source, 如UITableViewDataSource。
通過以上三種模式，View既能向Controller通信，又無需知道具體的Controller是誰，這樣，View 就與Controller解耦了。
除此之外， iOS 還提供了 Action-Target 模式來讓Controller 監聽View 觸發的事件。 View 又是如何獲取數據呢？ iOS提供了 Data source 的概念，其實也就是Protocol 的應用。
綜上所述， 正是在iOS MVC框架的驅使下， 才需要深入理解 Delegate、Protocol等概念。

H. android可以使用MVC設計模式嗎是不是和java的MVC設計模式一樣的

可以 其實設計模式都是配置這里 配置那裡 只要你會一種 另外一種配置相信也不成問題

I. 如何構建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。