告别onActivityResult：Android数据回传的三大痛点与终极方案

调用registerForActivityResult后得到的ActivityResultLauncher<I>，是触发操作的"扳机"。调用launch(input: I)时，整个流程便启动了。

新旧对比：代码的涅槃重生

让我们用新API重构ProfileActivity，并为"编辑昵称"创建一个自定义契约。

1. 定义一个类型安全的契约 (EditNameContract)

// EditNameContract.kt
class EditNameContract : ActivityResultContract<String, String?>() {
    // 输入: 旧昵称(String), 输出: 新昵称(String?)
    override fun createIntent(context: Context, input: String): Intent {
        return Intent(context, EditNameActivity::class.java).apply {
            putExtra("initialName", input)
        }
    }

    override fun parseResult(resultCode: Int, intent: Intent?): String? {
        if (resultCode != Activity.RESULT_OK) return null
        return intent?.getStringExtra("newName")
    }
}

2. 在ProfileActivity中注册回调并使用

// ProfileActivity.kt (新写法)
class ProfileActivity : AppCompatActivity() {

    private lateinit var avatarView: ImageView
    private lateinit var nameView: TextView

    // 注册"编辑昵称"的回调
    private val editNameLauncher = registerForActivityResult(EditNameContract()) { newName ->
        // 结果处理逻辑高度内聚！newName是String?类型，由Contract保证
        newName?.let { nameView.text = it }
    }

    // 使用系统内置契约注册"选择图片"的回调
    private val cropImageLauncher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result ->
        if (result.resultCode == Activity.RESULT_OK) {
            val imageUri = result.data?.data
            avatarView.setImageURI(imageUri)
        }
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // ...
        nameView.setOnClickListener {
            val currentName = nameView.text.toString()
            editNameLauncher.launch(currentName)
        }

        avatarView.setOnClickListener {
            val intent = Intent(this, CropImageActivity::class.java)
            cropImageLauncher.launch(intent)
        }
    }
    // 不再需要重写 onActivityResult() 方法！
}

ActivityResultCallback的场景化实战

场景一：权限请求——简化异步流程

在registerForActivityResult出现之前，处理权限请求是一个相当繁琐的过程。你需要重写onRequestPermissionsResult，匹配requestCode，然后处理一个IntArray。现在，这一切被极大地简化了。

1. 请求单个权限

// 注册一个回调，用于处理单个权限的请求结果
val requestPermissionLauncher = registerForActivityResult(
    ActivityResultContracts.RequestPermission()
) { isGranted: Boolean ->
    // 场景：用户点击“上传头像”时，请求相机权限
    if (isGranted) {
        // 权限被授予，可以执行打开相机的操作
        openCamera()
    } else {
        // 权限被拒绝,需要向用户解释为什么需要此权限
        showPermissionDeniedDialog()
    }
}

// 在需要时启动权限请求
fun onAvatarClick() {
    requestPermissionLauncher.launch(Manifest.permission.CAMERA)
}

2. 请求多个权限

// 注册一个回调,用于处理多个权限的请求结果
val requestMultiplePermissionsLauncher = registerForActivityResult(
    ActivityResultContracts.RequestMultiplePermissions()
) { permissions: Map<String, Boolean> ->
    // 此Lambda就是一个ActivityResultCallback<Map<String, Boolean>>的实例
    // 场景：应用启动时,一次性请求定位和存储权限
    val allGranted = permissions.entries.all { it.value }
    if (allGranted) {
        // 所有权限都被授予
        initializeMapAndStorage()
    } else if (permissions[Manifest.permission.ACCESS_FINE_LOCATION] == true) {
        // 仅定位权限被授予
        showMapButDisableSaving()
    } else {
        // 存在被拒绝的权限
        showGeneralPermissionWarning()
    }
}

// 在需要时启动
fun onAppStart() {
    requestMultiplePermissionsLauncher.launch(
        arrayOf(
            Manifest.permission.ACCESS_FINE_LOCATION,
            Manifest.permission.WRITE_EXTERNAL_STORAGE
        )
    )
}

核心价值：将复杂的权限请求/响应流程封装成一个简单的“发起->布尔/Map回调”模型,代码意图清晰,极易处理。

场景二：与ViewModel结合——实现UI与逻辑的彻底解耦

这是一种更高级、更符合现代MVVM架构的用法。UI层（Activity/Fragment）只负责注册回调和启动操作,而真正的结果处理逻辑则位于ViewModel中。

1. ViewModel中定义回调逻辑

// MyViewModel.kt
class MyViewModel : ViewModel() {
    private val _userName = MutableLiveData<String>()
    val userName: LiveData<String> = _userName

    /**
     * 这里是关键：创建一个ActivityResultCallback实例,
     * 它的逻辑是更新ViewModel内部的数据状态。
     * 它不依赖任何UI组件！
     */
    val editNameCallback = ActivityResultCallback<String?> { newName ->
        // 场景：从编辑页返回新的用户名,更新LiveData,UI会自动响应变化
        newName?.takeIf { it.isNotBlank() }?.let {
            _userName.value = it
        }
    }
}

2. Fragment中连接UI与ViewModel

// ProfileFragment.kt
class ProfileFragment : Fragment() {
    private val viewModel: MyViewModel by viewModels()

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

        // 使用ViewModel中的回调实例来注册Launcher
        val editNameLauncher = registerForActivityResult(
            EditNameContract(),
            viewModel.editNameCallback // 直接传递ViewModel中的回调实例
        )

        // UI观察ViewModel中的数据
        viewModel.userName.observe(viewLifecycleOwner) { name ->
            binding.nameTextView.text = name
        }

        // UI触发事件
        binding.editNameButton.setOnClickListener {
            editNameLauncher.launch(viewModel.userName.value)
        }
    }
}

核心价值：

• 职责分离：Fragment只做UI相关的事,ViewModel负责处理业务逻辑和状态管理
• 可测试性极高：ViewModel中的editNameCallback是一个独立的逻辑单元,可以非常轻松地进行单元测试,无需创建任何UI组件。你可以直接调用viewModel.editNameCallback.onActivityResult("New Name")来测试它的行为

场景三：拦截返回键事件——OnBackPressedDispatcher的回调革命

Android官方通过OnBackPressedDispatcher进一步推广回调模式,替代传统的onBackPressed()重写方式。例如,在Fragment中处理返回键事件:

// MyFragment.kt
class MyFragment : Fragment() {
    private val backButtonCallback = OnBackPressedCallback(true) {
        // 自定义返回键逻辑
        if (shouldInterceptBackPress) {
            showConfirmationDialog()
        } else {
            isEnabled = false
            activity?.onBackPressed()
        }
    }

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        requireActivity().onBackPressedDispatcher.addCallback(viewLifecycleOwner, backButtonCallback)
    }
}

设计亮点:

• 生命周期感知：回调自动绑定Fragment的生命周期,避免内存泄漏
• 链式责任模式：多个回调按添加顺序逆序执行,支持复杂的返回逻辑组合

场景四：LiveData的数据驱动——观察者模式的完美实践

LiveData通过观察者模式实现数据与UI的自动同步,本质上是回调机制的高级封装:

// ViewModel.kt
class UserViewModel : ViewModel() {
    private val _userData = MutableLiveData<User>()
    val userData: LiveData<User> = _userData

    fun fetchUserData() {
        viewModelScope.launch {
            val data = userRepository.getUser() // 异步获取数据
            _userData.postValue(data) // 触发回调更新UI
        }
    }
}

// Activity.kt
class UserActivity : AppCompatActivity() {
    private val viewModel: UserViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        viewModel.userData.observe(this) { user ->
            // 数据变化自动更新UI
            binding.userName.text = user.name
        }
    }
}

核心优势:

• 自动生命周期管理：LiveData仅向活跃的LifecycleOwner发送更新
• 数据版本控制：避免旧数据覆盖新数据的问题

场景五：Flow的异步回调——协程时代的响应式编程

在协程中,Flow通过collect操作符实现流式数据的回调处理:

// Repository.kt
fun fetchDataStream(): Flow<List<Data>> = flow {
    while (true) {
        emit(database.queryData())
        delay(5000)
    }
}

// ViewModel.kt
fun startDataPolling() {
    viewModelScope.launch {
        repository.fetchDataStream()
            .onEach { data -> _data.value = data }
            .catch { e -> _error.value = e }
            .collect()
    }
}

设计哲学:

• 冷流与热流：Flow默认是冷流,仅在收集时执行
• 结构化并发：自动取消协程作用域,避免资源泄漏

结论：Callback模式已成为Android架构的基石

从registerForActivityResult到OnBackPressedDispatcher,从LiveData到Flow,Android官方通过一系列回调机制的革新,正在构建一个统一的设计范式:

1. 解耦与职责分离：将事件触发与处理逻辑分离,提升代码可维护性
2. 生命周期安全：所有回调均与Lifecycle深度集成,杜绝内存泄漏
3. 声明式编程：通过配置而非命令式代码控制行为
4. 可测试性提升：纯逻辑回调易于单元测试

这种演进不仅体现在API设计层面,更反映了Android开发哲学的根本转变——从"面向过程"的Activity生命周期管理,转向"声明式"的响应式架构。拥抱这些变化