背景

有時我們能在Chrome開發者工具的Network tab里觀察到SAP UI5應用會發出某些狀態為"取消"的OData請求。如下圖第五個請求。

之前有一種似是而非的說法:極短時間內發送兩個OData請求，則第一個會自動被cancel掉。

這個說法從字面上看，有兩點值得推敲:

1. cancel掉，被誰cancel掉？UI5框架還是Chrome？

2. “極短”，多短算極短？

我用代碼在for循環里一共發10個OData請求：

無論是同步還是異步，都沒有任何的請求被cancel。

10個同步請求：

10個異步請求：

就算發100個request都不會有一個request被cancel:

驗證結果，之前的說法“極短時間內發送兩個OData request，前一個會自動被cancel掉”是錯誤的。

那再回到本文第一張圖觀察到的cancel的場景, 原因究竟是什么？

觀察產生了被取消的OData請求的應用代碼，觀察到第523行有這個refresh操作：

在這個方法的第601行，bChangeDetected變量為true導致abortPendingRequest的調用。

abortPendingRequest的注釋已經很清楚地說明問題了。

什么情況下會導致AbortPendingRequest? 直接使用Chrome開發者工具的全文搜索得到答案：OData model的三個API: filter, sort, refresh

下面是我的同事Li Ben的進一步補充。

關于這個現象發生的原因和條件的問題

1. 在哪里可以看到這個cancel現象?

在我們的live search功能上，如果輸入較快或者正常速度輸入，會看到前面很多輸入請求都會被cancel掉:

如果輸入較慢則不會:

真的是快慢的原因嗎？

仔細觀察network發現，真正的原因是當上一次的network還處于pending狀態的時候，繼續輸入發起的請求就會cancel掉上一次的請求:

繼續深究， 這是在哪里做到的？

在SAP UI5的OData框架里面有這樣的實現:

在ODataModel.js中維護了一個http request的pending list，將已經發送但是還沒有收到響應的request對象都緩存在這個列表中:

每次發起OData請求的時候都會調用ODataModel的_request()方法，這個方法會把當前的request加到pending list中，并且通過一個wrap method包裝回調函數，確保在響應返回的時候首先把緩存的request對象從pending list中拿掉:

每次在OData Model上發起filter, sort, refresh操作的時候，都會檢查是否存在pending的request對象，如果存在未完成的請求，abort掉它:

回答上面的問題，在什么情況下會發生這種現象?

1. 同一個ODataModel的instance上發出的連續請求，因為pending list是緩存在this級別上面的。

2. 前一個Http請求的network還處于pending status的時候。

3. 就讀ODataModel的代碼和觀察到的現象，在ODataModel上發起filter, sort或者refresh的時候。

為什么在OData的request對象上發起abort調用就可以取消底層的network call?

簡單的說，UI5里面的OData Request對象是底層的Ajax Request對象XmlHttpRequest的一個代理，在ODataModel的_submit方法中:

具體實現是UI5中利用了一個第三方的庫datajs，datajs最終會調用瀏覽器的底層http對象XMLHttpRequest:

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

總結

以上是生活随笔為你收集整理的谣言粉碎机 - 极短时间内发送两个Odata request，前一个会自动被cancel掉?的全部內容，希望文章能夠幫你解決所遇到的問題。

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