FirebaseRemoteConfig扩展函数中LiveData参数与返回值的差异及选型
两种FirebaseRemoteConfig LiveData扩展写法的对比与选择
我在ViewModel中创建函数以避免使用Flow和LiveData时的代码重复,为此编写了如下两个FirebaseRemoteConfig扩展函数。纠结于将LiveData作为参数传入和作为返回值返回这两种写法的差异,想请教哪种更合理?
写法1:传入MutableLiveData作为参数
inline fun <reified T> FirebaseRemoteConfig.fetchToLiveData( key: String, gson: Gson, liveData: MutableLiveData<T> ) { this.fetchAndActivate().addOnCompleteListener { if (it.isSuccessful) { val keyString = this.getString(key) val type = object : TypeToken<T>() {}.type val jsonModel = gson.fromJson<T>(keyString, type) liveData.postValue(jsonModel) } } }
写法2:返回LiveData实例
inline fun <reified T> FirebaseRemoteConfig.fetchToLiveData( key: String, gson: Gson ): LiveData<T> { val liveData = MutableLiveData<T>() this.fetchAndActivate().addOnCompleteListener { if (it.isSuccessful) { val keyString = this.getString(key) val type = object : TypeToken<T>() {}.type val jsonModel = gson.fromJson<T>(keyString, type) liveData.postValue(jsonModel) } } return liveData }
两种写法的核心差异分析
- 写法1的问题:
- 调用方需要自行创建
MutableLiveData并传入,函数仅负责更新值,控制权分散,容易出现调用方误修改LiveData值的情况,打破数据单向流动的原则。 - 如果多次调用该函数时传入不同的LiveData实例,会导致多个独立的观察者,增加不必要的资源消耗和状态管理复杂度。
- 调用方需要自行创建
- 写法2的优势:
- 封装性更强:函数内部创建
MutableLiveData,对外仅返回不可变的LiveData,确保只有函数内部能更新数据,调用方只能观察,符合LiveData的设计初衷。 - 调用更简洁:不需要提前初始化LiveData,直接获取返回实例即可,代码更清爽。
- 避免外部干扰:外部无法修改返回的LiveData,保证了数据来源的单一性,降低了bug发生的概率。
- 封装性更强:函数内部创建
结论
优先选择写法2,它更贴合LiveData的设计模式,在状态管理上更安全、可控。写法1仅适合少数需要复用已有LiveData实例的特殊场景,但这种场景在日常开发中非常少见,不推荐作为常规写法。
内容的提问来源于stack exchange,提问作者Askeri Mühendis
相关产品推荐
相关产品推荐

