这周在重构一个 Android 平板蓝牙控制的 App，之前为了赶工期，代码写的比较乱， 正好这段时间赶上多个客户的定制要求，发现要一套代码实现多套差异化的需求，如果代码不好好规整根本改不动。
自己欠的技术债，总归是要还的。
在改造的过程中，发现之前使用 LiveData 的方式有不少问题，总结一下：
逻辑不要放在 Fragment 中
能在 ViewModel 中处理的，尽量在 ViewModel 中处理。
Activity / Fragment 尽量只监听 LiveData, 然后直接显示，不做任何复杂的逻辑判断。
集中在 ViewModel 处理，逻辑更清晰。
- 多个 Fragment 都有逻辑处理，会导致代码分散，不容易排查
- 同一个状态影响到多个 LiveData，如果不在 ViewModel 中统一处理，也会出现逻辑分散到各处。
相关的状态放到一个 LiveData 中
例如倒计时的分、秒，可以放到一个 data class 中。
避免，秒数先变化，而分没有变。
data class LeftTime(var minute: String, var second: String)
val leftTime = MutableLiveData<LeftTime>()
leftTime.postValue(LeftTime(leftMinuteText, leftSecondText))
标准 snippet
viewModel.someStatus.observe(viewLifecycleOwner) {
if (it == true) {
// do something
}
}
可以先用 android studio 的自动补全，参数填写 this，再按照提示自动修改为 viewLifecycleOwner。
这里的 viewLifecycleOwner 即 getViewLifecycleOwner:
Get a LifecycleOwner that represents the Fragment's View lifecycle. In most cases, this mirrors the lifecycle of the Fragment itself, but in cases of detached Fragments, the lifecycle of the Fragment can be considerably longer than the lifecycle of the View itself.
旧式写法：
viewModel.someStatus.observe(
viewLifecycleOwner, Observer {
it?.let {
// do something
}
}
)
微信关注我哦 👍
我是来自山东烟台的一名开发者，有感兴趣的话题，或者软件开发需求，欢迎加微信 zhongwei 聊聊， 查看更多联系方式