深入理解 Kotlin coroutine (二)

Z70czd

于 2024-04-02 07:58:48 发布

阅读量208

点赞数 1

分类专栏：程序员文章标签： kotlin 开发语言 android

本文链接：https://blog.csdn.net/Z70czd/article/details/137254770

版权

程序员专栏收录该内容

242 篇文章 0 订阅

订阅专栏

运行结果：

World! Hello,

大家看到了，嵌套的 runBlocking 实际上仍然只是一段顺序代码而已。

那么，让我们再仔细看看前面的例子，不知道大家有没有问题：如果我在 launch 创建的协程当中多磨叽一会儿，主线程上的协程 delay(2000L) 好像也没多大用啊。有没有什么方法保证协程执行完？

4. 外部控制协程

我们在上一篇文章当中只是对内置的基础 API 进行了简单的封装，而 kotlinx.coroutines 却为我们做了非常多的事情。比如，每一个协程都看做一个 Job，我们在一个协程的外部也可以控制它的运行。

fun main(args: Array<String>) = runBlocking<Unit> { val job = launch(CommonPool) { delay(1000L) println("World!") } println("Hello,") job.join() }

job.join 其实就是要求当前协程等待 job 执行完成之后再继续执行。

其实，我们还可以取消协程，让他直接停止执行：

fun main(args: Array<String>) = runBlocking<Unit> { val job = launch(CommonPool) { delay(1000L) println("World!") } println("Hello,") job.cancel() }

job.cancel 会直接终止 job 的执行。如果 job 已经执行完毕，那么 job.cancel 的执行时没有意义的。我们也可以根据 cancel 的返回值来判断是否取消成功。

另外，cancel 还可以提供原因：

job.cancel(IllegalAccessException("World!"))

如果我们提供了这个原因，那么被取消的协程会将它打印出来。

Hello, Exception in thread "main" java.lang.IllegalAccessException: World! at example13.Example_13Kt$main$1.doResume(example-13.kt:14) at kotlin.coroutines.experimental.jvm.internal.CoroutineImpl.resume(CoroutineImpl.kt:53) at kotlinx.coroutines.experimental.DispatchedContinuation$resume$1.run(CoroutineDispatcher.kt:57)

其实，如果你自己做过对线程任务的取消，你大概会知道除非被取消的线程自己去检查取消的标志位，或者被 interrupt，否则取消是无法实现的，这有点儿像一个人执意要做一件事儿，另一个人说你别做啦，结果人家压根儿没听见，你说他能停下来吗？那么我们前面的取消到底是谁去监听了这个 cancel 操作呢？

当然是 delay 这个操作了。其实所有 kotlinx.coroutines 当中定义的操作都可以做到这一点，我们对代码稍加改动，你就会发现异常来自何处了：

val job = launch(CommonPool) { try { delay(1000L) println("World!") } catch(e: Exception) { e.printStackTrace() }finally { println("finally....") } } println("Hello,") job.cancel(IllegalAccessException("World!"))

是的，你没看错，我们居然可以在协程里面对 cancel 进行捕获，如果你愿意的话，你甚至可以继续在这个协程里面运行代码，但请不要这样做，下面的示例破坏了 cancel 的设计本意，所以请勿模仿：

val job = launch(CommonPool) { try { ... }finally { println("finally....") } println("I'm an EVIL!!! Hahahaha") }

说这个是什么意思呢？在协程被 cancel 掉的时候，我们应该做的其实是把战场打扫干净，比如：

val job = launch(CommonPool) { val inputStream = ... try { ... }finally { inputStream.close() } }

我们再来考虑下面的情形：

fun main(args: Array<String>) = runBlocking<Unit> { val job = launch(CommonPool) { var nextPrintTime = 0L var i = 0 while (true) { // computation loop val currentTime = System.currentTimeMillis() if (currentTime >= nextPrintTime) { println("I'm sleeping ${i++} ...") nextPrintTime = currentTime + 500L } } } delay(1300L) // delay a bit println("main: I'm tired of waiting!") job.cancel() // cancels the job delay(1300L) // delay a bit to see if it was cancelled.... println("main: Now I can quit.") }

不得不说，kotlinx.coroutines 在几天前刚刚更新的文档和示例非常的棒。我们看到这个例子，while(true) 会让这个协程不断运行来模拟耗时计算，尽管外部调用了 job.cancel()，但由于内部并没有 care 自己是否被 cancel，所以这个 cancel 显然有点儿失败。如果你想要在类似这种耗时计算当中检测当前协程是否被取消的话，你可以这么写：

... while (isActive) { // computation loop ... } ...

isActive 会在 cancel 之后被置为 false。

其实，通过这几个示例大家就会发现协程的取消，与我们通常取消线程操作的思路非常类似，只不过人家封装的比较好，而我们呢，每次还得自己搞一个 CancelableTask 来实现 Runnable 接口去承载自己的异步操作，想想也是够原始呢。

5. 轻量级线程

协程时轻量级的，它拥有自己的运行状态，但它对资源的消耗却非常的小。其实能做到这一点的本质原因，我们已经在上一篇文章当中提到过，一台服务器开 1k 线程和 1k 协程来响应服务，前者对资源的消耗必然很大，而后者可能只是基于很少的几个或几十个线程来工作的，随着请求数量的增加，协程的优势可能会体现的更加明显。

我们来看个比较简单的例子：

fun main(args: Array<String>) = runBlocking<Unit> { val jobs = List(100_000) { launch(CommonPool) { delay(1000L) print(".") } } jobs.forEach { it.join() } //这里不能用 jobs.forEach(Job::join)，因为 Job.join 是 suspend 方法 }

通过 List 这个方法，我们可以瞬间创建出很多对象放入返回的 List，注意到这里的 jobs 其实就是协程的一个 List。

运行上面的代码，我们发现 CommonPool 当中的线程池的线程数量基本上维持在三四个就足够了，如果我们用线程来写上面的代码会是什么感觉？

fun main(args: Array<String>) = runBlocking<Unit> { val jobs = List(100_000) { thread { Thread.sleep(1000L) log(".") } } jobs.forEach(Thread::join) // Thread::join 说起来也是 1.1 的新特性呢！ }

运行时，在创建了 1k 多个线程之后，就抛出了异常：

Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method)

嗯，又多了一个用协程的理由，对不对？

6. 携带值的 Job

我们前面说了，通过携程返回的 Job，我们可以控制携程的运行。可有时候我们更关注协程运行的结果，比如从网络加载一张图片：

suspend fun loadImage(url: String): Bitmap { ... return ... }

没错，我们更关注它的结果，这种情况我们该怎么办呢？如果 loadImage 不是 suspend 方法，那么我们在非 UI 线程当中直接获取他们：

val imageA = loadImage(urlA) val imageB = loadImage(urlB) onImageGet(imageA, imageB)

这样的操作有什么问题？顺序获取两张图片，耗时，不经济。所以传统的做法就是开两个线程做这件事儿，这意味着你会看到两个回调，并且还要同步这两个回调，想想都头疼。

不过我们现在有更好的办法：

val imageA = defer(CommonPool) { loadImage(urlA) } val imageB = defer(CommonPool) { loadImage(urlB) } onImageGet(imageA.await(),imageB.await())

代码量几乎没有增加，不过我们却做到了两张图片异步获取，并同时传给 onImageGet 以便继续后面的操作。

defer 到底是个什么东西？其实大家大可不必看到新词就感到恐慌，这东西用法几乎跟 launch 一样，只不过它返回的 Deferred 功能比 Job 多了一样：携带返回值。我们前面看到的 imageA 其实就是一个 Deferred 实例，而它的 await 方法返回的则是 Bitmap 类型，也即 loadImage(urlA) 的返回值。

所以如果你对协程运行的结果感兴趣，直接使用 defer 来替换你的 launch 就可以了。需要注意的是，即便你不调用 await，defer 启动的协程也会立即运行，如果你希望你的协程能够按需启动，例如只有你调用 await 之后再启动，那么你可以用 lazyDefer：

val imageA = lazyDefer(CommonPool) { loadImage(urlA) } val imageB = lazyDefer(CommonPool) { loadImage(urlB) } onImageGet(imageA.await(),imageB.await()) //这时候才开始真正去加载图片

7. 生成器
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

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

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

学习分享

在当下这个信息共享的时代，很多资源都可以在网络上找到，只取决于你愿不愿意找或是找的方法对不对了

很多朋友不是没有资料，大多都是有几十上百个G，但是杂乱无章，不知道怎么看从哪看起，甚至是看后就忘

如果大家觉得自己在网上找的资料非常杂乱、不成体系的话，我也分享一套给大家，比较系统，我平常自己也会经常研读。

2021最新上万页的大厂面试真题

七大模块学习资料：如NDK模块开发、Android框架体系架构…

2021大厂面试真题：

只有系统，有方向的学习，才能在短时间内迅速提高自己的技术，只有不断地学习，不懈的努力才能拥有更好的技术，才能在互联网行业中立于不败之地。

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门即可获取！

5%以上Android开发知识点，真正体系化！**