SAP UI5和Angular的函數防抖(Debounce)和函數節流(Throttle)實現原理介紹

時間 2021-02-14

標籤 html git github 編程安全網絡閉包框架函數工具欄目 AngularJS 简体版

原文原文鏈接

這是Jerry 2021年的第 11 篇文章，也是汪子熙公衆號總共第 282 篇原創文章。html

Jerry以前的文章 SAP UI5 OData謠言粉碎機：極短期內發送兩個Odata request, 前一個會自動被cancel掉嗎，介紹過SAP成都研究院CRM Fiori開發團隊開發過的一個Live Search的場景。git

用戶建立Opportunity，維護Account字段，每輸入一個字符，都會觸發SAP UI5 Input控件的liveChange事件。在該事件的onAccountInputFieldChanged處理函數裏，根據用戶輸入，發送OData請求到後臺進行查詢。github

若是用戶輸入速度很快，則在短期內，會有多個OData請求發送到後臺，進而出現Jerry文章裏描述的OData請求被cancel的狀況。
編程

最近Jerry作SAP Spartacus開發，遇到了一樣的場景。所以經過本文把本身最近所學總結一下，記錄下SAP UI5和Angular裏如何使用函數防抖(Debounce)和函數節流(Throttle)來避免短期內觸發高頻次函數調用的狀況出現。安全

爲了便於講解，Jerry作了一個只包含一個Input控件的SAP UI5頁面。源代碼地址.網絡

在Input裏輸入字符，會觸發liveChange事件，將當前Input的最新內容，發送到一個我本身開發的後臺服務去。該後臺服務什麼也不作，只是簡單將收到的內容返回給UI.閉包

這個SAP UI5頁面裏的Input控件的liveChange事件處理以下：框架

從Chrome控制檯打印的輸出來看，我在一秒鐘以內，連續快速輸入了1234共4個字符，一共產生了4個發送日後臺的請求。函數

SAP UI5如何使用函數防抖(Debounce)來下降函數調用的頻次

函數防抖(Debounce)，最先源於機械開關和繼電器的術語「去彈跳」，即將多個信號合併爲一個信號。工具

想象一個你們現實生活中都會遇到的場景：進電梯。電梯都有一個自動關閉門的超時時間，假設爲2秒。當電梯檢測到有人進入時，會重置這個2秒的計時器。若是下一個2秒以內，沒有新的乘客進入電梯，電梯門纔會自動關上。

電梯延遲關門這個場景，就是一個典型的函數防抖的現實例子。電梯關門的行爲就是「函數」，經過電梯門的自動關閉超時時間，2秒，來延遲電梯門的關閉動做的執行，從而下降電梯門的關閉頻率，這就是「防抖」。

能夠想象，若是電梯門的自動關閉沒有設定超時時間，而是檢測到沒有人進出以後，當即關閉，這樣會大大增長電梯門開合的頻率，既浪費能源，也不安全。這就比如Jerry本文開頭提到的例子：既然我短期內輸入了字符1234，我指望在UI看到的，是後臺服務接收到1234後返回的結果。至於後臺如何對前三個請求，即字符1，字符12和字符123進行處理，我再也不關心。

咱們能夠仿照電梯門關閉超時時間的設定，來給SAP UI5的函數調用實現防抖控制。

下圖debounce變量是一個函數構造器，自己是一個函數，接收另外一個函數fn做爲輸入參數，職責是經過閉包，將fn改形成一個具備防抖控制功能的新函數，該新函數經過第17行的return語句返回。

防抖時間間隔經過函數構造器另外一個輸入參數delay指定。

假設咱們指定的防抖時間間隔爲3000毫秒即3秒，若是3秒以內，debounce函數構造器返回的新函數被不斷調用，此時執行上圖代碼第19行，調用clearTimeout重置計數器，此時原始函數fn不會獲得執行。這個場景能夠類比成：在電梯關門超時時間內，又有新的乘客進入，電梯超時計時器重置，電梯門不會關閉。

代碼第20行，使用setTimeout重啓超時時間間隔爲3秒的計數器，3秒事後，若是JavaScript任務隊列裏沒有其餘待執行任務，則執行原始函數fn. 代碼的第20行，比如電梯設備從新開啓了3秒的超時定時器。

若是在等待的3秒以內，沒有新的函數調用觸發，則3秒事後，執行21行的原始函數fn；這比如電梯在3秒以內，始終沒有新的乘客進入，則 3秒事後，電梯門自動關閉。

debounce函數構造器的使用方式也很簡單。

代碼第78行，將原始的sendRequest函數，以及3000毫秒的防抖時間間隔，傳入debounce構造器，返回一個兼有數據發送功能和防抖功能的debounceVersion函數。在第85行原來調用sendRequest函數的位置，改成調用debounceVersion函數便可。

函數防抖功能的測試：我在同一分鐘的第46秒，48秒，50秒，51秒四個時間點，分別輸入了1，2，3，4總共4個字符，可是在最後一次即51.996秒又過了3秒以後，才僅僅有一個請求發送到後臺：這說明3秒的函數防抖間隔生效了：

SAP UI5如何使用函數節流(Throttle)來下降函數調用的頻次

上述函數防抖的實現存在一個問題，仍是以電梯的例子來講明。

設想有一個空間無限的電梯，關門的超時時間爲3秒。若是不斷的有新的乘客以小於3秒的時間間隔進入電梯，則電梯門永遠沒有機會關閉——即函數永遠得不到執行。

函數節流(Throttle)是另外一種下降函數調用頻次的思路，同函數防抖的區別是，後者能保證在指定的節流間隔內，至少執行一次函數。

函數節流構造器的一個最簡單的實現版本：

被節流器改造後的函數每次觸發時，取一個當前系統時間戳，同前一次觸發時取的時間戳比較。若是兩者的時間差，大於等於構造器的輸入參數delay即節流時間間隔，則進入第39行的else分支，觸發原始函數fn；不然說明節流時間間隔還未到達，使用第34行setTimeout，將原始函數fn，從新放入JavaScript事件隊列內，延遲執行：

函數節流版本的構造器使用方式，同函數防抖版本的構造器沒有差異：將原始函數sendRequest傳入構造器throttle，返回一個具備節流功能的新函數throttleVersion，在Input控件liveChange事件處理函數裏，調用throttleVersion這個新函數便可。

函數節流的測試結果：我設置的節流時間間隔爲3秒，從Chrome控制檯打印輸出能觀察到，SAP UI5確實是大體以3秒的時間間隔，向後臺發起的數據請求。

本文介紹的兩種函數防抖和函數節流的實現代碼，僅僅考慮了最基本的狀況，還有不少不完善的地方，有興趣的朋友能夠在網絡上搜索，這方面的資料很是多，這裏再也不贅述。

Jerry以前的分享提到過，Angular是響應式編程開發庫RxJS的重度使用者，後者提供了衆多功能強大的Operators，使得Angular開發人員不用重複造輪子，就能輕易實現出具備函數防抖和函數節流的場景。

用Angular從新實現本文SAP UI5的Demo，總共代碼只有44行：

從rxjs/operators工具庫中直接導出debounceTime和throttleTime這兩個operators：

相似SAP UI5 Input控件的liveChange，Angular FormControl的valueChanges也給應用開發人員提供了編寫業務邏輯，響應用戶輸入的位置：後者的valueChanges數據類型是Observable，應用開發人員能夠經過pipe調用，傳入RxJS各類功能強大的Operators，讓本身編寫的包含業務邏輯的事件響應函數，按照實際需求來觸發。