说在前头纪晓岚问和珅为何他们往灾民粥里掺沙子和珅道“你是有所不知啊如不掺沙子灾民怕是一口粥也喝不上啊”。同理架构的存在是为 “在实际开发过程中消除不可预期问题”而非为架构而架构。为使架构组件真正能在团队中普及乃至最终有效达成 “消除大部分不可预期问题” 目的本文采取 “淡化理论概念 设计简明易懂” 方式让团队新手老手都能因为 “这框架好懂、简便、用着舒服”而自然而然效仿和使用。本文假设您已具备 State、Event、响应式编程、BehaviorSubject、PublishSubject、函数式编程、纯函数、副作用、MVI、软件工程、设计模式原则、一致性问题、单一职责原则、过度设计 等前置知识且在团队中推行 MVI 遭遇不利想就近找到平替方案。通过本文可快速了解1.为何使用 MVI是否非用不可2.为何最终考虑 SharedFlow 实现3.repeatOnLifecycle SharedFlow 实现思路文章目录一览前置知识为何使用 MVI是否非用不可MVI 经典模型改善版本 1添加防抖处理使用 DataBinding ObservableField使用 distinctUntilChanged使用 RecyclerView DiffUtils改善版本 2简化 Action 和 Reduce使用 Sealed Class 分流改善版本 3改用 PublishSubject 回推结果使用 SharedFlow 回推结果改善版本 4通过计数防止重复回推改善版本 5封装和屏蔽样板代码改善版本 6State 和 Event 合与分State 和 Event 什么时候该分什么时候该合添加 version 防止订阅回推三层架构 vs 二层架构综上前置知识上一期《MVI 的存在意义》我们已铺垫如下信息1.响应式编程暗示人们应当总是向数据源请求数据并在指定观察者中响应数据的变化。2.响应式编程的好处是便于测试有输入必有回响。3.响应式编程存在 “多个粘性观察者回推不符预期数据” 的漏洞。4.MVI 即是通过 “聚合页面状态” 消除该漏洞。5.鉴于 “响应式编程” 便于测试官方出于完备性考虑也是以响应式编程作为架构示例。6.由于 Kotlin 抹平语法复杂度便于响应式编程且 Kotlin 开发者更容易跟着官方文档走接受这套开发模式乃至有机会踩坑且有动力通过 MVI 改善。7.Android 开发者 70% 仍是纯 Java响应式编程在 Android Java 开发者中的推行不太理想。为何使用 MVI是否非用不可所以至此第一个问题的答案呼之欲出因为对一部分开发者来说响应式编程很香但又存在漏洞即部分 BehaviorSubject 框架存在过度设计导致存在 “多个粘性观察者不符预期回推” 的漏洞所以需要 MVI 出马解决。注什么是过度设计如何避免具体见上期解析本文不再累述。那有人可能会问既然部分 BehaviorSubject 框架过度设计那替换成没有过度设计的 BehaviorSubject比如 ObservableField 不就可以了可以是可以不过也看情况MVI 天然适合与 Jetpack Compose 搭配如果是使用 Jetpack Compose就用不上 ObservableField只能使用 LiveData/StateFlow 来回推 UiStates也即只能通过 MVI 来消除漏洞难有别的平替方案。所以如果暂不使用 Jetpack Compose根据上期的分析易知只要消除过度设计就能从源头上把问题解决无所谓开发者用不用 MVI。鉴于上期文末已分享 MVI 最小成本平替方案本文直接从 “设计模式原则” 出发探索一种更加普适的方案相信阅读后你会耳目一新。MVI 经典模型1.创建一个 UiStates反映当前页面的所有状态。data class UiStates { val weather : Weather, val isLoading : Boolean, val error : ListUiEvent, }2.创建一个 Intent用于发送请求时携带参数和指明当前想执行的业务。sealed class MainPageIntent { data class GetWeather(val cityCode) : MainPageIntent() }3.创建一个 Actions用于 reduce 当前业务的 partialChange 并生成新的 UiStates。sealed class MainPageActions { fun reduce(oldStates : UiStates) : UiStates { return when(this){ Loading - oldStates.copy(isLoading true) is Success - oldStates.copy(isLoading false, weather this.weather) is Error - oldStates.copy(isLoading false, error listOf(UiEvent(msg))) } } object Loading : MainPageActions() data class Success(val weather : Weather) : MainPageActions() data class Error(val msg : String) : MainPageActions() }4.创建当前页面使用的 MVI-Model。class MainPageModel : MVI_ModelUiStates() { private val _stateFlow MutableStateFlow(UiStates()) val stateFlow _stateFlow.asStateFlow private fun sendResult(uiStates: S) _stateFlow.emit(uiStates) fun input(intent: Intent) viewModelScope.launch{ onHandle() } private suspend fun onHandle(intent: Intent) { when(intent){ is GetWeather - { sendResult(MainPageActions.Loading.reduce(oldStates) val response api.post() if(response.isSuccess) sendResult( MainPageActions.Success(response.data).reduce(oldStates) else sendResult( MainPageActions.Error(response.message).reduce(oldStates) } } } }5.创建 MVI-View并在 stateFlow 中响应 MVI-Model 数据。class MainPageActivity : Android_Activity(){ private val model : MainPageModel fun onCreate(){ lifecycleScope.launch { repeatOnLifecycle(Lifecycle.State.STARTED) { model.stateFlow.collect {uiStates - progressView.setProgress(uiStates.isLoading) tvWeatherInfo.setText(uiStates.weather.info) ... } } model.input(Intent.GetWeather(BEI_JING)) } }整个流程用一张图来表示即改善版本 1添加防抖处理使用 DataBinding ObservableField考虑到 DataBinding ObservableField 存在防抖特性故页面可通过 ObservableField 完成末端状态改变尽可能消除 “控件刷新” 性能开销。class MainPageActivity : Android_Activity(){ private val model : MainPageModel private val views : MainPageViews fun onCreate(){ lifecycleScope.launch { repeatOnLifecycle(Lifecycle.State.STARTED) { model.stateFlow.collect {uiStates - views.progress.set(uiStates.isLoading) views.weatherInfo.set(uiStates.weather.info) ... } } model.input(Intent.GetWeather(BEI_JING)) } class MainPageViews : Jetpack_ViewModel() { val progress ObservableBoolean(false) val weatherInfo ObservableFieldString() ... } }不过这要求开发者具备 DataBinding 使用经验、额外书写 DataBinding 样板代码和 XML 绑定。使用 distinctUntilChanged除了 DataBinding网上还提到有 2 类方案一类是通过 distinctUntilChanged 来为 ViewStates 的属性提供防抖但如此后续便难屏蔽 diff只能暴露给开发者手动 map distinct 分流增加手写代码量和认知成本class View-Controller : Android-Activity() { fun onCreate() { lifecycleScope.launch { repeatOnLifecycle(Lifecycle.State.STARTED) { viewModel.uiState .map { it.isDownload } .distinctUntilChanged() .collect { progress it } viewModel.uiState .map { it.Setting } .distinctUntilChanged() .collect { btnChecked it } ... } } } }使用 RecyclerView DiffUtils另一类是通过 RecyclerView 编写页面。如此便难支持复杂交互效果、容易引入其他不可预期问题也难在多数开发者中普及开有点为 MVI 而 MVI且 DiffUtils 需手动配置equals 列表密密麻麻易漏写或写错val diff object : DiffUtil.ItemCallbackViewStates() { override fun areItemsTheSame(oldItem: ViewStates, newItem: ViewStates): Boolean { return oldItem.equals(newItem) } override fun areContentsTheSame(oldItem: ViewStates, newItem: ViewStates): Boolean { return oldItem.progress().equals(newItem.progress()) ... equals ... ... equals ... ... equals ... ... } }易得 diff 方式皆存在学习成本和使用成本当同事写多了感觉厌烦便自动回归原始架构目的前功尽弃。故我们只好另辟蹊径探索少有人走的路改善版本 2简化 Action 和 Reduce如上文所述响应式编程漏洞是由多观察者引起只要使用单一观察者便无该漏洞需修补。不过单一观察者并不意味着只能通过 data class 聚合 UiStates我们也可将其限定为每次只从同一个出口回推当前业务的数据如此便也无线程安全问题乃至无需 Actions 和 reduce使用 Sealed Class 分流为此每个页面可以简单通过 Intent 来包含入参和结果的传递loading、error 等 Action 可以通过单独的 Intent 来反映如此将 MVI 中最繁琐的 Action 设计拍平sealed class MainIntent { data class Loading(var progress: Boolean) : MainIntent() data class Info(var title: String) : MainIntent() ... } class Model : Jetpack-ViewModel() { private val _states MutableLiveDataMainIntent() val states _states.asLiveData() fun request(intent: Intent){ when(intent){ is Intent.XXX - { _states.setValue(MainIntent.Loading(true)) _states.setValue(MainIntent.Info(DataRepository.getInfo())) _states.setValue(MainIntent.Loading(false)) } } } } class View-Controller : Android-Activity() { private val model : Model private val holder : StateHolder fun onCreate(){ model.states.observe(this){ when(it){ is MainIntent.Loading - holder.progress it.progress is MainIntent.Info - holder.tvTitle it.title ... } } } }然而 BehaviorSubject 天然不适合连续发送消息的场景例如息屏页面生命周期离开 STARTED期间所获消息BehaviorSubject 仅存留最后一个那么分流设计下亮屏后页面生命周期重回 STARTED多种类消息只会推送最后一个其余皆丢失比如 Loading、Success、Error 等数据最终只响应 Error故改用 PublishSubject比如 SharedFlow 来处理。那么有人可能会问改用 PublishSubject那 State 如何保留和自动回推笔者认为会有这样的疑问本身是由于搞混组件的职责所致。网上流行的写法领域层和表现层混杂一处BehaviorSubject 同时承担业务消息回推和 State 容器这也是造成响应式编程漏洞的祸根。根据单一职责原则组件宜职责单一各司其职。在领域层消息分发环节可以使用 PublishSubject 专职业务消息的回推在表现层渲染环节可以使用 BehaviorSubject 通知控件渲染并为控件兜着最后一次状态。对此下文的 “改善版本 6” 一节通过图文详细介绍 State 和 Event 合与分的时机和设计。改善版本 3改用 PublishSubject 回推结果使用 SharedFlow 回推结果SharedFlow 内有一队列如欲亮屏后自动推送多种类消息则可将 replay 次数设置为与队列长度一致例如 10class Model : Jetpack-ViewModel() { private val _sharedFlow: MutableSharedFlowViewStates? by lazy { MutableSharedFlow( onBufferOverflow BufferOverflow.DROP_OLDEST, extraBufferCapacity DEFAULT_QUEUE_LENGTH, replay DEFAULT_QUEUE_LENGTH ) } val sharedFlow _sharedFlow.asSharedFlow() companion object { private const val DEFAULT_QUEUE_LENGTH 10 } }由于 replay 会重走设定次数中队列的元素故重走 STARTED 时会重走所有包括已消费和未消费过视觉上给人感觉即控件上旧数据 “一闪而过”这体验并不好改善版本 4通过计数防止重复回推故此处可加个判断 —— 如已消费则下次 replay 时不消费。class Model : class Model : Jetpack-ViewModel() { private var observerCount 0 private val _sharedFlow: MutableSharedFlowViewStates? by lazy { MutableSharedFlow( onBufferOverflow BufferOverflow.DROP_OLDEST, extraBufferCapacity DEFAULT_QUEUE_LENGTH, replay DEFAULT_QUEUE_LENGTH ) } val sharedFlow _sharedFlow.asSharedFlow() companion object { private const val DEFAULT_QUEUE_LENGTH 10 } } data class ConsumeOnceValueE( var consumeCount: Int 0, val value: E ) class View-Controller : Android-Activity() { private val model : Model private val holder : StateHolder fun onCreate(){ lifecycleScope?.launch { repeatOnLifecycle(Lifecycle.State.STARTED) { model.states.collect { if (version currentVersion) { if (model.consumeCount observerCount) returncollect model.consumeCount when(it){ is MainIntent.Download - holder.progress it.progress is MainIntent.Setting - holder.btnChecked it.btnChecked is MainIntent.Info - holder.tvTitle it.title is MainIntent.List - holder.list it.list } } } } } } }但每次创建一页面都需如此写一番繁琐且易出错故可将其内聚统一抽取至单独框架维护MVI-Dispatcher-KTX 应运而生改善版本 5封装和屏蔽样板代码如下通过将 repeatOnLifecycle、计数比对、mutable/immutable 等样板逻辑内聚open class MviDispatcherKTXE : ViewModel(), DefaultLifecycleObserver { private var observerCount 0 private val _sharedFlow: MutableSharedFlowConsumeOnceValueE? by lazy { MutableSharedFlow( onBufferOverflow BufferOverflow.DROP_OLDEST, extraBufferCapacity initQueueMaxLength(), replay initQueueMaxLength() ) } protected open fun initQueueMaxLength(): Int { return DEFAULT_QUEUE_LENGTH } fun output(activity: AppCompatActivity?, observer: (E) - Unit) { observerCount activity?.lifecycle?.addObserver(this) activity?.lifecycleScope?.launch { activity.repeatOnLifecycle(Lifecycle.State.STARTED) { _sharedFlow?.collect { if (it.consumeCount observerCount) returncollect it.consumeCount observer.invoke(it.value) } } } } override fun onDestroy(owner: LifecycleOwner) { super.onDestroy(owner) observerCount-- } protected suspend fun sendResult(event: E) { _sharedFlow?.emit(ConsumeOnceValue(value event)) } fun input(event: E) { viewModelScope.launch { onHandle(event) } } protected open suspend fun onHandle(event: E) {} data class ConsumeOnceValueE( var consumeCount: Int 0, val value: E ) companion object { private const val DEFAULT_QUEUE_LENGTH 10 } }如此开发者哪怕不熟 MVI、mutable只需关注 “input-output” 两处即可自动完成 “单向数据流” 开发,改善版本 6State 和 Event 合与分State 和 Event 什么时候该分什么时候该合为了改善 “副作用”关于 “副作用” 见上期解析通常是传输过程中合并 UiStates 和 UiEvents并在响应时分开处理这也和 “响应式编程” 串流设计不谋而合。对此官方做法是将 UiEvents 整合到 UiStates界面事件 | Android Developers笔者认为此做法相较于 UiStates 和 UiEvents 分开发送的优点在于使 UiEvents 同处于 STATRED 环节响应避免手写遗漏乃至引发 “弹窗无法获取 token” 等情况缺点是需要手动 filterNot 屏蔽已消费事件增加学习成本且埋下手写的一致性隐患。故笔者采取的是另一种办法 —— 将 UiState 整合到 UiEvent响应时再将 UiState 和 UiEvent 解离。也即我们可以采用 PublishSubject 来做观察者并在观察者回调中单独对 UiState 采取 BehaviorSubject比如 ObservableField的方式来通知控件响应和渲染。添加 version 防止订阅回推故此处可再加个 verison 比对open class MviDispatcherKTXE : ViewModel(), DefaultLifecycleObserver { private var version START_VERSION private var currentVersion START_VERSION private var observerCount 0 ... 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) returncollect it.consumeCount observer.invoke(it.value) } } } } } protected suspend fun sendResult(event: E) { version _sharedFlow?.emit(ConsumeOnceValue(value event)) } companion object { private const val DEFAULT_QUEUE_LENGTH 10 private const val START_VERSION -1 } }如此即可从根源上消除 “响应式编程” 的漏洞且无论团队成员是否理解 “响应式编程”都可快速稳定迭代不滋生不可预期问题。class MainPageActivity : Android_Activity(){ private val model : MainPageModel private val views : MainPageViews fun onOutput(){ model.output(this){ intent - when(intent){ MainIntent.Progress - views.progress.set(intent.progress) MainIntent.Weather - views.weatherInfo.set(intent.weather) MainIntent.Error - showErrorDialog() } } model.input(Intent.GetWeather(BEI_JING)) } class MainPageViews : Jetpack_ViewModel() { val progress ObservableBoolean(false) val weatherInfo ObservableFieldString() ... } }三层架构 vs 二层架构换言之上述设计属于三层架构表现层、领域层、数据层也即表现层使用 Jetpack ViewModel 做 StateHolder其中安排各式 ObservableField 作为 BehaviorSubject用于为 State 兜着状态、自动通知控件渲染以及旋屏重建时一对一自动回推。领域层使用 MVI-Dispatcher 做业务处理其中安排一个 PublishSubject 用作唯一出口 output 消息回推。三层架构由于各司其职消息回推环节不使用 BehaviorSubject从而从根源上消除 “响应式编程” 漏洞。且三层架构复用性更佳同一业务的页面皆可共用同一套业务逻辑避免业务逻辑的冗余反之网上流行的二层架构表现层数据层。其中 ViewModel 属于表现层意味着每个页面都要在配套的 ViewModel 书写业务逻辑对于冗余的业务逻辑后续容易发生修改其中一个页面的忘记另一页面的造成代码更新的不一致。注SharedFlow 仅限于 Kotlin 项目如 Java 项目也想用可参考 MVI-Dispatcher 设计其内部维护一队列通过基于 LiveData 改造的 Mutable-Result 亦圆满实现上述功能。综上理论模型皆旨在特定环境下解决特定问题直用于生产环境或存在不可预期问题故我们不断尝试、交流和更新。感谢实事求是测试反馈交流的小伙伴让 MVI-Dispatcher 系框架得以演化至今。GithubMVI-DispatcherGithubMVI-Dispatcher-KTX作者KunMinX链接https://juejin.cn/post/7134594010642907149最后如果想要成为架构师或想突破20~30K薪资范畴那就不要局限在编码业务要会选型、扩展提升编程思维。此外良好的职业规划也很重要学习的习惯很重要但是最重要的还是要能持之以恒任何不能坚持落实的计划都是空谈。如果你没有方向这里给大家分享一套由阿里高级架构师编写的《Android八大模块进阶笔记》帮大家将杂乱、零散、碎片化的知识进行体系化的整理让大家系统而高效地掌握Android开发的各个知识点。相对于我们平时看的碎片化内容这份笔记的知识点更系统化更容易理解和记忆是严格按照知识体系编排的。全套视频资料一、面试合集二、源码解析合集三、开源框架合集欢迎大家一键三连支持若需要文中资料直接点击文末CSDN官方认证微信卡片免费领取↓↓↓
说在前头纪晓岚问和珅为何他们往灾民粥里掺沙子和珅道“你是有所不知啊如不掺沙子灾民怕是一口粥也喝不上啊”。同理架构的存在是为 “在实际开发过程中消除不可预期问题”而非为架构而架构。为使架构组件真正能在团队中普及乃至最终有效达成 “消除大部分不可预期问题” 目的本文采取 “淡化理论概念 设计简明易懂” 方式让团队新手老手都能因为 “这框架好懂、简便、用着舒服”而自然而然效仿和使用。本文假设您已具备 State、Event、响应式编程、BehaviorSubject、PublishSubject、函数式编程、纯函数、副作用、MVI、软件工程、设计模式原则、一致性问题、单一职责原则、过度设计 等前置知识且在团队中推行 MVI 遭遇不利想就近找到平替方案。通过本文可快速了解1.为何使用 MVI是否非用不可2.为何最终考虑 SharedFlow 实现3.repeatOnLifecycle SharedFlow 实现思路文章目录一览前置知识为何使用 MVI是否非用不可MVI 经典模型改善版本 1添加防抖处理使用 DataBinding ObservableField使用 distinctUntilChanged使用 RecyclerView DiffUtils改善版本 2简化 Action 和 Reduce使用 Sealed Class 分流改善版本 3改用 PublishSubject 回推结果使用 SharedFlow 回推结果改善版本 4通过计数防止重复回推改善版本 5封装和屏蔽样板代码改善版本 6State 和 Event 合与分State 和 Event 什么时候该分什么时候该合添加 version 防止订阅回推三层架构 vs 二层架构综上前置知识上一期《MVI 的存在意义》我们已铺垫如下信息1.响应式编程暗示人们应当总是向数据源请求数据并在指定观察者中响应数据的变化。2.响应式编程的好处是便于测试有输入必有回响。3.响应式编程存在 “多个粘性观察者回推不符预期数据” 的漏洞。4.MVI 即是通过 “聚合页面状态” 消除该漏洞。5.鉴于 “响应式编程” 便于测试官方出于完备性考虑也是以响应式编程作为架构示例。6.由于 Kotlin 抹平语法复杂度便于响应式编程且 Kotlin 开发者更容易跟着官方文档走接受这套开发模式乃至有机会踩坑且有动力通过 MVI 改善。7.Android 开发者 70% 仍是纯 Java响应式编程在 Android Java 开发者中的推行不太理想。为何使用 MVI是否非用不可所以至此第一个问题的答案呼之欲出因为对一部分开发者来说响应式编程很香但又存在漏洞即部分 BehaviorSubject 框架存在过度设计导致存在 “多个粘性观察者不符预期回推” 的漏洞所以需要 MVI 出马解决。注什么是过度设计如何避免具体见上期解析本文不再累述。那有人可能会问既然部分 BehaviorSubject 框架过度设计那替换成没有过度设计的 BehaviorSubject比如 ObservableField 不就可以了可以是可以不过也看情况MVI 天然适合与 Jetpack Compose 搭配如果是使用 Jetpack Compose就用不上 ObservableField只能使用 LiveData/StateFlow 来回推 UiStates也即只能通过 MVI 来消除漏洞难有别的平替方案。所以如果暂不使用 Jetpack Compose根据上期的分析易知只要消除过度设计就能从源头上把问题解决无所谓开发者用不用 MVI。鉴于上期文末已分享 MVI 最小成本平替方案本文直接从 “设计模式原则” 出发探索一种更加普适的方案相信阅读后你会耳目一新。MVI 经典模型1.创建一个 UiStates反映当前页面的所有状态。data class UiStates { val weather : Weather, val isLoading : Boolean, val error : ListUiEvent, }2.创建一个 Intent用于发送请求时携带参数和指明当前想执行的业务。sealed class MainPageIntent { data class GetWeather(val cityCode) : MainPageIntent() }3.创建一个 Actions用于 reduce 当前业务的 partialChange 并生成新的 UiStates。sealed class MainPageActions { fun reduce(oldStates : UiStates) : UiStates { return when(this){ Loading - oldStates.copy(isLoading true) is Success - oldStates.copy(isLoading false, weather this.weather) is Error - oldStates.copy(isLoading false, error listOf(UiEvent(msg))) } } object Loading : MainPageActions() data class Success(val weather : Weather) : MainPageActions() data class Error(val msg : String) : MainPageActions() }4.创建当前页面使用的 MVI-Model。class MainPageModel : MVI_ModelUiStates() { private val _stateFlow MutableStateFlow(UiStates()) val stateFlow _stateFlow.asStateFlow private fun sendResult(uiStates: S) _stateFlow.emit(uiStates) fun input(intent: Intent) viewModelScope.launch{ onHandle() } private suspend fun onHandle(intent: Intent) { when(intent){ is GetWeather - { sendResult(MainPageActions.Loading.reduce(oldStates) val response api.post() if(response.isSuccess) sendResult( MainPageActions.Success(response.data).reduce(oldStates) else sendResult( MainPageActions.Error(response.message).reduce(oldStates) } } } }5.创建 MVI-View并在 stateFlow 中响应 MVI-Model 数据。class MainPageActivity : Android_Activity(){ private val model : MainPageModel fun onCreate(){ lifecycleScope.launch { repeatOnLifecycle(Lifecycle.State.STARTED) { model.stateFlow.collect {uiStates - progressView.setProgress(uiStates.isLoading) tvWeatherInfo.setText(uiStates.weather.info) ... } } model.input(Intent.GetWeather(BEI_JING)) } }整个流程用一张图来表示即改善版本 1添加防抖处理使用 DataBinding ObservableField考虑到 DataBinding ObservableField 存在防抖特性故页面可通过 ObservableField 完成末端状态改变尽可能消除 “控件刷新” 性能开销。class MainPageActivity : Android_Activity(){ private val model : MainPageModel private val views : MainPageViews fun onCreate(){ lifecycleScope.launch { repeatOnLifecycle(Lifecycle.State.STARTED) { model.stateFlow.collect {uiStates - views.progress.set(uiStates.isLoading) views.weatherInfo.set(uiStates.weather.info) ... } } model.input(Intent.GetWeather(BEI_JING)) } class MainPageViews : Jetpack_ViewModel() { val progress ObservableBoolean(false) val weatherInfo ObservableFieldString() ... } }不过这要求开发者具备 DataBinding 使用经验、额外书写 DataBinding 样板代码和 XML 绑定。使用 distinctUntilChanged除了 DataBinding网上还提到有 2 类方案一类是通过 distinctUntilChanged 来为 ViewStates 的属性提供防抖但如此后续便难屏蔽 diff只能暴露给开发者手动 map distinct 分流增加手写代码量和认知成本class View-Controller : Android-Activity() { fun onCreate() { lifecycleScope.launch { repeatOnLifecycle(Lifecycle.State.STARTED) { viewModel.uiState .map { it.isDownload } .distinctUntilChanged() .collect { progress it } viewModel.uiState .map { it.Setting } .distinctUntilChanged() .collect { btnChecked it } ... } } } }使用 RecyclerView DiffUtils另一类是通过 RecyclerView 编写页面。如此便难支持复杂交互效果、容易引入其他不可预期问题也难在多数开发者中普及开有点为 MVI 而 MVI且 DiffUtils 需手动配置equals 列表密密麻麻易漏写或写错val diff object : DiffUtil.ItemCallbackViewStates() { override fun areItemsTheSame(oldItem: ViewStates, newItem: ViewStates): Boolean { return oldItem.equals(newItem) } override fun areContentsTheSame(oldItem: ViewStates, newItem: ViewStates): Boolean { return oldItem.progress().equals(newItem.progress()) ... equals ... ... equals ... ... equals ... ... } }易得 diff 方式皆存在学习成本和使用成本当同事写多了感觉厌烦便自动回归原始架构目的前功尽弃。故我们只好另辟蹊径探索少有人走的路改善版本 2简化 Action 和 Reduce如上文所述响应式编程漏洞是由多观察者引起只要使用单一观察者便无该漏洞需修补。不过单一观察者并不意味着只能通过 data class 聚合 UiStates我们也可将其限定为每次只从同一个出口回推当前业务的数据如此便也无线程安全问题乃至无需 Actions 和 reduce使用 Sealed Class 分流为此每个页面可以简单通过 Intent 来包含入参和结果的传递loading、error 等 Action 可以通过单独的 Intent 来反映如此将 MVI 中最繁琐的 Action 设计拍平sealed class MainIntent { data class Loading(var progress: Boolean) : MainIntent() data class Info(var title: String) : MainIntent() ... } class Model : Jetpack-ViewModel() { private val _states MutableLiveDataMainIntent() val states _states.asLiveData() fun request(intent: Intent){ when(intent){ is Intent.XXX - { _states.setValue(MainIntent.Loading(true)) _states.setValue(MainIntent.Info(DataRepository.getInfo())) _states.setValue(MainIntent.Loading(false)) } } } } class View-Controller : Android-Activity() { private val model : Model private val holder : StateHolder fun onCreate(){ model.states.observe(this){ when(it){ is MainIntent.Loading - holder.progress it.progress is MainIntent.Info - holder.tvTitle it.title ... } } } }然而 BehaviorSubject 天然不适合连续发送消息的场景例如息屏页面生命周期离开 STARTED期间所获消息BehaviorSubject 仅存留最后一个那么分流设计下亮屏后页面生命周期重回 STARTED多种类消息只会推送最后一个其余皆丢失比如 Loading、Success、Error 等数据最终只响应 Error故改用 PublishSubject比如 SharedFlow 来处理。那么有人可能会问改用 PublishSubject那 State 如何保留和自动回推笔者认为会有这样的疑问本身是由于搞混组件的职责所致。网上流行的写法领域层和表现层混杂一处BehaviorSubject 同时承担业务消息回推和 State 容器这也是造成响应式编程漏洞的祸根。根据单一职责原则组件宜职责单一各司其职。在领域层消息分发环节可以使用 PublishSubject 专职业务消息的回推在表现层渲染环节可以使用 BehaviorSubject 通知控件渲染并为控件兜着最后一次状态。对此下文的 “改善版本 6” 一节通过图文详细介绍 State 和 Event 合与分的时机和设计。改善版本 3改用 PublishSubject 回推结果使用 SharedFlow 回推结果SharedFlow 内有一队列如欲亮屏后自动推送多种类消息则可将 replay 次数设置为与队列长度一致例如 10class Model : Jetpack-ViewModel() { private val _sharedFlow: MutableSharedFlowViewStates? by lazy { MutableSharedFlow( onBufferOverflow BufferOverflow.DROP_OLDEST, extraBufferCapacity DEFAULT_QUEUE_LENGTH, replay DEFAULT_QUEUE_LENGTH ) } val sharedFlow _sharedFlow.asSharedFlow() companion object { private const val DEFAULT_QUEUE_LENGTH 10 } }由于 replay 会重走设定次数中队列的元素故重走 STARTED 时会重走所有包括已消费和未消费过视觉上给人感觉即控件上旧数据 “一闪而过”这体验并不好改善版本 4通过计数防止重复回推故此处可加个判断 —— 如已消费则下次 replay 时不消费。class Model : class Model : Jetpack-ViewModel() { private var observerCount 0 private val _sharedFlow: MutableSharedFlowViewStates? by lazy { MutableSharedFlow( onBufferOverflow BufferOverflow.DROP_OLDEST, extraBufferCapacity DEFAULT_QUEUE_LENGTH, replay DEFAULT_QUEUE_LENGTH ) } val sharedFlow _sharedFlow.asSharedFlow() companion object { private const val DEFAULT_QUEUE_LENGTH 10 } } data class ConsumeOnceValueE( var consumeCount: Int 0, val value: E ) class View-Controller : Android-Activity() { private val model : Model private val holder : StateHolder fun onCreate(){ lifecycleScope?.launch { repeatOnLifecycle(Lifecycle.State.STARTED) { model.states.collect { if (version currentVersion) { if (model.consumeCount observerCount) returncollect model.consumeCount when(it){ is MainIntent.Download - holder.progress it.progress is MainIntent.Setting - holder.btnChecked it.btnChecked is MainIntent.Info - holder.tvTitle it.title is MainIntent.List - holder.list it.list } } } } } } }但每次创建一页面都需如此写一番繁琐且易出错故可将其内聚统一抽取至单独框架维护MVI-Dispatcher-KTX 应运而生改善版本 5封装和屏蔽样板代码如下通过将 repeatOnLifecycle、计数比对、mutable/immutable 等样板逻辑内聚open class MviDispatcherKTXE : ViewModel(), DefaultLifecycleObserver { private var observerCount 0 private val _sharedFlow: MutableSharedFlowConsumeOnceValueE? by lazy { MutableSharedFlow( onBufferOverflow BufferOverflow.DROP_OLDEST, extraBufferCapacity initQueueMaxLength(), replay initQueueMaxLength() ) } protected open fun initQueueMaxLength(): Int { return DEFAULT_QUEUE_LENGTH } fun output(activity: AppCompatActivity?, observer: (E) - Unit) { observerCount activity?.lifecycle?.addObserver(this) activity?.lifecycleScope?.launch { activity.repeatOnLifecycle(Lifecycle.State.STARTED) { _sharedFlow?.collect { if (it.consumeCount observerCount) returncollect it.consumeCount observer.invoke(it.value) } } } } override fun onDestroy(owner: LifecycleOwner) { super.onDestroy(owner) observerCount-- } protected suspend fun sendResult(event: E) { _sharedFlow?.emit(ConsumeOnceValue(value event)) } fun input(event: E) { viewModelScope.launch { onHandle(event) } } protected open suspend fun onHandle(event: E) {} data class ConsumeOnceValueE( var consumeCount: Int 0, val value: E ) companion object { private const val DEFAULT_QUEUE_LENGTH 10 } }如此开发者哪怕不熟 MVI、mutable只需关注 “input-output” 两处即可自动完成 “单向数据流” 开发,改善版本 6State 和 Event 合与分State 和 Event 什么时候该分什么时候该合为了改善 “副作用”关于 “副作用” 见上期解析通常是传输过程中合并 UiStates 和 UiEvents并在响应时分开处理这也和 “响应式编程” 串流设计不谋而合。对此官方做法是将 UiEvents 整合到 UiStates界面事件 | Android Developers笔者认为此做法相较于 UiStates 和 UiEvents 分开发送的优点在于使 UiEvents 同处于 STATRED 环节响应避免手写遗漏乃至引发 “弹窗无法获取 token” 等情况缺点是需要手动 filterNot 屏蔽已消费事件增加学习成本且埋下手写的一致性隐患。故笔者采取的是另一种办法 —— 将 UiState 整合到 UiEvent响应时再将 UiState 和 UiEvent 解离。也即我们可以采用 PublishSubject 来做观察者并在观察者回调中单独对 UiState 采取 BehaviorSubject比如 ObservableField的方式来通知控件响应和渲染。添加 version 防止订阅回推故此处可再加个 verison 比对open class MviDispatcherKTXE : ViewModel(), DefaultLifecycleObserver { private var version START_VERSION private var currentVersion START_VERSION private var observerCount 0 ... 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) returncollect it.consumeCount observer.invoke(it.value) } } } } } protected suspend fun sendResult(event: E) { version _sharedFlow?.emit(ConsumeOnceValue(value event)) } companion object { private const val DEFAULT_QUEUE_LENGTH 10 private const val START_VERSION -1 } }如此即可从根源上消除 “响应式编程” 的漏洞且无论团队成员是否理解 “响应式编程”都可快速稳定迭代不滋生不可预期问题。class MainPageActivity : Android_Activity(){ private val model : MainPageModel private val views : MainPageViews fun onOutput(){ model.output(this){ intent - when(intent){ MainIntent.Progress - views.progress.set(intent.progress) MainIntent.Weather - views.weatherInfo.set(intent.weather) MainIntent.Error - showErrorDialog() } } model.input(Intent.GetWeather(BEI_JING)) } class MainPageViews : Jetpack_ViewModel() { val progress ObservableBoolean(false) val weatherInfo ObservableFieldString() ... } }三层架构 vs 二层架构换言之上述设计属于三层架构表现层、领域层、数据层也即表现层使用 Jetpack ViewModel 做 StateHolder其中安排各式 ObservableField 作为 BehaviorSubject用于为 State 兜着状态、自动通知控件渲染以及旋屏重建时一对一自动回推。领域层使用 MVI-Dispatcher 做业务处理其中安排一个 PublishSubject 用作唯一出口 output 消息回推。三层架构由于各司其职消息回推环节不使用 BehaviorSubject从而从根源上消除 “响应式编程” 漏洞。且三层架构复用性更佳同一业务的页面皆可共用同一套业务逻辑避免业务逻辑的冗余反之网上流行的二层架构表现层数据层。其中 ViewModel 属于表现层意味着每个页面都要在配套的 ViewModel 书写业务逻辑对于冗余的业务逻辑后续容易发生修改其中一个页面的忘记另一页面的造成代码更新的不一致。注SharedFlow 仅限于 Kotlin 项目如 Java 项目也想用可参考 MVI-Dispatcher 设计其内部维护一队列通过基于 LiveData 改造的 Mutable-Result 亦圆满实现上述功能。综上理论模型皆旨在特定环境下解决特定问题直用于生产环境或存在不可预期问题故我们不断尝试、交流和更新。感谢实事求是测试反馈交流的小伙伴让 MVI-Dispatcher 系框架得以演化至今。GithubMVI-DispatcherGithubMVI-Dispatcher-KTX作者KunMinX链接https://juejin.cn/post/7134594010642907149最后如果想要成为架构师或想突破20~30K薪资范畴那就不要局限在编码业务要会选型、扩展提升编程思维。此外良好的职业规划也很重要学习的习惯很重要但是最重要的还是要能持之以恒任何不能坚持落实的计划都是空谈。如果你没有方向这里给大家分享一套由阿里高级架构师编写的《Android八大模块进阶笔记》帮大家将杂乱、零散、碎片化的知识进行体系化的整理让大家系统而高效地掌握Android开发的各个知识点。相对于我们平时看的碎片化内容这份笔记的知识点更系统化更容易理解和记忆是严格按照知识体系编排的。全套视频资料一、面试合集二、源码解析合集三、开源框架合集欢迎大家一键三连支持若需要文中资料直接点击文末CSDN官方认证微信卡片免费领取↓↓↓
