來自我的同事，SAP成都研究院的架構師Li Ben。

在SAP CRM Fiori App的早期開發過程中，關于live search功能上有一個問題，就是有時候發現live search返回的suggestion item并不完全匹配我們輸入的search string, 比如正常情況輸入abcde，應該匹配4個結果:

但是有時候輸入abcde，會匹配更多的結果，發現里面有些item并不匹配abcde，他們只能匹配abcd:

問題分析

用戶輸入到abcd和abcde的時候，都向后臺發出了請求查詢匹配的結果，最后將結果顯示到suggestion item中。

App請求的發送有先后順序(先發abcd，再發abcde)，但是響應處理是通過異步回調，這里不能保證處理返回結果的先后順序跟請求發送的順序一致，在用戶輸入較快，或者后臺處理需要一定時間的情況下，有可能第二個請求(abcde)先于第一個請求(abcd)返回。造成的結果是用戶最后的輸入停留在abcde，而最后的返回結果是匹配的abcd(如上圖)。

改進方案

方法1 - Throttle: 函數節流

Throttle又叫函數節流，目標是防止短時間內對一些昂貴的函數做出重復調用。

實現思想是在第一次調用函數的時候做一個定時器，同時設定一個threshold時間(函數的真正邏輯在定時器的threshold時間之后才被定時器執行)，在該threshold之內，如果該函數沒有被再次調用，就讓定時器執行該函數的邏輯代碼；如果threshold之內該函數被再次調用，取消上一次設定的定時器，重新生成一個新的定時器，讓真正的邏輯重新被推遲到threshold時間之后執行。例子:

代碼看上去還是很直觀的。
Throttle - 函數節流的更多介紹：

http://wiki.jikexueyuan.com/project/brief-talk-js/function-throttling.html

方法2：Asynchronous Completion Token(ACT):

ACT最早是用來解決通信系統的多路信號的問題，就是不同的請求發出之后，接受響應的一端需要知道每個響應對應的原始請求是什么。我們live search的問題類似，我們需要知道匹配用戶最后輸入字符串的那個響應，本質上也是ACT問題的一種。

ACT實現思路簡單講，就是給每個請求和對應的響應分配一個唯一的token，響應返回的時候校驗token，具體實現結合應用場景可能有所不同。

我在My Lead上為了驗證ACT簡單實現了一下：

(1) 定義兩個變量緩存響應和用戶的最終輸入：

(2) 在change事件觸發的方法里，讓sLastInput保持跟用戶的輸入一致。

(3) 如果緩存的響應里面已經有了匹配的結果，不需要發出請求，直接從緩存取，這里我將用戶最終輸入的字符串作為validate token。

(4) 如果緩存里面沒有匹配的結果才發出請求，在響應返回的callback里面，緩存結果并校驗token:

ACT Pattern的更多介紹: http://www.cs.wustl.edu/~schmidt/PDF/ACT.pdf

這本書里也講了ACT：

http://software-pattern.org/Book/29

比較一下Throttle和Async Completion Token:

要獲取更多Jerry的原創文章，請關注公眾號"汪子熙":

總結

以上是生活随笔為你收集整理的SAP UI5 函数节流和异步完成令牌的应用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。