浅谈如何提高AJAX客户端响应速度-ajax请求响应

笔者从事AJAX 方面的研发多年，参与开发了目前国内较为成熟的AJAX平台 -dorado 。根据笔者的经验，导致这种结果的根本原因并不在AJAX 。很多时候系统响应速度的降低都是由不够合理的界面设计和不够高效的编程习惯造成的。下面我们就来分析几个 AJAX 开发过程中需要时刻注意的环节。

n 合理的使用AJAX客户端编程和远程过程调用。

AJAX客户端的编程主要都是基于 JavaScript 的。而 JavaScript 是一种解释型的编程语言，它的运行效率相对于 Java 等都要稍逊一筹。同时 JavaScript 又是运行在浏览器这样一个严格受限的环境当中。因此开发人员对于哪些逻辑可以在客户端执行应该有一个清醒的认识。

在实际的应用中究竟应该怎样使用客户端编程，这依赖于开发人员的经验判断。这里很多问题是只可意会的。由于篇幅有限，在这里我们大致归纳出下面这几个注意事项：

u 尽可能避免频繁的使用远程过程调用，例如避免在循环体中使用远程过程调用。

u 如果可能的话尽可能使用 AJAX 方式的远程过程调用（异步方式的远程过程调用）。

u 避免将重量级的数据操作放置在客户端。例如：大批量的数据复制操作、需要通过大量的数据遍历完成的计算等。

n 改进对 DOM 对象的操作方式。

客户端的编程中，对 DOM 对象的操作往往是最容易占用 CPU 时间的。而对于 DOM 对象的操作，不同的编程方法之间的性能差异又往往是非常大的。

以下是三段运行结果完全相同的代码，它们的作用是在网页中创建一个 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 ”之间的差别在于在创建表格单元时使用了不同的 API 方法。而“测试代码 2 ”和“测试代码 3 ” 之间的差别在于处理顺序的略微不同。

“测试代码 1 ”和“测试代码 2 ”之间如此大的性能差别我们无从分析，目前所知的是 insertRow 和 insertCell 是 DHTML 中表格特有的 API ， createElement 和 appendChild 是 W3C DOM 的原生 API 。而前者应该是对后者的封装。不过，我们并不能因此而得出结论认为 DOM 的原生 API 总是优于对象特有的 API 。建议大家在需要频繁调用某一 API 时，对其性能表现做一些基本的测试。

“测试代码 2 ”和“测试代码 3 ”之间的性能差异主要来自于他们的构建顺序不同。“测试代码 2 ”的做法是首先创建最外层的 <TABLE> 对象，然后再在循环中依次创建 <TR> 和 <TD> 。而“测试代码 3 ”的做法是首先在内存中由内到外的构建好整个表格，***再将它添加到网页中。这样做的目的是尽可能的减少浏览器重新计算页面布局的次数。每当我们将一个对象添加到网页中时，浏览器都会尝试对页面中的控件的布局进行重新计算。所以，如果我们能够首先在内存中将整个要构造的对象全部创建好，然后再一次性的添加到网页中。那么，浏览器将只会做一次布局的重计算。总结为一句话那就是越晚执行 appendChild 越好。有时为了提高运行效率，我们甚至可以考虑先使用 removeChild 将已存在的控件从页面中移除，然后构造完成后再重新将其放置回页面当中。

n 提高字符串累加的速度

在使用 AJAX 提交信息时，我可能常常需要拼装一些比较大的字符串通过 XmlHttp 来完成 POST 提交。尽管提交这样大的信息的做法看起来并不优雅，但有时我们可能不得不面对这样的需求。那么 JavaScript 中对字符串的累加速度如何呢？我们先来做下面的这个实验。累加一个长度为 30000 的字符串。

/* 测试代码 1 - 耗时 : 14.325 秒 */    
var str = "";   
for (var i = 0; i < 50000; i++) {   
       str += "xxxxxx";   
}

这段代码耗时 14.325 秒，结果并不理想。现在我们将代码改为如下的形式：

/* 测试代码 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 秒！同样的结果，我们做的只是首先拼装一些较小的字符串然后再组装成更大的字符串。这种做法可以有效的在字符串拼装的后期减小内存复制的数据量。知道了这一原理之后我们还可以把上面的代码进一步拆散以后进行测试。下面的代码仅耗时 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 格式的（其实绝大多数情况下，我们都可以设法将要提交的信息组装成 XML 格式），我们还能找到更高效更优雅的方法 — 利用 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

避免 DOM 对象的内存泄漏。

关于 IE 中 DOM 对象的内存泄露是一个常常被开发人员忽略的问题。然而它带来的后果却是非常严重的！它会导致 IE 的内存占用量持续上升，并且浏览器的整体运行速度明显下降。对于一些泄露比较严重的网页，甚至只要刷新几次，运行速度就会降低一倍。

比较常见的内存泄漏的模型有“ 循环引用模型”、“ 闭包函数模型”和“ DOM 插入顺序模型” , 对于前两种泄漏模型，我们都可以通过在网页析构时解除引用的方式来避免。而对于“ DOM 插入顺序模型”则需要通过改变一些惯有的编程习惯的方式来避免。

有关内存泄漏的模型的更多介绍可以通过 Google 很快的查到，本文不做过多的阐述。不过，这里我向您推荐一个可用于查找和分析网页内存泄露的小工具 — Drip ，目前的较新版本是 0.5 ，下载地址是 http://outofhanwell.com/ieleak/index.php

n 复杂页面的分段装载和初始化

对系统当中某些确实比较复杂而又不便使用 IFrame 的界面，我们可以对其实施分段装载。例如对于多页标签的界面，我们可以首先下载和初始化多页标签的默认页，然后利用 AJAH （ asynchronous JavaScript and HTML ）技术来异步的装载其他标签页中的内容。这样就能保证界面可以在***时间首先展现给用户。把整个复杂界面的装载过程分散到用户的操作过程当中。

n 利用 GZIP 压缩网络流量。

除了上面提到的这些代码级的改良之外，我们还可以利用 GZIP 来有效的降低网络流量。目前常见的主流浏览器已经全部支持 GZIP 算法，我们往往只需要编写少量的代码就可以支持 GZIP 了。例如在 J2EE 中我们可以在 Filter 中通过下面的代码来判断客户端浏览器是否支持 GZIP 算法，然后根据需要利用 java.util.zip.GZIPOutputStream 来实现 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% 左右，而它造成的服务端和客户端的性能损耗几乎是可以忽略的。结合其他因素，支持 GZIP 的网站有可能为我们节约 50% 的网络流量。因此 GZIP 的使用可以为那些网络环境不是特别好的应用带来显著的性能提升。使用 Http 的监视工具 Fiddler 可以方便的检测出网页在使用 GZIP 前后的通讯数据量。 Fiddler 的下载地址是 http://www.fiddlertool.com/fiddler/

关于 Web 应用的性能优化其实是一个非常大的话题。本文由于篇幅有限，只能涉及其中的几个细节，并且也无法将这些细节的优化方式全面的展现给大家。期望本文能够引起大家对 Web 应用尤其是客户端性能优化的充分重视。毕竟服务端编程技巧已为大家熟知多年，在服务端挖掘性能的潜力已经不大了。而在客户端的方法改进往往能够得到令人惊奇的性能提升。

【编辑推荐】