理解配置变更与Fragment生命周期
在android系统中，当设备发生配置变更（如屏幕旋转、键盘可用性改变、语言设置切换等）时，默认情况下，当前的activity会被销毁并重新创建。这意味着activity实例及其所承载的fragment实例都会经历完整的生命周期销毁与重建过程。
当一个Activity被重新创建时，系统会自动恢复其之前添加的Fragment实例。问题的核心在于，如果我们在宿主Activity的onCreate方法中无条件地添加一个新的Fragment实例，那么在Activity因配置变更而重建时，系统在恢复旧Fragment的同时，我们又手动添加了一个新的Fragment。这样，旧Fragment和新Fragment会同时存在于同一个容器中，导致UI元素（例如RecyclerView）出现重复叠加的现象，即用户在滚动时会看到旧数据在背景中，新数据在前景中。
ViewModel在数据持久化中的作用
为了解决Activity/Fragment重建导致的数据丢失问题，Android架构组件引入了ViewModel。ViewModel的生命周期独立于Activity或Fragment的生命周期，它会一直存在，直到其关联的Activity或Fragment彻底销毁（例如用户退出应用或Activity被系统回收）。
在提供的代码示例中，MoviesViewModel很好地利用了ViewModel的特性：
class MoviesViewModel(application: Application) : AndroidViewModel(application) {
private val repository = MoviesRepository()
val myResponse: MutableLiveData<Response<MovieResponse>> = MutableLiveData()
fun getPageOfMovies() {
viewModelScope.launch {
val response = repository.getPageOfMovies()
myResponse.value = response
}
}
}MoviesViewModel通过viewModelScope.launch异步获取数据，并将结果保存在myResponse: MutableLiveData中。当MoviesFragment因屏幕旋转而重建时，它会通过ViewModelProvider获取到同一个MoviesViewModel实例。这意味着myResponse中已经包含的数据不会丢失，Fragment会重新观察到这个LiveData并获取到之前加载的数据。
因此，ViewModel已经很好地解决了数据在配置变更时的持久化问题。然而，数据重复叠加的问题并非来源于ViewModel的数据丢失，而是来源于Fragment实例的重复添加。
正确的Fragment管理策略
解决RecyclerView数据重复叠加的关键在于宿主Activity中对Fragment的正确管理。我们必须确保Fragment只在Activity首次创建时被添加，而在Activity因配置变更而重建时，则应依赖系统自动恢复Fragment。这可以通过检查savedInstanceState参数来判断Activity是否是首次创建：
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
// 只有当savedInstanceState为null时，才添加Fragment
// 这表示Activity是首次创建，而不是因配置变更而重建
if (savedInstanceState == null) {
supportFragmentManager.beginTransaction()
.replace(R.id.fragment_container, MoviesFragment()) // 使用replace或add并检查tag
.commit()
}
}
}在上述MainActivity的onCreate方法中：
- savedInstanceState是一个Bundle对象，如果Activity是首次创建（例如应用启动），它将是null。
- 如果Activity是因为配置变更（如屏幕旋转）而被销毁并重建，那么savedInstanceState将包含之前保存的状态信息，此时它将不为null。
通过这个判断，我们确保MoviesFragment只在MainActivity首次启动时被添加到R.id.fragment_container中。当MainActivity因旋转而重建时，由于savedInstanceState不为null，if条件不满足，就不会再次执行Fragment事务，系统会自动恢复之前存在的MoviesFragment实例，从而避免了Fragment的重复叠加。
RecyclerView Adapter与数据更新
MoviesAdapter的代码逻辑对于RecyclerView的数据显示是正确的：
class MoviesAdapter : RecyclerView.Adapter<MoviesAdapter.ViewHolder>() {
private var moviesList = MovieResponse(0, emptyList(), 0, 0)
// ... onCreateViewHolder, getItemCount, onBindViewHolder ...
@SuppressLint("NotifyDataSetChanged")
fun setData(movies: MovieResponse) {
moviesList = movies
notifyDataSetChanged()
}
// ...
}当MoviesViewModel获取到新的电影数据时，它会通过myResponse.observe回调，调用adapter.setData(movies)。setData方法更新了适配器内部的数据源moviesList，并调用notifyDataSetChanged()通知RecyclerView刷新视图。这一机制确保了RecyclerView能够正确显示最新数据。在Fragment管理正确的前提下，即使Fragment重建，由于它观察的是同一个ViewModel中的LiveData，当LiveData的数据不变时，setData可能不会被再次触发，或者如果数据有更新，也会正确刷新。
注意事项与最佳实践
- add() vs. replace()： 在Fragment事务中，replace()操作会移除容器中现有的所有Fragment，然后添加新的Fragment。而add()操作则是在现有Fragment之上添加新的Fragment。对于大多数单Fragment容器的场景，replace()更为常用且安全，因为它能避免Fragment叠加。如果必须使用add()，则需要配合findFragmentByTag()或findFragmentById()来检查Fragment是否已存在，以避免重复添加。
- UI状态的保存： 尽管ViewModel能很好地保存数据，但对于一些临时的UI状态（如RecyclerView的滚动位置、EditText的输入内容、Tab的选中状态等），可能需要结合onSaveInstanceState()和onRestoreInstanceState()方法来手动保存和恢复。然而，对于本例中的数据重复问题，主要原因在于Fragment的重复添加。
- 使用FragmentContainerView： 在Jetpack Compose时代，官方推荐使用FragmentContainerView作为Fragment的容器，它提供了更好的Fragment管理和动画支持。
- 测试配置变更： 在开发过程中，务必通过模拟器或真机进行屏幕旋转、多窗口模式切换等操作，以充分测试应用在各种配置变更下的行为，确保UI和数据的一致性。
总结
RecyclerView在屏幕旋转时出现数据重复叠加的问题，并非RecyclerView或ViewModel本身的缺陷，而是源于宿主Activity在处理Fragment生命周期时的常见误区。通过在Activity的onCreate方法中，利用savedInstanceState参数来判断Activity是否是首次创建，并据此决定是否添加Fragment，可以有效地避免Fragment的重复加载，从而确保RecyclerView在配置变更时能够正确显示数据，提供流畅的用户体验。结合ViewModel进行数据持久化，以及正确的Fragment管理策略，是构建健壮Android应用的关键。
