前面两篇文章介绍了协程的一些基本概念和基本知识,这篇则介绍在Android中如何使用协程配合Retrofit发起网络请求,同时介绍在使用协程时如何优雅的取消已经发起的网络请求。
需要文章中demo完整代码的同学可以私我。
创建CoroutineScope
在前面的文章中我写到CoroutineScope.launch方法是一个很常用的协程构建器。因此使用协程必须先得创建一个CoroutineScope对象,代码如下:
CoroutineScope(Dispatchers.Main + Job())
上面的代码创建了一个CoroutineScope对象,为其协程指定了在主线程中执行,同时分配了一个Job
在demo中我使用的是MVP模式写的,所以我将CoroutineScope的创建放到了BasePresenter中,代码如下:
使用CoroutineScope.cancel()取消协程
大家应该可以看到上面BasePresenter.detachView中调用了presenterScope.cancel(),那这个方法有什么作用呢,作用就是取消掉presenterScope创建的所有协程和其子协程。
前面的文章我也介绍过使用launch创建协程时会返回一个Job对象,通过Job对象的cancel方法也可以取消该任务对应的协程,那我这里为什么不使用这种方式呢?
很明显,如果使用Job.cancel()方式取消协程,那我创建每个协程的时候都必须保存返回的Job对象,然后再去取消,显然要更复杂点,而使用CoroutineScope.cancel()则可以一次性取消该协程上下文创建的所有协程和子协程,该代码也可以很方便的提取到基类中,这样后面在写业务代码时也就不用关心协程与View的生命周期的问题。
其实大家看源码的话也可以发现CoroutineScope.cancel()最终使用的也是Job.cancel()取消协程
扩展Retrofit.Call适配协程
大家可以看到上面的api接口定义应该很熟悉,我们可以通过下面的代码发起异步网络请求
前面的文章介绍过协程可以让异步代码像写同步代码那样方便,那上面这段异步代码能不能使用协程改造成类似写同步代码块那样呢?很显然是可以的,具体改造代码如下:
上面的代码扩展了一个挂起函数await,执行该方法时,会执行Retrofit.Call的异步请求同时在协程中挂起该函数,直到异步请求成功或者出错再重新恢复所在协程。
suspendCoroutine
全局函数,此函数可以获取当前方法所在协程上下文,并将当前协程挂起,直到某个时机再重新恢复协程执行,但是这个时机其实是由开发者自己控制的,就像上面代码中的it.resume和it.resumeWithException。
发起请求,写法一
从上面的代码大家可以发现,协程中对异常的处理使用的是try-catch的方式,初学,我也暂时只想到了这种方式。所以在使用协程时,最好在业务的适当地方使用try-catch捕获异常,否则一旦协程执行出现异常,程序就崩掉了。
另外上面的代码的写法还有一个问题,因为挂起函数执行时会挂起当前协程,所以上述两个请求是依次顺序执行,因此上面的queryGanks()方法其实是耗费了两次网络请求的时间,因为请求Android列表和请求ios列表两个请求不是并行的,所以这种写法肯定不是最优解。
发起请求,写法二
下面我们再换另外一种写法。
这种写法与前一种写法的区别是采用async构建器创建了两个子协程分别去请求Android列表和IOS列表,同时因为async构建器执行的时候不会挂起当前协程,所以两个请求是并行执行的,因此效率较上一个写法要高很多。
发起请求,写法三
第三个写法就是在Retorfit的CallAdapter上做文章,通过自定义实现CallAdapterFactory,将api定义时的结果Call直接转换成Deferred,这样就可以同时发起Android列表请求和IOS列表请求,然后通过Deferred.await获取请求结果,这种写法是写法一写法二的结合。
这种写法JakeWharton大神早已为我们实现了,大家可以在他的github中搜索retrofit2-kotlin-coroutines-adapter
这里我就不说这种方案的具体实现了,感兴趣的同学可以去看其源码。
写法三的具体代码如下:
上面的第三种写法看起来更简洁,也是并行请求,耗时为请求时间最长的那个请求的时间,和第二种差不多。