Advantage

MVVM MVP similar goals and ideas, using data binding (Data Binding), dependency property (Dependency Property), command (Command), routed events (Routed Event) and other new features, to create a more flexible and efficient architecture.

The data driver
in MVVM, the previously developed model must be processed traffic data, then the data change according, to acquire UI-REFERENCE then update the UI, but also to get user input through the UI, by in MVVM, the data and business logic in View Model in a separate, ViewModel as long as the focus on data and business logic, and do not need to deal with UI or controls. By the data automatically to drive the UI to automatically update the UI, the UI has changed and automatically fed back to the data, the data become the dominant factor, so that as long as the interest in the business logic processing data, convenient and much simpler.
Low coupling
MVVM pattern, the data is independent of the UI, ViewModel only responsible for processing and providing data, like how to deal with data by the UI UI decide for themselves, ViewModel and does not involve any associated UI UI controls do not hold a reference to , even if the control change (TextView replaced EditText) ViewModel almost do not need to change any code, focus on their data processing on it, if MVP is experiencing UI changes, you may need to change the way get UI change the interface to update the UI, change the code to obtain input from the UI, UI may also need to change the access codes and so on object properties.
Update the UI
in MVVM, we can modify the data directly in the View Model worker thread (as long as the data is thread-safe), the rest of the data binding framework to seal the deal, a lot of things you do not need to care about.
Teamwork
division MVVM is very significant because between View and View Model are loosely coupled. It is a business and data processing, is a specialized UI processing. There are two people to do the complete division of labor, to do a UI (xml and Activity) to write a ViewModel, more efficient.
Reusability
a View Model View multiplexed into multiple, the same copy of the data, do show a different UI for the UI version iteration frequent changes, as long as the replacement View layer on the line, if you want to on the UI do AbTest is more convenient.
Unit Testing
View Model which is the data and business logic, View of the UI is concerned, this test is very easy to do, there is no mutual dependence, either UI or business logic unit testing unit testing are low coupling of.

Division of labor

View

View and UI layer to do is work-related, we just write in XML and Activity or Fragment Code View layer, and the View layer is not business-related thing, that is, we do not write the Activity and business logic related to the code, nor need to write code to update UI based on business logic, because the update UI binding achieved by updating the UI ViewModel which do (you can update the data source bound), Activity thing to do is to initialize some controls (such as color control, Add RecyclerView dividing line), Activity can update the UI, but the updated UI must be the business logic and data are not related, but simply update the UI based on click or slide and other events (such as sliding a color gradient, in accordance click to hide and so simple UI logic), Activity (View layer) can handle UI events, but just handle UI handled their own affairs, View layer handles only thing View layer. Simply put: View layer without any business logic, does not involve operational data, not data processing, strictly separate UI and data.

ViewModel

ViewModel summary
ViewModel layer to do just the opposite and the View layer, and only ViewModel business logic and business data related to the matter, and without any UI, controls related matter, ViewModel layer does not hold any reference to the control, but do not UI update references do things through the UI controls in the ViewModel. ViewModel is focus on the business logic processing, are also operate on the data operations, these data source bindings on the corresponding control will automatically change to the UI, developers do not need to be concerned about what the UI update. DataBinding framework already supports two-way binding, so that we can get this data back to the View layer ViewModel layer by way binding, and operate it. About handling of UI control events, we also hope that these event handlers bound to the controls, and these events unified, easy handling and the elegant ViewModel event code. For this reason we have to some commonly used by BindingAdapter done a package, put a package into one event Command, for each event we have to deal with a ReplyCommand on the line, ReplyCommand will probably give you the data you need, this so that when we deal with events only concerned with processing data on the line, see the specific section MVVM Light Toolkit Command usage guidelines. Once again do not do UI and ViewModel related things.
The following classes ViewModel generally comprises the following five sections:

Context (context)
Model (Data Model Bean)
Data Field (data binding)
Command (command to bind)
Child ViewModel （子ViewModel）

ViewModel recommended not to introduce too many member variables, member variables only the best top five kinds of (context, model, ...) mentioned, can not enter other types of variables try not to introduce too many variables for the entire membership great damage to the code structure, maintenance people should always be concerned about the back member variable is initialized when, what time is cleared, what time is assigned or changed, a detail not careful might potentially arise Bug. Too many variables are not clearly defined and no members commented code is difficult to maintain.
notes

How to define whether or not associated with UI?
As long as it has nothing to do with the control UI, it can be a string, bitmap, etc.

Model

Model What is it, in fact, a prototype data, that is, we use Json turn of Java Bean, we may know, the mapping should ViewModel to the View data may need to copy large amounts of data on the Model of Model take the field to generate the corresponding the ObservableField (we will not take a direct data do show the Model), where in fact it is necessary to preserve the original Model referenced in a ViewModel, which for us is very useful, because there may be some operations and we need to enter the user's change the data source, we may need to pass a Bean details page after page click on the list, we may need to put this model as a form submitted to the server. These require our ViewModel hold the appropriate model.

Decoupling implementation

activity on viewmodel have examples, but viewmodel no instance of activity, so there is no activity leak, while viewmodel and life cycle binding. That viewmodel activity and how they interact with it?
Binding can be achieved by listening LiveData.
How to achieve a single variable value is updated