Android registerForActivityResult是否需主动注销？如何管理多请求码？

首先明确结论：完全不需要手动注销注册的回调，API本身内置了完整的生命周期感知能力，正常使用不存在宿主销毁后的安全风险。

• 底层实现机制：该API依托AndroidX的ActivityResultRegistry实现，回调的注册生命周期完全和宿主（Activity/Fragment）的Lifecycle绑定，注册时会自动生成全局唯一的请求标识，和回调逻辑做映射存储。
• 自动清理逻辑：当宿主进入ON_DESTROY状态时，Registry会自动遍历所有注册的回调条目，从内部映射表中移除所有关联的回调；即便在宿主销毁的临界状态有结果返回，因为映射关系已经被解绑，结果会被直接丢弃，不会执行业务逻辑，不存在崩溃或泄漏的问题。
• 状态恢复特性：哪怕宿主因为配置变更（屏幕旋转、系统语言切换）被重建，只要回调是在宿主初始化阶段（类成员变量位置、onCreate方法内、ViewLifecycleOwner初始化阶段）完成注册的，重建后会自动从保存的状态中恢复请求映射关系，不会丢失待返回的结果回调。
• 唯一的风险触发场景：如果在宿主的生命周期状态已经高于INITIALIZED（比如在onResume、普通按钮点击事件中直接调用registerForActivityResult），系统会直接抛出IllegalStateException，这类报错是不符合注册时机要求的错误用法，不存在运行时的隐性风险。

核心设计思路：抛弃旧版手动维护requestCode的分支逻辑，以“一个业务启动场景对应一个独立注册的回调实例”为最佳实践。
旧版onActivityResult靠手动传入的requestCode作为分支判断的依据，本质是因为旧API没有做回调和启动场景的解耦；而新API的设计逻辑是，每个通过registerForActivityResult生成的launcher，会被系统自动分配全局唯一的隐式请求码，不需要开发者手动维护，完全可以实现旧版多requestCode的能力，且代码可维护性更强。
举个适配示例：当你需要从同一个宿主，分别启动用户选择页、系统图片选择页两个不同目标，接收各自返回结果时，不需要在同一个回调里做分支判断，只需要分别注册两个独立的回调：

// 注册启动用户选择页的专属回调
val launcherSelectUser = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result ->
    if (result.resultCode == Activity.RESULT_OK) {
        // 仅处理用户选择页的返回逻辑，无需额外判断来源
        val selectedUser = result.data?.getParcelableExtra<User>("selected_user")
        // 执行对应业务更新
    }
}

// 注册启动图片选择页的专属回调
val launcherPickImage = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result ->
    if (result.resultCode == Activity.RESULT_OK) {
        // 仅处理图片选择页的返回逻辑
        val pickedUri = result.data?.data
        // 执行对应业务更新
    }
}

实际启动对应目标Activity时，直接调用对应的launcher即可，完全不需要手动传requestCode：

// 响应用户选择按钮点击
btnSelectUser.setOnClickListener {
    launcherSelectUser.launch(Intent(this, SelectUserActivity::class.java))
}

// 响应图片选择按钮点击
btnPickImage.setOnClickListener {
    launcherPickImage.launch(Intent(Intent.ACTION_PICK).apply { type = "image/*" })
}

这种方案相比旧版的优势：

• 彻底告别手动维护requestCode的繁琐逻辑，不会出现requestCode值冲突、和系统预留请求码撞车的问题
• 每个回调的业务职责单一，没有跨场景的分支判断冗余，后续维护新业务场景时，只需要新增独立的回调注册，不会影响已有逻辑
• 类型安全更高，不需要在回调里靠字符串标识做来源判断，降低分支漏写的概率

如果是动态变化的业务场景（比如列表页每个条目点击都需要启动对应详情页接收结果），可以通过ActivityResultRegistry的动态注册能力完成适配，但绝大多数常规业务场景下，类成员变量级的静态注册完全可以满足需求，无需额外的动态逻辑。

内容的提问来源于stack exchange，提问作者MohammadReza Berenji