Official document connection (wall climbing required)

1, Introduction

The ViewModel class is designed to store and manage UI related data in a life-cycle aware manner. The data in the ViewModel will survive even if the activity configuration changes, such as when the horizontal and vertical screens are switched.

If the above is the official website, it won't be translated. It's meaningless and English is not good. Let's talk in my vernacular.
Let's first look at the pain points that ViewModel can solve.

1. Data persistence

We know that when the screen rotates, it will experience the destruction and re creation of activities. This involves the problem of data saving. Obviously, re requesting or loading data is unfriendly. Before the emergence of ViewModel, we can use the onSaveInstanceState() mechanism of activity to save and recover data, but the disadvantage is obvious. onSaveInstanceState is only suitable for saving a small amount of data that can be serialized and deserialized. If we need to save a large bitmap list, this mechanism is obviously inappropriate.
Due to the special design of ViewModel, this pain point can be solved.
Let's take a look at the ViewModel life cycle diagram:

As can be seen from the figure, the ViewModel life cycle runs through the entire activity life cycle, including the re creation of the activity due to rotation, which will not end until the activity is actually destroyed. In that case, it's better to store data.

2. Asynchronous callback problem

Usually, our app needs to frequently request data asynchronously, such as calling the interface to request server data. Of course, the callbacks of these requests are quite time-consuming. Previously, we received these callbacks in Activity or fragment. Therefore, we have to consider the potential memory leakage. For example, the interface request is returned only after the Activity is destroyed. Dealing with these problems will add a lot of complex work to us.
But now we use ViewModel to process data callback, which can perfectly solve this pain point.

3. Share the burden of UI controller

From the earliest MVC to the current popular MVP and MVVM, the purpose is to clarify responsibilities and separate the burden of UI controller.
UI controller s such as Activity and Fragment are designed to render and display data, respond to user behavior, and process some interactions of the system. If you ask him to be responsible for loading network or database data, it will make it look bloated and difficult to manage. Therefore, in order to be concise, refreshing and smooth, we can separate the responsibility of data operation from ViewModel.

4. Sharing data between Fragments

(you can look at the following usage introduction first)

For example, there are multiple fragments in an Activity, and some interaction needs to be done between the fragments. My previous practice is that interface callbacks need to be managed uniformly in the Activity, and inevitably fragments have to hold each other's references. If you think about it carefully, you can see that this is a very important thing. If the coupling is high, you still need a lot of fault-tolerant judgment (such as whether the other party's fragment is still alive).

So what about using ViewModel (example on the official website):
(an activity and its internal fragment s can share a ViewModel)

public class SharedViewModel extends ViewModel {
    private final MutableLiveData<Item> selected = new MutableLiveData<Item>();

    public void select(Item item) {
        selected.setValue(item);
    }

    public LiveData<Item> getSelected() {
        return selected;
    }
}


public class MasterFragment extends Fragment {
    private SharedViewModel model;
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        model = ViewModelProviders.of(getActivity()).get(SharedViewModel.class);
        itemSelector.setOnClickListener(item -> {
            model.select(item);
        });
    }
}

public class DetailFragment extends Fragment {
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        SharedViewModel model = ViewModelProviders.of(getActivity()).get(SharedViewModel.class);
        model.getSelected().observe(this, { item ->
           // Update the UI.
        });
    }
}

If you carefully experience such benefits, you will find:
1. Activity doesn't need to do anything, and doesn't even know about this interaction. It is perfectly decoupled.
2. The Fragment only needs to interact with the ViewModel, and does not need to know the status or even existence of the other Fragment, let alone hold its reference. When the other party's Fragment is destroyed, it will not affect any work of itself.
3. The life cycle of fragments does not affect each other, and even the replacement of fragments with others does not affect the operation of the system.

2, Usage introduction

ViewModel is generally used with LiveData. LiveData can refer to me Another article.
First, get the ViewModel instance through the provided class ViewModelProviders:

Or with Factory

VM internal operations:

Then, you can observe the data changes in the activity:

3, Principle of source code analysis

Start from the beginning of the ViewModel life cycle. When did it start? Nonsense, of course, starts when we instantiate it. When do we instantiate it? The original words on the official website are:
You usually request a ViewModel the first time the system calls an activity object's onCreate() method.
Yes, we usually initialize in onCreate.

ViewModel birth:

The instantiated code is very simple. Let's slowly analyze what we have done

1. The first is the of method of ViewModelProviders:

If the parameter has activity and fragment, I will only post the activity. The key point is that a Factory is introduced here. The method without Factory only initializes a sDefaultFactory (Factory implementation class) through initializefactoryifneed:

There is only one create method. If you think about it with your fingers, you know it must be used to initialize viewmodel. Put it in the until you can use it. Continue to see the method:

Two new classes, ViewModelProvider and ViewModelStores, appear. Look at ViewModelProvider first:

The superfluous items are omitted. This class simply maintains an mFactory, a newly emerging class ViewModelStore (to be discussed later), and provides a get method for generating ViewModel with mFactory and ViewModelStore. Wow, here we have seen the final instantiation of ViewModel, but don't worry, there are still a lot of things.

Look again

What did you do. First look at ViewModelStores:

There are only two of methods. holderFragmentFor is a static method that initializes HolderFragment. The trick is that HolderFragment plays a vital role. I won't talk about its important role here, just look at getViewModelStore()

Nothing to say. Look at ViewModelStore:

Obviously, it is a class used to store ViewModel instances. It internally maintains a HashMap to store ViewModel,
It also provides get, put and clear methods.

What has ViewModelProviders of done so far:
1. The ViewModelProvider is initialized, and the Factory used to create the VM and the ViewModelStore where the user stores the VM are maintained internally;
2. Initialize the Factory used to generate the ViewModel (DefaultFactory by default);
3. The HolderFragment and ViewModelStore are instantiated through the static method of ViewModelStores

2. Then the get method of ViewModelProvider:

It's already posted on it. Please post it again:

The logic is not complicated. First, see whether the ViewModelStore has been saved. If not, instantiate it through the factory and coexist in the ViewModelStore.

Death of ViewModel:

Let's look at how ViewModel ended its life.

Vm has only one onCleared method, so when did it call it
Here we will introduce the holder fragment mentioned earlier,

When Vm was created, it was mentioned that a HolderFragment was instantiated. When instantiating, use the createHolderFragment method above to the fragmentmanager beginTransaction(). add(holder, HOLDER_TAG). commitAllowingStateLoss();
We know that after commit, fragment will have soul and obtain life cycle. Look at the onDestroy method
Mviewmodelstore. Was called clear();

So far, Google has made full use of the feature of fragment life cycle to make Vm complete onCleared.
(I have to say here that Google's lifecycle and ViewModel all use some features of fragment to play these life cycles. Why do I like using fragment so much? I haven't fully understood it yet)

So the question is, why does the horizontal and vertical screen switching ViewModel not onCleared?
Look, there is one in the construction method of HolderFragment
setRetainInstance(true);
So everything is clear, (if you don't know, baidu what this method is for)
Google really makes full use of fragment features.

4, Attention

The official website uses a large red exclamation mark to indicate:
Caution: A ViewModel must never reference a view, Lifecycle, or any class that may hold a reference to the activity context.
Because the ViewModel life cycle may be long and the activity life cycle, in order to avoid memory leakage, Google prohibits holding references to Context or activity or view in the ViewModel.
This bothered me for a long time. Later, I found that there is an AndroidViewModel class, which internally maintains an ApplicationContext. It is really impossible to use one