Jetpack Activity Results API 详解与源码分析

如果需要自定义行为，可以继承 ActivityResultContract<I, O> 并重写关键方法。例如，自定义一个铃声选择器：

class PickRingtone : ActivityResultContract<Int, Uri?>() {
    override fun createIntent(context: Context, ringtoneType: Int) =
        Intent(RingtoneManager.ACTION_RINGTONE_PICKER).apply {
            putExtra(RingtoneManager.EXTRA_RINGTONE_TYPE, ringtoneType)
        }

    override fun parseResult(resultCode: Int, result: Intent?): Uri? {
        if (resultCode != Activity.RESULT_OK) {
            return null
        }
        return result?.getParcelableExtra(RingtoneManager.EXTRA_RINGTONE_PICKED_URI)
    }
}

3. ActivityResultCallback → 结果回调

第二个入参，见名知意：启动 Activity 并返回当前 Activity 时的结果回调。Activity Result API 体现了模版方法模式的封装思想，开发者按需注入协定类型和结果回调即可，无需关注底层细节。

原理深度解析

在 Activity、Fragment 中可以直接使用 registerForActivityResult()，是因为 ComponentActivity 和 Fragment 都实现了 ActivityResultCaller 接口。

1. Activity 内部机制

跟下 ComponentActivity#registerForActivityResult() 可以发现，第一个参数构造了一个 key，规则为 activity_rq# + 一个自增的 AtomicInteger 值。这就是为什么不需要另外定义 REQUEST_CODE 就能进行区分的原因。

继续跟 ActivityResultRegistry#register()，其核心逻辑是添加了一个观察者，当生命周期组件状态切换到 ON_START 时执行回调。随后返回一个 ActivityResultLauncher 实例。

基本的调用链条如下：

1. ComponentActivity 内部初始化了一个 ActivityResultRegistry 实例，并重写了 onLaunch()；
2. 开发者调用 registerForActivityResult() 最终调用 ActivityResultRegistry.register()，在此添加了一个观察者，当生命周期状态切换到 ON_START 时，执行协定 Contract.parseResult() 生成输出内容，并把结果作为参数传入回调 callback.onActivityResult() 中；
3. 注意！②是要生命周期发生改变才会触发的，开发者要调用 ActivityResultLauncher.launch() 才会发起跳转，其中回调了 onLaunch() 方法，在此调用了协定 Contract.createIntent() 返回一个和 startActivityForResult() 搭配使用的 Intent 实例；
4. 跳转目标 Activity 后返回此页面，生命周期发生改变，然后回调②中的相关代码。

2. Fragment 内部机制

Fragment 的实现思路也很简单，想办法拿到宿主 Activity 中的 ActivityResultRegistry 实例，调它的 register() 拿到返回的 ActivityResultLauncher 实例引用。最后返回新的 ActivityResultLauncher 实例，在 launch() 中调用前面那个 Activity 的 ActivityResultLauncher 实例引用的 launch() 方法。这实际上是一种委托代理模式。

这里有一个小细节，生命周期组件传入的是 Fragment.this，所以不用担心 Fragment 销毁没解绑导致的内存泄露问题。

3. 非 Activity/Fragment 接收 Activity 结果

如果需要在非 Activity/Fragment 的类中处理 Activity 结果，可以实现一个 LifecycleObserver 用于处理协定的注册和启动器的启动。通过绑定到特定的 LifecycleOwner，确保回调在正确的生命周期节点触发。

4. 配置改变引起 Activity 重建的处理

在 ActivityResultRegistry 中还发现了针对配置更改导致重建的场景处理。系统保存了 key(requestCode) 相关的数据、处理结果、Random 随机数实例。requestCode 和 Result 得以保留，Activity 重建后，再把它们分发给新注册的 Callback，避免了数据的丢失。这对于处理屏幕旋转等场景至关重要。

5. 测试 Activity 结果调用

默认情况下，registerForActivityResult() 会自动使用 Activity 提供的 ActivityResultRegistry，而它还提供了一个重载，支持传入自己的 ActivityResultRegistry 实例。这主要用于拦截结果调用进行测试，不会另外启动另一个 Activity。在单元测试中，可以通过注入 Mock 的 Registry 来验证业务逻辑是否正确响应了回调。

常见封装策略

虽然 Activity Results API 已经简单易用，但对于喜欢精简代码的开发者来说，还可以利用 Kotlin 相关的语法特性进一步封装。

扩展方法封装

最简单的封装就是写几个扩展方法，从 ActivityResultLauncher 生成和 launch() 调用处入手：

// 扩展
fun ComponentActivity.registerActResult(callback: ActivityResultCallback<ActivityResult>) =
    registerForActivityResult(ActivityResultContracts.StartActivityForResult()) {
        callback.onActivityResult(it) }

fun Fragment.registerActResult(callback: ActivityResultCallback<ActivityResult>) =
    registerForActivityResult(ActivityResultContracts.StartActivityForResult()) {
        callback.onActivityResult(it) }

fun Intent.launch(launcher: ActivityResultLauncher<Intent>) {
    launcher.launch(this)
}

// 注册处
private val mLauncher = registerActResult { 
    // 处理结果
}

// 调用处
Intent(this, SecondActivity::class.java).launch(mLauncher) 

基于 Caller 的优化

还可以优化成基于 ActivityResultCaller 进行扩展，然后把常用的一些跳转，如权限、打开相机、录像等写成一个个扩展函数，用的时候直接调用即可。如果想代码写得更少更优雅，可以结合生命周期回调，各种简化调用的扩展，甚至弄成 DSL 调用等。

最佳实践与注意事项

1. 注册时机

registerForActivityResult() 必须在 ON_START 之前注册，通常在 onCreate() 时初始化。如果在 OnCreate() 之后才初始化可能会报错，因为此时生命周期状态可能已经越过临界点。

2. 内存泄漏防护

由于启动器持有对 Contract 和 Callback 的引用，务必确保 Callback 不会持有 Activity 或 Fragment 的强引用。建议使用弱引用或者在 onDestroy 时取消注册（虽然框架通常会自动处理）。

3. 线程安全

ActivityResultRegistry 内部使用了锁机制来保证线程安全，但在主线程外调用 launch() 可能会导致 UI 更新异常，建议在主线程中发起跳转。

4. 错误处理

在 parseResult 中应妥善处理 RESULT_CANCELED 或其他非 OK 状态，避免空指针异常。对于文件选择等操作，需检查 Uri 是否有效。

小结

借着重构 BaseFragment 的机缘巧合，深入了解了 Activity Results API 的用法，阅读源码了解到背后的实现原理，并尝试进行了封装。心里有底了，赶紧在重构项目的时候安排上！！！

该 API 不仅简化了代码结构，还增强了类型安全性，解决了 Fragment 生命周期管理的诸多痛点。理解其底层原理有助于在复杂场景下更好地调试和优化应用性能。