【Jetpack篇】协程+Retrofit网络请求状态封装实战

在App中，对于网络请求状态一般性的就分为加载中、请求错误、请求成功、请求成功但数据为null。为了用户体验，不同的状态需要对用户展示不同的界面，例如网络异常的提醒，点击重新请求等。

之前项目一直都是以Retrofit+RxJava+OkHttp为网络请求框架，RxJava已经很好的封装了不同的请求状态，onSubscribe、onNext、onError等，只需要在不同的回调中做出相应的动作就ok了。

RxJava很好用，但随着新技术的出现，RxJava的可替代性也就越高。Kotlin的协程就是这么一个存在。

本文是以Jetpack架构为基础，协程+Retrofit+Okhttp为网络请求框架，对不同的请求状态（loading，error，empty等）做了封装，让开发者不用再去关心哪里需要loading，哪里需要展示error提示。

同时，在封装的过程中，Jetpack和协程的使用也存在着几个坑，本文也将一一描述。

协程的基本使用

API：www.wanandroid.com/project/tre… 来自鸿洋大大的wanandroid

如果需要使用协程，则添加依赖

dependencies {
implementation ‘org.jetbrains.kotlinx:kotlinx-coroutines-android:1.3.9’
}

在Retrofit2.6.0前，我们使用协程，api请求后返回的数据可以用Call或者Defeerd包裹处理，2.6后，可以直接返回数据，只不过需要加上suspend的修饰，如下：

interface ProjectApi {

@GET(“project/tree/json”)
suspend fun loadProjectTree(): BaseResp<List>
}

因为使用的是Jetpack架构，所以将整个网络请求主要分为UI、ViewModel、Repository三层，以LiveData为媒介进行通信。

首先是Repository层进行网络请求，

class ProjectRepo{
private lateinit var mService: ProjectApi

init {
mService = RetrofitManager.initRetrofit().getService(ProjectApi::class.java)
}

suspend fun loadProjectTree(): List {
return mService.loadProjectTree()
}
}

利用Retrofit和OkHttp创建了一个apiService，内部细节在这里就先不展开，接着直接调用loadProjectTree()进行网络请求，将数据返回。loadProjectTree()用suspend关键字进行标记，Kotlin 利用此关键字强制从协程内调用函数。

接着ViewModel层，

class ProjectViewModel : ViewModel(){
//LiveData
val mProjectTreeLiveData = MutableLiveData<List>()
fun loadProjectTree() {
viewModelScope.launch(Dispatchers.IO) {
val data = mRepo.loadProjectTree()
mProjectTreeLiveData.postValue(data)
}
}
}

创建类ProjectViewModel并继承ViewModel，内部新建一个LiveData做UI通信使用，利用viewModelScope.launch(Dispatchers.IO) 创建一个新的协程，然后在 I/O 线程上执行网络请求，请求的数据利用LiveData通知给UI。

这里提到了viewModelScope.launch(Dispatchers.IO)，viewModelScope是一个协程的作用域，ViewModel KTX 扩展中已经将此作用域封装好，直接使用就可以。Dispatchers.IO 表示此协程在 I/O线程上执行，而launch则是创建一个新的协程。

最后是UI层，

class ProjectFragment : Fragment {

override fun initData() {
//请求数据，调用loadProjectTree
mViewModel?.loadProjectTree()
mViewModel?.mProjectTreeLiveData?.observe(this, Observer {
//更新UI
})
}

UI层开始调用ViewModel的请求方法执行网络请求，LiveData注册一个观察者，观察数据变化，并且更新UI。

到这里，网络请求的逻辑基本上通顺了。

在一切环境正常的情况下，上面的请求是可以的，但是app还存在网络不畅，异常，数据为null的情况，上述就不在满足要求了，接下来就开始对数据异常的情况进行处理。

网络请求异常处理

对于协程异常的处理，Android开发者的官网上也给出了答案（developer.android.google.cn/kotlin/coro… ） ，直接对网络请求进行一个try-catch处理，发生异常了，直接在catch中做出相应动作就ok了，我们就来看看具体实现。

class ProjectViewModel : ViewModel(){
//LiveData
val mProjectTreeLiveData = MutableLiveData<List>()
fun loadProjectTree() {
viewModelScope.launch(Dispatchers.IO) {
try {
val data = mRepo.loadProjectTree()
mProjectTreeLiveData.postValue(data)
} catch (e: Exception) {
//异常
error(e)
} finally {

}
}
}
}

还是在ViewModel层，对mRepo.loadProjectTree()的请求加上了try-catch块，当发生异常时根据Exception类型对用户做出提示。

到这里，异常的来源已经找到了，接着就需要将异常显示在UI层来提醒用户。我们都知道mProjectTreeLiveData利用PostValue将数据分发给了UI，如法炮制，也就可以利用LiveData将异常也分发给UI。

说干就干。

网络请求状态封装

1、 [Error状态]

依旧在ViewModel层，我们新添加一个针对异常的LiveData：errorLiveData

class ProjectViewModel : ViewModel(){
//异常LiveData
val errorLiveData = MutableLiveData()
//LiveData
val mProjectTreeLiveData = MutableLiveData<List>()
fun loadProjectTree() {
viewModelScope.launch(Dispatchers.IO) {
try {
val data = mRepo.loadProjectTree()
mProjectTreeLiveData.postValue(data)
} catch (e: Exception) {
//异常
error(e)
errorLiveData.postValue(e)
} finally {

}
}
}
}

在UI层，利用errorLiveData注册一个观察者，如果有异常通知，则显示异常的UI（UI层代码省略）。这样确实可以实现我们一开始要的功能：请求成功则显示成功界面，失败显示异常界面。但是有一个问题，就是不够优雅，如果有多个ViewModel，多个UI，那就要每个页面都要写errorLiveData，很冗余。

那我们可以将公共方法抽离出来，新建一个BaseViewModel类,

open class BaseViewModel : ViewModel() {
val errorLiveData = MutableLiveData()

fun launch(
block: suspend () -> Unit,
error: suspend (Throwable) -> Unit,
complete: suspend () -> Unit
) {
viewModelScope.launch(Dispatchers.IO) {
try {
block()
} catch (e: Exception) {
error(e)
} finally {
complete()
}
}
}

}

除了定义errorLiveData外，还将新建协程的操作放到其中，开发者只需要将每个ViewModel继承BaseViewModel，重写launch（）即可，那么上面的案例中的ViewModel就修改成下面这种，

class ProjectViewModel : BaseViewModel(){

//LiveData
val mProjectTreeLiveData = MutableLiveData<List>()
fun loadProjectTree() {
launch(
{
val state = mRepo.loadProjectTree()
mProjectTreeLiveData.postValue(state.data)
},
{
errorLiveData.postValue(it)
},
{
loadingLiveData.postValue(false)
}
)
}
}

同样的，UI层也可以新建一个BaseFragment抽象类，在onViewCreated中利用errorLiveData注册观察者，收到异常通知，则进行相应的动作。

abstract class BaseFragment<T : ViewDataBinding, VM : BaseViewModel> : Fragment(){

override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
super.onViewCreated(view, savedInstanceState)
mViewModel = getViewModel()

mViewModel?.errorLiveData?.observe(viewLifecycleOwner, Observer {
Log.d(TAG, "onViewCreated: error ")
showError()
throwableHandler(it)
})
}
}

每个子Fragment只需要继承BaseFragment即可，具体的异常监听就不用开发者管理。

2、 [Loading状态]

除了异常状态外，请求必不可少的就是Loading，这里Loading分为两种，一种是整个页面替换为Loading，例如Recyclerview列表时，就可以直接整个页面先Loading，而后显示数据；还有一种是数据界面不替换，只是个Loading Dialog显示在上层，例如点击登录时，需要一个loading。

Loading和异常处理的思路一致，可以在BaseViewModel中添加一个LoadingLiveData，数据类型为Boolean，在每个请求一开始LoadingLiveData.postValue(true)，结束请求或者请求异常时，就LoadingLiveData.postValue(false)。UI层BaseFragment中，则可以监听LoadingLiveData发出的是true还是false，以便对Loading的显示和隐藏进行控制。

ViewModel层：

open class BaseViewModel : ViewModel() {
//加载中
val loadingLiveData = SingleLiveData()
//异常
val errorLiveData = SingleLiveData()

fun launch(
block: suspend () -> Unit,
error: suspend (Throwable) -> Unit,
complete: suspend () -> Unit
) {
loadingLiveData.postValue(true)
viewModelScope.launch(Dispatchers.IO) {
try {
block()
} catch (e: Exception) {
Log.d(TAG, "launch: error ")
error(e)
} finally {
complete()
}
}
}
}

在BaseViewModel 中launch一开始就通知Loading显示，在try-catch-finally代码块的finally中将请求结束的通知分发出去。

UI层：

abstract class BaseFragment<T : ViewDataBinding, VM : BaseViewModel> : Fragment(){

override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
super.onViewCreated(view, savedInstanceState)
mViewModel = getViewModel()
//Loading 显示隐藏的监听
mViewModel?.loadingLiveData?.observe(viewLifecycleOwner, Observer {
if (it) {
//show loading
showLoading()
} else {

dismissLoading()
}
})

//请求异常的监听
mViewModel?.errorLiveData?.observe(viewLifecycleOwner, Observer {
Log.d(TAG, "onViewCreated: error ")
showError()
throwableHandler(it)
})
}
}

注册一个loading的观察者，​
当通知为true时，显示loading，false则隐藏。

3、 [Empty状态]

数据为空的状态发生在请求成功后，对于这种情况，可以直接在UI层中，请求成功的监听中对数据是否为null进行判断。

到这里，网络请求的基本封装已经完成，但是在运行测试的过程中，存在几个问题需要去解决，例如网络不通的情况下try-catch却不会抛出异常。接下来就开始进行二次封装。

暴露问题二次封装

问题一：网络请求异常，try-catch却不会将异常抛出

因为业务场景比较复杂，只依赖try-catch来获取异常，明显也会有所遗漏，那这种情况下我们可以直接以服务器返回的code，作为请求状态的依据。以上面Wanandroid的api为例，当errorCode=0时，则表示请求成功，其他的值都表示失败，那这就好办了。

我们新建一个密封类ResState，存放Success和Error状态，

sealed class ResState {
data class Success(val data: T) : ResState()
data class Error(val exception: Exception) : ResState()
}

对Repository层请求返回的数据进行code判断处理，新建一个BaseRepository类，

open class BaseRepository() {

suspend fun executeResp(
resp: BaseResp, successBlock: (suspend CoroutineScope.() -> Unit)? = null,
errorBlock: (suspend CoroutineScope.() -> Unit)? = null
): ResState {
return coroutineScope {
if (resp.errorCode == 0) {
successBlock?.let { it() }
ResState.Success(resp.data)
} else {
Log.d(TAG, “executeResp: error”)

最后

小编这些年深知大多数初中级Android工程师，想要提升自己，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。

因此我收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人

都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

资料⬅专栏获取
Log.d(TAG, “executeResp: error”)

最后

小编这些年深知大多数初中级Android工程师，想要提升自己，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。

因此我收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

[外链图片转存中…(img-iZmBd37E-1719095025083)]一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人

都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

资料⬅专栏获取