今天知道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是不写注释，所以写了别人不用还说写的垃圾，为了更贴合大众实际思路，我们可能提供几个函数：

kotlin 复制代码

fun observe()
fun initView(savedInstanceState: Bundle?)
fun initData()

然后再 initData 里面自己写网络请求。这就很烦人，经常搬砖的同学都知道，一个界面就一个网络请求是常态，但是他不是必然因素，每个界面都要自己写initData，我写多了也骂自己垃圾，为啥不封装一下，当然更多的时候是骂包这个玩意的人。

如何解决这个痛点

既然kotlin的扩展函数这么强大能不能自己包装一个什么东西，比如我们是通过liveData 进行数据监听，我们创建LiveData 的时候，就在协程里面请求数据，然后发送出去，这个时候，构造函数也执行完了，也不担心init 执行的时候属性变量没有赋值的问题，所以就开整：

kotlin 复制代码

val pageData = getNetLiveData()
fun  getNetLiveData(): LiveData<String> {
    val live = MutableLiveData<String>()
    viewModelScope.launch(Dispatchers.IO) {
        val params = mutableMapOf<String, String>()
        params.put("keywords", "")
        val json = OkHttpImpl.postSting(
            "这是网络请求地址",
            params
        )
        live.postValue(json)
    }
    return live
}

思路是，我们pageData 的对象通过函数getNetLiveData 创建，然后在函数getNetLiveData 里面直接创建一个协程请求网络，请求成功了，把数据抛出去，这只是基础概念，我们还可以抽离成泛型，抽离一个作用域函数啥的。

ktx 如何解决这个问题

当完成泛型抽离，想做作用域抽离的时候，灵光一闪，这玩意我见过。Google 官网将kotlin协程与liveData 结合使用

scss 复制代码

val user: LiveData<Result> = liveData {
    emit(Result.loading())
    try {
        emit(Result.success(fetchUser()))
    } catch(ioException: Exception) {
        emit(Result.error(ioException))
    }
}

这ktx 已经提供好了好吧。那么就直接用就行。直接在 mvnrepository liveData-ktx 最小版本，导入使用即可。

scss 复制代码

implementation("androidx.lifecycle:lifecycle-livedata-ktx:2.6.2")

例如这样：

javascript 复制代码

val liveData: LiveData<String> = liveData(Dispatchers.IO) {
    val params = mutableMapOf<String, String>()
    params.put("keywords", "")
    val json = OkHttpImpl.postSting(
        "https://..........",
        params
    )
    emit(json)
}

如何解决刷新

那么如何做到刷新呢？我们界面通常是有刷新的对吧，我们总不能刷新的时候重新创建 liveData 然后重新设置监听吧。所以我们需要正确的抽离业务逻辑。我们知道MutableLiveData可以通过setValue 或者post 发送多次消息，而LiveData 这个类因为函数是私有的，所以说，这个玩意并不能被外部调用。我们看下 liveData{} 函数的实现：

kotlin 复制代码

public fun <T> liveData(
    context: CoroutineContext = EmptyCoroutineContext,
    timeoutInMs: Long = DEFAULT_TIMEOUT,
    block: suspend LiveDataScope<T>.() -> Unit
): LiveData<T> = CoroutineLiveData(context, timeoutInMs, block)

CoroutineLiveData的实现：

csharp 复制代码

internal class CoroutineLiveData<T>(
    context: CoroutineContext = EmptyCoroutineContext,
    timeoutInMs: Long = DEFAULT_TIMEOUT,
    block: Block<T>
) : MediatorLiveData<T>()

OK，到这里，基本就清晰了，但是还是贴一下：

scala 复制代码

public class MediatorLiveData<T> extends MutableLiveData<T> {}

所以说，liveData{} 这个函数返回的其实是MediatorLiveData 对象，如果不熟悉这个玩意，但是MediatorLiveData的父类MutableLiveData是熟悉的。

代码看到这里，我们需要刷新的逻辑就非常清晰了，我们将liveData{} 函数的返回参数通过as 转化为 MediatorLiveData或MutableLiveData即可。MediatorLiveData是用于监听多个值得变化的，用的比较少，比如说，用于多接口并发请求，统一返回，比如说类型转化，服务器数据模型与本地数据模型不一致的情况，再比如说监听界面变化等。我们这里直接就强制转换为 MutableLiveData：

javascript 复制代码

val livedataKtx= liveData<String> {
    emit("luoye")
} as MutableLiveData<String>

在刷新的时候：

kotlin 复制代码

fun refresh(){
    livedataKtx.value="luoye"
}

使用KTX 库的好处还是非常明显的，比如我们不需要自己写协程切换，当然自己扩展函数抽离得好，也不是不行。

最后

其实，LiveData 要写，还是有很多知识点可以写的，但是这里只是进行了简单的逻辑的概述吧。我们通过属性变量的创建时机去进行接口请求或者缓存请求，那么在一定程度上是要比调用initData 更快的，而且这种逻辑非常清晰，我们将首次和刷新从逻辑层分离出来，这种代码看起来还是非常简洁的。

在这个逻辑上，我们可以发现compose 的中的界面数据，通过这种方式的刷新，反而更加的贴合吧。当然通过Flow,或者channel 等方式转LiveData 也是一种思路，但是在简单的界面请求中，感觉没有必要。