当系统
MainActivity.java
public class MainActivity extends AppCompatActivity implements SavedStateRegistryOwner {
ActivityMainBinding binding;
MyViewModel myViewModel;
final static String KEY_NUMBER = "my_number";
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
binding = DataBindingUtil.setContentView(this, R.layout.activity_main);
SavedStateViewModelFactory savedStateViewModelFactory = new SavedStateViewModelFactory(getApplication(), this);
myViewModel = savedStateViewModelFactory.create(MyViewModel.class);
binding.setData(myViewModel);
binding.setLifecycleOwner(this);
}
}
MyModelView
public class MyViewModel extends ViewModel {
private SavedStateHandle state;
public MyViewModel(SavedStateHandle savedStateHandle){
state = savedStateHandle;
}
public MutableLiveData getNumber() {
if(!state.contains(MainActivity.KEY_NUMBER)){
state.set(MainActivity.KEY_NUMBER,0);
}
return state.getLiveData(MainActivity.KEY_NUMBER);
}
public void add(){
getNumber().setValue(getNumber().getValue()+1);
}
}
布局文件
构建文件
plugins {
id 'com.android.application'
}
android {
compileSdk 32
defaultConfig {
applicationId "com.tjjingpan.study.viewmodelresotre1"
minSdk 23
targetSdk 32
versionCode 1
versionName "1.0"
testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
dataBinding.enabled = true
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}
}
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
}
dependencies {
implementation 'androidx.appcompat:appcompat:1.2.0'
implementation 'com.google.android.material:material:1.3.0'
implementation 'androidx.constraintlayout:constraintlayout:2.0.4'
implementation 'androidx.lifecycle:lifecycle-viewmodel-savedstate:2.3.1'
testImplementation 'junit:junit:4.+'
androidTestImplementation 'androidx.test.ext:junit:1.1.2'
androidTestImplementation 'androidx.test.espresso:espresso-core:3.3.0'
}
以下文档来自developer.android.com
bookmark_border
本指南介绍了用户对界面状态的预期,以及可用于保持状态的选项。
在系统销毁 activity 或应用后,快速保存和恢复 activity 的界面状态对打造良好的用户体验至关重要。用户希望界面状态保持不变,但系统可能会销毁 activity 及其存储状态。
如需使系统行为符合用户预期,您可组合使用以下方法:
最佳解决方案取决于界面数据的复杂程度、应用的使用场景,以及数据访问速度与内存用量之间的平衡。
确保您的应用符合用户的预期,并提供快速的自适应界面。避免在将数据加载到界面时出现延迟,尤其是在发生常见配置更改(比如旋转)之后。
ViewModel | Saved instance state | Persistent storage | |
存储位置 | 在内存中 | 在内存中 | 在磁盘或网络上 |
在配置更改后继续存在 | 是 | 是 | 是 |
在系统发起的进程终止后继续存在 | 否 | 是 | 是 |
在用户完全关闭 activity 或触发 onFinish() 后继续存在 | 否 | 否 | 是 |
数据限制 | 支持复杂对象,但是空间受可用内存的限制 | 仅适用于基元类型和简单的小对象,例如字符串 | 仅受限于磁盘空间或从网络资源检索的成本/时间 |
读取/写入时间 | 快(仅限内存访问) | 慢(需要序列化/反序列化) | 慢(需要磁盘访问或网络事务) |
只要您的应用安装在用户的设备上,持久性本地存储(例如数据库或共享偏好设置)就会继续存在(除非用户清除应用的数据)。虽然此类本地存储空间会在系统启动的活动和应用进程终止后继续存在,但由于必须从本地存储空间读取到内存,因此检索成本高昂。这种持久性本地存储空间通常已经是应用架构的一部分,用于存储您打开和关闭 activity 时不想丢失的所有数据。
ViewModel 和已保存实例状态均不是长期存储解决方案,因此不能替代本地存储空间,例如数据库。您只应该使用这些机制来暂时存储瞬时界面状态,对于其他应用数据,应使用永久性存储空间。请参阅应用架构指南,详细了解如何充分利用本地存储空间长期保留您的应用模型数据(例如在重启设备后)。
您可以通过在各种类型的保留机制之间划分工作,高效地保存和恢复界面状态。在大多数情况下,这些机制中的每一种都应存储 activity 中使用的不同类型的数据,具体取决于数据复杂度、访问速度和生命周期的权衡:
例如,假设有一个用于搜索歌曲库的 activity。应按如下方式处理不同的事件:
当用户添加歌曲时,ViewModel 会立即委托在本地保留此数据。如果新添加的这首歌曲应显示在界面中,则您还应更新 ViewModel
对象中的数据以表明该歌曲已添加。切记要在主线程以外执行所有数据库插入操作。
当用户搜索歌曲时,从数据库加载的任何复杂歌曲数据都应作为屏幕界面状态的一部分立即存储在 ViewModel
对象中。
当 activity 进入后台且系统调用保存的实例状态 API 时,应将搜索查询存储在保存的实例状态中,以备进程重新创建时使用。由于加载在此过程中保留下来的应用数据需要用到搜索查询,因此应将其存储在 ViewModel SavedStateHandle
中。这些就是加载数据并让界面恢复到当前状态所需的所有信息。
当到了用户该返回 activity 的时候,重新创建 activity 存在两种可能情况:
SavedStateHandle
,则界面应将查询传递给 ViewModel
。ViewModel
看到没有缓存任何搜索结果时,会委托使用指定的搜索查询加载搜索结果。ViewModel
实例尚未销毁,因此 ViewModel
会将所有信息缓存在内存中,而无需重新查询数据库。注意:最初创建 activity 时,保存的实例状态捆绑包中不含任何数据,ViewModel
对象也是空白的。创建 ViewModel
对象时,您将传递空白查询,以此告知 ViewModel
对象还没有要加载的数据。因此,activity 启动时为空白状态。