Retorfit + 协程机制 + MVVM
协程是一种解决方案,是一种解决嵌套,并发、弱化线程概念的方案。能让多个任务之间更好的协作,能够以同步的方式编排代码完成异步工作,将异步代码写的像同步代码一样直观。
重点
协程的本质是方法的挂起与恢复:return + callback
- 协程是什么:
协程是可以由程序自行控制挂起、恢复的程序
协程可以实现多任务的协作执行
协程可以用来解决异步任务控制流的灵活转移
- 协程的作用:
协程可以让异步代码同步化
协程可以降低异步程序的设计复杂度
协程本身不能让代码异步,只是让异步代码更简单控制流程
总结一句话:协程就是将程序进行挂起和恢复,解决异步回调让异步代码同步化。
什么是协程
Kotlin 协程的标准库:kotlinx-coroutines-core
它是协程的框架层的,而kotlin本身带有协程的基础层,要是用协程框架层封装需要引入依赖库,才能使用协程的框架层。
implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-core:1.4.2'
复制代码
常见的异步回调: 在enqueue中创建回调实例接受回调
retrofit.create(GitHubService::class.java).listRepos("octocat")
.enqueue(object : Callback<List<Repo>> {
override fun onResponse(call: Call<List<Repo>>, response: Response<List<Repo>>) {
println("retrofit:" + response.body()?.size)
}
override fun onFailure(call: Call<List<Repo>>, t: Throwable) {
TODO("Not yet implemented")
}
})
经过协程改造的异步程序:
- 在函数前面加上
suspend
定义为挂起函数,在retrofit 2.6以上的版本就已经支持协程了
/**
* kotlin 协程
*/
@GET("users/{user}/repos")
suspend fun listReposKx(@Path("user") user: String?): List<Repo>
- 协程的方式请求网络,将异步代码写成同步代码更加简单化
执行结果:
协程函数的挂起需要有一个
CoroutineScope
的空间,函数挂起并不会影响CoroutineScope
独立空间之外的代码执行,非阻塞式的挂起。
注意:通过suspend
修饰的挂起函数只能被挂起函数或协程调用。
协程运行:遇到挂起函数listReposKx
在线程2中执行,执行完毕后返回结果继续执行。挂起和恢复
协程和线程的区别:
线程Thread:指操作系统的线程,内核线程
协程Coroutines: 指语言实现的协程,运行在内核线程之上的
协程的基本要素
Kotlin的协程分为两层:
- 基础设施层:标准库的协程API,主要对协程提供了概念和语义上最基本的支持
- 业务框架层: 协程的上层框架支持
在上述代码中GlobalScope.launch
其实是业务框架层的实现。如果抛去框架层的封装,kotlin提供的基础层是如何实现协程的?这就需要了解协程的基本要素
如下代码:就是kotlin协程的基础层API包括:suspend挂起函数、Continuation、createCoroutine创建协程、startCoroutine启动协程、CoroutinContext协程上下文。这五个就是协程的基本要素
挂起函数suspend
挂起点: suspend修饰的函数,只能在其他挂起函数或者协程中调用。
挂起函数调用时包含了协程的“挂起”的语义,而挂起函数返回时则包含了协程的“恢复”语义。
挂起和恢复主要通过:Continuation
来实现,如下代码在service中添加的suspend函数反编译后的结果,在挂起函数中多了一个参数Continuation
。
其实在上述的createCoroutine
中传递了一个Continuation
实例,而Continuation
主要的作用就是执行挂起函数“恢复”后的代码并且得到挂起函数的返回值作为参数返回。
如何将异步回调通过挂起函数的改造呢?其实就是retrofit
中是如何处理suspend
函数的,通过kotlin的基础层API代码如下:通过suspendCoroutine
来实现挂起函数,在通过Continuation
返回异步回调请求的结果
在Retrofit
中的实现其实是一样的原理,Retrofit
通过对Call
进行了扩展方法处理,在Service API 的suspend
方法的基础上又调用了Retrofit
自己写的suspend
函数
其实对于常见的框架层的封装例如xxxScope.launch
:就是基于kotlin的基础层的API进行实现
协程上下文
在协程上下文(CoroutineContext)中存在着拦截器
ContinuationInterceptor
是一类协程上下文元素,可以对协程上下文所在协程的Continuation
进行拦截,可以实现切换线程。
协程上下文包含一个 协程调度器 (参见 CoroutineDispatcher)它确定了相关的协程在哪个线程或哪些线程上执行。协程调度器可以将协程限制在一个特定的线程执行,或将它分派到一个线程池,亦或是让它不受限地运行。
所有的协程构建器诸如 launch 和 async 接收一个可选的 CoroutineContext 参数,它可以被用来显式的为一个新协程或其它上下文元素指定一个调度器。
协程框架在Android上的应用
Kotlin 的框架层基于基础层进行的封装:
kotlinx-coroutines
Kotlin 提供了协程框架的基础库以及协程Android库
//kotlin 标准库-提供了协程的基础层
implementation "org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version"
def coroutines_version = "1.4.2"
//kotlin协程依赖库
implementation "org.jetbrains.kotlinx:kotlinx-coroutines-core:$coroutines_version"
//协程Android库,提供AndroidUI调度器
implementation "org.jetbrains.kotlinx:kotlinx-coroutines-android:$coroutines_version"
和协程相关的一些扩展库
官方文档中都有讲解这里不在复述了,重点讲解协程在Android中的应用。
- Job: 协程的启动模式
- 调度器:协程的线程调度(将协程在特有的线程或者线程池中执行)
- 作用域:协程的作用域(在Android中常见的:lifecycleScope viewmodelScope)
- Channel:“热”数据流,并发安全的通信机制(不去订阅也会发数据)
- Flow:“冷”数据流,协程的响应式API(和RxJava类似,只有订阅了才会发送数据)
- Select:可以对多个挂起事件进行等待
协程简化Dialog
创建Dialog的挂起函数给Context
扩展alert方法如下代码:
通过
suspendCancellableCoroutine
创建挂起函数,将异步流程同步化
通过协程来调用挂起函数:
lifecycleScope 和Activity/Fragment的生命周期绑定,可以直接拿到弹窗点击的结果进行处理
val show_dialog = findViewById<Button>(R.id.show_dialog)
show_dialog.setOnClickListener {
lifecycleScope.launch {
//Activity生命周期的协程
val myCheck = alert("警告", "Do You Want is?")
Log.e("TAG", "onCreate: $myCheck")
}
}
简化Handler的调用
Handler.post的异步调用
调用方式如下:
lifecycleScope.launch {
val handler = Handler(Looper.getMainLooper())
val h1 = handler.run { "test"}
Log.e("TAG", "onCreate: $h1") // test
val h2 = handler.runDelay(1000) { "delay" }
Log.e("TAG", "onCreate: $h2") // delay
}
协程:可以将所有的异步调用简化为同步调用的解决方案。
Job 启动模式
调度器
Retrofit+协程配合LiveData的封装原理
协程只是为了解决异步调用问题而存在的,Retrofit中内部已经将异步问题通过协程解决了,协程更多的是通过和LiveData和ViewModel结合再次简化封装部分业务逻辑。
需要引入的依赖库:
在解析josn的converter,kotlin推荐的moshi,可以调研调研。
//retrofit
api rootProject.depsLibs.retrofit
api rootProject.depsLibs.logging_interceptor
api rootProject.depsLibs.converter_gson
//协程相关
def coroutines_version = "1.4.2"
//kotlin协程依赖库
api "org.jetbrains.kotlinx:kotlinx-coroutines-core:$coroutines_version"
//协程Android库,提供AndroidUI调度器
api "org.jetbrains.kotlinx:kotlinx-coroutines-android:$coroutines_version"
api "androidx.core:core-ktx:1.3.2"
api "androidx.lifecycle:lifecycle-livedata-ktx:2.3.1"
api "androidx.lifecycle:lifecycle-livedata-core-ktx:2.3.1"
网络请求的生命周期管理由下面依赖库进行管理
lifecycleScope 来定义Activity/Fragment的生命周期管理的协程运行网络请求的挂起函数或者通过viewModelScope 的生命周期协程来管理网络请求的挂起函数(推荐)。
注意:Lifecycle 和 ViewModel的是不同的,ViewModel可以当屏幕发生旋转后继续存在。
关于Lifecycle和ViewModel的本质讲解看这里:
ViewModel 如何对视图状态管理
LiveData 如何安全观察数据
api "androidx.lifecycle:lifecycle-runtime-ktx:2.3.1"
api "androidx.lifecycle:lifecycle-viewmodel-ktx:2.3.1"
框架层设计
NetWorkManager
是网络框架的入口类,API设计:
网络请求返回数据结构设计:
**ResultData **
作为最终返回的数据结构类.**ResponseBean**
作为JSON的基础数据结构
通过Kotlin的密封类,用于区分网络状态,具体设计ApiResonse
主要包括网络异常状态、空数据状态、成功状态、业务错误状态。(对于code的业务错误状态.需要根据上述的错误处理器进行设置)ApiResponse
通过静态方法进行构建不同状态的返回数据
有两种create构建方法,第一个是捕捉到的网络请求系统异常,第二个
create
首先判断是否是成功的状态码,如果不是返回ApiAppErrorResponse
业务状态异常,data
为空表示返回空数据返回空数据下的状态,否则返回成功下的状态
核心类:RequestAction
通过kotlin的DSL包装网络请求动作
- api: 传递的就是Retrofit的Service中定义的suspend 挂起函数
- loadCache : 传递的就是加载缓存数据的函数
- saveCache:传递的是实现缓存数据的函数
注意:这几个关键的方法都是传递DSL包装的函数
例如这样的调用方式:代码看起来会非常舒服
@GET("users/{user}/repos")
suspend fun getJson2(@Path("user") user: String): ResponseBean<List<Repo>>
private val netApi = NetWorkManager.instance.create(Service::class.java)
val requestLiveData = viewModelScope.requestLiveData<List<Repo>> {
//请求网络
api { netApi.getJson2(name) }
//加载数据库缓存
loadCache {
//数据库请求,将结果返回给liveData中
_databaseLiveData
}
//将数据保存到数据库
saveCache {
//向数据库中保存数据
Log.e("TAG", "getRepo: ${it.size}")
}
}
下面就是通过协程来进行整合Retrofit+LiveData
CoroutineScope
是所有协程作用域的父类,对其进行扩展一个函数requestLiveData
,liveData 是扩展依赖库提供的使其可以在LiveDataScope
中运行挂起函数emit
以及api.invoke
都是挂起函数
异常处理设计
统一异常类:统一使用ResponseThrowable作为网络请求的所有异常类
IExceptionHandler
作为将异常转换为ResponseThrowable
的实现,appSuccessCode
用来定义业务层的成功码,非成功码下的都是业务异常,其他情况为系统异常
IAdapterHandler
用来处理 IExceptionHandler
转换的ResponseThrowable
异常
NetManager 的API
- 初始化设置
- 全局下异常处理的实现类如下,通过转换后的
ResponseThrowable
中的code
判断处于哪个异常情况
- 将异常转换为ResponseThrowable
框架层默认实现了:
DefaultExceptionHandler
如果不设置addExceptionHandler会使用默认的异常转换类
- MVVM 架构模式下在
ViewModel
中实现网络请求,外部通过repoLiveData
监听数据,这里_repoLiveData
使用MediaorLiveData
只能监听数据变化不能改变数据,为了防止外部改变数据导致不可预期的错误
- View层实现监听网络数据
监听到的数据都是在框架层定义好的
ResultData
直接拿到状态等信息,注意在Error
状态下所有的异常在框架层已经全部转换为了ResponseThrowable
通过自定义异常中的code来判断具体的异常情况
作者:JakePrim
链接:https://juejin.cn/post/7003177634620243981
来源:掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。