本系列是笔者解析阿里的开源协程库 coobjc 的开篇之作，首要聊一聊协程是什么以及怎么在iOS的开发进程中为我们带来帮忙。
本篇还不会涉及到 coobjc 的代码细节解读，详见后续哈～
- 阿里的iOS协程库 coobjc 源码解析（一）——元组和协程
协程是什么？
这是一个好问题，让我们可以思考，在我们有了进程、线程这样完善的系统资源分配和调度机制后，为什么我们还需求协程这个东西。
简单来说，协程是比线程的调度粒度更小的单位，就像线程之于进程，一个进程内可以有多条线程一同在工作——而多个协程可以一同工作在同一条线程中。
假设你需求更细致地了解，可以参看一下维基百科的解说。
在移动端，为什么我们需求协程？
根据奥卡姆剃刀原理，我们不妨思考下——假设没有协程，现有的并发模型，是怎么样的。
线程的熵增——无序的线程胀大
假定我们开发一款谈天类型的软件，APP的主页或许是一个谈天列表，这里边或许会涉及到 HTTP 央求、数据库的读写、文件读写、UI展示、长联接等模块。
因为现在还没有引入协程，所以我们的并发调度，最细粒度，也只能到线程，所以暂时我们的并发，都指代用线程进行并发的情况。
而在经年累月的保护之下，跟着功用的不断变多，业务越来越冗繁，我们或许会引入许多新的 HTTP 央求、数据库的读写、文件读写、UI展示、长链接等。
就是在这些大的模块方向里，我们因为新业务的接入，而不断地衍生出了子模块。
一种或许的情况是，这些不同的子模块，它们都有自己的网络央求模块，或许长联接模块、数据库模块、文件读写模块等，它们都各自随意地在项目里用线程建议并发，只为了结束自己的任务。
跟着业务的胀大和巨大化，线程的并发情况，在某些时间或许就会胀大到我们无法承受——某些极点时间，APP内一同在工作的线程逾越二三十条，乃至逾越50条、上百条——远超CPU中心数量。但实际上，有许多的并发实际上是无效的——并发没有带来功率上的进步，反而降低了功率。
固然，这种情况比较极点，往往大型项目都有Code Review，以及某些编码限制，来避免诸如此类的情况发生；其次是大型项目，一般也会有专门的UI库、网络库、缓存库等来整合这些大型模块的能力。
但是，线程的随意运用，本身是无序而且难以操控的，因为它仅仅东西的一种——它本质上处理了：我们有一个任务要实行，但我不想让它卡住其时正在实行的任务的这种问题。
线程并发任务的优先级操控问题
回到我们的谈天软件，进入一个新的谈天窗后，我们需求拉取新的消息。
在这种情况下，我们或许会面临的情况是，用户点进又退出了几个谈天窗，终究停留在了终究一个翻开的谈天窗里。
我们或许的结束，有两种情况：
- 每进入一个新的窗口，我们都建议一条异步线程，来拉取新的消息，示意图如下：
现已建议了谈天消息拉取的窗口，我们就不管了，我们只需求等候其时窗口的消息回来就可以结束任务了——究竟其他窗口的消息拉取和其时窗口的消息拉取是并发工作的，相互之间不会堵塞。
这样做的确能结束任务，但它也有它固有的缺点，就是它没办法确定哪个窗口的消息拉取的优先级是最高的。也就是说，实际上其他窗口的优先级并不如其时翻开的窗口的优先级那么高——但它们却和其时窗口占有相同的资源。
- 运用
NSOperation和NSOperationQueue来结束这个任务。
运用NSOperation和NSOperationQueue，我们可以更好的管理哪个窗口优先拉撤销息——通过暂停或撤销其他窗口的operation结束。
但这一同也会带来新的问题——我们需求在单个任务里管理错综复杂的暂停以及撤销情况——不断地在NSOperation里的每一步增加if判断，来承认任务是否暂停或撤销了，然后进行一些决断。
线程同步的问题
用锁
每一个窗口的消息拉取，落到实处，除了有网络央求在前，大约还会有缓存的写入在后。比方这样：
而一般多个窗口的缓存，都会存放在同一个数据库里——假设是比较久以前的项目或模块，缓存是直接用sqlite的C言语接口结束的，面临多线程的情况，我们需求为缓存的读写加锁，来确保缓存的正确性。
但假设并发的线程多了，我们缓存读写的进程出现了多个锁磕碰，会导致CPU不断切换到一个锁住的线程里，来查看锁的情况，然后导致并发功率奇低。
将缓存的操作，共同封装到一个指定的线程里
后来，许多封装得较好的数据库型东西库——如FMDB，Core Data等，都倾向于将数据库读写，放到同一线程里，以避免数据库的竟态条件问题。
这样，我们通过献身了必定的并发度，但换来了总体更安全和安稳的缓存读写机制。
引入协程再来看上面的问题
协程能敌对熵增吗？
哈哈，协程也不能敌对熵增，也就是协程也无法敌对无序扩张的并发，因为东西究竟是拿来用的，协程就是用来并发的，我们只要有需求，协程就是需求增加的。
我们的确可以通过一些手法，有用的优化或许减缓这个进程。但是我们无法反抗不断胀大的需求和业务。
所以假设有一种并发的手法，可以让并发的价值更小，我们显然是可以欣然承受的。
协程就是了，比照线程，它的上下文切换的价值了等于无；它可以分配更小的栈空间，更省内存——但其本质和线程做的事无异，都是为了并发。
只不过协程不可以并行——更精确的来说，是同一线程内的协程无法并行，所以我们假设用协程进行开发，我们首要需求从更大的角度考虑，每个线程应该担任一个怎么样的模块，然后在这个模块底下，我们再怎么通过协程来结束模块里的小任务。
协程具有更便当且高效的优先级操控
协程的体积很小，创建和销毁以及切换的价值，都十分小。其次是协程可以在实行到任意的当地进行yield，让出调度权限——让优先级更高的协程可以立刻进行，在实行结束后，又resume回来。
也就是前面说到的，谈天窗口的消息拉取进程，我们可以很轻松的将其改造为一个后进先出的情况。
运用协程并发，直接就能处理并发同步的问题
如上图所示，我们所有的谈天窗消息拉取任务，都工作在同一线程里，它们不存在并行的情况，我们可以很轻松地处理掉竟态条件的问题。
也就是我们可以安心肠进行缓存读写，而不需求考虑锁的问题。
其次是，假设我们需求多个协程之间进行更精密的协作，我们可以运用消息通道来进行结束。这类似于经典的生产者顾客模型——总而言之，都是可以处理的。
总结
协程给了我们更细粒度的调度方法，以避免我们在实行一些高并发任务时，乱用线程——假设我们逢并发必用线程，很或许到了终究，我们会创建了过多的线程——假设团队巨大，业务冗繁，就更简单形成这种情况，过多的线程将会导致CPU为了满意这些过多的线程的需求，进行了频繁的上下文切换，然后降低CPU的工作功率。
这，本质上就是因为我们小看了一条线程所能承受的作业，而导致我们不管大事小事，用线程并发就完事了。
实际上，许多时分，同质的任务——譬如数据库读写、文件读写等，或许同一业务下的任务，有时乃至只需求一条线程，兴许都能结束得不错。
固然，笔者也不会自负到以为一条线程能彻底对应上一个大模块，仅仅我期望协程的出现，可以引起我们的关注和思考，从头审视一条线程所能承担的责任。
其次是，我们是否能善用线程和协程，来打造愈加美好的并发环境呢？
