iOS編程中throttle那些事

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

定義

我經常有一種feel,對于英語這門語言的語感,會影響我們對于一些關鍵技術概念的理解。有時候在學習新技術知識的時候,我會先花一些時間去了解術語英文單詞的各種語義,在形成強烈清晰的語感之后,再去深入具體的技術語境。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源碼的時候,讀到過一段有意思的代碼:

- (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;

原諒我貼了一大段注釋,這段英文描述對于加深我們對于一些網絡行為的理解很有幫助。

這些知名的第三方網絡框架都有對Newtork Throttle的支持,你可能會好奇,我們為什么要對自己發出的網絡請求做流量控制,難道不應該盡可能最大限度的利用帶寬嗎?

此處需要科普一點TCP協議相關的知識。我們通過HTTP請求發送數據的時候,實際上數據是以Packet的形式存在于一個Send Buffer中的,應用層平時感知不到這個Buffer的存在。TCP提供可靠的傳輸,在弱網環境下,一個Packet一次傳輸失敗的概率會升高,即使一次失敗,TCP并不會馬上認為請求失敗了,而是會繼續重試一段時間,同時TCP還保證Packet的有序傳輸,意味著前面的Packet如果不被ack,后面的Packet就會繼續等待,如果我們一次往Send Buffer中寫入大量的數據,那么在弱網環境下,排在后面的Packet失敗的概率會變高,也就意味著我們HTTP請求失敗的幾率會變大,類似這樣:


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

那么,再看AFNetworking中的這個函數,是不是更能理解了呢?

- (void)throttleBandwidthWithPacketSize:(NSUInteger)numberOfBytes
                                  delay:(NSTimeInterval)delay;

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

場景三:Event Frequency Control

不知道大家在寫UI的時候,有沒有遇到過用戶快速連續點擊UIButton,產生多次Touch事件回調的場景。以前機器還沒那么快的時候,我在用一些App的時候,時不時會遇到偶爾卡頓,多次點擊一個Button,重復Push同一個Controller。有些工程師會在Button的點擊事件里記錄一個timestamp,然后判斷每次點擊的時間間隔,間隔過短就忽略,這也不失為一種解決辦法。

再后來學習RxSwift的時候,看到:

button.rx_tap
   .throttle(0.5, MainScheduler.instance)
   .subscribeNext { _ in 
      print("Hello World")
   }
   .addDisposableTo(disposeBag)

終于有了優雅的書寫方式。發現沒有,throttle又出現了,這里throttle控制的是什么呢?不是disk讀寫,也不是network buffer,而是事件,把事件本身抽象成了一種數據,控制這種數據的流量或者產生頻率,就解決了上面我們所說重復點擊按鈕的問題,so easy。

總結

當然還會有更多的場景,throttle其實是個基礎的計算機知識。理解throttle相關的技術概念,需要在不同場景下去抽象出一個flow被節流的畫面。現在,如果讓你來解釋一些具體的技術場景下,throttle是怎么回事,是不是可以信手拈來了:)

來源:MrPeakTech

上一篇: Swift 面試題

下一篇: 蘋果紀念iPhone發布10周年: 革命還在繼續

分享到: 更多
北京pk赛车开结果 排列三组六玩法 重庆时时猜龙虎走秘籍 天津时时彩 吉林快三彩票 1肖主3码三肖期期準 福彩3d什么是组选包胆 复式6码二中二是怎么样的 好彩客大小彩票计划软件 快三怎么玩法介绍视频 广东11选5计划软件手机版 二人麻将棋牌 二人麻将规则及玩法 pt电子游戏大奖视频 澳门21点规则 二人雀神麻将番数图解