RecyclerView屏幕旋转数据重复解决方法

1. 理解Android配置变更与生命周期

在Android系统中，当设备发生屏幕旋转、键盘可用性变化、语言切换等配置变更时，默认情况下，当前的Activity会被销毁并重新创建。这意味着Activity中的所有视图、数据以及其托管的Fragment都会随之被销毁，然后重新初始化。

对于包含RecyclerView的Fragment或Activity而言，如果不对这种重建行为进行妥善处理，就可能导致一些非预期的结果，例如数据重复加载、UI状态丢失，甚至出现像问题描述中“列表在列表之上”的UI重叠现象。

2. 问题根源：重复添加Fragment

在Android应用中，Fragment通常通过Activity的FragmentManager进行管理和添加。一个常见的错误模式是在Activity的onCreate()方法中无条件地添加Fragment：

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        // 错误示例：每次Activity重建都添加新的Fragment
        supportFragmentManager.beginTransaction()
            .add(R.id.fragment_container, MoviesFragment())
            .commit()
    }
}

当屏幕旋转时，MainActivity会被销毁并重建，onCreate()方法会再次执行。如果上述代码被执行，它将再次创建一个新的MoviesFragment实例，并将其添加到R.id.fragment_container中。然而，Android系统在Activity重建时会自动恢复之前添加的Fragment。因此，结果就是新的MoviesFragment被叠加在系统恢复的旧MoviesFragment之上，导致UI重叠和数据重复加载的假象。

3. 解决方案一：利用savedInstanceState避免重复添加Fragment

为了避免Fragment的重复添加，我们应该在onCreate()方法中检查savedInstanceState参数。savedInstanceState是一个Bundle对象，它在Activity首次创建时（即应用启动或Activity被首次实例化时）为null。而在Activity因配置变更（如屏幕旋转）而被重建时，savedInstanceState将包含之前保存的状态信息，因此它将不为null。

基于此，我们可以在onCreate()方法中添加一个条件判断，确保Fragment只在Activity首次创建时被添加：

import android.os.Bundle
import androidx.appcompat.app.AppCompatActivity

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        // 正确做法：只有在Activity首次创建时才添加Fragment
        if (savedInstanceState == null) {
            supportFragmentManager.beginTransaction()
                .replace(R.id.fragment_container, MoviesFragment()) // 建议使用replace而不是add，以防万一
                .commit()
        }
    }
}

通过这种方式，当屏幕旋转时，savedInstanceState不为null，if条件不满足，因此不会再次手动添加MoviesFragment。系统会自动处理Fragment的恢复，确保只有一个MoviesFragment实例存在于容器中。

4. 解决方案二：ViewModel实现数据持久化

即使Fragment不再重复添加，我们仍然需要确保RecyclerView中的数据在配置变更后能够保持不变，避免重新发起网络请求或数据加载操作。ViewModel是Android架构组件中专门用于解决此问题的类。ViewModel的生命周期比Activity或Fragment更长，它可以在配置变更（如屏幕旋转）期间存活下来。

分析提供的MoviesViewModel代码：

class MoviesViewModel(application: Application) : AndroidViewModel(application) {

    private val repository = MoviesRepository()
    val myResponse: MutableLiveData> = MutableLiveData()

    fun getPageOfMovies() {
        viewModelScope.launch {
            val response = repository.getPageOfMovies()
            myResponse.value = response
        }
    }
}

以及MoviesFragment中对ViewModel的使用：

class MoviesFragment : Fragment() {
    private var viewModel: MoviesViewModel? = null
    // ... 其他代码 ...

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        recyclerViewInit()
        viewModelInit()
    }

    private fun viewModelInit() {
        viewModel = ViewModelProvider(this)[MoviesViewModel::class.java]
        // 只有当数据为空时才发起请求，避免重复加载
        if (viewModel!!.myResponse.value == null) {
            viewModel!!.getPageOfMovies()
        }
        viewModel!!.myResponse.observe(viewLifecycleOwner) { response ->
            if (response.isSuccessful) {
                response.body()?.let { movies ->
                    adapter.setData(movies)
                }
            } else {
                Toast.makeText(requireContext(), response.code(), Toast.LENGTH_SHORT).show()
            }
        }
    }
}

这里有几个关键点：

• ViewModelProvider(this)[MoviesViewModel::class.java]: ViewModelProvider确保在Activity或Fragment重建时，获取到的是同一个MoviesViewModel实例。这意味着MoviesViewModel中的myResponse数据会保留。
• viewModelScope.launch: 用于在ViewModel的生命周期内启动协程，安全地执行异步操作。
• myResponse: MutableLiveData: LiveData是可观察的数据持有者，它感知生命周期。当myResponse的值更新时，所有活跃的观察者（如MoviesFragment中的observe调用）都会收到通知。
• myResponse.observe(viewLifecycleOwner): 使用viewLifecycleOwner作为生命周期所有者，确保当Fragment的视图被销毁时，观察者会自动停止观察，防止内存泄漏。
• 数据加载优化: 在viewModelInit中添加if (viewModel!!.myResponse.value == null)判断，可以避免在ViewModel已经有数据的情况下再次发起网络请求，进一步优化用户体验和资源消耗。

通过结合ViewModel，即使Activity/Fragment被重建，RecyclerView的数据源（myResponse）仍然存在于ViewModel中。Fragment重建后，它会重新连接到这个ViewModel，并观察myResponse的最新值，然后立即更新RecyclerView，从而实现数据的无缝恢复，避免重复加载和UI闪烁。

5. 代码审查与最佳实践

从提供的代码来看，MoviesViewModel和MoviesAdapter的实现是符合最佳实践的：

• MoviesViewModel职责单一，负责数据获取和暴露给UI。
• MoviesAdapter正确实现了RecyclerView.Adapter，并通过setData和notifyDataSetChanged更新数据。
• MoviesFragment使用了ViewModelProvider和LiveData的observe方法，并传入了viewLifecycleOwner，这些都是正确的。

因此，根据问题描述“数据加载后旧列表仍在背景中可见”，最根本的原因很可能是Activity中Fragment的添加逻辑没有正确处理配置变更，导致多个Fragment实例叠加。一旦解决了Activity中Fragment的重复添加问题，结合ViewModel的数据持久化能力，RecyclerView的显示将恢复正常。

6. 总结

解决Android RecyclerView在屏幕旋转时数据重复叠加问题的关键在于：

1. 在Activity的onCreate()方法中，始终检查savedInstanceState是否为null。 只有在savedInstanceState为null时才执行Fragment的添加（或替换）操作，以确保Fragment不会被重复创建和叠加。
2. 利用ViewModel管理UI相关的数据。 ViewModel的生命周期独立于Activity/Fragment的重建，可以确保数据在配置变更后依然持久化，避免不必要的网络请求或数据重新加载。

通过以上两点，可以有效地解决RecyclerView在配置变更时的数据重复和UI叠加问题，为用户提供流畅、稳定的应用体验。