前言：

自己一直以來被公司的各種項目丫的比較忙刻帚，所以一直以來自己的寫的原文都是比較少的潦嘶，但是還是會盡力抽出時間來閱讀一些技術(shù)文章，并在這里把看到好的文章進行一次轉(zhuǎn)發(fā)崇众，希望能有更多好學(xué)和希望自己技術(shù)進階的童鞋們一點小福音掂僵，廢話不多說，讓咱們開始撒顷歌。

不知道大家對throttle這個單詞是否看著眼熟锰蓬，還是說對這個計算機基礎(chǔ)概念有很清晰的了解了。今天就來聊聊和throttle相關(guān)的一些技術(shù)場景眯漩。

定義

我經(jīng)常有一種感覺芹扭，對于英語這門語言的語感，會影響我們對于一些關(guān)鍵技術(shù)概念的理解赦抖。有時候在學(xué)習(xí)新技術(shù)知識的時候舱卡，我會先花一些時間去了解術(shù)語英文單詞的各種語義，在形成強烈清晰的語感之后队萤，再去深入具體的技術(shù)語境轮锥。throttle也算是個生僻的單詞，至少在口語中畢竟少用到要尔，先來看看詞義：

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

中文翻譯是節(jié)流器舍杜，一種控制流量的設(shè)備。對應(yīng)到我們計算機世界赵辕，可以理解成既绩，一種控制數(shù)據(jù)或者事件流量大小的機制。這么說可能還是有些抽象还惠，再來看看一些具體的技術(shù)場景加深理解饲握。

場景一：GCD Background Queue

話說GCD幾乎是iOS面試的必問題，也是個送分題:)。

我一般會機械式的先問：GCD有哪幾種Queue救欧？回答：串行Queue和并行Queue歪今。

我繼續(xù)問：Global Queue有哪幾種優(yōu)先級？回答：有幾種吧颜矿，大概記得Default，Low嫉晶，High吧骑疆。

我雙眉一挑，進一步試探：不知道少俠有沒有研究過DISPATCH_QUEUE_PRIORITY_BACKGROUND作何用替废？問完立即豎起耳朵箍铭，殷殷期盼縈繞于心的關(guān)鍵字。如果能聽到「I/O Throttle 呀椎镣！」诈火，我會瞬間覺得面試氣氛被點亮了。

當(dāng)然啦状答，答不出I/O Throttle并不能說明技術(shù)不扎實冷守，但能答出來，至少表明對待技術(shù)是有好奇心的惊科，加分拍摇！

官方文檔如是說：

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的影響需要補充一些大學(xué)課本上的知識。一次磁盤讀寫操作涉及到的硬件資源主要有兩個蜡娶，CPU和磁盤混卵。任務(wù)本身由CPU觸發(fā)和調(diào)度，讀操作發(fā)生時窖张，CPU告知Disk去獲取某個地址的數(shù)據(jù)幕随，此時由于Disk的讀操作存在尋址延遲，CPU是處于I/O wait狀態(tài)荤堪，一直維持到Disk返回數(shù)據(jù)為止合陵。處于I/O wait狀態(tài)的CPU，此時并不能把這部分等待的時間用來處理其他任務(wù)澄阳，也就是說這一段等待的CPU時間被“浪費”了拥知。而CPU是公共的系統(tǒng)資源，這部分資源的損耗自然會對系統(tǒng)的整體表現(xiàn)產(chǎn)生負(fù)面影響碎赢。即使Global Queue使用的是子線程低剔，也會造成CPU資源的消耗。

如果把任務(wù)的Priority調(diào)整為DISPATCH_QUEUE_PRIORITY_BACKGROUND，那么這些任務(wù)中的I/O操作就被被控制襟齿，雖然具體的控制策略并沒有官方文檔描述（一種可能的策略是并發(fā)的Disk I/O變?yōu)榇械模┮鏊覀兡艽_認(rèn)的是，部分I/O操作的啟動時間很有可能被適當(dāng)延遲猜欺，把更多的CPU資源騰出來處理其他任務(wù)(比如說一些系統(tǒng)資源的調(diào)度任務(wù))位隶，這樣可以讓我們的系統(tǒng)更加穩(wěn)定高效。簡而言之开皿，對于重度磁盤I/O依賴的后臺任務(wù)涧黄，如果對實時性要求不高，放到DISPATCH_QUEUE_PRIORITY_BACKGROUND Queue中是個好習(xí)慣赋荆，對系統(tǒng)更友好笋妥。

實際上I/O Throttle還分為好幾種，有Disk I/O Throttle窄潭，Memory I/O Throttle春宣，和Network I/O Throttle。語義類似只不過場景不同嫉你，繼續(xù)往下看月帝。

場景二：ASIHttpRequest Network Throttle

早幾年讀ASIHttpRequest源碼的時候，讀到過一段有意思的代碼：

- (void)handleNetworkEvent:(CFStreamEventType)type

{

[self performThrottling];

}

在AFNetworking中也有類似的代碼：

/**Throttles request bandwidth by limiting the packet size and adding a delay for each chunk read from the upload stream.When uploading over a 3G or EDGE connection, requests may fail with "request body stream exhausted". Setting a maximum packet size and delay according to the recommended values (`kAFUploadStream3GSuggestedPacketSize` and `kAFUploadStream3GSuggestedDelay`) lowers the risk of the input stream exceeding its allocated bandwidth. Unfortunately, there is no definite way to distinguish between a 3G, EDGE, or LTE connection over `NSURLConnection`. As such, it is not recommended that you throttle bandwidth based solely on network reachability. Instead, you should consider checking for the "request body stream exhausted" in a failure block, and then retrying the request with throttled bandwidth.

@param numberOfBytes Maximum packet size, in number of bytes. The default packet size for an input stream is 16kb.

@param delay Duration of delay each time a packet is read. By default, no delay is set.

*/

- (void)throttleBandwidthWithPacketSize:(NSUInteger)numberOfBytes

delay:(NSTimeInterval)delay;

原諒我貼了一大段注釋幽污，這段英文描述對于加深我們對于一些網(wǎng)絡(luò)行為的理解很有幫助嫁赏。

這些知名的第三方網(wǎng)絡(luò)框架都有對Newtork Throttle的支持，你可能會好奇油挥，我們?yōu)槭裁匆獙ψ约喊l(fā)出的網(wǎng)絡(luò)請求做流量控制潦蝇，難道不應(yīng)該盡可能最大限度的利用帶寬嗎？

此處需要科普一點TCP協(xié)議相關(guān)的知識深寥。我們通過HTTP請求發(fā)送數(shù)據(jù)的時候攘乒，實際上數(shù)據(jù)是以Packet的形式存在于一個Send Buffer中的，應(yīng)用層平時感知不到這個Buffer的存在惋鹅。TCP提供可靠的傳輸则酝，在弱網(wǎng)環(huán)境下，一個Packet一次傳輸失敗的概率會升高闰集，即使一次失敗沽讹，TCP并不會馬上認(rèn)為請求失敗了，而是會繼續(xù)重試一段時間武鲁，同時TCP還保證Packet的有序傳輸爽雄，意味著前面的Packet如果不被ack，后面的Packet就會繼續(xù)等待沐鼠，如果我們一次往Send Buffer中寫入大量的數(shù)據(jù)挚瘟，那么在弱網(wǎng)環(huán)境下叹谁，排在后面的Packet失敗的概率會變高，也就意味著我們HTTP請求失敗的幾率會變大乘盖，類似這樣：

大部分時候在應(yīng)用層寫代碼的時候焰檩，估計不少同學(xué)都意識不到Newtork Throttle這種機制的存在，在弱網(wǎng)環(huán)境下（丟包率高订框，帶寬低析苫，延遲高）一些HTTP請求(比如上傳圖片或者日志文件)失敗率會激增，有些朋友會覺得這個我們也沒辦法穿扳，畢竟網(wǎng)絡(luò)辣么差藤违。其實，作為有追求的工程師纵揍，我們可以多做一點點，而且弱網(wǎng)下請求的成功率其實是個很值得深入研究的方向议街。針對弱網(wǎng)場景泽谨，我們可以啟用Newtork Throttle機制，減小我們一次往Send Buffer中寫入的數(shù)據(jù)量特漩，或者延遲某些請求的發(fā)送時間吧雹，這樣所有的請求在弱網(wǎng)環(huán)境下，都能「耐心一點涂身，多等一會」雄卷，請求成功率自然也就適當(dāng)提高啦。

那么蛤售，再看AFNetworking中的這個函數(shù)丁鹉，是不是更能理解了呢？

- (void)throttleBandwidthWithPacketSize:(NSUInteger)numberOfBytes

delay:(NSTimeInterval)delay;

Network Throttle體現(xiàn)了一句至理名言「慢即是快」悴能。

場景三：Event Frequency Control

不知道大家在寫UI的時候揣钦，有沒有遇到過用戶快速連續(xù)點擊UIButton，產(chǎn)生多次Touch事件回調(diào)的場景漠酿。以前機器還沒那么快的時候冯凹，我在用一些App的時候，時不時會遇到偶爾卡頓炒嘲，多次點擊一個Button宇姚，重復(fù)Push同一個Controller。有些工程師會在Button的點擊事件里記錄一個timestamp夫凸，然后判斷每次點擊的時間間隔浑劳，間隔過短就忽略，這也不失為一種解決辦法夭拌。

再后來學(xué)習(xí)RxSwift的時候呀洲，看到：

button.rx_tap

.throttle(0.5, MainScheduler.instance)

.subscribeNext { _ in

print("Hello World")

}

.addDisposableTo(disposeBag)

終于有了優(yōu)雅的書寫方式。發(fā)現(xiàn)沒有，throttle又出現(xiàn)了道逗，這里throttle控制的是什么呢兵罢？不是disk讀寫，也不是network buffer滓窍，而是事件卖词，把事件本身抽象成了一種Data，控制這種數(shù)據(jù)的流量或者產(chǎn)生頻率吏夯，就解決了上面我們所說重復(fù)點擊按鈕的問題此蜈，so easy。

總結(jié)

當(dāng)然還會有更多的場景噪生，throttle其實是個基礎(chǔ)的計算機知識裆赵。理解throttle相關(guān)的技術(shù)概念，需要在不同場景下去抽象出一個flow被節(jié)流的畫面。現(xiàn)在，如果讓你來解釋一些具體的技術(shù)場景下胞皱，throttle是怎么回事谬运，是不是可以信手拈來了:)