我們遇到了一個IE8惡夢，RPC服務返回列表（或多或少）60個對象，每個對象有5個屬性。儘管現代瀏覽器能夠完成這項工作，但IE8的響應性還不夠。 甚至有關於此的open issue。GWT RPC Alternative
我們正在計劃更改需要發送大量對象列表的服務的RPC，但我們希望更改服務器和客戶端上可能的最小代碼量。
第一個問題：在這種情況下，IE8的JSON反序列化運行速度會更快嗎？
我們喜歡輕鬆的RPC服務。我們有我們的CustomRemoteService實現，我們的CustomAsyncCallback實現，我們的CustomRPCException實現等等。 RF對我們來說是一個相當大的改變。
第二個問題：使用返回單個JSON字符串的RPC服務，然後反序列化客戶端可以完成這項工作嗎？
或者你能推薦另一種方法嗎？
謝謝！
首先問：請問反序列化JSON運行在IE8更快對於這種情況？
它應該運行速度更快，因爲IE8支持原生JSON解析（和在IE6和7，您可以使用eval()應該仍然運行比手工解析字符串更快）
但高度取決於你對解析對象所做的工作：如果你對它進行處理以從中重建POJO，你可能會失去所有JSON的好處;另一方面，JS覆蓋圖沒有開銷，但要求將所有數組或列表更改爲JsArray s，並且日期不容易用JSON編碼，它們需要額外的編組/解組。
第二個問題：會使用RPC服務，它返回一個JSON字符串，然後反序列化它的客戶端能勝任這項工作？
如果您的JSON處理比RPC反序列化輕，那麼是的。在客戶端解析響應是一個簡單的eval()（是的，奇怪的是它不使用本機JSON），然後在解析對象中查找; RPC反序列化中成本最高的是解釋值以重建對象;獲取一個字符串只是一個數組中的查找，所以它將取決於你以後對該字符串的處理。
我覺得你的IE8痛苦。我們遇到了同樣的問題。我們的解決方案是將所有內容序列化到JSON客戶端，然後只發送一個JSON對象並處理繁重的服務器端。 IE8仍然沒有像我們希望的那樣快速地處理反序列化，但它確實加快了一些（大約三倍）。另一種選擇可能是懶惰地執行RPC調用，如果這種情況在您的情況下可能會發生。
問題是IE8是而不是如果您有任何大量的併發RPC調用發生，理想的瀏覽器。我希望很快看到這個bug。