背景

有時(shí)我們能在Chrome開(kāi)發(fā)者工具的Network tab里觀察到SAP UI5應(yīng)用會(huì)發(fā)出某些狀態(tài)為"取消"的OData請(qǐng)求。如下圖第五個(gè)請(qǐng)求。

之前有一種似是而非的說(shuō)法:極短時(shí)間內(nèi)發(fā)送兩個(gè)OData請(qǐng)求，則第一個(gè)會(huì)自動(dòng)被cancel掉。

這個(gè)說(shuō)法從字面上看，有兩點(diǎn)值得推敲:

1. cancel掉，被誰(shuí)cancel掉？UI5框架還是Chrome？

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

我用代碼在for循環(huán)里一共發(fā)10個(gè)OData請(qǐng)求：

無(wú)論是同步還是異步，都沒(méi)有任何的請(qǐng)求被cancel。

10個(gè)同步請(qǐng)求：

10個(gè)異步請(qǐng)求：

就算發(fā)100個(gè)request都不會(huì)有一個(gè)request被cancel:

驗(yàn)證結(jié)果，之前的說(shuō)法“極短時(shí)間內(nèi)發(fā)送兩個(gè)OData request，前一個(gè)會(huì)自動(dòng)被cancel掉”是錯(cuò)誤的。

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

觀察產(chǎn)生了被取消的OData請(qǐng)求的應(yīng)用代碼，觀察到第523行有這個(gè)refresh操作：

在這個(gè)方法的第601行，bChangeDetected變量為true導(dǎo)致abortPendingRequest的調(diào)用。

abortPendingRequest的注釋已經(jīng)很清楚地說(shuō)明問(wèn)題了。

什么情況下會(huì)導(dǎo)致AbortPendingRequest? 直接使用Chrome開(kāi)發(fā)者工具的全文搜索得到答案：OData model的三個(gè)API: filter, sort, refresh

下面是我的同事Li Ben的進(jìn)一步補(bǔ)充。

關(guān)于這個(gè)現(xiàn)象發(fā)生的原因和條件的問(wèn)題

1. 在哪里可以看到這個(gè)cancel現(xiàn)象?

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

如果輸入較慢則不會(huì):

真的是快慢的原因嗎？

仔細(xì)觀察network發(fā)現(xiàn)，真正的原因是當(dāng)上一次的network還處于pending狀態(tài)的時(shí)候，繼續(xù)輸入發(fā)起的請(qǐng)求就會(huì)cancel掉上一次的請(qǐng)求:

繼續(xù)深究， 這是在哪里做到的？

在SAP UI5的OData框架里面有這樣的實(shí)現(xiàn):

在ODataModel.js中維護(hù)了一個(gè)http request的pending list，將已經(jīng)發(fā)送但是還沒(méi)有收到響應(yīng)的request對(duì)象都緩存在這個(gè)列表中:

每次發(fā)起OData請(qǐng)求的時(shí)候都會(huì)調(diào)用ODataModel的_request()方法，這個(gè)方法會(huì)把當(dāng)前的request加到pending list中，并且通過(guò)一個(gè)wrap method包裝回調(diào)函數(shù)，確保在響應(yīng)返回的時(shí)候首先把緩存的request對(duì)象從pending list中拿掉:

每次在OData Model上發(fā)起filter, sort, refresh操作的時(shí)候，都會(huì)檢查是否存在pending的request對(duì)象，如果存在未完成的請(qǐng)求，abort掉它:

回答上面的問(wèn)題，在什么情況下會(huì)發(fā)生這種現(xiàn)象?

1. 同一個(gè)ODataModel的instance上發(fā)出的連續(xù)請(qǐng)求，因?yàn)閜ending list是緩存在this級(jí)別上面的。

2. 前一個(gè)Http請(qǐng)求的network還處于pending status的時(shí)候。

3. 就讀ODataModel的代碼和觀察到的現(xiàn)象，在ODataModel上發(fā)起filter, sort或者refresh的時(shí)候。

為什么在OData的request對(duì)象上發(fā)起abort調(diào)用就可以取消底層的network call?

簡(jiǎn)單的說(shuō)，UI5里面的OData Request對(duì)象是底層的Ajax Request對(duì)象XmlHttpRequest的一個(gè)代理，在ODataModel的_submit方法中:

具體實(shí)現(xiàn)是UI5中利用了一個(gè)第三方的庫(kù)datajs，datajs最終會(huì)調(diào)用瀏覽器的底層http對(duì)象XMLHttpRequest:

要獲取更多Jerry的原創(chuàng)技術(shù)文章，請(qǐng)關(guān)注公眾號(hào)"汪子熙":

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。