淺談如何提高AJAX客戶端響應速度
筆者從事AJAX 方面的研發(fā)多年，參與開發(fā)了目前國內(nèi)較為成熟的AJAX平臺 -dorado 。根據(jù)筆者的經(jīng)驗，導致這種結(jié)果的根本原因并不在AJAX 。很多時候系統(tǒng)響應速度的降低都是由不夠合理的界面設計和不夠高效的編程習慣造成的。下面我們就來分析幾個 AJAX 開發(fā)過程中需要時刻注意的環(huán)節(jié)。
<!-- [if !supportLists]-->n <!-- [endif]-->合理的使用AJAX客戶端編程和遠程過程調(diào)用。
AJAX客戶端的編程主要都是基于 JavaScript 的。而 JavaScript 是一種解釋型的編程語言，它的運行效率相對于 Java 等都要稍遜一籌。同時 JavaScript 又是運行在瀏覽器這樣一個嚴格受限的環(huán)境當中。因此開發(fā)人員對于哪些邏輯可以在客戶端執(zhí)行應該有一個清醒的認識。
在實際的應用中究竟應該怎樣使用 客戶端編程，這依賴于開發(fā)人員的經(jīng)驗判斷。這里很多問題是只可意會的。由于篇幅有限，在這里我們大致歸納出下面這幾個注意事項：
<!-- [if !supportLists]-->u <!-- [endif]-->盡可能避免頻繁的使用遠程過程調(diào)用，例如避免在循環(huán)體中使用遠程過程調(diào)用。
<!-- [if !supportLists]-->u <!-- [endif]-->如果可能的話盡可能使用 AJAX 方式的遠程過程調(diào)用（異步方式的遠程過程調(diào)用）。
<!-- [if !supportLists]-->u <!-- [endif]-->避免將重量級的數(shù)據(jù)操作放置在 客戶端。例如：大批量的數(shù)據(jù)復制操作、需要通過大量的數(shù)據(jù)遍歷完成的計算等。
<!-- [if !supportLists]-->n <!-- [endif]-->改進對 DOM 對象的操作方式。
客戶端的編程中，對 DOM 對象的操作往往是最容易占用 CPU 時間的。而對于 DOM 對象的操作，不同的編程方法之間的性能差異又往往是非常大的。
以下是三段運行結(jié)果完全相同的代碼，它們的作用是在網(wǎng)頁中創(chuàng)建一個 10x1000 的表格。然而它們的運行速度卻有著天壤之別。
- /* 測試代碼 1 - 耗時 : 41 秒 */
- var table = document.createElement("TABLE");
- document.body.appendChild(table);
- for(var i = 0; i < 1000; i++){
- var row = table.insertRow(-1);
- for(var j = 0; j < 10; j++){
- var cell = objRow.insertCell(-1);
- cell.innerText = "( " + i + " , " + j + " )";
- }
- }
- /* 測試代碼 2 - 耗時 : 7.6 秒 */
- var table = document.getElementById("TABLE");
- document.body.appendChild(table);
- var tbody = document.createElement("TBODY");
- table.appendChild(tbody);
- for(var i = 0; i < 1000; i++){
- var row = document.createElement("TR");
- tbody.appendChild(row);
- for(var j = 0; j < 10; j++){
- var cell = document.createElement("TD");
- row.appendChild(cell);
- cell.innerText = "( " + i + " , " + j + " )";
- }
- }
- /* 測試代碼 3 - 耗時 : 1.26 秒 */
- var tbody = document.createElement("TBODY");
- for(var i = 0; i < 1000; i++){
- var row = document.createElement("TR");
- for(var j = 0; j < 10; j++){
- var cell = document.createElement("TD");
- cell.innerText = "( " + i + " , " + j + " )";
- row.appendChild(cell);
- }
- tbody.appendChild(row);
- }
- var table = document.getElementById("TABLE");
- table.appendChild(tbody);
- document.body.appendChild(table);
這里的“測試代碼 1 ”和“測試代碼 2 ”之間的差別在于在創(chuàng)建表格單元時使用了不同的 API 方法。而“測試代碼 2 ”和“測試代碼 3 ” 之間的差別在于處理順序的略微不同。
“測試代碼 1 ”和“測試代碼 2 ”之間如此大的性能差別我們無從分析，目前所知的是 insertRow 和 insertCell 是 DHTML 中表格特有的 API ， createElement 和 appendChild 是 W3C DOM 的原生 API 。而前者應該是對后者的封裝。不過，我們并不能因此而得出結(jié)論認為 DOM 的原生 API 總是優(yōu)于對象特有的 API 。建議大家在需要頻繁調(diào)用某一 API 時，對其性能表現(xiàn)做一些基本的測試。
“測試代碼 2 ”和“測試代碼 3 ”之間的性能差異主要來自于他們的構建順序不同。“測試代碼 2 ”的做法是首先創(chuàng)建最外層的 <TABLE> 對象，然后再在循環(huán)中依次創(chuàng)建 <TR> 和 <TD> 。而“測試代碼 3 ”的做法是首先在內(nèi)存中由內(nèi)到外的構建好整個表格，***再將它添加到網(wǎng)頁中。這樣做的目的是盡可能的減少瀏覽器重新計算頁面布局的次數(shù)。每當我們將一個對象添加到網(wǎng)頁中時，瀏覽器都會嘗試對頁面中的控件的布局進行重新計算。所以，如果我們能夠首先在內(nèi)存中將整個要構造的對象全部創(chuàng)建好，然后再一次性的添加到網(wǎng)頁中。那么，瀏覽器將只會做一次布局的重計算 。總結(jié)為一句話那就是越晚執(zhí)行 appendChild 越好。有時為了提高運行效率，我們甚至可以考慮先使用 removeChild 將已存在的控件從頁面中移除，然后構造完成后再重新將其放置回頁面當中。
<!-- [if !supportLists]-->n <!-- [endif]-->提高字符串累加的速度
在使用 AJAX 提交信息時，我可能常常需要拼裝一些比較大的字符串通過 XmlHttp 來完成 POST 提交。盡管提交這樣大的信息的做法看起來并不優(yōu)雅，但有時我們可能不得不面對這樣的需求。那么 JavaScript 中對字符串的累加速度如何呢？我們先來做下面的這個實驗。累加一個長度為 30000 的字符串。
- /* 測試代碼 1 - 耗時 : 14.325 秒 */
- var str = "";
- for (var i = 0; i < 50000; i++) {
- str += "xxxxxx";
- }
這段代碼耗時 14.325 秒，結(jié)果并不理想。現(xiàn)在我們將代碼改為如下的形式：
- /* 測試代碼 2 - 耗時 : 0.359 秒 */
- var str = "";
- for (var i = 0; i < 100; i++) {
- var sub = "";
- for (var j = 0; j < 500; j++) {
- sub += "xxxxxx";
- }
- str += sub;
- }
這段代碼耗時 0.359 秒！同樣的結(jié)果，我們做的只是首先拼裝一些較小的字符串然后再組裝成更大的字符串。這種做法可以有效的在字符串拼裝的后期減小內(nèi)存復制的數(shù)據(jù)量。知道了這一原理之后我們還可以把上面的代碼進一步拆散以后進行測試。下面的代碼僅耗時 0.140 秒。
- /* 測試代碼 3 - 耗時 : 0.140 秒 */
- var str = "";
- for (var i1 = 0; i1 < 5; i1++) {
- var str1 = "";
- for (var i2 = 0; i2 < 10; i2++) {
- var str2 = "";
- for (var i3 = 0; i3 < 10; i3++) {
- var str3 = "";
- for (var i4 = 0; i4 < 10; i4++) {
- var str4 = "";
- for (var i5 = 0; i5 < 10; i5++) {
- str4 += "xxxxxx";
- }
- str3 += str4;
- }
- str2 += str3;
- }
- str1 += str2;
- }
- str += str1;
- }
不過，上面這種做法也許并不是***的！如果我們需要提交的信息是 XML 格式的（其實絕大多數(shù)情況下，我們都可以設法將要提交的信息組裝成 XML 格式），我們還能找到更高效更優(yōu)雅的方法 — 利用 DOM 對象為我們組裝字符串。下面這段代買組裝一個長度為 950015 的字符串僅須耗時 0.890 秒。
- /* 利用 DOM 對象組裝信息 - 耗時 : 0.890 秒 */
- var xmlDoc;
- if (browserType == BROWSER_IE) {
- xmlDoc = new ActiveXObject("Msxml.DOMDocument");
- }
- else {
- xmlDoc = document.createElement("DOM");
- }
- var root = xmlDoc.createElement("root");
- for (var i = 0; i < 50000; i++) {
- var node = xmlDoc.createElement("data");
- if (browserType == BROWSER_IE) {
- node.text = "xxxxxx";
- }
- else {
- node.innerText = "xxxxxx";
- }
- root.appendChild(node);
- }
- xmlDoc.appendChild(root);
- var str;
- if (browserType == BROWSER_IE) {
- str = xmlDoc.xml;
- }
- else {
- str = xmlDoc.innerHTML;
- }
- <!-- [if !supportLists]-->n
<!-- [endif]-->避免 DOM 對象的內(nèi)存泄漏。
關于 IE 中 DOM 對象的內(nèi)存泄露是一個常常被開發(fā)人員忽略的問題。然而它帶來的后果卻是非常嚴重的！它會導致 IE 的內(nèi)存占用量持續(xù)上升，并且瀏覽器的整體運行速度明顯下降。對于一些泄露比較嚴重的網(wǎng)頁，甚至只要刷新幾次，運行速度就會降低一倍。
比較常見的內(nèi)存泄漏的模型有“ 循環(huán)引用 模型”、“ 閉包函數(shù) 模型”和“ DOM 插入順序模型” , 對于前兩種泄漏模型，我們都可以通過在網(wǎng)頁析構時解除引用的方式來避免。而對于“ DOM 插入順序模型”則需要通過改變一些慣有的編程習慣的方式來避免。
有關內(nèi)存泄漏的模型的更多介紹可以通過 Google 很快的查到，本文不做過多的闡述。不過，這里我向您推薦一個可用于查找和分析網(wǎng)頁內(nèi)存泄露的小工具 — Drip ，目前的較新版本是 0.5 ，下載地址是 http://outofhanwell.com/ieleak/index.php
<!-- [if !supportLists]-->n <!-- [endif]-->復雜頁面的分段裝載和初始化
對系統(tǒng)當中某些確實比較復雜而又不便使用 IFrame 的界面，我們可以對其實施分段裝載。例如對于多頁標簽的界面，我們可以首先下載和初始化多頁標簽的默認頁，然后利用 AJAH （ asynchronous JavaScript and HTML ）技術來異步的裝載其他標簽頁中的內(nèi)容。這樣就能保證界面可以在***時間首先展現(xiàn)給用戶。把整個復雜界面的裝載過程分散到用戶的操作過程當中。
<!-- [if !supportLists]-->n <!-- [endif]-->利用 GZIP 壓縮網(wǎng)絡流量。
除了上面提到的這些代碼級的改良之外，我們還可以利用 GZIP 來有效的降低網(wǎng)絡流量。目前常見的主流瀏覽器已經(jīng)全部支持 GZIP 算法，我們往往只需要編寫少量的代碼就可以支持 GZIP 了。例如在 J2EE 中我們可以在 Filter 中通過下面的代碼來判斷客戶端瀏覽器是否支持 GZIP 算法，然后根據(jù)需要利用 java.util.zip.GZIPOutputStream 來實現(xiàn) GZIP 的輸出。
- /* 判斷瀏覽器對 GZIP 支持方式的代碼 */
- private static String getGZIPEncoding(HttpServletRequest request) {
- String acceptEncoding = request.getHeader("Accept-Encoding");
- if (acceptEncoding == null) return null;
- acceptEncodingacceptEncoding = acceptEncoding.toLowerCase();
- if (acceptEncoding.indexOf("x-gzip") >= 0) return "x-gzip";
- if (acceptEncoding.indexOf("gzip") >= 0) return "gzip";
- return null;
- }
一般而言， GZIP 對于 HTML 、 JSP 的壓縮比可以達到 80% 左右，而它造成的服務端和客戶端的性能損耗幾乎是可以忽略的。結(jié)合其他因素，支持 GZIP 的網(wǎng)站有可能為我們節(jié)約 50% 的網(wǎng)絡流量。因此 GZIP 的使用可以為那些網(wǎng)絡環(huán)境不是特別好的應用帶來顯著的性能提升。使用 Http 的監(jiān)視工具 Fiddler 可以方便的檢測出網(wǎng)頁在使用 GZIP 前后的通訊數(shù)據(jù)量。 Fiddler 的下載地址是 http://www.fiddlertool.com/fiddler/
關于 Web 應用的性能優(yōu)化其實是一個非常大的話題。本文由于篇幅有限，只能涉及其中的幾個細節(jié)，并且也無法將這些細節(jié)的優(yōu)化方式全面的展現(xiàn)給大家。期望本文能夠引起大家對 Web 應用尤其是客戶端性能優(yōu)化的充分重視。畢竟服務端編程技巧已為大家熟知多年，在服務端挖掘性能的潛力已經(jīng)不大了。而在客戶端的方法改進往往能夠得到令人驚奇的性能提升。
【編輯推薦】
