ViewModel

像Activity，Fragment這類應用組件都有自己的生命周期並且是被Android的Framework所管理的。Framework可能會根據用戶的一些操作和設備的狀態對Activity或者Fragment進行銷毀和重構。作為開發者，這些行為我們是無法幹預的。

所以Activity或Fragment中的一些數據也會隨著銷毀而丟失，隨著重構而重新生成。比如你的Activity中有個用戶列表，當這個Activity重構的時候，新的Activity會重新獲取用戶列表。對於一些簡單的數據，Activity可以使用onSaveInstanceState()方法，並從onCreate的bundle中重新獲取。但這一方法途徑僅僅適合一些簡單的UI狀態，對於用戶列表這種龐大的數據並不適合。

還存在一個問題，Activity或者Fragment經常會做一些異步的耗時操作。隨之就需要Activity和Fragment管理這些異步操作，並在自己被destroyed的時候清理它們，從而保證內存溢出這類問題的發生。這樣的處理會隨著項目擴大而變得十分復雜，一不留神，你的App就Crash了。

Activity和Fragment本身需要處理很多用戶的輸入事件並和操作系統打交道，所以當它們還要花時間管理它們的數據資源時，class文件就會變得異常龐大，然後就會造就出所謂的god activities和god fragments。這些UI控制類僅僅靠一個class就能處理相關的所有事務。簡直跟上帝沒啥兩樣。但這些類如果要進行單元測試的話，那就尷尬了。

所以就有了MVC,MVP這類設計模式，將視圖與數據分離。今天講到的ViewModel類的功能也一樣，就是講數據從UI中分離出來。並且當Activity或Fragment重構的時候，ViewModel會自動保留之前的數據並給新的Activity或Fragment使用。對於上面提到的用戶列表的例子，ViewModel會為我們很好的管理這些數據。

public class MyViewModel extends ViewModel {
    private MutableLiveData<List<User>> users;
    public LiveData<List<User>> getUsers() {
        
 
if (users == null) {
            users = new MutableLiveData<List<Users>>();
            loadUsers();
        }
        return users;
    }

    private void loadUsers() {
        // do async operation to fetch users
    }
}

接著在我們的Activity中就能這樣使用了：

public class MyActivity extends AppCompatActivity {
    public void onCreate(Bundle savedInstanceState) {
        MyViewModel model = ViewModelProviders.of(this).get(MyViewModel.class);
        model.getUsers().observe(this, users -> {
            // update UI
        });
    }
}

這是當MyActivity被重構時，獲得到的model實例是與重構前同一個，當MyActivity被銷毀時，Framework會調用ViewModel的onCleared(),我們就可以在此方法中做資源的清理。

因為ViewModel的生命周期是和Activity或Fragment分開的，所以在ViewModel中絕對不能引用任何View對象或者任何引用了Activity的Context的對象。如果ViewModel中需要Application的Context的話，可以繼承AndroidViewModel。

Fragment之間的數據共享

在Activity中包好多個Fragment並且需要相互通信是非常常見的，這時就需要這些Fragment定義一些接口，然後讓Activity來進行協調。而且這些Fragment還需要處理其他Fragment不可見或者還沒有創建這些細節問題。

上面這個動點可以被ViewModel輕易解決，想象意向有這麽個Activity，它包含FragmentA和FragmentB，其中A是用戶列表，B是用戶的詳細數據，點擊列表上的某個用戶，在B中顯示相應的數據。

看看使用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 onActivityCreated() {
        model = ViewModelProviders.of(getActivity()).get(SharedViewModel.class);
        itemSelector.setOnClickListener(item -> {
            model.select(item);
        });
    }
}

public class DetailFragment extends LifecycleFragment {
    public void onActivityCreated() {
        SharedViewModel model = ViewModelProviders.of(getActivity()).get(SharedViewModel.class);
        model.getSelected().observe(this, { item ->
           // update UI
        });
    }
}

這裏要註意的是兩個Fragment都使用了getActivity作為參數來獲得ViewModel實例。這表示這兩個Fragment獲得的ViewModel對象是同一個。

使用了ViewModel的好處如下：

• Activity不需要做任何事情，不需要幹涉這兩個Fragment之間的通信。
• Fragment不需要互相知道，即使一個消失不可見，另一個也能很好的工作。
• Fragment有自己的生命周期，它們之間互不幹擾，即便你用一個FragmentC替代了B，FragmentA也能正常工作，沒有任何問題。

ViewModel的生命周期

ViewModel的生命周期跟著傳遞給ViewModelProvider的LifeCycle走，當生成了ViewModel的實例後，它會一直待在內存中，直到對應的LifeCycle徹底結束。下面是ViewModel與Activity對應的生命周期圖：

轉自https://www.cnblogs.com/zqlxtt/p/6888507.html

Android官方架構組件介紹之ViewModel（三）