阿里妹导读：刚刚，阿里巴巴正式对外开源了基于 Apache 2.0 协议的协程开发框架 coobjc，开发者们可以在 Github 上自主下载。
专注于为中小企业提供网站建设、成都网站制作服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业乳源免费做网站提供优质的服务。我们立足成都，凝聚了一批互联网行业人才，有力地推动了成百上千家企业的稳健成长，帮助中小企业通过网站建设实现规模扩充和转变。
coobjc是为iOS平台打造的开源协程开发框架，支持Objective-C和Swift，同时提供了cokit库为Foundation和UIKit中的部分API提供了 协程 化支持，本文将为大家详细介绍coobjc的设计理念及核心优势。
从2008年第一个iOS版本发布至今的11年时间里，iOS的异步编程方式发展缓慢。
基于 Block 的异步编程回调是目前 iOS 使用最广泛的异步编程方式，iOS 系统提供的 GCD 库让异步开发变得很简单方便，但是基于这种编程方式的缺点也有很多，主要有以下几点：
针对多线程以及尤其引发的各种崩溃和性能问题，我们制定了很多编程规范、进行了各种新人培训，尝试降低问题发生的概率，但是问题依然很严峻，多线程引发的问题占比并没有明显的下降，异步编程本来就是很复杂的事情，单靠规范和培训是难以从根本上解决问题的，需要有更加好的编程方式来解决。
上述问题在很多系统和语言开发中都可能会碰到，解决问题的标准方式就是使用协程，C#、Kotlin、Python、Javascript 等热门语言均支持协程极其相关语法，使用这些语言的开发者可以很方便的使用协程及相关功能进行异步编程。
2017 年的 C++ 标准开始支持协程，Swift5 中也包含了协程相关的标准，从现在的发展趋势看基于协程的全新的异步编程方式，是我们解决现有异步编程问题的有效的方式，但是苹果基本已经不会升级 Objective-C 了，因此使用Objective-C的开发者是无法使用官方的协程能力的，而最新 Swift 的发布和推广也还需要时日，为了让广大iOS开发者能快速享受到协程带来的编程方式上的改变，手机淘宝架构团队基于长期对系统底层库和汇编的研究，通过汇编和C语言实现了支持 Objective-C 和 Swift 协程的完美解决方案 —— coobjc。
核心能力
内置系统扩展库
coobjc设计
最底层是协程内核，包含了栈切换的管理、协程调度器的实现、协程间通信channel的实现等。
中间层是基于协程的操作符的包装，目前支持async/await、Generator、Actor等编程模型。
最上层是对系统库的协程化扩展，目前基本上覆盖了Foundation和UIKit的所有IO和耗时方法。
核心实现原理
协程的核心思想是控制调用栈的主动让出和恢复。一般的协程实现都会提供两个重要的操作：
我们基于线程的代码执行时候，是没法做出暂停操作的，我们现在要做的事情就是要代码执行能够暂停，还能够再恢复。 基本上代码执行都是一种基于调用栈的模型，所以如果我们能把当前调用栈上的状态都保存下来，然后再能从缓存中恢复，那我们就能够实现yield和 resume。
实现这样操作有几种方法呢？
上述第三种和第四种只是能过做到跳转，但是没法保存调用栈上的状态，看起来基本上不能算是实现了协程，只能算做做demo，第五种除非官方支持，否则自行改写编译器通用性很差。而第一种方案的 ucontext 在iOS上是废弃了的，不能使用。那么我们使用的是第二种方案，自己用汇编模拟一下 ucontext。
模拟ucontext的核心是通过getContext和setContext实现保存和恢复调用栈。需要熟悉不同CPU架构下的调用约定(Calling Convention). 汇编实现就是要针对不同cpu实现一套，我们目前实现了 armv7、arm64、i386、x86_64，支持iPhone真机和模拟器。
说了这么多，还是看看代码吧，我们从一个简单的网络请求加载图片功能来看看coobjc到底是如何使用的。
下面是最普通的网络请求的写法：
下面是使用coobjc库协程化改造后的代码：
原本需要20行的代码，通过coobjc协程化改造后，减少了一半，整个代码逻辑和可读性都更加好，这就是coobjc强大的能力，能把原本很复杂的异步代码，通过协程化改造，转变成逻辑简洁的顺序调用。
coobjc还有很多其他强大的能力，本文对于coobjc的实际使用就不过多介绍了，感兴趣的朋友可以去官方github仓库自行下载查看。
我们在iPhone7 iOS11.4.1的设备上使用协程和传统多线程方式分别模拟高并发读取数据的场景，下面是两种方式得到的压测数据。
从上面的表格我们可以看到使用在并发量很小的场景，由于多线程可以完全使用设备的计算核心，因此coobjc总耗时要比传统多线程略高，但是由于整体耗时都很小，因此差异并不明显，但是随着并发量的增大，coobjc的优势开始逐渐体现出来，当并发量超过1000以后，传统多线程开始出现线程分配异常，而导致很多并发任务并没有执行，因此在上表中显示的是大于20秒，实际是任务已经无法正常执行了，但是coobjc仍然可以正常运行。
我们在手机淘宝这种超级App中尝试了协程化改造，针对部分性能差的页面，我们发现在滑动过程中存在很多主线程IO调用、数据解析，导致帧率下降严重，通过引入coobjc，在不改变原有业务代码的基础上，通过全局hook部分IO、数据解析方法，即可让原来在主线程中同步执行的IO方法异步执行，并且不影响原有的业务逻辑，通过测试验证，这样的改造在低端机(iPhone6及以下的机器)上的帧率有20%左右的提升。
简明
易用
清晰
性能
程序是写来给人读的，只会偶尔让机器执行一下。——Abelson and Sussman
基于协程实现的编程范式能够帮助开发者编写出更加优美、健壮、可读性更强的代码。
协程可以帮助我们在编写并发代码的过程中减少线程和锁的使用，提升应用的性能和稳定性。
本文作者：淘宝技术
文/OneV's Den这是我在今年 1 月 10 日@Swift 开发者大会上演讲的文字稿。相关的视频还在制作中，没有到现场的朋友可以通过这个文字稿了解到这个 session 的内容。虽然我的工作是程序员，但是最近半年其实我的主要干的事儿是养了一个小孩。 所以这半年来可以说没有积累到什么技术，反而是积累了不少养小孩的心得。 当知道了有这么次会议可以分享这半年来的心得的时候，我毫不犹豫地选定了主题。那就是如何打造一个让人愉快的小孩但考虑到这是一次开发者会议...当我把这个想法和题目提交给大会的时候，被残酷地拒绝了。考虑到我们是一次开发者大会，所以我需要找一些更合适的主题。其实如果你对自己的代码有感情的话，我们开发和维护的项目或者框架就如同自己的孩子一般这也是我所能找到的两者的共同点。所以，我将原来拟定的主题换了两个字：如何打造一个让人愉快的框架在正式开始前，我想先给大家分享一个故事。我们那儿的 iOS 开发小组里有一个叫做武田君的人，他的代码写得不错，做事也非常严谨，可以说是楷模般的员工。但是他有一个致命的弱点 -- 喜欢自己发明轮子。他出于本能地抗拒在代码中使用第三方框架，所以接到开发任务以后他一般都要花比其他小伙伴更多的时间才能完成。武田君其实在各个方面都有建树...比如网络请求 模型解析 导航效果 视图动画 ... 不过虽然造了很多轮子，但是代码的重用比较糟糕，耦合严重。在新项目中使用的话，只能复制粘贴，然后针对项目修修补补。因为承担的任务总是没有办法完成，他一直是项目 deadline 的决定者，在日本这种社会，压力可想而知。就在我这次回国之前，武田君来向我借了一本我本科时候最喜欢的书。就是这本：我有时候就想，到底是什么让一个开发者面临如此大的精神压力，我们有什么办法来缓解这种压力。在我们有限的开发生涯中，应该如何有效利用时间来做一些更有价值的事情。以上故事纯属虚构，如有雷同实属巧合使用框架在了解如何制作框架之前，先让我们看看如何使用框架。可以说，如果你想成为一个框架的提供者，首先你必须是一个优秀的使用者。在 iOS 开发的早期，使用框架其实并不是一件让人愉悦的事情。可能有几年经验的开发者都有这样的体会，那就是：忘不了那些年，被手动引用和.a文件所支配的恐惧其实恐惧源于未知，回想一下，当我们刚接触软件开发的时候，懵懵懂懂地引用了一个静态库，然后面对一排排编译器报错时候手足无措的绝望。但是当我们了解了静态库的话，我们就能克服这种恐惧了。什么是静态库 (Static Library)所谓静态库，或者说 .a 文件，就是一系列从源码编译的目标文件的集合。它是你的源码的实现所对应的二进制。配合上公共的 .h 文件，我们可以获取到 .a 中暴露的方法或者成员等。在最后编译 app 的时候 .a 将被链接到最终的可执行文件中，之后每次都随着 app 的可执行二进制文件一同加载，你不能控制加载的方式和时机，所以称为静态库。在 iOS 8 之前，iOS 只支持以静态库的方式来使用第三方的代码。什么是动态框架 (Dynamic Framework)与静态相对应的当然是动态。我们每天使用的 iOS 系统的框架是以 .framework 结尾的，它们就是动态框架。Framework 其实是一个 bundle，或者说是一个特殊的文件夹。系统的 framework 是存在于系统内部，而不会打包进 app 中。app 的启动的时候会检查所需要的动态框架是否已经加载。像 UIKit 之类的常用系统框架一般已经在内存中，就不需要再次加载，这可以保证 app 启动速度。相比静态库，framework 是自包含的，你不需要关心头文件位置等，使用起来很方便。Universal FrameworkiOS 8 之前也有一些第三方库提供 .framework 文件，但是它们实质上都是静态库，只不过通过一些方法进行了包装，相比传统的 .a 要好用一些。像是原来的 Dropbox 和 Facebook 等都使用这种方法来提供 SDK。不过因为已经脱离时代，所以在此略过不说。有兴趣和需要的朋友可以参看一下这里和这里。Library v.s. Framework对比静态库和动态框架，后者是有不少优势的。首先，静态库不能包含像 xib 文件，图片这样的资源文件，其他开发者必须将它们复制到 app 的 main bundle 中才能使用，维护和更新非常困难；而 framework 则可以将资源文件包含在自己的 bundle 中。 其次，静态库必须打包到二进制文件中，这在以前的 iOS 开发中不是很大的问题。但是随着 iOS 扩展（比如通知中心扩展或者 Action 扩展）开发的出现，你现在可能需要将同一个 .a 包含在 app 本体以及扩展的二进制文件中，这是不必要的重复。最后，静态库只能随应用 binary 一起加载，而动态框架加载到内存后就不需要再次加载，二次启动速度加快。另外，使用时也可以控制加载时机。动态框架有非常多的优点，但是遗憾的是以前 Apple 不允许第三方框架使用动态方式，而只有系统框架可以通过动态方式加载。
这个看你需求了，navigation 和 tabbar controller 是可以相互交叉的，你可以参考写你想做的app的类似线上app。