阿里妹导读：刚刚，阿里巴巴正式对外开源了基于 Apache 2.0 协议的协程开发框架 coobjc，开发者们可以在 Github 上自主下载。coobjc 是为 iOS 平台打造的开源协程开发框架，支持 Objective- C 和 Swift，同时提供了 cokit 库为 Foundation 和 UIKit 中的部分 API 提供了协程化支持，本文将为大家详细介绍 coobjc 的设计理念及核心优势。
开源地址
https://github.com/alibaba/coobjc
iOS 异步编程问题
从 2008 年第一个 iOS 版本发布至今的 11 年时间里，iOS 的异步编程方式发展缓慢。
基于 Block 的异步编程回调是目前 iOS 使用最广泛的异步编程方式，iOS 系统提供的 GCD 库让异步开发变得很简单方便，但是基于这种编程方式的缺点也有很多，主要有以下几点：
容易进入 ” 嵌套地狱 ”
错误处理复杂和冗长
容易忘记调用 completion handler
条件执行变得很困难
从互相独立的调用中组合返回结果变得极其困难
在错误的线程中继续执行（如子线程操作 UI）
难以定位原因的多线程崩溃（手淘中多线程 crash 已占比 60% 以上）
锁和信号量滥用带来的卡顿、卡死
针对多线程以及尤其引发的各种崩溃和性能问题，我们制定了很多编程规范、进行了各种新人培训，尝试降低问题发生的概率，但是问题依然很严峻，多线程引发的问题占比并没有明显的下降，异步编程本来就是很复杂的事情，单靠规范和培训是难以从根本上解决问题的，需要有更加好的编程方式来解决。
解决方案
上述问题在很多系统和语言开发中都可能会碰到，解决问题的标准方式就是使用协程，C#、Kotlin、Python、Javascript 等热门语言均支持协程极其相关语法，使用这些语言的开发者可以很方便的使用协程及相关功能进行异步编程。
2017 年的 C++ 标准开始支持协程，Swift5 中也包含了协程相关的标准，从现在的发展趋势看基于协程的全新的异步编程方式，是我们解决现有异步编程问题的有效的方式，但是苹果基本已经不会升级 Objective-C 了，因此使用 Objective- C 的开发者是无法使用官方的协程能力的，而最新 Swift 的发布和推广也还需要时日，为了让广大 iOS 开发者能快速享受到协程带来的编程方式上的改变，手机淘宝架构团队基于长期对系统底层库和汇编的研究，通过汇编和 C 语言实现了支持 Objective-C 和 Swift 协程的完美解决方案 —— coobjc。
核心能力
提供了类似 C# 和 Javascript 语言中的 Async/Await 编程方式支持，在协程中通过调用 await 方法即可同步得到异步方法的执行结果，非常适合 IO、网络等异步耗时调用的同步顺序执行改造。
提供了类似 Kotlin 中的 Generator 功能，用于懒计算生成序列化数据，非常适合多线程可中断的序列化数据生成和访问。
提供了 Actor Model 的实现，基于 Actor Model，开发者可以开发出更加线程安全的模块，避免由于直接函数调用引发的各种多线程崩溃问题。
提供了元组的支持，通过元组 Objective- C 开发者可以享受到类似 Python 语言中多值返回的好处。
内置系统扩展库
提供了对 NSArray、NSDictionary 等容器库的协程化扩展，用于解决序列化和反序列化过程中的异步调用问题。
提供了对 NSData、NSString、UIImage 等数据对象的协程化扩展，用于解决读写 IO 过程中的异步调用问题。
提供了对 NSURLConnection 和 NSURLSession 的协程化扩展，用于解决网络异步请求过程中的异步调用问题。
提供了对 NSKeyedArchieve、NSJSONSerialization 等解析库的扩展，用于解决解析过程中的异步调用问题。
coobjc 设计
最底层是协程内核，包含了栈切换的管理、协程调度器的实现、协程间通信 channel 的实现等。
中间层是基于协程的操作符的包装，目前支持 async/await、Generator、Actor 等编程模型。
最上层是对系统库的协程化扩展，目前基本上覆盖了 Foundation 和 UIKit 的所有 IO 和耗时方法。
核心实现原理
协程的核心思想是控制调用栈的主动让出和恢复。一般的协程实现都会提供两个重要的操作：
Yield：是让出 cpu 的意思，它会中断当前的执行，回到上一次 Resume 的地方。
Resume：继续协程的运行。执行 Resume 后，回到上一次协程 Yield 的地方。
我们基于线程的代码执行时候，是没法做出暂停操作的，我们现在要做的事情就是要代码执行能够暂停，还能够再恢复。基本上代码执行都是一种基于调用栈的模型，所以如果我们能把当前调用栈上的状态都保存下来，然后再能从缓存中恢复，那我们就能够实现 yield 和 resume。
实现这样操作有几种方法呢？
第一种：利用 glibc 的 ucontext 组件(云风的库)。
第二种：使用汇编代码来切换上下文(实现 c 协程)，原理同 ucontext。
第三种：利用 C 语言语法 switch-case 的奇淫技巧来实现（Protothreads)。
第四种：利用了 C 语言的 setjmp 和 longjmp。
第五种：利用编译器支持语法糖。
上述第三种和第四种只是能过做到跳转，但是没法保存调用栈上的状态，看起来基本上不能算是实现了协程，只能算做做 demo，第五种除非官方支持，否则自行改写编译器通用性很差。而第一种方案的 ucontext 在 iOS 上是废弃了的，不能使用。那么我们使用的是第二种方案，自己用汇编模拟一下 ucontext。
模拟 ucontext 的核心是通过 getContext 和 setContext 实现保存和恢复调用栈。需要熟悉不同 CPU 架构下的调用约定(Calling Convention). 汇编实现就是要针对不同 cpu 实现一套，我们目前实现了 armv7、arm64、i386、x86_64，支持 iPhone 真机和模拟器。
Show me the code
说了这么多，还是看看代码吧，我们从一个简单的网络请求加载图片功能来看看 coobjc 到底是如何使用的。
下面是最普通的网络请求的写法：
下面是使用 coobjc 库协程化改造后的代码：
原本需要 20 行的代码，通过 coobjc 协程化改造后，减少了一半，整个代码逻辑和可读性都更加好，这就是 coobjc 强大的能力，能把原本很复杂的异步代码，通过协程化改造，转变成逻辑简洁的顺序调用。
coobjc 还有很多其他强大的能力，本文对于 coobjc 的实际使用就不过多介绍了，感兴趣的朋友可以去官方 github 仓库自行下载查看。
性能提升
我们在 iPhone7 iOS11.4.1 的设备上使用协程和传统多线程方式分别模拟高并发读取数据的场景，下面是两种方式得到的压测数据。
测试机器：iPhone7 iOS11.4.1
数据文件大小：20M
协程最多使用线程数：4
数据测试结果(统计的是所有并发访问结束的总耗时)：
从上面的表格我们可以看到使用在并发量很小的场景，由于多线程可以完全使用设备的计算核心，因此 coobjc 总耗时要比传统多线程略高，但是由于整体耗时都很小，因此差异并不明显，但是随着并发量的增大，coobjc 的优势开始逐渐体现出来，当并发量超过 1000 以后，传统多线程开始出现线程分配异常，而导致很多并发任务并没有执行，因此在上表中显示的是大于 20 秒，实际是任务已经无法正常执行了，但是 coobjc 仍然可以正常运行。
我们在手机淘宝这种超级 App 中尝试了协程化改造，针对部分性能差的页面，我们发现在滑动过程中存在很多主线程 IO 调用、数据解析，导致帧率下降严重，通过引入 coobjc，在不改变原有业务代码的基础上，通过全局 hook 部分 IO、数据解析方法，即可让原来在主线程中同步执行的 IO 方法异步执行，并且不影响原有的业务逻辑，通过测试验证，这样的改造在低端机 (iPhone6 及以下的机器) 上的帧率有 20% 左右的提升。
优势
简明
概念少：只有很少的几个操作符，相比响应式几十个操作符，简直不能再简单了。
原理简单：协程的实现原理很简单，整个协程库只有几千行代码。
易用
使用简单：它的使用方式比 GCD 还要简单，接口很少。
改造方便：现有代码只需要进行很少的改动就可以协程化，同时我们针对系统库提供了大量协程化接口。
清晰
同步写异步逻辑：同步顺序方式写代码是人类最容易接受的方式，这可以极大的减少出错的概率。
可读性高：使用协程方式编写的代码比 block 嵌套写出来的代码可读性要高很多。
性能
调度性能更快：协程本身不需要进行内核级线程的切换，调度性能快，即使创建上万个协程也毫无压力。
减少卡顿卡死: 协程的使用以帮助开发减少锁、信号量的滥用，通过封装会引起阻塞的 IO 等协程接口，可以从根源上减少卡顿、卡死，提升应用整体的性能。
总结
程序是写来给人读的，只会偶尔让机器执行一下。——Abelson and Sussman
基于协程实现的编程范式能够帮助开发者编写出更加优美、健壮、可读性更强的代码。
协程可以帮助我们在编写并发代码的过程中减少线程和锁的使用，提升应用的性能和稳定性。
本文作者：淘宝技术
阅读原文
本文来自云栖社区合作伙伴“阿里技术”，如需转载请联系原作者。