今天知道LiveData的ktx是真的香
主要还是认知问题，Android 官网从一开始就在推ktx，现在都已经2.+ 版本了，但是呢，因为之前没有从0开始写过一个Kotlin的APP，就陷入了一个JAVA 思维，在JAVA 中我们知道要做到像协程这么处理不是不能，只是过于复杂，一般水平的人根本驾驭不住，恰巧，我根本不敢想。也就导致了一个问题，ktx 这个界面路过了无数次，今天终于看到了TA。
什么痛点？
写过界面base 的同学可能有经验，如果是说，想要在viewModel 创建的时候，就开始进行异步进行网络请求，除了要处理构造函数传递进来的入参，还有要处理viewModel的Factory，就是说，viewModel想要通过构造函数传参，Factory 的重写成自己的，但是我们又没法确定后续的viewModel的构造是啥，init执行的时候，属性变量都还没有赋值，所以在init 里面写，逻辑就根本行不通，就只能在Lifecycle里面写，当生命周期到什么时候，就主动调用这个viewModel规范好的内容，然后通过liveData 和泛型把数据抛给用户层。
上面是理想情况，现实情况并不是这个样子的，因为有些界面接口请求并不是一个，可能是多个请求顺序执行，而且，每个人都有自己的想法，嗯，我们通常的认为别人可以理解自己的想法，所以，base是不写注释，所以写了别人不用还说写的垃圾，为了更贴合大众实际思路，我们可能提供几个函数：
fun observe()
fun initView(savedInstanceState: Bundle?)
fun initData()
然后再 initData 里面自己写网络请求。这就很烦人，经常搬砖的同学都知道，一个界面就一个网络请求是常态，但是他不是必然因素，每个界面都要自己写initData，我写多了也骂自己垃圾，为啥不封装一下，当然更多的时候是骂包这个玩意的人。
如何解决这个痛点
既然kotlin的扩展函数这么强大能不能自己包装一个什么东西，比如我们是通过liveData 进行数据监听，我们创建LiveData 的时候，就在协程里面请求数据，然后发送出去，这个时候，构造函数也执行完了，也不担心init 执行的时候 属性变量没有赋值的问题，所以就开整：
val pageData = getNetLiveData()
fun getNetLiveData(): LiveData {
val live = MutableLiveData()
viewModelScope.launch(Dispatchers.IO) {
val params = mutableMapOf()
params.put("keywords", "")
val json = OkHttpImpl.postSting(
"这是网络请求地址",
params
)
live.postValue(json)
}
return live
}
思路是，我们pageData 的对象通过函数getNetLiveData 创建，然后在函数getNetLiveData 里面直接创建一个协程 请求网络，请求成功了，把数据抛出去，这只是基础概念，我们还可以抽离成泛型，抽离一个作用域函数啥的。
ktx 如何解决这个问题
当完成泛型抽离，想做作用域抽离的时候，灵光一闪，这玩意我见过。
val user: LiveData = liveData {
emit(Result.loading())
try {
emit(Result.success(fetchUser()))
} catch(ioException: Exception) {
emit(Result.error(ioException))
}
}
这ktx 已经提供好了好吧。那么就直接用就行。直接在 mvnrepository liveData-ktx 最小版本，导入使用即可。
implementation("androidx.lifecycle:lifecycle-livedata-ktx:2.6.2")
例如这样：
val liveData: LiveData = liveData(Dispatchers.IO) {
val params = mutableMapOf()
params.put("keywords", "")
val json = OkHttpImpl.postSting(
"https://..........",
params
)
emit(json)
}
如何解决刷新
那么如何做到刷新呢？我们界面通常是有刷新的对吧，我们总不能刷新的时候重新创建 liveData 然后重新设置监听吧。 所以我们需要正确的抽离业务逻辑。我们知道MutableLiveData可以通过setValue 或者post 发送多次消息，而LiveData 这个类因为函数是私有的，所以说，这个玩意并不能被外部调用。我们看下 liveData{} 函数的实现：
public fun liveData(
context: CoroutineContext = EmptyCoroutineContext,
timeoutInMs: Long = DEFAULT_TIMEOUT,
block: suspend LiveDataScope.() -> Unit
): LiveData = CoroutineLiveData(context, timeoutInMs, block)
CoroutineLiveData的实现：
internal class CoroutineLiveData(
context: CoroutineContext = EmptyCoroutineContext,
timeoutInMs: Long = DEFAULT_TIMEOUT,
block: Block
) : MediatorLiveData()
OK，到这里，基本就清晰了，但是还是贴一下：
public class MediatorLiveData extends MutableLiveData {}
所以说，liveData{} 这个函数返回的其实是MediatorLiveData 对象，如果不熟悉这个玩意，但是MediatorLiveData的父类MutableLiveData是熟悉的。
代码看到这里，我们需要刷新的逻辑就非常清晰了，我们将liveData{} 函数的返回参数 通过as 转化为 MediatorLiveData或MutableLiveData即可。MediatorLiveData是用于监听多个值得变化的，用的比较少，比如说，用于多接口并发请求，统一返回，比如说类型转化，服务器数据模型与本地数据模型不一致的情况，再比如说监听界面变化等。我们这里直接就强制转换为 MutableLiveData：
val livedataKtx= liveData {
emit("luoye")
} as MutableLiveData
在刷新的时候：
fun refresh(){
livedataKtx.value="luoye"
}
使用KTX 库的好处还是非常明显的，比如我们不需要自己写协程切换，当然自己扩展函数抽离得好，也不是不行。
最后
其实，LiveData 要写，还是有很多知识点可以写的，但是这里只是进行了简单的逻辑的概述吧。我们通过属性变量的创建时机去进行接口请求或者缓存请求，那么在一定程度上是要比调用initData 更快的，而且这种逻辑非常清晰，我们将首次和刷新从逻辑层分离出来，这种代码看起来还是非常简洁的。
在这个逻辑上，我们可以发现compose 的中的界面数据，通过这种方式的刷新，反而更加的贴合吧。当然通过Flow,或者channel 等方式 转LiveData 也是一种思路，但是在简单的界面请求中，感觉没有必要。
Android 学习笔录
Android 性能优化篇：https://qr18.cn/FVlo89
Android Framework底层原理篇：https://qr18.cn/AQpN4J
Android 车载篇：https://qr18.cn/F05ZCM
Android 逆向安全学习笔记：https://qr18.cn/CQ5TcL
Android 音视频篇：https://qr18.cn/Ei3VPD
Jetpack全家桶篇（内含Compose）：https://qr18.cn/A0gajp
OkHttp 源码解析笔记：https://qr18.cn/Cw0pBD
Kotlin 篇：https://qr18.cn/CdjtAF
Gradle 篇：https://qr18.cn/DzrmMB
Flutter 篇：https://qr18.cn/DIvKma
Android 八大知识体：https://qr18.cn/CyxarU
Android 核心笔记：https://qr21.cn/CaZQLo
Android 往年面试题锦：https://qr18.cn/CKV8OZ
2023年最新Android 面试题集：https://qr18.cn/CgxrRy
Android 车载开发岗位面试习题：https://qr18.cn/FTlyCJ
音视频面试题锦：https://qr18.cn/AcV6Ap