【思货】kotlin协程优雅的与Retrofit缠绵-正文

时间 2019-11-06

标签思货 kotlin 优雅 retrofit 缠绵正文繁體版

原文原文链接

Kotlin已经成为Android开发的Google第一推荐语言，项目中也已经使用了很长时间的kotlin了，加上Kotlin1.3的发布，kotlin协程也已经稳定了，不免会有一些本身的思考。java

对于项目中的网络请求功能，咱们也在不停的反思，如何将其写的优雅、简洁、快速、安全。相信这也是各位开发者在不停思考的问题。因为咱们的项目都是使用的Retrofit做为网络库，因此，全部的思考都是基于Retrofit展开的。android

本篇文章中将会从个人思考进化历程开始讲起。涉及到Kotlin的协程、扩展方法、DSL，没有基础的小伙伴，先去了解这三样东西，本篇文章再也不进行讲解。 DSL能够看看我写这篇简介git

在网络请求中，咱们须要关注的隐式问题就是：页面生命周期的绑定，关闭页面后须要关闭未完成的网络请求。为此，各位前辈，是八仙过海、各显神通。我也是从学习、模仿前辈，到自我理解的转变。github

1. Callback

在最初的学习使用中，Callback异步方法是Retrofit最基本的使用方式，以下：数据库

接口：编程

interface DemoService {

    @POST("oauth/login")
    @FormUrlEncoded
    fun login(@Field("name") name: String, @Field("pwd") pwd: String): Call<String>
}
复制代码

使用：api

val retrofit = Retrofit.Builder()
    .baseUrl("https://baidu.com")
    .client(okHttpClient.build())
    .build()

val api = retrofit.create(DemoService::class.java)
val loginService = api.login("1", "1")
loginService.enqueue(object : Callback<String> {
    override fun onFailure(call: Call<String>, t: Throwable) {

    }

    override fun onResponse(call: Call<String>, response: Response<String>) {

    }
})
复制代码

这里再也不细说。缓存

在关闭网络请求的时候，须要在onDestroy中调用cancel方法：安全

override fun onDestroy() {
    super.onDestroy()
    loginService.cancel()
}
复制代码

这种方式，容易致使忘记调用cancel方法，并且网络操做和关闭请求的操做是分开的，不利于管理。服务器

这固然不是优雅的方法。随着Rx的火爆，咱们项目的网络请求方式，也逐渐转为了Rx的方式

2. RxJava

此种使用方式，百度一下，处处都是教程讲解，可见此种方式起码是你们较为承认的一种方案。

在Rx的使用中，咱们也尝试了各类各样的封装方式，例如自定义Subscriber，将onNext、onCompleted、onError进行拆分组合，知足不一样的需求。

首先在Retrofit里添加Rx转换器RxJava2CallAdapterFactory.create()：

addCallAdapterFactory(RxJava2CallAdapterFactory.create())
复制代码

RxJava的使用方式大致以下，先将接口的Call改成Observable：

interface DemoService {

    @POST("oauth/login")
    @FormUrlEncoded
    fun login(@Field("name") name: String, @Field("pwd") pwd: String): Observable<String>
}
复制代码

使用：（配合RxAndroid绑定声明周期）

api.login("1","1")
    .subscribeOn(Schedulers.io())
    .observeOn(AndroidSchedulers.mainThread()) //RxAndroid
    .subscribe(object :Observer<String> {
        override fun onSubscribe(d: Disposable) {

        }

        override fun onComplete() {

        }

        override fun onNext(t: String) {

        }

        override fun onError(e: Throwable) {
        }
    })
复制代码

这种使用方式确实方便了很多，响应式编程的思想也很优秀，一切皆为事件流。经过RxAndroid来切换UI线程和绑定页面生命周期，在页面关闭的时候，自动切断向下传递的事件流。

RxJava最大的风险即在于内存泄露，而RxAndroid确实规避了必定的泄露风险。而且经过查看RxJava2CallAdapterFactory的源码，发现也确实调用了cancel方法，嗯……貌似不错呢。但老是以为RxJava过于庞大，有些大材小用。

3. LiveData

随着项目的的推动和Google全家桶的发布。一个轻量化版本的RxJava进入到了咱们视线，那就是LiveData，LiveData借鉴了不少RxJava的的设计思想，也是属于响应式编程的范畴。LiveData的最大优点即在于响应Acitivty的生命周期，不用像RxJava再去绑定声明周期。

一样的，咱们首先须要添加LiveDataCallAdapterFactory （连接里是google官方提供的写法，可直接拷贝到项目中），用于把retrofit的Callback转换为LiveData：

addCallAdapterFactory(LiveDataCallAdapterFactory.create())
复制代码

接口改成：

interface DemoService {

    @POST("oauth/login")
    @FormUrlEncoded
    fun login(@Field("name") name: String, @Field("pwd") pwd: String): LiveData<String>
}
复制代码

调用：

api.login("1", "1").observe(this, Observer {string ->
    
})
复制代码

以上就是最基础的使用方式，在项目中使用时候，一般会自定义Observer，用来将各类数据进行区分。

在上面调用的observe方法中，咱们传递了一个this，这个this指的是声明周期，通常咱们在AppCompatActivity中使用时，直接传递其自己就能够了。

下面简单跳转源码进行说明下。经过查看源码能够发现：

public void observe(@NonNull LifecycleOwner owner, @NonNull Observer<T> observer) 复制代码

其this自己是传递的LifecycleOwner。

那么咱们在一层层跳转AppCompatActivity，会发现AppCompatActivity是继承于SupportActivity的父类：

public class SupportActivity extends Activity implements LifecycleOwner, Component 复制代码

其自己对LifecycleOwner接口进行了实现。也就是说，除非特殊要求，通常咱们只须要传递其自己就能够了。LiveData会自动处理数据流的监听和解除绑定。

一般来讲：在onCreate中对数据进行一次性的绑定，后面就不须要再次绑定了。

当生命周期走到onStart和onResume的时候，LiveData会自动接收事件流；

当页面处于不活动的时候，将会暂停接收事件流，页面恢复时恢复数据接收。（例如A跳转到B，那么A将会暂停接收。当从B回到A之后，将恢复数据流接收）

当页面onDestroy时候，会自动删除观察者，从而中断事件流。

能够看出LiveData做为官方套件，使用简单，生命周期的响应也是很智能的，通常都不须要额外处理了。

（更高级的用法，能够参考官方Demo，能够对数据库缓存等待都进行一整套的响应式封装，很是nice。建议学习下官方的封装思想，就算不用，也是对本身大有裨益）

4. Kotlin协程

上面说了那么多，这里步入了正题。你们仔细观察下会发现，上面均是使用的Retrofit的enqueue异步方法，再使用Callback进行的网络回调，就算是RxJava和Livedata的转换器，内部其实也是使用的Callback。在此以前，Retrofit的做者也写了一个协程的转换器，地址在这，但内部依然使用的是Callback，本质均为同样。（目前该库才被废弃，其实我也以为这样使用协程就没意义了，Retrofit在最新的2.6.0版本，直接支持了kotlin协程的suspend挂起函数），

以前了解Retrofit的小伙伴应该知道，Retrofit是有同步和异步两种调用方式的。

void enqueue(Callback<T> callback);
复制代码

上面这就是异步调用方式，传入一个Callback，这也是咱们最最最经常使用到的方式。

Response<T> execute() throws IOException;
复制代码

上面这种是同步调用方法，会阻塞线程，返回的直接就是网络数据Response，不多使用。

后来我就在思考，能不能结合kotlin的协程，抛弃Callback，直接使用Retrofit的同步方法，把异步当同步写，代码顺序书写，逻辑清晰，效率高，同步的写法就更加方便对象的管理。

说干就干。

首先写一个协程的扩展方法：

val api = ……
fun <ResultType> CoroutineScope.retrofit() {
    this.launch(Dispatchers.Main) {
        val work = async(Dispatchers.IO) {
            try {
                api.execute() // 调用同步方法
            } catch (e: ConnectException) {
                e.logE()
                println("网络链接出错")
                null
            } catch (e: IOException) {
                println("未知网络错误")
                null
            }
        }
        work.invokeOnCompletion { _ ->
            // 协程关闭时，取消任务
            if (work.isCancelled) {
                api.cancel() // 调用 Retrofit 的 cancel 方法关闭网络
            }
        }
        val response = work.await() // 等待io任务执行完毕返回数据后，再继续后面的代码

        response?.let {

            if (response.isSuccessful) {
                println(response.body()) //网络请求成功，获取到的数据
            } else {
                // 处理 HTTP code
                when (response.code()) {
                    401 -> {
                    }
                    500 -> {
                        println("内部服务器错误")
                    }
                }
                println(response.errorBody()) //网络请求失败，获取到的数据
            }

        }
    }
}
复制代码

上面就是核心代码，主要的意思都写了注释。整个工做流程是出于ui协程中，因此能够随意操做UI控件，接着在io线程中去同步调用网络请求，而且等待io线程的执行完毕，接着再拿到结果进行处理，整个流程都是基于同步代码的书写方式，一步一个流程，没有回掉而致使的代码割裂感。那么继续，咱们想办法把获取的数据返回出去。

这里咱们采用DSL方法，首先自定义一个类：

class RetrofitCoroutineDsl<ResultType> {
    var api: (Call<ResultType>)? = null

    internal var onSuccess: ((ResultType?) -> Unit)? = null
        private set
    internal var onComplete: (() -> Unit)? = null
        private set
    internal var onFailed: ((error: String?, code, Int) -> Unit)? = null
        private set

    var showFailedMsg = false

    internal fun clean() {
        onSuccess = null
        onComplete = null
        onFailed = null
    }

    fun onSuccess(block: (ResultType?) -> Unit) {
        this.onSuccess = block
    }

    fun onComplete(block: () -> Unit) {
        this.onComplete = block
    }

    fun onFailed(block: (error: String?, code, Int) -> Unit) {
        this.onFailed = block
    }

}
复制代码

此类对外暴露了三个方法：onSuccess，onComplete，onFailed，用于分类返回数据。

接着，咱们对咱们的核心代码进行改造，将方法进行传递：

fun <ResultType> CoroutineScope.retrofit( dsl: RetrofitCoroutineDsl<ResultType>.() -> Unit //传递方法，须要哪一个，传递哪一个
) {
    this.launch(Dispatchers.Main) {
        val retrofitCoroutine = RetrofitCoroutineDsl<ResultType>()
        retrofitCoroutine.dsl()
        retrofitCoroutine.api?.let { it ->
            val work = async(Dispatchers.IO) { // io线程执行
                try {
                    it.execute()
                } catch (e: ConnectException) {
                    e.logE()
                    retrofitCoroutine.onFailed?.invoke("网络链接出错", -100)
                    null
                } catch (e: IOException) {
                    retrofitCoroutine.onFailed?.invoke("未知网络错误", -1)
                    null
                }
            }
            work.invokeOnCompletion { _ ->
                // 协程关闭时，取消任务
                if (work.isCancelled) {
                    it.cancel()
                    retrofitCoroutine.clean()
                }
            }
            val response = work.await()
            retrofitCoroutine.onComplete?.invoke()
            response?.let {
                    if (response.isSuccessful) {
                        retrofitCoroutine.onSuccess?.invoke(response.body())
                    } else {
                        // 处理 HTTP code
                        when (response.code()) {
                            401 -> {
                            }
                            500 -> {
                            }
                        }
                        retrofitCoroutine.onFailed?.invoke(response.errorBody(), response.code())
                    }
            }
        }
    }
}
复制代码

这里使用DSL传递方法，能够更具须要传递的，例如只须要onSuccess，那就只传递这一个方法，没必要三个都传递，按需使用。

使用方式：

首先须要按照kotlin的官方文档来改造下activity：

abstract class BaseActivity : AppCompatActivity(), CoroutineScope {

    private lateinit var job: Job // 定义job

    override val coroutineContext: CoroutineContext
        get() = Dispatchers.Main + job // Activity的协程

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        job = Job()
    }

    override fun onDestroy() {
        super.onDestroy()
        job.cancel() // 关闭页面后，结束全部协程任务
    }
}
复制代码

Activity实现CoroutineScope接口，就能直接根据当前的context获取协程使用。

接下来就是真正的使用，在任意位置便可调用此扩展方法：

retrofit<String> {
    api = api.login("1","1")

    onComplete {
    }

    onSuccess { str ->
    }

    onFailed { error, code ->
    }
}
复制代码

在有的时候，咱们只须要处理onSuccess的状况，并不关心其余两个。那么直接写：

retrofit<String> {
    api = api.login("1","1")

    onSuccess { str ->
    }
}
复制代码

须要哪一个写哪一个，代码很是整洁。

能够看出，咱们不须要单独再对网络请求进行生命周期的绑定，在页面被销毁的时候，job也就被关闭了，当协程被关闭后，会执行调用 Retrofit 的 cancel 方法关闭网络。

5. 小节

协程的开销是小于Thread多线程的，响应速度很快，很是适合轻量化的工做流程。对于协程的使用，还有带我更深刻的思考和学习。协程并非Thread的替代品，仍是多异步任务多一个补充，咱们不能按照惯性思惟去理解协程，而是要多从其自己特性入手，开发出它更安逸的使用方式。并且随着Retrofit 2.6.0的发布，自带了新的协程方案，以下：

@GET("users/{id}")
suspend fun user(@Path("id") long id): User
复制代码

增长了suspend挂起函数的支持，可见协程的应用会愈来愈受欢迎。

上面所说的全部网络处理方法，不管是Rx仍是LiveData，都是很好的封装方式，技术没有好坏之分。个人协程封装方式，也许也不是最好的，可是咱们不能缺少思考、探索、实践三要素，去想去作。

最好的答案，永远都是本身给出的。

第一次写这种类型的文章记录，流程化比较严重，记录不严谨，各位见谅。谢谢你们的阅读