Android ViewModel的使用總結
ViewModel 相關問題是高頻面試題。主要源于它是 MVVM 架構模式的重要組件，并且它可以在因配置更改導致頁面銷毀重建時依然保留 ViewModel 實例。
看看 ViewModel 的生命周期
ViewModel 只有在正常 Activity finish 時才會被清除。
問題來了：
為什么Activity旋轉屏幕后ViewModel可以恢復數據 ViewModel 的實例緩存到哪兒了 什么時候 ViewModel#onCleared() 會被調用在解決這三個問題之前，回顧下 ViewModel 的用法特性
基本使用MainRepositoryclass MainRepository { suspend fun getNameList(): List<String> {return withContext(Dispatchers.IO) { listOf('張三', '李四')} }}MainViewModel
class MainViewModel: ViewModel() { private val nameList = MutableLiveData<List<String>>() val nameListResult: LiveData<List<String>> = nameList private val mainRepository = MainRepository()fun getNames() {viewModelScope.launch { nameList.value = mainRepository.getNameList()} }}MainActivity
class MainActivity : AppCompatActivity() { // 創建 ViewModel 方式 1 // 通過 kotlin 委托特性創建 ViewModel // 需添加依賴 implementation ’androidx.activity:activity-ktx:1.2.3’ // viewModels() 內部也是通過 創建 ViewModel 方式 2 來創建的 ViewModel private val mainViewModel: MainViewModel by viewModels() override fun onCreate(savedInstanceState: Bundle?) {super.onCreate (savedInstanceState)setContentView(R.layout.activity_main)// 創建 ViewModel 方式 2val mainViewModel = ViewModelProvider(this).get(MainViewModel::class.java)mainViewModel.nameListResult.observe(this, { Log.i('MainActivity', 'mainViewModel: nameListResult: $it') Log.i('MainActivity', 'MainActivity: ${this@MainActivity} mainViewModel: $mainViewModel mainViewModel.nameListResult: ${mainViewModel.nameListResult}')})mainViewModel.getNames() }}
測試步驟：打開app -> 正常看到日志
18:03:02.575 : mainViewModel: nameListResult: [張三, 李四]18:03:02.575 : com.yqy.myapplication.MainActivity@7ffa77 mainViewModel: com.yqy.myapplication.MainViewModel@29c0057 mainViewModel.nameListResult: androidx.lifecycle.MutableLiveData@ed0d744
接著測試步驟：打開設置更換系統語言 -> 切換到當前app所在的任務 再看日志
18:03:59.622 : mainViewModel: nameListResult: [張三, 李四]18:03:59.622 : com.yqy.myapplication.MainActivity@49a4455 mainViewModel: com.yqy.myapplication.MainViewModel@29c0057 mainViewModel.nameListResult: androidx.lifecycle.MutableLiveData@ed0d744
神奇！MainActivity 被重建了，而 ViewModel 的實例沒有變，并且 ViewModel 對象里的 LiveData 對象實例也沒變。 這就是 ViewModel 的特性。
ViewModel 出現之前，Activity 可以使用 onSaveInstanceState() 方法保存，然后從 onCreate() 中的 Bundle 恢復數據，但此方法僅適合可以序列化再反序列化的少量數據（IPC 對 Bundle 有 1M 的限制），而不適合數量可能較大的數據，如用戶信息列表或位圖。 ViewModel 的出現完美解決這個問題。
我們先看看 ViewModel 怎么創建的： 通過上面的實例代碼，最終 ViewModel 的創建方法是
val mainViewModel = ViewModelProvider(this).get(MainViewModel::class.java)
神奇！MainActivity 被重建了，而 ViewModel 的實例沒有變，并且 ViewModel 對象里的 LiveData 對象實例也沒變。 這就是 ViewModel 的特性。
ViewModel 出現之前，Activity 可以使用 onSaveInstanceState() 方法保存，然后從 onCreate() 中的 Bundle 恢復數據，但此方法僅適合可以序列化再反序列化的少量數據（IPC 對 Bundle 有 1M 的限制），而不適合數量可能較大的數據，如用戶信息列表或位圖。 ViewModel 的出現完美解決這個問題。
我們先看看 ViewModel 怎么創建的： 通過上面的實例代碼，最終 ViewModel 的創建方法是
val mainViewModel = ViewModelProvider(this).get(MainViewModel::class.java)
創建 ViewModelProvider 對象并傳入了 this 參數，然后通過 ViewModelProvider#get 方法，傳入 MainViewModel 的 class 類型，然后拿到了 mainViewModel 實例。
ViewModelProvider 的構造方法
public ViewModelProvider(@NonNull ViewModelStoreOwner owner) { // 獲取 owner 對象的 ViewModelStore 對象this(owner.getViewModelStore(), owner instanceof HasDefaultViewModelProviderFactory? ((HasDefaultViewModelProviderFactory) owner).getDefaultViewModelProviderFactory(): NewInstanceFactory.getInstance()); }
ViewModelProvider 構造方法的參數類型是 ViewModelStoreOwner ？ViewModelStoreOwner 是什么？我們明明傳入的 MainActivity 對象呀！ 看看 MainActivity 的父類們發現
public class ComponentActivity extends androidx.core.app.ComponentActivity implements...// 實現了 ViewModelStoreOwner 接口ViewModelStoreOwner,...{ private ViewModelStore mViewModelStore;// 重寫了 ViewModelStoreOwner 接口的唯一的方法 getViewModelStore() @NonNull @Override public ViewModelStore getViewModelStore() {if (getApplication() == null) { throw new IllegalStateException('Your activity is not yet attached to the ' + 'Application instance. You can’t request ViewModel before onCreate call.');}ensureViewModelStore();return mViewModelStore; }
ComponentActivity 類實現了 ViewModelStoreOwner 接口。 奧 ~~ 剛剛的問題解決了。
再看看剛剛的 ViewModelProvider 構造方法里調用了 this(ViewModelStore, Factory)，將 ComponentActivity#getViewModelStore 返回的 ViewModelStore 實例傳了進去，并緩存到 ViewModelProvider 中
public ViewModelProvider(@NonNull ViewModelStore store, @NonNull Factory factory) {mFactory = factory;// 緩存 ViewModelStore 對象mViewModelStore = store; }
接著看 ViewModelProvider#get 方法做了什么
@MainThread public <T extends ViewModel> T get(@NonNull Class<T> modelClass) {String canonicalName = modelClass.getCanonicalName();if (canonicalName == null) { throw new IllegalArgumentException('Local and anonymous classes can not be ViewModels');}return get(DEFAULT_KEY + ':' + canonicalName, modelClass); }
獲取 ViewModel 的 CanonicalName , 調用了另一個 get 方法
@MainThread public <T extends ViewModel> T get(@NonNull String key, @NonNull Class<T> modelClass) { // 從 mViewModelStore 緩存中嘗試獲取ViewModel viewModel = mViewModelStore.get(key);// 命中緩存if (modelClass.isInstance(viewModel)) { if (mFactory instanceof OnRequeryFactory) {((OnRequeryFactory) mFactory).onRequery(viewModel); } // 返回緩存的 ViewModel 對象 return (T) viewModel;} else { //noinspection StatementWithEmptyBody if (viewModel != null) {// TODO: log a warning. }}// 使用工廠模式創建 ViewModel 實例if (mFactory instanceof KeyedFactory) { viewModel = ((KeyedFactory) mFactory).create(key, modelClass);} else { viewModel = mFactory.create(modelClass);}// 將創建的 ViewModel 實例放進 mViewModelStore 緩存中mViewModelStore.put(key, viewModel);// 返回新創建的 ViewModel 實例return (T) viewModel; }
mViewModelStore 是啥？通過 ViewModelProvider 的構造方法知道 mViewModelStore 其實是我們 Activity 里的 mViewModelStore 對象，它在 ComponentActivity 中被聲明。 看到了 put 方法，不難猜它內部用了 Map 結構。
public class ViewModelStore {// 果不其然，內部有一個 HashMap private final HashMap<String, ViewModel> mMap = new HashMap<>(); final void put(String key, ViewModel viewModel) {ViewModel oldViewModel = mMap.put(key, viewModel);if (oldViewModel != null) { oldViewModel.onCleared();} }// 通過 key 獲取 ViewModel 對象 final ViewModel get(String key) {return mMap.get(key); } Set<String> keys() {return new HashSet<>(mMap.keySet()); } /** * Clears internal storage and notifies ViewModels that they are no longer used. */ public final void clear() {for (ViewModel vm : mMap.values()) { vm.clear();}mMap.clear(); }}
到這兒正常情況下 ViewModel 的創建流程看完了，似乎沒有解決任何問題~ 簡單總結：ViewModel 對象存在了 ComponentActivity 的 mViewModelStore 對象中。 第二個問題解決了：ViewModel 的實例緩存到哪兒了
轉換思路 mViewModelStore 出現頻率這么高，何不看看它是什么時候被創建的呢？
記不記得剛才看 ViewModelProvider 的構造方法時 ，獲取 ViewModelStore 對象時，實際調用了 MainActivity#getViewModelStore() ，而 getViewModelStore() 實現在 MainActivity 的父類 ComponentActivity 中。
// ComponentActivity#getViewModelStore() @Override public ViewModelStore getViewModelStore() {if (getApplication() == null) { throw new IllegalStateException('Your activity is not yet attached to the ' + 'Application instance. You can’t request ViewModel before onCreate call.');}ensureViewModelStore();return mViewModelStore; }
在返回 mViewModelStore 對象之前調用了 ensureViewModelStore()
void ensureViewModelStore() {if (mViewModelStore == null) { NonConfigurationInstances nc = (NonConfigurationInstances) getLastNonConfigurationInstance(); if (nc != null) {// Restore the ViewModelStore from NonConfigurationInstancesmViewModelStore = nc.viewModelStore; } if (mViewModelStore == null) {mViewModelStore = new ViewModelStore(); }} }
當 mViewModelStore == null 調用了 getLastNonConfigurationInstance() 獲取 NonConfigurationInstances 對象 nc，當 nc != null 時將 mViewModelStore 賦值為 nc.viewModelStore，最終 viewModelStore == null 時，才會創建 ViewModelStore 實例。
不難發現，之前創建的 viewModelStore 對象被緩存在 NonConfigurationInstances 中
// 它是 ComponentActivity 的靜態內部類 static final class NonConfigurationInstances {Object custom;// 果然在這兒ViewModelStore viewModelStore; }
當 mViewModelStore == null 調用了 getLastNonConfigurationInstance() 獲取 NonConfigurationInstances 對象 nc，當 nc != null 時將 mViewModelStore 賦值為 nc.viewModelStore，最終 viewModelStore == null 時，才會創建 ViewModelStore 實例。
不難發現，之前創建的 viewModelStore 對象被緩存在 NonConfigurationInstances 中
// 它是 ComponentActivity 的靜態內部類 static final class NonConfigurationInstances {Object custom;// 果然在這兒ViewModelStore viewModelStore; }
NonConfigurationInstances 對象通過 getLastNonConfigurationInstance() 來獲取的
// Activity#getLastNonConfigurationInstance /** * Retrieve the non-configuration instance data that was previously * returned by {@link #onRetainNonConfigurationInstance()}. This will * be available from the initial {@link #onCreate} and * {@link #onStart} calls to the new instance, allowing you to extract * any useful dynamic state from the previous instance. * * <p>Note that the data you retrieve here should <em>only</em> be used * as an optimization for handling configuration changes. You should always * be able to handle getting a null pointer back, and an activity must * still be able to restore itself to its previous state (through the * normal {@link #onSaveInstanceState(Bundle)} mechanism) even if this * function returns null. * * <p><strong>Note:</strong> For most cases you should use the {@link Fragment} API * {@link Fragment#setRetainInstance(boolean)} instead; this is also * available on older platforms through the Android support libraries. * * @return the object previously returned by {@link #onRetainNonConfigurationInstance()} */ @Nullable public Object getLastNonConfigurationInstance() {return mLastNonConfigurationInstances != null? mLastNonConfigurationInstances.activity : null; }
好長一段注釋，大概意思有幾點：
onRetainNonConfigurationInstance 方法和 getLastNonConfigurationInstance 是成對出現的，跟 onSaveInstanceState 機制類似，只不過它是僅用作處理配置更改的優化。 返回的是 onRetainNonConfigurationInstance 返回的對象onRetainNonConfigurationInstance 和 getLastNonConfigurationInstance 的調用時機在本篇文章不做贅述，后續文章會進行解釋。
看看 onRetainNonConfigurationInstance 方法
/*** 保留所有適當的非配置狀態*/ @Override @Nullable @SuppressWarnings('deprecation') public final Object onRetainNonConfigurationInstance() {// Maintain backward compatibility.Object custom = onRetainCustomNonConfigurationInstance();ViewModelStore viewModelStore = mViewModelStore;// 若 viewModelStore 為空，則嘗試從 getLastNonConfigurationInstance() 中獲取if (viewModelStore == null) { // No one called getViewModelStore(), so see if there was an existing // ViewModelStore from our last NonConfigurationInstance NonConfigurationInstances nc = (NonConfigurationInstances) getLastNonConfigurationInstance(); if (nc != null) {viewModelStore = nc.viewModelStore; }}// 依然為空，說明沒有需要緩存的，則返回 nullif (viewModelStore == null && custom == null) { return null;}// 創建 NonConfigurationInstances 對象，并賦值 viewModelStoreNonConfigurationInstances nci = new NonConfigurationInstances();nci.custom = custom;nci.viewModelStore = viewModelStore;return nci; }
到這兒我們大概明白了，Activity 在因配置更改而銷毀重建過程中會先調用 onRetainNonConfigurationInstance 保存 viewModelStore 實例。 在重建后可以通過 getLastNonConfigurationInstance 方法獲取之前的 viewModelStore 實例。
現在解決了第一個問題：為什么Activity旋轉屏幕后ViewModel可以恢復數據
再看第三個問題：什么時候 ViewModel#onCleared() 會被調用
public abstract class ViewModel { protected void onCleared() { } @MainThread final void clear() {mCleared = true;// Since clear() is final, this method is still called on mock objects// and in those cases, mBagOfTags is null. It’ll always be empty though// because setTagIfAbsent and getTag are not final so we can skip// clearing itif (mBagOfTags != null) { synchronized (mBagOfTags) {for (Object value : mBagOfTags.values()) { // see comment for the similar call in setTagIfAbsent closeWithRuntimeException(value);} }}onCleared(); }}
onCleared() 方法被 clear() 調用了。 剛才看 ViewModelStore 源碼時好像是調用了 clear() ，回顧一下：
public class ViewModelStore { private final HashMap<String, ViewModel> mMap = new HashMap<>(); final void put(String key, ViewModel viewModel) {ViewModel oldViewModel = mMap.put(key, viewModel);if (oldViewModel != null) { oldViewModel.onCleared();} } final ViewModel get(String key) {return mMap.get(key); } Set<String> keys() {return new HashSet<>(mMap.keySet()); } /** * Clears internal storage and notifies ViewModels that they are no longer used. */ public final void clear() {for (ViewModel vm : mMap.values()) { vm.clear();}mMap.clear(); }}
onCleared() 方法被 clear() 調用了。 剛才看 ViewModelStore 源碼時好像是調用了 clear() ，回顧一下：
public class ViewModelStore { private final HashMap<String, ViewModel> mMap = new HashMap<>(); final void put(String key, ViewModel viewModel) {ViewModel oldViewModel = mMap.put(key, viewModel);if (oldViewModel != null) { oldViewModel.onCleared();} } final ViewModel get(String key) {return mMap.get(key); } Set<String> keys() {return new HashSet<>(mMap.keySet()); } /** * Clears internal storage and notifies ViewModels that they are no longer used. */ public final void clear() {for (ViewModel vm : mMap.values()) { vm.clear();}mMap.clear(); }}
在 ViewModelStore 的 clear() 中，遍歷 mMap 并調用 ViewModel 對象的 clear() ， 再看 ViewModelStore 的 clear() 什么時候被調用的：
// ComponentActivity 的構造方法 public ComponentActivity() {... getLifecycle().addObserver(new LifecycleEventObserver() { @Override public void onStateChanged(@NonNull LifecycleOwner source, @NonNull Lifecycle.Event event) {if (event == Lifecycle.Event.ON_DESTROY) { // Clear out the available context mContextAwareHelper.clearAvailableContext(); // And clear the ViewModelStore if (!isChangingConfigurations()) {getViewModelStore().clear(); }} }});... }
觀察當前 activity 生命周期，當 Lifecycle.Event == Lifecycle.Event.ON_DESTROY，并且 isChangingConfigurations() 返回 false 時才會調用 ViewModelStore#clear 。
// Activity#isChangingConfigurations() /** * Check to see whether this activity is in the process of being destroyed in order to be * recreated with a new configuration. This is often used in * {@link #onStop} to determine whether the state needs to be cleaned up or will be passed * on to the next instance of the activity via {@link #onRetainNonConfigurationInstance()}. * * @return If the activity is being torn down in order to be recreated with a new configuration, * returns true; else returns false. */ public boolean isChangingConfigurations() {return mChangingConfigurations; }
isChangingConfigurations 用來檢測當前的 Activity 是否因為 Configuration 的改變被銷毀了, 配置改變返回 true，非配置改變返回 false。
總結，在 activity 銷毀時，判斷如果是非配置改變導致的銷毀， getViewModelStore().clear() 才會被調用。
第三個問題：什么時候 ViewModel#onCleared() 會被調用 解決！
以上就是Android ViewModel的使用總結的詳細內容，更多關于Android ViewModel的使用的資料請關注好吧啦網其它相關文章！
相關文章：
網公網安備