在Adapter中如何正确使用ActivityResultLauncher？

Question

在使用 `ActivityResultLauncher` 时，部分开发者尝试在 RecyclerView 的 Adapter 中直接调用其 `launch()` 方法来启动目标 Activity，并期望获取返回结果。然而，由于 Adapter 并非 LifecycleOwner，直接持有或传递 `ActivityResultLauncher` 可能导致内存泄漏或生命周期不一致的问题。 此外，在 Adapter 中错误地初始化 `ActivityResultLauncher` 实例，例如在 ViewHolder 或绑定方法中重复创建，也可能引发异常或结果无法正确回调。 那么，如何在 Adapter 中安全地使用 `ActivityResultLauncher` 来启动 Activity 并接收结果？有哪些推荐的实践方式可以避免生命周期和内存相关的问题？

Answer 1

一、问题背景与核心挑战

在 Android 开发中，ActivityResultLauncher 是用于启动 Activity 并接收返回结果的推荐方式。随着 Activity Result API 的引入，传统的 startActivityForResult() 和 onActivityResult() 已被弃用。

然而，在实际开发中，部分开发者尝试在 RecyclerView.Adapter 中直接使用 ActivityResultLauncher 来启动目标 Activity，并期望获取结果回调。由于 Adapter 不具备生命周期感知能力（即不是 LifecycleOwner），这种做法可能导致以下问题：

• 内存泄漏：若在 Adapter 中持有 ActivityResultLauncher 实例，可能因生命周期管理不当导致内存泄漏。
• 生命周期不一致：ActivityResultLauncher 需依赖于正确的 LifecycleOwner（如 Fragment 或 Activity）进行注册和调用，否则可能无法正确接收结果。
• 重复初始化异常：在 ViewHolder 或绑定方法中反复创建 ActivityResultLauncher 实例，可能导致注册冲突或结果无法回调。

二、错误实践分析

以下是常见的错误代码示例：

class MyAdapter : RecyclerView.Adapter() {
    private lateinit var launcher: ActivityResultLauncher

    override fun onBindViewHolder(holder: MyViewHolder, position: Int) {
        // 错误地在 onBindViewHolder 中初始化
        launcher = registerForActivityResult(...) // ❌ 错误操作
        holder.itemView.setOnClickListener { launcher.launch(...) }
    }
}
    

上述代码的问题包括：

• 每次绑定 ViewHolder 时都重新注册 ActivityResultLauncher，导致多次注册，行为不可控。
• Adapter 本身并非 LifecycleOwner，无法安全地注册该 Launcher。
• 若 Adapter 被多个 Fragment/Activity 使用，难以统一处理结果回调逻辑。

三、推荐解决方案

为了解决上述问题，应将 ActivityResultLauncher 的注册和调用限制在具有生命周期控制能力的组件中，例如 Fragment 或 Activity。以下是几种推荐的实践方式：

1. 通过接口回调机制通知宿主组件启动 Activity

2. Adapter 通过定义接口将点击事件传递给 Fragment 或 Activity，由其负责调用 launch() 方法。

   
   interface OnItemClickListener {
       fun onItemClicked(data: SomeData)
   }
   
   class MyAdapter(private val listener: OnItemClickListener) : RecyclerView.Adapter() {
       override fun onBindViewHolder(holder: MyViewHolder, position: Int) {
           holder.itemView.setOnClickListener {
               listener.onItemClicked(dataList[position])
           }
       }
   }
               

   Fragment 中实现接口并处理 Launcher：

   
   class MyFragment : Fragment() {
       private lateinit var launcher: ActivityResultLauncher
   
       override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
           launcher = registerForActivityResult(...) { result ->
               // 处理返回结果
           }
   
           val adapter = MyAdapter { data ->
               val intent = Intent(context, TargetActivity::class.java)
               launcher.launch(intent)
           }
           recyclerView.adapter = adapter
       }
   }
               

3. 使用 ViewModel + LiveData 解耦 UI 层逻辑

4. 将点击事件封装到 ViewModel 中，由 ViewModel 触发一个事件，由宿主组件监听并执行 Launcher。

   
   class SharedViewModel : ViewModel() {
       private val _itemClickedEvent = MutableLiveData()
       val itemClickedEvent: LiveData = _itemClickedEvent
   
       fun onItemClicked(data: SomeData) {
           _itemClickedEvent.value = data
       }
   }
               

   Adapter 通过 ViewModel 发送事件：

   
   class MyAdapter(val viewModel: SharedViewModel) : RecyclerView.Adapter() {
       override fun onBindViewHolder(holder: MyViewHolder, position: Int) {
           holder.itemView.setOnClickListener {
               viewModel.onItemClicked(dataList[position])
           }
       }
   }
               

   Fragment 监听事件并启动 Activity：

   
   viewModel.itemClickedEvent.observe(viewLifecycleOwner) { data ->
       launcher.launch(Intent(requireContext(), TargetActivity::class.java))
   }
               

四、进阶建议与架构设计思考

为了更好地组织代码结构，提升可维护性，建议采用以下进阶策略：

策略	说明	优点	适用场景
单向数据流（UDF）	通过状态驱动 UI 更新，事件统一由顶层组件处理	减少副作用，提升测试性和可维护性	复杂交互界面，需统一状态管理
使用 Navigation Component	结合 Safe Args 传递参数，避免手动处理 Launcher	简化导航逻辑，增强类型安全	涉及 Fragment 间跳转的场景
自定义 ResultContract	定义特定输入输出类型的 Contract，提高复用性	使 Launcher 更具语义化和通用性	需要复用相同业务逻辑的多个位置

五、总结与后续演进方向

从生命周期管理的角度来看，ActivityResultLauncher 必须在具有生命周期控制能力的组件中注册和调用。Adapter 作为 UI 组件之一，不具备生命周期感知能力，因此不应承担该职责。

推荐的做法是通过回调接口、ViewModel、LiveData 等机制将事件上抛至 Fragment 或 Activity，再由它们统一处理 Launcher 的调用和结果接收。

此外，随着 Jetpack Compose 的普及，新的 rememberLauncherForActivityResult 提供了更简洁的函数式写法，值得在未来项目中尝试。

未来可以进一步探索如何将这些模式与 MVI 架构、Clean Architecture 深度融合，以构建更加健壮、易扩展的 Android 应用程序。