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

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

使用者建立Opportunity，維護Account欄位，每輸入一個字元，都會觸發SAP UI5 Input控制元件的liveChange事件。在該事件的onAccountInputFieldChanged處理函式裡，根據使用者輸入，傳送OData請求到後臺進行查詢。

如果使用者輸入速度很快，則在短時間內，會有多個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，讓自己編寫的包含業務邏輯的事件響應函式，按照實際需求來觸發。