刚刚，阿里开源 iOS 协程开发框架 coobjc！

原创淘宝技术阿里云开发者

阿里妹导读：刚刚，阿里巴巴正式对外开源了基于 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%左右的提升。