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對應的生命週期圖：