iOS 编程中 throttle 的那些事


不知道大家对throttle这个单词是否看着眼熟，还是说对这个计算机基础概念有很清晰的了解了。今天就来聊聊和throttle相关的一些技术场景。

定义

我经常有一种感觉，对于英语这门语言的语感，会影响我们对于一些关键技术概念的理解。有时候在学习新技术知识的时候，我会先花一些时间去了解术语英文单词的各种语义，在形成强烈清晰的语感之后，再去深入具体的技术语境。throttle也算是个生僻的单词，至少在口语中毕竟少用到，先来看看词义：

a device controlling the flow of fuel or power to an engine.

中文翻译是节流器，一种控制流量的设备。对应到我们计算机世界，可以理解成，一种控制数据或者事件流量大小的机制。这么说可能还是有些抽象，再来看看一些具体的技术场景加深理解。

场景一：GCD Background Queue

话说GCD几乎是iOS面试的必问题，也是个送分题:)。

我一般会机械式的先问：GCD有哪几种Queue？回答：串行Queue和并行Queue。

我继续问：Global Queue有哪几种优先级？回答：有几种吧，大概记得Default，Low，High吧。

我双眉一挑，进一步试探：不知道少侠有没有研究过DISPATCH_QUEUE_PRIORITY_BACKGROUND作何用？问完立即竖起耳朵，殷殷期盼萦绕于心的关键字。如果能听到「I/O Throttle 呀！」，我会瞬间觉得面试气氛被点亮了。

当然啦，答不出I/O Throttle并不能说明技术不扎实，但能答出来，至少表明对待技术是有好奇心的，加分！

官方文档如是说：

Items dispatched to the queue run at background priority; the queue is scheduled for execution after all high priority queues have been scheduled and the system runs items on a thread whose priority is set for background
status. Such a thread has the lowest priority and any disk I/O is throttled to minimize the impact on the system.

那Disk I/O Throttle做什么用呢？按照上面这段描述，Disk I/O会impact system performance。

理解Disk I/O的影响需要补充一些大学课本上的知识。一次磁盘读写操作涉及到的硬件资源主要有两个，CPU和磁盘。任务本身由CPU触发和调度，读操作发生时，CPU告知Disk去获取某个地址的数据，此时由于Disk的读操作存在寻址延迟，CPU是处于I/O wait状态，一直维持到Disk返回数据为止。处于I/O wait状态的CPU，此时并不能把这部分等待的时间用来处理其他任务，也就是说这一段等待的CPU时间被“浪费”了。而CPU是公共的系统资源，这部分资源的损耗自然会对系统的整体表现产生负面影响。即使Global
Queue使用的是子线程，也会造成CPU资源的消耗。

如果把任务的Priority调整为DISPATCH_QUEUE_PRIORITY_BACKGROUND，那么这些任务中的I/O操作就被被控制，虽然具体的控制策略并没有官方文档描述（一种可能的策略是并发的Disk I/O变为串行的），但我们能确认的是，部分I/O操作的启动时间很有可能被适当延迟，把更多的CPU资源腾出来处理其他任务(比如说一些系统资源的调度任务)，这样可以让我们的系统更加稳定高效。简而言之，对于重度磁盘I/O依赖的后台任务，如果对实时性要求不高，放到DISPATCH_QUEUE_PRIORITY_BACKGROUND
Queue中是个好习惯，对系统更友好。

实际上I/O Throttle还分为好几种，有Disk I/O Throttle，Memory I/O Throttle，和Network I/O Throttle。语义类似只不过场景不同，继续往下看。

场景二：ASIHttpRequest Network Throttle

早几年读ASIHttpRequest源码的时候，读到过一段有意思的代码：

[code= cpp; gutter: true; first-line: 1 hljs objectivec">- (/**
Throttles request bandwidth by limiting the packet size - (button.rx_tap
.throttle(