Question
From: Wang, Jerry
Sent: Friday, 19 June, 2015 4:31 PM
Subject: RE: [Follow up] Why the synchronous request did not BLOCK the UI
Hi all,
這個issue很有意思，昨天和德國同僚開會時，他們問我們為什麼我們code裡寫的odata request是同步的，但是并沒有block 住UI。當時我沒答上來，因為确實我看起來也是沒block UI。
今天我做了研究，通過圖表和視訊 理直氣壯地告訴他們：代碼沒問題，是我們眼睛犯錯了。視訊在下面的share folder裡。研究思路在下面的郵件裡。
Please read more detail from Jerry’s mail.
Jerry’s analysis process
手動在背景reques響應裡加上一個延時，來模拟背景耗時很長的scenario.
Then I test in UI with this modified Odata implementation. Now as expected it took around 13 seconds to get the returned image url.
During this timeframe, UI is completely freezed: end user does not have any chances to click anything in UI.
Synchronous mode
Afterwards the synchronous behavior is quite obvious now. I click one item in navigation list to trigger the synchronous request for Image url retrieval. And after that, I cannot do any operation on UI - it is completely freezed.
Please refer to attached video “synchronous.wmv”.
Asynchronous mode
Then I change the manual latency to 20 seconds and retest the UI.
Now every time I click one opportunity in the navigation list, still one http request for image logo is sent out. Compared with synchronous mode, this time the UI is not blocked - I can continue to work on UI without waiting for the response.
This asynchronous behavior could also easily be found in the timechart in Chrome network: