【业务场景架构实战】5. 使用 Flow 模式传递状态过程中的思考点我在使用 Kotlin Flow 实现业务功能模块的

天下难事，必作于易；天下大事，必作于细。

我在使用 Kotlin Flow 实现业务功能模块的过程中，遇到一些细节上的问题，虽然微小，但仍值得思考、学习和记录。请将本文结合前一篇文章《【业务场景架构实战】4. 支付状态分层流转的设计和实现》共同阅读。

1. 如何将 `支付 SDK` 的回调式接口封装为 `Flow`

这是一个典型场景，把 传统回调 -> Flow 的编程风格进行转换，其核心思想是用 callbackFlow {}，将异步回调改写为同步的格式。

异步 API

fun pay(orderId: String, callback: (result: PaymentResult) -> Unit)

改写后的 Flow，便于进行状态监听

class AlipaySdkWrapper : PaymentSdkWrapper {
    override fun pay(orderId: String): Flow<PaymentResult> = callbackFlow {
        // 假设这是支付宝SDK提供的函数
        AlipaySdk.pay(orderId) { result ->
            trySend(result) // 将回调结果发送到Flow
            close()         // 一次性回调，结果出来就关闭流
        }

        // 当Flow被取消/关闭时，执行清理逻辑
        awaitClose {
            // 比如取消支付请求（如果SDK支持）
            // AlipaySdk.cancel(orderId)
        }
    }
}

关于 callbackFlow，还有一些细节需要留意：

内部使用 trySend() 向下游发射数据。
默认是冷流，只有新产生订阅者时，才会触发 AlipaySdk.pay()，这也符合支付接口原本的设计意图。
如果支付只有一次最终结果（成功/失败），则可使用 close() 对流执行关闭操作。如果支付接口仍然存在多次回调（例如处理中->成功/失败），则不可进行 close()。
awaitClose() 用于在流关闭后（例如 VM 销毁、Flow 被取消等），释放 SDK 的 listener（例如 unregisterListener），防止资源泄漏。

在 ViewModel 里调用支付接口

经过改写后，在 VM 层就可以通过统一的方式调用支付，这样做的好处是，外部代码观察到的是同一的 Flow 接口，而底层具体实现可以无痛替换（例如改为微信支付、银联支付、苹果支付等）。

viewModelScope.launch {
    paymentSdk.pay("123456")
        .collect { result ->
            when (result) {
                is PaymentResult.Success -> println("支付成功")
                is PaymentResult.Failed -> println("支付失败")
            }
        }
}

2. 使用 `ActivityComponent` 引起的生命周期倒置问题

在唤起聚合支付 SDK 所提供的收银台过程中，其支付接口 pay(activity, orderInfo) 需要传入一个 Activity 类型的参数，这样设计的原因，是由于收银台会以类似 Dialog Fragment 的方式呈现在当前页面上，涉及到页面视图的引用，因此必须使用到 Activity 对象。

但是，这对我们的分层设计产生了一个不大不小的困扰，最初对于分层的设计如下：

DataSource
Repository
ViewModel
UI

其中 DataSource 位于最底层，提供支付 SDK、后端接口等的抽象。在上述分层设计里，除了最上层 UI，其他各层是不会接触到页面层级对象的，正是由于这种设计，才能够保持 ViewModel 独立于页面生命周期的特性，以便在页面销毁后重建时恢复状态。

然而，如果通过 Hilt 将 Activity 提供给 PaymentSdk，虽然可以简化支付接口的层层调用，使其只需要传递订单信息，但却打破了这种解耦关系。

错误写法，将 PaymentSdk 生命周期声明为页面级

@Module
@InstallIn(ActivityComponent::class)
abstract class PaymentModule {

    @Binds
    abstract fun bindPaymentSdkWrapper(
        impl: AlipaySdkWrapper
    ): PaymentSdkWrapper
}

上面这种写法会导致 Repository、DataSource 生命周期倒置的问题。Repository 是全局单例，而它持有了 DataSource，因此后者必须也是全局单例，从而将其声明为 ActivityComponent 是行不通的，除非也将 Repository 改写为同样的 ActivityComponent。但这样的话，会导致 Repository 跟随页面销毁重建，并没有必要这么做，在实现时还是要尽可能保持整洁和精简。

因此，最终采用的方案是，保持 AlipaySdk.pay() 接口的 Activity 参数，从 Activity-VieModel-Repository 中层层传递过来。

CourseDetailActivity.kt

btnPay.setOnClickListener {
    viewModel.pay(this)
}

3. `ViewModel` 对外暴露状态：成员变量 or 接口返回值

这也是一个值得探究的问题。

我们知道在传统的 LiveData 模式中，ViewModel 内部持有 LiveData 成员变量，Activity 通过订阅该对象，实现对数据流的监听。

在 Flow 问世以来，它逐渐替代掉了老旧的 LiveData，提供 StateFlow、SharedFlow 供页面监听，它的写法是与 LiveData 相似的。

但有一点区别尤其明显—— Flow 可以用作函数返回值，并且这也是一种非常典型的 Flow 用法。

1. UI State 成员变量模式

特点是 状态驱动，ViewModel 内部维护页面状态变量。注意到这里更底层的 Repository 实际上是返回的 Flow 对象，在 ViewModel 收集它时，用 collect 对内部状态进行更新。

ViewModel 层更新状态

@HiltViewModel
class PaymentViewModel @Inject constructor(
    private val repository: PaymentRepository
) : ViewModel() {

    private val _uiState = MutableStateFlow(PaymentUiState(idle = true))
    val uiState: StateFlow<PaymentUiState> = _uiState

    fun pay(activity: Activity, orderInfo: OrderInfo) {
        viewModelScope.launch {
            repository.startPay(activity, orderInfo) // ===> 下游 Repository 接口返回 Flow<PaymentResult> 对象
                .map { result ->
                    when (result) {
                        is PaymentResult.Success -> PaymentUiState(success = true, message = "支付成功")
                        is PaymentResult.Failure -> PaymentUiState(success = false, message = result.reason)
                        is PaymentResult.Cancelled -> PaymentUiState(success = false, message = "用户取消")
                    }
                }
                .collect { state ->
                    _uiState.value = state
                }
        }
    }
}

UI 层收集状态

lifecycleScope.launchWhenStarted {
    viewModel.uiState.collect { uiState ->
        when {
            uiState.idle -> showIdleUI()
            uiState.success -> showSuccessUI()
            else -> showErrorUI(uiState.message)
        }
    }
}

2. ViewModel 函数返回值式

特点是 流程驱动，Activity 调用 ViewModel 函数 -> 函数返回状态 -> Activity 收集函数返回的状态。由于 ViewModel 内部不对状态进行维护，每一次调用都生成独立的流，能够用于 多订单并行支付 的场景。

Activity 调用 vm.pay() 获得 StateFlow，进行收集并展示

@AndroidEntryPoint
class PaymentActivity : AppCompatActivity() {

    private val viewModel: PaymentViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        val orderInfo = OrderInfo(id = "12345")

        lifecycleScope.launchWhenStarted {
            viewModel.pay(this@PaymentActivity, orderInfo).collect { uiState ->
                when {
                    uiState.idle -> showIdleUI()
                    uiState.success -> showSuccessUI()
                    else -> showErrorUI(uiState.message)
                }
            }
        }
    }
}

3. 我的选择

最终在两者之间，我选择了前者，即 UI State 成员变量模式。对于 Activity 来说，维护在 ViewModel 中的状态更适合描述和记录页面信息，在发生问题时，通过打印当前状态，也更容易进行定位排查。

4. 选择 `Fake 实现` 所处的层次

使用 Hilt 的一个重要优势，就是可以在开发阶段，在真实业务逻辑实现与 Fake 实现之间灵活切换。

DataSource
Repository
ViewModel
UI

回到我们的分层设计，在这个分层中，ViewModel 和 UI 作为终端呈现，没有为其设计虚假实现得必要。因此，我们对 Fake 对象的选择，要么是 FakeDataSource，要么是 FakeRepository。

在进行决策时，牢记这个原则：

越是底层的 Fake，其代码覆盖程度越广。

FakeRepository 与 FakeDataSourcee

对两种 Fake 方案的自测覆盖范围，对比阐述如下：

Fake 所在层次	Repository 层	DataSource 层
能测到 UI	✅	✅
能测到 ViewModel	✅	✅
能测到 Reopsitory	❌	✅
能测到 DataSource	❌	❌
开发复杂程度	低	中

可见两者最主要的区别是，使用 FakeDataSource 可以用来验证 Repository内部逻辑是否正确。后续在接入新的支付渠道时，测试逻辑能够保持一致性，测试范围的覆盖也更加到位。

最终我选择的是 FakeDataSource 来实现。

【业务场景架构实战】5. 使用 Flow 模式传递状态过程中的思考点

1. 如何将 支付 SDK 的回调式接口封装为 Flow

在 ViewModel 里调用支付接口

2. 使用 ActivityComponent 引起的生命周期倒置问题

3. ViewModel 对外暴露状态：成员变量 or 接口返回值