iOS編程中throttle的事

不知道你們對throttle這個單詞是否看着眼熟，仍是說對這個計算機基礎概念有很清晰的瞭解了。今天就來聊聊和throttle相關的一些技術場景。

iOS開發交流技術羣：563513413，無論你是大牛仍是小白都歡迎入駐 ，分享BAT,阿里面試題、面試經驗，討論技術， 你們一塊兒交流學習成長！

定義
我常常有一種感受，對於英語這門語言的語感，會影響咱們對於一些關鍵技術概念的理解。有時候在學習新技術知識的時候，我會先花一些時間去了解術語英文單詞的各類語義，在造成強烈清晰的語感以後，再去深刻具體的技術語境。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源碼的時候，讀到過一段有意思的代碼：

Ios代碼

1.  - (void)handleNetworkEvent:(CFStreamEventType)type  
2.  {  
3.  //...  
4.  [self performThrottling];  
5.  //...  
6.  }

在AFNetworking中也有相似的代碼：

Swift代碼

1.  /**  
2.  Throttles request bandwidth by limiting the packet size and adding a delay for each chunk read from the upload stream.  

4.  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.  

6.  @param numberOfBytes Maximum packet size, in number of bytes. The default packet size for an input stream is 16kb.  
7.  @param delay Duration of delay each time a packet is read. By default, no delay is set.  
8.  */  
9.  - (void)throttleBandwidthWithPacketSize:(NSUInteger)numberOfBytes  
10.  delay:(NSTimeInterval)delay;

原諒我貼了一大段註釋，這段英文描述對於加深咱們對於一些網絡行爲的理解頗有幫助。

這些知名的第三方網絡框架都有對Newtork Throttle的支持，你可能會好奇，咱們爲何要對本身發出的網絡請求作流量控制，難道不該該儘量最大限度的利用帶寬嗎？

此處須要科普一點TCP協議相關的知識。咱們經過HTTP請求發送數據的時候，實際上數據是以Packet的形式存在於一個Send Buffer中的，應用層平時感知不到這個Buffer的存在。TCP提供可靠的傳輸，在弱網環境下，一個Packet一次傳輸失敗的機率會升高，即便一次失敗，TCP並不會立刻認爲請求失敗了，而是會繼續重試一段時間，同時TCP還保證Packet的有序傳輸，意味着前面的Packet若是不被ack，後面的Packet就會繼續等待，若是咱們一次往Send Buffer中寫入大量的數據，那麼在弱網環境下，排在後面的Packet失敗的機率會變高，也就意味着咱們HTTP請求失敗的概率會變大，相似這樣：

image

大部分時候在應用層寫代碼的時候，估計很多同窗都意識不到Newtork Throttle這種機制的存在，在弱網環境下（丟包率高，帶寬低，延遲高）一些HTTP請求(好比上傳圖片或者日誌文件)失敗率會激增，有些朋友會以爲這個咱們也沒辦法，畢竟網絡辣麼差。其實，做爲有追求的工程師，咱們能夠多作一點點，並且弱網下請求的成功率實際上是個很值得深刻研究的方向。針對弱網場景，咱們能夠啓用Newtork Throttle機制，減少咱們一次往Send Buffer中寫入的數據量，或者延遲某些請求的發送時間，這樣全部的請求在弱網環境下，都能「耐心一點，多等一會」，請求成功率天然也就適當提升啦。

那麼，再看AFNetworking中的這個函數，是否是更能理解了呢？

Swift代碼

1.  - (void)throttleBandwidthWithPacketSize:(NSUInteger)numberOfBytes  
2.  delay:(NSTimeInterval)delay;

Network Throttle體現了一句至理名言「慢便是快」。

場景三：Event Frequency Control
不知道你們在寫UI的時候，有沒有遇到過用戶快速連續點擊UIButton，產生屢次Touch事件回調的場景。之前機器還沒那麼快的時候，我在用一些App的時候，時不時會遇到偶爾卡頓，屢次點擊一個Button，重複Push同一個Controller。有些工程師會在Button的點擊事件裏記錄一個timestamp，而後判斷每次點擊的時間間隔，間隔太短就忽略，這也不失爲一種解決辦法。

再後來學習RxSwift的時候，看到：

Rxswift代碼

1.  button.rx_tap  
2.  .throttle(0.5, MainScheduler.instance)  
3.  .subscribeNext { _ in   
4.  print("Hello World")  
5.  }  
6.  .addDisposableTo(disposeBag)

終於有了優雅的書寫方式。發現沒有，throttle又出現了，這裏throttle控制的是什麼呢？不是disk讀寫，也不是network buffer，而是事件，把事件自己抽象成了一種Data，控制這種數據的流量或者產生頻率，就解決了上面咱們所說重複點擊按鈕的問題，so easy。

總結
固然還會有更多的場景，throttle實際上是個基礎的計算機知識。理解throttle相關的技術概念，須要在不一樣場景下去抽象出一個flow被節流的畫面。如今，若是讓你來解釋一些具體的技術場景下，throttle是怎麼回事，是否是能夠信手拈來

來自: mrpeak