Android ViewModel的使用總結
ViewModel 相關問題是高頻面試題。主要源于它是 MVVM 架構模式的重要組件，并且它可以在因配置更改導致頁面銷毀重建時依然保留 ViewModel 實例。
看看 ViewModel 的生命周期
ViewModel 只有在正常 Activity finish 時才會被清除。
問題來了：
- 為什么Activity旋轉屏幕后ViewModel可以恢復數據
- ViewModel 的實例緩存到哪兒了
- 什么時候 ViewModel#onCleared() 會被調用
在解決這三個問題之前，回顧下 ViewModel 的用法特性
基本使用
MainRepository
class 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() {
// 創(chuàng)建 ViewModel 方式 1
// 通過 kotlin 委托特性創(chuàng)建 ViewModel
// 需添加依賴 implementation 'androidx.activity:activity-ktx:1.2.3'
// viewModels() 內部也是通過 創(chuàng)建 ViewModel 方式 2 來創(chuàng)建的 ViewModel
private val mainViewModel: MainViewModel by viewModels()
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate (savedInstanceState)
setContentView(R.layout.activity_main)
// 創(chuàng)建 ViewModel 方式 2
val 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
接著測試步驟：打開設置更換系統(tǒng)語言 -> 切換到當前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 怎么創(chuàng)建的： 通過上面的實例代碼，最終 ViewModel 的創(chuàng)建方法是
val mainViewModel = ViewModelProvider(this).get(MainViewModel::class.java)
神奇！MainActivity 被重建了，而 ViewModel 的實例沒有變，并且 ViewModel 對象里的 LiveData 對象實例也沒變。 這就是 ViewModel 的特性。
ViewModel 出現之前，Activity 可以使用 onSaveInstanceState() 方法保存，然后從 onCreate() 中的 Bundle 恢復數據，但此方法僅適合可以序列化再反序列化的少量數據（IPC 對 Bundle 有 1M 的限制），而不適合數量可能較大的數據，如用戶信息列表或位圖。 ViewModel 的出現完美解決這個問題。
我們先看看 ViewModel 怎么創(chuàng)建的： 通過上面的實例代碼，最終 ViewModel 的創(chuàng)建方法是
val mainViewModel = ViewModelProvider(this).get(MainViewModel::class.java)
創(chuàng)建 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 的父類們發(fā)現
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.
}
}
// 使用工廠模式創(chuàng)建 ViewModel 實例
if (mFactory instanceof KeyedFactory) {
viewModel = ((KeyedFactory) mFactory).create(key, modelClass);
} else {
viewModel = mFactory.create(modelClass);
}
// 將創(chuàng)建的 ViewModel 實例放進 mViewModelStore 緩存中
mViewModelStore.put(key, viewModel);
// 返回新創(chuàng)建的 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 的創(chuàng)建流程看完了，似乎沒有解決任何問題~ 簡單總結：ViewModel 對象存在了 ComponentActivity 的 mViewModelStore 對象中。 第二個問題解決了：ViewModel 的實例緩存到哪兒了
轉換思路 mViewModelStore 出現頻率這么高，何不看看它是什么時候被創(chuàng)建的呢？
記不記得剛才看 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 NonConfigurationInstances
mViewModelStore = nc.viewModelStore;
}
if (mViewModelStore == null) {
mViewModelStore = new ViewModelStore();
}
}
}
當 mViewModelStore == null 調用了 getLastNonConfigurationInstance() 獲取 NonConfigurationInstances 對象 nc，當 nc != null 時將 mViewModelStore 賦值為 nc.viewModelStore，最終 viewModelStore == null 時，才會創(chuàng)建 ViewModelStore 實例。
不難發(fā)現，之前創(chuàng)建的 viewModelStore 對象被緩存在 NonConfigurationInstances 中
// 它是 ComponentActivity 的靜態(tài)內部類
static final class NonConfigurationInstances {
Object custom;
// 果然在這兒
ViewModelStore viewModelStore;
}
當 mViewModelStore == null 調用了 getLastNonConfigurationInstance() 獲取 NonConfigurationInstances 對象 nc，當 nc != null 時將 mViewModelStore 賦值為 nc.viewModelStore，最終 viewModelStore == null 時，才會創(chuàng)建 ViewModelStore 實例。
不難發(fā)現，之前創(chuàng)建的 viewModelStore 對象被緩存在 NonConfigurationInstances 中
// 它是 ComponentActivity 的靜態(tài)內部類
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 機制類似，只不過它是僅用作處理配置更改的優(yōu)化。
- 返回的是 onRetainNonConfigurationInstance 返回的對象
onRetainNonConfigurationInstance 和 getLastNonConfigurationInstance 的調用時機在本篇文章不做贅述，后續(xù)文章會進行解釋。
看看 onRetainNonConfigurationInstance 方法
/**
* 保留所有適當的非配置狀態(tài)
*/
@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;
}
}
// 依然為空，說明沒有需要緩存的，則返回 null
if (viewModelStore == null && custom == null) {
return null;
}
// 創(chuàng)建 NonConfigurationInstances 對象，并賦值 viewModelStore
NonConfigurationInstances 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 it
if (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的使用的資料請關注腳本之家其它相關文章！
相關文章
這篇文章主要為大家詳細介紹了Android View事件分發(fā)機制，具有一定的參考價值，感興趣的小伙伴們可以參考一下2016-11-11
Android中Android Virtual Device（AVD）使用教程
這篇文章主要介紹了Android中Android Virtual Device（AVD）使用教程,本文還對使用過程中發(fā)生的一些錯誤給出了處理方法,需要的朋友可以參考下2015-01-01
這篇文章主要介紹了Android屏幕旋轉之橫屏豎屏切換的實現，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧2019-10-10
本篇文章主要介紹了Android 國際貨幣格式化的示例代碼，小編覺得挺不錯的，現在分享給大家，也給大家做個參考。一起跟隨小編過來看看吧2017-11-11
ImageView 實現Android colorPikcer 選擇器的示例代碼
本篇文章主要介紹了ImageView 實現Android colorPikcer 選擇器的示例代碼，具有一定的參考價值，感興趣的小伙伴們可以參考一下。2017-10-10
這篇文章主要為大家詳細介紹了Android實現自定義滑動式抽屜效果菜單，文中示例代碼介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們可以參考一下2016-05-05
Android Studio 3.5格式化布局代碼時錯位、錯亂bug的解決
這篇文章主要介紹了Android Studio 3.5格式化布局代碼時錯位、錯亂bug的解決，具有很好的參考價值，希望對大家有所幫助。一起跟隨小編過來看看吧2020-03-03
這篇文章主要介紹了Android Intent傳遞數據底層分析詳細介紹的相關資料,需要的朋友可以參考下2017-02-02
Flutter如何輕松實現動態(tài)更新ListView淺析
在Android中通常都會用到listview.那么flutter里面怎么用呢?下面這篇文章主要給大家介紹了關于Flutter如何輕松實現動態(tài)更新ListView的相關資料,需要的朋友可以參考下2022-02-02
LinearLayout是線性布局控件：要么橫向排布，要么豎向排布，下面通過本篇文章給大家介紹Android布局之LinearLayout線性布局，涉及到android linearlayout 布局相關知識，對本文感興趣的朋友一起學習吧2015-12-12