背景

上期《Jetpack 领域层组件拆解及改善建议》侧重拆解 “领域层” 组件设计误区，并给出改善建议 —— 通过 MVI-Dispatcher 承担 Event-Handler，

然有小伙伴表示，不仅要 MVI-Dispatcher，还想看看 Kotlin 版 MVI 实践

故这期，我们肝了个 MVI-Dispatcher-KTX 框架及示例。以下排坑故事：

SharedFlow 也 “丢” Result？

同 MVI-Dispatcher，KTX 版在 sample module 提供一系列常规 + 暴力测试，

我们于 ComplexRequester 安排 4 组事件选项，事件 1 可轮询通知事件 4 回推 UI，事件 2 延迟 200 毫秒后可回推 UI，事件 3 可直接回推 UI，

class ComplexRequester : MviDispatcherKTX<ComplexEvent>() {
  override suspend fun onHandle(event: ComplexEvent) {
    when (event) {
      is ComplexEvent.ResultTest1 -> interval(100).collect { input(ComplexEvent.ResultTest4(it)) }
      is ComplexEvent.ResultTest2 -> timer(1000).collect { sendResult(event) }
      is ComplexEvent.ResultTest3 -> sendResult(event)
      is ComplexEvent.ResultTest4 -> sendResult(event)
    }
  }
  ...
}
复制代码

与此同时，我们在 MainActivity 通过 output 函数注册观察 MVI-Dispatcher-KTX，并通过 input 函数向 MVI-Dispatcher-KTX 发起事件 1、2、3，

class MainActivity : BaseActivity() {

  ...
  
  override fun onOutput() {
    complexRequester.output(this) { complexEvent ->
      when (complexEvent) {
        is ComplexEvent.ResultTest1 -> Log.d("e", "---1")
        is ComplexEvent.ResultTest2 -> Log.d("e", "---2")
        is ComplexEvent.ResultTest3 -> Log.d("e", "---3")
        is ComplexEvent.ResultTest4 -> Log.d("e", "---4 " + complexEvent.count)
      }
    }
  }
  
  override fun onInput() {
    super.onInput()
    
    complexRequester.input(ComplexEvent.ResultTest1())
    
    complexRequester.input(ComplexEvent.ResultTest2())
    complexRequester.input(ComplexEvent.ResultTest2())
    complexRequester.input(ComplexEvent.ResultTest2())
    complexRequester.input(ComplexEvent.ResultTest2())
    
    complexRequester.input(ComplexEvent.ResultTest3())
    complexRequester.input(ComplexEvent.ResultTest3())
    complexRequester.input(ComplexEvent.ResultTest3())
  }
}
复制代码

结果出人意料：

com.kunminx.purenote_ktx D/e: ---4 0
com.kunminx.purenote_ktx D/e: ---4 1
com.kunminx.purenote_ktx D/e: ---4 2
com.kunminx.purenote_ktx D/e: ---4 3
com.kunminx.purenote_ktx D/e: ---4 4
com.kunminx.purenote_ktx D/e: ---4 5
com.kunminx.purenote_ktx D/e: ---4 6
com.kunminx.purenote_ktx D/e: ---4 7
com.kunminx.purenote_ktx D/e: ---2
com.kunminx.purenote_ktx D/e: ---2
com.kunminx.purenote_ktx D/e: ---2
com.kunminx.purenote_ktx D/e: ---2
com.kunminx.purenote_ktx D/e: ---4 8
com.kunminx.purenote_ktx D/e: ---4 9
com.kunminx.purenote_ktx D/e: ---4 10
com.kunminx.purenote_ktx D/e: ---4 11
com.kunminx.purenote_ktx D/e: ---4 12
复制代码

事件 3 回推结果呢？

MVI-Dispatcher 测试时无此问题，为何 KTX 版有？

于是继续打 Log 观察：

class ComplexRequester : MviDispatcherKTX<ComplexEvent>() {
  override suspend fun onHandle(event: ComplexEvent) {
    when (event) {
      ...
      is ComplexEvent.ResultTest3 -> {
        Log.d("---", "ResultTest3-sendResult")
        sendResult(event)
      }
    }
  }
}
复制代码

KTX 版基类中观察 SharedFlow 收集时机：

open class MviDispatcherKTX<E> : ViewModel() {
  fun output(activity: AppCompatActivity?, observer: (E) -> Unit) {
    initQueue()
    activity?.lifecycleScope?.launch {
      Log.d("---", "activity.lifecycleScope.launch")
      activity.repeatOnLifecycle(Lifecycle.State.STARTED) {
        Log.d("---", "activity.repeatOnLifecycle")
        _sharedFlow?.collect { observer.invoke(it) }
      }
    }
  }
  ...
}
复制代码

继续输出结果：

com.kunminx.purenote_ktx D/---: activity.lifecycleScope.launch
com.kunminx.purenote_ktx D/---: ResultTest3-sendResult
com.kunminx.purenote_ktx D/---: ResultTest3-sendResult
com.kunminx.purenote_ktx D/---: ResultTest3-sendResult
com.kunminx.purenote_ktx D/---: activity.repeatOnLifecycle
com.kunminx.purenote_ktx D/e: ---4 0
com.kunminx.purenote_ktx D/e: ---4 1
com.kunminx.purenote_ktx D/e: ---4 2
com.kunminx.purenote_ktx D/e: ---4 3
com.kunminx.purenote_ktx D/e: ---4 4
复制代码

发现端倪 —— sharedFlow.emit 事件 3 时机早于 activity.repeatOnLifecycle 时机，错过 sharedFlow 收集时，

故此处将 sharedFlow replay 值改为 1 验证下：

open class MviDispatcherKTX<E> : ViewModel() {
  private var _sharedFlow: MutableSharedFlow<E>? = null

  private fun initQueue() {
    if (_sharedFlow == null) _sharedFlow = MutableSharedFlow(
      replay = 1,
      onBufferOverflow = BufferOverflow.DROP_OLDEST,
      extraBufferCapacity = initQueueMaxLength()
    )
  }
  ...
}
复制代码

这下收到，确实是时机问题，也即 sharedFlow 并非人眼感知到的 “丢 Result”，而是其默认 replay = 0，不自动回推缓存数据给订阅者，该设计符合 “Result” 场景。

为何不用 StateFlow？

架构组件应致力消除不可预期错误，而非逆行倒施。

“响应式编程” 属理想化模型，BehaviorSubject / StateFlow / LiveData 皆过度设计，在 “命令式编程” 环境下易滋生不可预期错误，应彻底移除或规避。

例如此场景如单纯指望 replay = 1，发射 3 次也仅能收到 1 次，不利于 MVI 多类型消息响应，故修改 replay 方案暂且 pass。

com.kunminx.purenote_ktx D/---: activity.lifecycleScope.launch
com.kunminx.purenote_ktx D/---: ResultTest3-sendResult
com.kunminx.purenote_ktx D/---: ResultTest3-sendResult
com.kunminx.purenote_ktx D/---: ResultTest3-sendResult
com.kunminx.purenote_ktx D/---: activity.repeatOnLifecycle
com.kunminx.purenote_ktx D/e: ---3
com.kunminx.purenote_ktx D/e: ---4 0
com.kunminx.purenote_ktx D/e: ---4 1
com.kunminx.purenote_ktx D/e: ---4 2
com.kunminx.purenote_ktx D/e: ---4 3
com.kunminx.purenote_ktx D/e: ---4 4
复制代码

那怎办，repeatOnLifecycle STARTED 回调相对 emit 存在时延，其实在 Activity 中易解决，即通过 View.post 时机，让 emit 处于 MessageQueue 中顺序执行，如此便能确保时机正确，

但发射一事件还要 View.post，显然易忘记、造成一致性问题，且 MVI-Dispatcher-KTX 采用内聚设计，故此处不妨往 input 方法注入 Activity，再于内部拿取 decorView 自动完成 post …

open class MviDispatcherKTX<E> : ViewModel() {
  ...
  fun input(event: E, activity: AppCompatActivity?) {
    activity?.window?.decorView?.post {
      viewModelScope.launch { onHandle(event) }
    }
  }
}
复制代码

倒也行，不过每次 input 都额外注入个 Activity，这写法是不有点莫名其妙？

且如我想在 KTX 版子类内部 input “side effect” 怎办？故该方案暂且 pass。

… 还有无别的办法？

有，

考虑到 “错过事件” 情形较极端，常规 “从数据层取数据” 等操作，由于操作有其耗时，不易遇见；

如是页面 onCreate 环节末尾发送某 sealed.object 通知，由于毫不费时，则易先于 activity.repeatOnLifecycle(Lifecycle.State.STARTED)，错过时机，

故此处可于每次 input 时自动延迟 1 毫秒 ——

默认设置为 1 毫秒，且通过维护一 delayMap 自动判断时机取消延迟：

open class MviDispatcherKTX<E> : ViewModel() {

  ...
  
  fun input(event: E) {
    viewModelScope.launch {
      if (needDelayForLifecycleState) delayForLifecycleState().collect { onHandle(event) }
      else onHandle(event)
    }
  }

  private val needDelayForLifecycleState
    get() = delayMap.isNotEmpty()
}
复制代码

输出 Log 看看：

com.kunminx.purenote_ktx D/---: activity.lifecycleScope.launch
com.kunminx.purenote_ktx D/---: activity.repeatOnLifecycle
com.kunminx.purenote_ktx D/---: ResultTest3-sendResult
com.kunminx.purenote_ktx D/e: ---3
com.kunminx.purenote_ktx D/---: ResultTest3-sendResult
com.kunminx.purenote_ktx D/e: ---3
com.kunminx.purenote_ktx D/---: ResultTest3-sendResult
com.kunminx.purenote_ktx D/e: ---3
com.kunminx.purenote_ktx D/e: ---4 0
com.kunminx.purenote_ktx D/e: ---4 1
com.kunminx.purenote_ktx D/e: ---4 2
com.kunminx.purenote_ktx D/e: ---4 3
com.kunminx.purenote_ktx D/e: ---4 4
复制代码

至此，3 个事件 3 皆收到。

Tip 2022.8.16：

V6.6 版后取消初始化延迟设定，改用拦截方式实现 “确保消费且只消费一次” 设定，具体见下文加餐。

UnPeek-LiveData 如何？

让我们借一部说话，看看 UnPeek-LiveData 表现：

public class MainActivity extends BaseActivity {
  private UnPeekLiveData<String> unpeek = new UnPeekLiveData<>();
  
  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    
    ...

    unpeek.observe(this,s -> {
      Log.d("----",s);
    });
    unpeek.setValue("hahaha");
  }
}
复制代码

输出 Log 看看：

com.kunminx.unpeeklivedata D/----: hahaha
复制代码

鉴于 UnPeek-LiveData 表现，加之 MVI-Dispatcher 内部维护定长队列，故默认无原生 LiveData “连发丢事件” 问题。

加餐 2022.08.16：

实现 SharedFlow “消费且只消费一次”

有小伙伴反馈 “息屏亮屏” 场景下，亮屏后无法响应息屏时推送最新数据，

考虑过 Channel，然 Channel 只能用于一对一场景，难实现一对多，

期望结果是，在确保 “多观察者消费且各只消费一次” 前提下，消除页面初始化和息屏亮屏等场景 “Flow 错过收集”，

故综合考虑，采取 replay 次数与队列长度保持一致方式。

与此同时，通过 version 对比实现新订阅不接收推送；通过 observerCount 对比实现重回 Started 时只消费未消费过的消息。

提示：replay 次数可根据实际业务需求，在对应 MVI-Dispatcher-KTX 子类中重写 initQueueMaxLength( ) 以修改。

fun output(activity: AppCompatActivity?, observer: (E) -> Unit) {
  currentVersion = version
  observerCount++
  activity?.lifecycle?.addObserver(this)
  activity?.lifecycleScope?.launch {
    activity.repeatOnLifecycle(Lifecycle.State.STARTED) {
      _sharedFlow?.collect {
        if (version > currentVersion) {
          if (it.consumeCount >= observerCount) return@collect
          it.consumeCount++
          observer.invoke(it.value)
        }
      }
    }
  }
}
复制代码

最后

MVI-Dispatcher-KTX + 排坑小故事至此已分享完毕，目前 MVI-Dispatcher 及 MVI-Dispatcher-KTX 正在公测中，欢迎各位大佬测试反馈：

Github：MVI-Dispatcher

Github：MVI-Dispatcher-KTX

License：本文封面 Android 机器人是在 Google 原创及共享成果基础上再创作而成，遵照知识共享署名 3.0 许可所述条款付诸应用。

repeatOnLifecycle + SharedFlow 隐藏坑排查与治理

背景

SharedFlow 也 “丢” Result？

为何不用 StateFlow？

UnPeek-LiveData 如何？

加餐 2022.08.16：

实现 SharedFlow “消费且只消费一次”

最后