对项目之外的文件加载，使用普通的方式散乱在代码中，也不太合适，那么就需要一个封装的加载器，统一加载文件的接口和调用方式。我下面将要讲的“加载器”，不是传说中的模块化中的加在方式，我更多的是从代码维护方面来考虑，使得一目了然的看到页面本身的功能需要按需加载一些什么文件列表，并且可以标记已经加载的文件，而不会使得url散乱在页面中。

//需要按需加载的内部文件列表映射
mis.classFiles = {
  'AjaxEvent': 'includes/ajax.lib.js',
  'AjaxRequest': 'includes/request.lib.js',
  'colorFade': 'includes/effects.lib.js'
}

//标记已经include的内部文件
mis.includedFiles = {};

//对内的文件加载
mis.include = function(classname,callback){
  if(mis.includedFiles[classname]){
    callback && callback();
	  return true;
  }else if(mis.classFiles[classname]){
	  return mis.loadJavaScript(mis.classFiles[classname],callback);
  }else{
	  return false;
  }
}

//标记已经load的内部和外部文件
mis.loadedJavaScript = {}

//无限制的加载file文件
mis.loadJavaScript = function(file,callback){
  callback = callback || function(){};
  if(mis.loadedJavaScript[file]){
	  callback(true);
	  return true;
  }else{
	  var head = document.getElementsByTagName("head")[0];
	  var script = head.appendChild(document.createElement("script"));

    script.onload = script.onreadystatechange = function(){
		  if((!/*@cc_on!@*/0) || (/loaded|complete/).test(script.readyState)){
        script.onreadystatechange = null;
	      mis.loadedJavaScript[file] = true;
	      callback(true);
		  }
	  }

	  script.src = file;
	  return true;
  }
}

代码上没啥技巧，只是让它看起来更直观了点而已。

重构本来就不是一件应该特别拨出时间做的事情，重构应该随时随地进行。
第一次做某件事情时只管去做；第二次做类似的事情会产生反感，但无论如何还是可以去做；第三次再做类似的事，你就应该重构。 ——“事不过三，三则重构。”

1. 只要将相对独立的代码从大型函数中提炼出来，就可以大大提高代码的可读性。
2. 不单只让函数能够功能单一的执行，同时也需要让一个类也只需要明确的做一件事情，或者只是对各个功能的集合（代理、命名空间）。
3. 在该函数最常引用的类中建立一个有着类似行为的新函数，将旧函数变成一个单纯的委托函数，或者将旧函数完全移除。根据这个函数与哪个对象的交流比较多，决定将函数移动的位置。
4. 抽象函数可以是多重的，将可复用的代码尽量的抽象它，在抽象后的函数中，又需要对函数进行进一步的思考，是否功能还可以更加的细化，让功能函数为更多的其他函数、对象、类所复用。距离组织一个库来说：core大部分只提供核心类（核心对象）的扩展、继承机制、底层内置功能的扩充、封装机制、兼容性判断机制、对象版本管理机制等，这就算是一个core最细化的抽象。
5. 一个类应该是一个清楚的抽象，处理一些明确的责任。
6. “封装”意味着每个对象都应该尽可能少了解系统的其他部分，如此一来，一旦发生变化，需要了解这一变化的对象和函数就会比较少，这会使变化比较容易进行。
7. 有几个原因造成我喜欢简短而命名良好的函数：首先，如果每个函数的粒度都很小，那么函数被复用的机会就更大；其次，这会使高层函数读起来就像一系列注释；再次，如果函数都是细粒度，那么函数的覆写也会更容易些。
   在函数的命名上，长度不是问题，关键在于函数名称和函数本体之间的语义距离。
   创造一个新函数，根据这个函数的意图来对它命名（以它“做什么”来命名，而不是以它“怎么做”命名），但是如果你想不出一个更有意义的名称，那就别动。
   如果在提炼的函数中需要一些原来旧函数中的局部变量数据，那么就将这些局部变量数据通过参数的形式传递过去。
8. 当一个函数有参数的时候，在函数体里就尽量不要去修改参数的值，不管是通过值还是引用传递进来的，除非有另外特定的目的。
9. 将函数细粒化为一个个功能单一的函数，再调用这些函数，这必然造成了性能上更多的耗费，但是这跟后期的维护、以及代码的可读性等等相比，或许还是值得这么做的。
10. 永远不要认为你写的代码只是自己看的而已，要想到新来的人接手你的这些代码的时候，他们看你的代码，是否能够很愉快的接受并理清整个思路。不要把这个维护代码的痛苦留给接手你的人。不管你是通过更多的注释还是重构代码的方式来解决代码的可维护性的问题，都要想到这一点。
11. 在分解一个函数的时候，我的思路是：需求是什么 –> 需求的功能有哪些 –> 团队开发方式是如何的 –> 在当前功能点下，罗列函数层级的功能点，并根据这些功能点进行整合，即是高内聚，低耦合。之后逐一组建函数。
    明白需求是什么，这个是做开发的最先需要了解清楚的，这点无可厚非；在这个需求下面，需要实现一些什么功能，这个是需要根据需求来分析出来的，之后的就是根据自己团队的代码开发模式，并逐步将需求的功能点，细化到代码层级的功能点，将功能抽象出来，提高代码的可复用度。

自己之前所遵守的高性能、微小代码量、满脑子模块化、保持结构样式逻辑高度分离等的思维，再次进行了权衡的颠覆。对于代码，性能重要，但是人也能很容易的看懂这也重要。一个项目，到底是开发新功能的需求大，还是维护、优化项目的需求更多，这个就需要在高速开发和提高代码的可读性和较少维护成本进行权衡。

使用工具进行页面拼装的方式，固然可以提高开发效率，这对于一些促销页面开发、或者是有PM、运营所自定义页面来说，确实有必要。但是这些都是辅助页面，核心产品才是主要关注点，核心产品一般不会轻易的推倒重来，而是不断的进行优化、功能升级、新功能上线等。为此，对于开发者来说，除了代码能够给电脑读，还能很好的给其他开发者读懂，这个有必要。在性能和代码量上或许可以做个权衡，也或者可以从其他方面进行优化来弥补这方面的损失。

模块化，有时候真的很少用到，除非是大站点，从整体架构考虑，提高功能的聚合度和整体统一。在一些细小项目、功能开发中，用到更多的还是借助于统一的库，进行二次的功能开发，封装为适合该项目、功能的功能函数集。就如上面《重构》书中所述，当这个功能为几个项目、功能所使用的时候，那么就有必要抽象出来，作为一个模块。但是，对于模块，从现阶段来说，它已经不是跟以前一样，只是一个js文件，它所要负责是它的功能范围内的HTML、CSS、JS，对于页面来说，我无需关心这个模块有啥，我只需要调用这个模块的接口，加载这个模块，那么我的页面中就有了这个模块最基本的功能，再复杂点，就是提供给模块进行扩展的接口，在模块的基础上，进行自定义结构、样式、逻辑。

所以，对于模块化，要区分好Moudle，Utilities，功能函数的差别。Util只是对功能逻辑的封装，加载这个js文件，就可以直接使用它所提供的逻辑方法，它并不涉及到样式、结构，只是一个逻辑。功能函数更多的是存在于页面中的，如果使用度够高，那么就会成为Util的一部分。功能函数更多的是在已有的库的基础上进行的二次封装、抽象，提供给其他的功能直接调用。将页面中都会用到的功能进行抽取，作为一个独立的功能函数，通过参数来体现功能的差异。

在结构、样式、逻辑上，这个并没有完全的分离的界限，很多时候都需要看功能的具体需求，不能完全要求分离结构和逻辑，就使得在逻辑方面需要做很多的动态创建结构的工作。这就需要权衡：如何使用正确的HTML标签，标签能否提供一些辅助的信息，来简化逻辑的操作和代码量。适合在标签上能做的事情，就让标签来提供。“各司其职”的折中是互相辅助。

想得有点多了，需要慢慢学习和实践~~

最理想的方式，无非就是统一使用onload来检测link元素是否加载完毕。但是事不与程序猿人愿~ 但是兼容办法还是有的。

在IE、Opera下，可以直接使用onload、onreadystatechange这两种方式都可以检测link元素是否加载完成，跟检测script一样的原理。

在Chrome、Safari等基于Webkit内核的浏览器下，估计就要监控document.styleSheets.length的变化了。Webkit内核的浏览器在处理document.styleSheets.length的方式是这样的，当加载完了一个link之后，length就会加1，那么这样的话，就可以使用setInterval的方式来检测length的变化了，对于同时检测多个link是否加载完成的方式也可以利用这个，看length增加了多少。《测试用例》示例如下：

[javascript]
var link = document.createElement("link");
var cn = document.styleSheets.length;

var ti = setInterval(function() {
if (document.styleSheets.length > cn) {
alert("CSS loaded");
clearInterval(ti);
}
}, 10);

link.href="http://www.ilovejs.net/lab/css.php";
link.rel = "stylesheet";
document.getElementsByTagName("head")[0].appendChild(link);
[/javascript]

但是在Firefox下，情况就有些恶心了，所使用到的方式跟上面的两类浏览器的处理方式都不太相同。对于document.styleSheets.length的处理也不同于Webkit，它的处理方式是只要link元素一附加到document之后，length就会立即加1，而不管css文件是否加载完毕（测试用例如上面的链接）。为此，对于Firefox的处理方式，使用style标签，而不是link，并且使用传统的@import的方式，通过判断style.sheet.cssRules是否存在来检测css文件是否加载完成，具体如下所示《测试用例》：

[javascript]
var head = document.getElementsByTagName("head")[0];

var style = document.createElement(‘style’);
//加载css.php文件，需要2秒之后才会返回响应内容
style.textContent = ‘@import "http://www.ilovejs.net/lab/css/css.php"’;
style.rel="stylesheet";

var fi = setInterval(function() {
try {
style.sheet.cssRules; // 这句是关键，在css加载完成的时候，style元素就会有这么个对象。

alert("CSS loaded");

clearInterval(fi);

} catch (e){}

}, 10);

head.appendChild(style);
[/javascript]

为此，想要写一个兼容性的检测CSS文件是否加载完成的代码，估计看起来会比较丑陋，差异大，处理的方式各异，期待onload统一的那一天咯~~

下面是简单的一个UIX事件绑定方式：

[javascript]
// UIX system
var UIX = UIX || {
"registry":{},
"register":function(type,uixes){
if(!this.registry[type]){
this.registry[type]={};
}
for(var uix in uixes){
if(uixes.hasOwnProperty(uix)){
this.registry[type][uix] = uixes[uix];
}
}
},
"handleEvent": function(evt){
if(evt.type in this.registry){
var actions = this.registry[evt.type];
for(var uix in actions){
el = evt.target || evt.srcElement;
if(el.getAttribute("data-uix") == uix){
actions[uix].call(el,evt);
}
}
}
}
};
//End uix system
[/javascript]

如上代码所示，原理是将事件都绑定到document上，目标元素就使用自定义字段data-uix作为一类相似事件行为的标识，但是涉及到document以及具体的DOM元素的事件处理逻辑，所以就需要进行两个事件绑定的过程：第一个是将uix的事件接口绑定到document上，之后声明每一类的自定义data-uix事件处理程序，这个并不是绑定的方式，而是以data-uix为标识的映射函数

[javascript]
// UIX system 派上用场了
//document绑定事件
addEvent(document,"click",function(e){
UIX.handleEvent(e || window.event);
});
UIX.register("click",{
"mask_read":function(){ //data-uix为mask_read的一类click事件。
var index = this.getAttribute("data-index");
var url = this.getAttribute("data-href");
location.href = "mask_read.php?index="+index+"&url=" + encodeURIComponent(url);
return true;
},
"read_button":function(){ //data-uix为read_button的一类click事件。
getData.request(this.getAttribute("data-read"));
}
});
[/javascript]

使用这样的微UIX事件绑定机制，可以根据事件类型来区分该事件类型下的每一类绑定该事件的元素集合，并且使用委托的方式。

UIX介绍完了，现在接下来说一下在Ipod Safari下开发这个所遇到的一些问题。首先说一下功能需求：提供已经阅读和未阅读的类型，那么区别这个已读跟未读的状态；页面需要基于Ajax请求，来加载URL列表。就这两个需求。

• 在区别已读跟未读状态的时候，既要不阻碍点击URL的title进入到收藏的网址的网站，而且又能够在自己的数据库里标记这条URL已经阅读过，那么就需要在click事件的时候，发送一个请求给服务端，更新数据库的标识。通常的这个做法都是通过动态的New一个Image实例，声明src的方式，但是使用这个方式的时候，FF浏览器下好使，但是Chrome、Safari、Ipod Safari不好使了，无效。因为src指向的是一个php的页面，有朋友测试妨碍西安src如果不指向一个图片的时候，请求无效。所以这种方式使用Image实例指向php页面的方式就不行了（之后测试了使用script标签指向php文件的方式，也不行）。只有使用比较搓的备选方案了，使用中间跳转页的方式，但是这样又会遇到这个样的一个问题：浏览器回退的时候会跳到这个中间页，如果才能够把这个中间页不在浏览器的history里保存呢？方案是有的，使用location.replace做跳转，replace接受一个url的字符串参数，表示跳转到该url下，而不把当前URL记录到history中。
• 第二个需求中，又会遇到怎样的问题呢？异步请求的更新问题，问题还是纠结在浏览器回退的时候，网址夹页面中已经点击过的URL应该清除掉，因为它已经阅读过了。FF、Chrome浏览器下点击回退按钮的时候，会自动重新发送Ajax请求去加载数据，而Safari、Opera、Ipod Safari却没有，那么这就又纳闷了。经过跟朋友讨论过之后，使用：window.onunload=window.onbeforeunload=function(){};
  就好使了，Safari、Opera、Ipod Safari都会自动重新发送请求，更新页面。大致的意思就是声明了这个onunload、onbeforeunload之后，浏览器不会cache页面的内容。

本来以为做这个会很简单，Ipod Safari下总会遇到各种各样跟浏览器不同的行为，特别在事件方面，支持的程度不同之外，触发、执行的方式都有可能不同，或者因为其他的影响而有莫名其妙的失效的情况。

由于个人网址夹是open、并且是个人使用的，所以就不在此提供测试地址了。YY一下

在perl文件的头部，添加了几个配置项：
$yui_compressor_path：YUI compressor 的jar文件的路径（建议是本地的绝对路径）
$google_compiler_path：Google Compiler的jar文件的路径（建议是本地的绝对路径）
$compress_type：所使用的压缩方式，值可以为：yui/gc。
$compilation_level：Google Compiler压缩的级别，值可以为：SIMPLE_OPTIMIZATIONS/ADVANCED_OPTIMIZATIONS/WHITESPACE_ONLY
$output_dir：编译后的文件的输出目录（建议是跟当前需要编译的文件同一目录下）

建议是在每一个开发目录下配置一个build.pl文件，那么就可以对在当前的目录下进行开发，最后build编译。如今编译的文件都会保存在当前目录下的output文件夹里，文件名不变，可以直接使用编译好的文件进行测试、发布。

如下图所示的嵌套包含示意图，理论上可以无限级的嵌套，压缩：

可以对当前级声明compress:true进行压缩，嵌套之后，在output文件夹中会有中间产物页面产生，但是对于最终页面是没影响的。这样，就可以将几个页面中通用的部分抽取出来，统一管理。

最新的build程序：build_1_0_3_linux.rar，build_1_0_3_win.rar。

1. 定义局部变量。对于当前函数作用域内，如果需要使用这个作用域外部的一些变量，那么就尽量使用局部变量储存外部的变量吧，特别是对于嵌套多级的作用域查询，这个耗时也是比较严重的。还有就是获取DOM节点、NodeList、HTMLCollection等等，可以将NodeList、HTMLCollection转化为数组的形式进行操作，减少DOM即时更新所造成的性能消耗。
2. 不要使用with语句。with语句会在当前作用域下面增加作用域链，造成当前作用域下面变量的遍历性能消耗更大。
3. 对于闭包的使用，节省点，不要太过多了。闭包就是提供一个所谓的“封闭式”的作用域，只允许向包含它向别人访问，而不允许别人访问它。但是声明一个闭包的代价比声明普通的函数的代价是要更高的，况且还有IE下内存泄漏的危险。
4. 获取字面量对象的属性和数组的项比获取变量更慢。如果你要获取一些数据的时候，使用变量比用数组、字面量对象的索引来访问来的更快。在循环中经常会需要访问数据，使用变量存储一下，来的更快。
5. 在数组中不要嵌套的过深。js中没有二维数组的概念，但是可以自己编写一个二维数组，并且可以无限的嵌套下去，json很经常就是这么干的。但是嵌套的越深，访问数组中的项就更难了，级数和性能消耗成正比的。
6. 少用for-in循环。众所周知，for-in用于遍历对象的属性和方法，它所要消耗比for、while、do-while更多的性能。在for-in循环中，对于每一个循环，javasript需要创建一个函数来处理每一个循环，这就带来这么两个性能问题：函数创建、销毁的过程；这个函数在创建之后，又会储存它直接上级的作用域的活动对象。
7. 对于循环，合并控制循环的语句，以及控制变量变化方式。在一个控制循环的语句中，比如循环结束条件、索引的递增等等，如果可以优化这些操作，那么对于整个循环的性能是有帮助的。比如对于结束循环条件：for(var i =0;i<10;i++)，每次循环的时候，都要执行：#1 i是否存在；#2 i是否 < 10；#3 i++。优化一下，使用while或者do-while：var i = 9;do { ...} while(i--)，那么这样之后，每一个循环需要执行的操作：#1 i--；#2 i是否为true。这样就对循环条件的执行步骤进行了简化。
8. 对于HTMLCollection，尽量定义一个数组来储存它。这样可以避免DOM即时更新所造成的影响。
9. 在操作DOM节点的时候，尽量让它飘了吧。让DOM元素脱离document之后再对它进行操作，最后再重新插回document中，最小化reflow（改变了DOM元素布局性的相关的属性之后就会触发，比如：height、width等）、repaint（改变了DOM元素显示上的变化就会触发，比如：background、color等）所造成的影响。
10. 改变DOM节点样式的时候，尽量改变DOM元素的class而不是style属性。原因你懂的……

规则是死的，不能泛用；规则又是活的，看你是否活学活用，用到思维里去，在你编写代码的时候就可以随手写出符合这些规则的代码。

英文原文：http://jonraasch.com/blog/10-javascript-performance-boosting-tips-from-nicholas-zakas

首先，让我们从UI Thread、UI Queue、UI Upate的角度去分析整个页面和javascript的行为。浏览器在加载HTML到最后呈现出来的这段过程，整个就是一个UI Thread进程，这个UI Thread里是一个浏览器的响应队列，而UI Queue则是浏览器的行为队列，包括UI Update，javascript的执行行为。那么在页面加载的过程中，UI Queue里面就储存了UI Update、js加载、js解析、js执行等。不管是UI Thread，还是UI Queue，都是按照顺序来的。页面在刚开始未遇到js的加载和执行的时候，是UI Update的一个过程，一旦遇到js，就会等待js的加载、解析、执行完毕之后，接着又开始UI Update，如此这样的一个相应顺序。

那么当js的加载是异步了之后呢，这个时候，js的加载和解析不会在UI Queue的执行队列里，而是等到js加载、解析完毕，一到执行的时候，就添加到UI Queue队列中，从而阻塞了UI Queue中后面的行为（UI Update）的执行。这就是开头所说的在js的执行期总会阻塞页面的渲染，也就是UI Update。但是这个动态加载的方式跟普通在页面中使用script标签来加载的时候的优势是：将js的加载、解析的行为独立出来，不影响浏览器的UI Update，知道执行期才阻塞。这就很多的程度上加快了页面的渲染和展现。

再来说说defer和async属性，defer属性最开始是为IE所实现的，现代的浏览器也都逐渐实现了，那么它的工作原理是什么呢。它的作用跟上面动态加载的优势很相同，js的加载和解析是独立的，但是有一点不同的是：使用了defer属性之后，js代码会等到DOM加载完成的时候才执行，这个时候就又更大限度的让浏览器尽快的UI Update部分完成，让js的执行对浏览器的渲染所造成的影响更小化。那么async呢，是跟上面所说的动态加载js的优势是一样的，也是独立js的加载、解析，解析完成的时候就立即添加到UI Queue队列中去等待执行，阻塞后面的UI Update行为。

那么怎样将js的执行对UI Update的影响更小呢？使用HTML5的Worker机制吧，将复杂的js执行交给Worker去执行，Worker是一个独立的js执行环境，这个环境里没有window、DOM的概念，只是用来处理复杂的运算，再将处理后的结果通过postMessage方法发送会浏览器，Worker和页面之间通过postMessage方法来实现跟浏览器的数据交换。这样，将复杂运算交给Worker之后，在页面中所执行的js代码，将会是大大的减小，减小到只需要处理一个onmessage事件，将页面的js执行时间最小化。

杯具的还是defer、async、Worker还不能够完全的被目前市面上流行的浏览器所兼容，期待浏览器统一的那一天。

—- EOF —-

按需加载表面理解起来很简单，但是怎么个按需法呢？我所理解的按需，包括两个方面：一个是按用户的需要；另一个是网站本身的需要。按需加载主要解决的问题就是加快页面的初始化以及在页面初始化的时候最大化减少HTTP请求，因为有些模块比如：图片导航tab、多级菜单、内容导航等等，这些在初始化页面的时候有很多内容都是处于隐藏状态，用户是看不到的，那么这些内容对不同的用户来说有不同的需求，那么这些就可以从页面的初始化中剥离出来，按用户的需求通过异步通信来加载内容和资源。对于网站本身的需要来加载后续资源，比如Google首页对于结果页的一些js、image等资源的pre-fetch的方式，通过分析用户可能会产生的行为，为后续的页面提前加载内容，加快后续页面的初始化速度，从缓存中读取页面所需要的资源。

接下来分析一下淘宝首页（http://www.taobao.com）的一些按需加载的技巧。首先对于中间栏的这个部分的实现：

看这个模块的源码之后发现，除了初始化第一个tab内容之后，后面隐藏的几个tab的资源是没有加载的，它是将这些资源的HTML设置到一个隐藏的textarea控件的值里面，在点击了左右的导航按钮之后，就读出这个textarea的内容并解析到tab中，当然这也同时是加载图片等资源。我想，这样做的一个好处就是上面说的按需加载，加快页面的初始化速度；还有另外一个作用是减少页面初始化的DOM节点数。将这个添加更多DOM节点推迟到按照用户的需要去点击导航按钮。这个在加快页面的初始化方面也是很不错的技巧。

再来分析一下Yahoo首页的其中一个模块的实现方式，也是比较类似的：

如上图，在下部的导航中，初始化的时候会默认加载一个tab看到的导航的图片和问题，而其他隐藏的每一个导航tab，在页面初始化的时候HTML的结构均使用四个span标签代替，之后在点击左右导航按钮的时候，进行异步请求资源，并替换掉每一个相应的span标签。它在初始化页面的时候使用span标签，只是为了保持一个高度上的“空架子”，在之后的按需请求中往这个架子中替换内容，这样其中的一个原因可能是为了不至于在替换标签的时候在高度上的过度出现闪烁。

按需加载的思维在很多网站中都有体现，利用Ajax技术，异步请求内容，将隐藏的内容、资源的加载跟页面的初始化剥离开来，加快页面的初始化。

分支、惰性实例化、惰性载入函数、单例的两种模式、享元类、函数绑定（纠正函数一个执行上下文）、函数curry化、高级定时器、保护上下文的构造函数、函数节流、自定义事件……

js中的继承、原型、构造函数这些都是老生常谈的了。但是对于构造函数式继承和原型式继承的优缺点，还是有必要了解一下的。原型式继承的主要优点就是共享方法和属性，使得从原型对象中继承出来的子对象都可以在内存中共享全部的方法和属性，这如果是在大型的继承链中将会大大的改善性能和减少内存的使用量。

接下来看看上面所罗列的每一个所谓的“高级”技巧的具体细节咧：

1. 惰性实例化
   惰性实例化所要解决的问题是这样的：避免了在页面中js初始化执行的时候就实例化了类，如果在页面中没有使用到这个实例化的对象，那么这就造成了一定的内存的浪费和性能的消耗，那么如果将一些类的实例化推迟到需要使用它的时候才开始去实例化，那么这就避免了刚才说的问题，做到了“按需供应”，简单代码示例如下：
   [javascript]
   var myNamespace = function(){
   var Configure = function(){
   var privateName = "someone’s name";
   var privateReturnName = function(){
   return privateName;
   }
   var privateSetName = function(name){
   privateName = name;
   }
   //返回单例对象
   return {
   setName:function(name){
   privateSetName(name);
   },
   getName:function(){
   return privateReturnName();
   }
   }
   }
   //储存configure的实例
   var instance;

   return {
   getInstance:function(){
   if(!instance){
   instance = Configure();
   }
   return instance;
   }
   }
   }();
   //使用方法上就需要getInstance这个函数作为中间量了：
   myNamespace.getInstance().getName();
   [/javascript]
   上面的就是简单的惰性实例化的示例，但是有一点缺点就是需要使用中间量来调用内部的Configure函数所返回的对象的方法（当然也可以使用变量来储存myNamespace.getInstance()返回的实例对象）。将上面的代码稍微修改一下，就可以只用比较得体的方法来使用内部的方法和属性：
   [javascript]
   //惰性实例化的变体
   var myNamespace2 = function(){
   var Configure = function(){
   var privateName = "someone’s name";
   var privateReturnName = function(){
   return privateName;
   }
   var privateSetName = function(name){
   privateName = name;
   }
   //返回单例对象
   return {
   setName:function(name){
   privateSetName(name);
   },
   getName:function(){
   return privateReturnName();
   }
   }
   }
   //储存configure的实例
   var instance;

   return {
   init:function(){
   //如果不存在实例，就创建单例实例
   if(!instance){
   instance = Configure();
   }
   //将Configure创建的单例
   for(var key in instance){
   if(instance.hasOwnProperty(key)){
   this[key]=instance[key];
   }
   }
   this.init = null;
   return this;
   }
   }
   }();
   //使用方式：
   myNamespace2.init();
   myNamespace2.getName();
   [/javascript]
   上面修改了自执行函数返回的对象的代码，在获取Configure函数返回的对象的时候，将该对象的方法赋给myNamespace2，这样，调用方式就发生了一点改变了。

2. 分支
   分支技术解决的一个问题是处理浏览器之间兼容性的重复判断的问题。普通解决浏览器之间的兼容性的方式是使用if逻辑来进行特性检测或者能力检测，来实现根据浏览器不同的实现来实现功能上的兼容，但问题是，没执行一次代码，可能都需要进行一次浏览器兼容性方面的检测，这个是没有必要的，能否在代码初始化执行的时候就检测浏览器的兼容性，在之后的代码执行过程中，就无需再进行检测了呢？答案是有的，分支技术就可以解决这个问题（同样，惰性载入函数也可以实现Lazy Definied，这个在后面将会讲到），下面以声明一个XMLHttpRequest实例对象为例子：
   [javascript]
   //分支
   var XHR= function(){
   var standard = {
   createXHR : function(){
   return new XMLHttpRequest();
   }
   }
   var newActionXObject = {
   createXHR : function(){
   return new ActionXObject("Msxml2.XMLHTTP");
   }
   }
   var oldActionXObject = {
   createXHR : function(){
   return new ActionXObject("Microsoft.XMLHTTP");
   }
   }
   if(standard.createXHR()){
   return standard;
   }else{
   try{
   newActionXObject.createXHR();
   return newActionXObject;
   }catch(o){
   oldActionXObject.createXHR();
   return oldActionXObject;
   }
   }
   }();
   [/javascript]

   从上面的例子可以看出，分支的原理就是：声明几个不同名称的对象，但是给这些对象都声明一个名称相同的方法（这个就是关键），并给这些来自于不同的对象但是拥有相同的方法进行浏览器之间各自的实现，接着就开始进行一次浏览器检测，并经过浏览器检测的结果来决定返回哪一个对象，这样不论返回的是哪一个对象，最后名称相同的方法都作为了对外一致的接口。

   这个是在Javascript运行期期间进行动态检测，并将检测的结果返回赋值给其他的对象，并提供相同的接口，这样储存的对象就可以使用名称相同的接口了。其实，惰性载入函数跟分支在原理是非常相近的，只是在代码实现方面有差异而已。

3. 惰性载入函数
   惰性载入函数就是英文中传说的“Lazy Defined”，它的主要解决的问题也是为了处理兼容性。原理跟分支类似，下面是简单的代码示例：
   [javascript]
   var addEvent = function(el,type,handle){
   addEvent = el.addEventListener ? function(el,type,handle){
   el.addEventListener(type,handle,false);
   }:function(el,type,handle){
   el.attachEvent("on"+type,handle);
   };
   //在第一次执行addEvent函数时，修改了addEvent函数之后，必须执行一次。
   addEvent(el,type,handle);
   }
   [/javascript]
   从代码上看，惰性载入函数也是在函数内部改变自身的一种方式，这样之后，当重复执行的时候，就不会再进行兼容性方面的检测了。
4. 单例的两种模式
   单例模式是家喻户晓的了，也是当前最流行的一种编写方式，注明的模块模式的编写方式也是从这个思想中衍生出来的。单例模式有两种方式：一种是所谓的“门户大开型”，另外一种就是使用闭包来创建私有属性和私有方法的方式。第一种方式跟构造函数的“门户大开型”是一个样的，声明的方法和属性对外都是开放的，可以通过实例来调用。但是使用闭包来实现的单例模式，可以在一个“封闭”的作用域内声明一些不为外部所调用的私有属性和私有方法，而且还有一个很主要的功能，就是私有属性可以作为一个“数据存储器”，在闭包内声明的方法都可以访问这些私有属性，但是外部不可访问。那么重复添加、修改、删除这些私有属性所储存的数据是安全的，不受外部其他程序的影响。
5. 享元类
   顾名思义，“享”、“元”。就是共享通用的方法和属性，将差异比较大的类中相同功能的方法集中到一个类中声明，这样需要这些方法的类就可以直接从享元类中进行扩展，这样使得这样通用的方法只需要声明一遍就行了。这个从代码的大小、质量来说还是有一定的效益的。
6. 函数绑定
   函数绑定就是为了纠正函数的执行上下文，特别是函数中带有this关键字的时候，这点尤其显得重要，稍微不小心，使得函数的执行上下文发生了跟预期的不同的改变，导致了代码执行上的错误（有时候也不会出现错误，这样调试起来，会很变态）。对于这个问题，bind函数是再熟悉不过的了，bind函数的功能就是提供一个可选的执行上下文传递给函数，并且在bind函数内部返回一个函数，来纠正在函数调用上出现的执行上下文发生的变化。最容易出现的错误就是回调函数和事件处理程序一起使用了，下面是摘自《Javascript高级程序设计第二版》的一个示例：
   [javascript]
   var handler = {
   message:"Event handler",
   handlerClick:function(e){
   alert(this.message);
   }
   }
   var btn = document.getElementById("my-btn");
   //这句就造成了回调函数执行上下文的改变了
   EventUtil.addHandler(btn,"click",handler.handlerClick);
   [/javascript]
   解决的办法之一，就是纠正一下handler.handlerClick执行的上下文环境，改为：
   [javascript]
   //这样运行的很好
   EventUtil.addHandler(btn,"click",function(e){
   handler.handlerClick(e);
   });
   [/javascript]
   上面就很好的纠正了回调函数的执行上下文了。而且，也可以使用传说中的bind函数来解决：
   [javascript]
   var bind = function(fn,context){
   return function(){
   return fn.apply(context || this,arguments);
   }
   }
   EventUtil.addHandler(btn,"click",bind(handler.handlerClick));// So Good！
   [/javascript]
7. 函数curry化
   函数curry化的主要功能就是提供了强大的动态函数创建的功能。通过调用另一个函数并为它传入要curry的函数和必要的参数。说白点就是利用已有的函数，再创建一个动态的函数，该动态的函数内部还是通过该已有的函数来发生作用，只是传入更多的参数来简化函数的参数方面的调用。具体示例：
   [javascript]
   //curry function
   function curry(fn){
   var args = [].slice.call(arguments,1); //这个就相当于一个存储器了。
   return function(){
   return fn.apply(null,args.concat([].slice.call(arguments,0)));
   }
   }
   //Usage:
   function add(num1,num2){
   return num1+num2;
   }
   var newAdd = curry(add,5);
   alert(newAdd(6));
   [/javascript]
   在curry函数的内部，私有变量args就相当于一个存储器，来暂时的存储在curry函数调用的时候所传递的参数值，这样跟后面的动态创建的函数调用的时候的参数合并，并执行，就得到了一样的效果了。
8. 高级定时器
   提到定时器，无非就是利用setTimeout/setInterval了。但问题是定时器并不是相当于新开一个线程来执行js程序，也不会说是在指定的时间间隔内就会一定执行。指定的时间间隔表示何时将定时器的代码添加到浏览器的执行队列，而不是合适实际执行代码。对此，就有这样的一个问题了：如果代码执行时间超过了定时器指定的时间间隔，那么在指定的时间里代码还是加入的执行队列，但是并没有执行，这样就会造成了无意义的代码执行，这也是使用setInterval的弊端。为此，使用setTimeout才能更好的避免这个问题，在代码本身中执行完毕了，再通过setTimeout来重新设定定时器，把代码加入到执行队列。比如：
   [javascript]
   setTimeout(function(){
   //many code here…
   setTimeout(arguments.callee,100); //Key
   },100);
   [/javascript]
   当然了，定时器还有很多其他的技巧和实际作用，看需求而定，更详细的解释可以查看《Javascript高级程序设计第二版》（第467页）。
9. 保护上下文的构造函数
   这个主要是避免构造函数在没有使用new来实例化的时候，内部的this指向错误问题。通常没有使用new的话，this一般执行window去了，因此造成了执行错误，给代码带来了灾难。使用下面的方式就可以避免这个问题：
   [javascript]
   function myClass(name,size){
   if(this instanceof myClass){ //Key,使用instanceof来检测当前实例是否是myClass的实例化对象
   this.name = name;
   this.size = size;
   }else{
   return new myClass(name,size);
   }
   }
   [/javascript]

   但是上面通过instanceof的方式，给继承造成了一定的困扰，因为子类并不是myClass的实例对象，所以会出现属性和方法无法被继承的方式。在说解决办法之前，先来了解一下instanceof操作符的原理：它首先会检测对象当前的原型是否指向右边的构造函数，如果找不到，就会往上一级的原型去查找，直到找到为止，并返回true，否则就返回false。

   基于上面的instanceof的原理，在继承的时候，就可以给子类的prototype原型赋于一个父类的实例化对象就行了，这样就可以在子类继承的时候绕过instanceof的检测。

10. 函数节流

    函数节流函数节流解决的问题是一些代码（特别是事件）在无间断的执行，这严重的影响了浏览器的性能，再没有给它设定间断来执行的话，可能造成浏览器反应速度变慢或者直接就崩溃了。比如：resize事件、mousemove、mouseover、mouseout等等事件。

    这个时候，就可以加入定时器的功能了，将事件进行“节流”，即是：在事件触发的时候，设定一个定时器来执行事件处理程序，这样可以很大的程度上缓解浏览器的负担，又缓冲的余地去更新页面。具体的实例可以查看支付宝中部“导购场景”的导航：http://life.alipay.com/?src=life_alipay_index_big，以及当当网首页左边的导航栏：http://www.dangdang.com/等等，这些都是为了解决mouseover和mouseout移动过快的时候加大浏览器处理的负担，特别是在涉及到有Ajax调用，而且Ajax调用是么有缓存的情况下，给服务器也造成了很大的负担。为此，函数节流就派上用场了。比如简单的示例如下（出自本人写的：http://www.ilovejs.net/lab/tween/tweener_tab_modify.html）：
    [javascript]
    oTrigger.onmouseover=function(e){
    //如果上一个定时器还没有执行，则先清除掉定时器
    oContainer.autoTimeoutId && clearTimeout(oContainer.autoTimeoutId);
    e = e || window.event;
    var target = e.target || e.srcElement;
    if((/li$/i).test(target.nodeName)){
    oContainer.timeoutId = setTimeout(function(){
    addTweenForContainer(oContainer,oTrigger,target);
    },300);
    }
    }
    [/javascript]

11. 自定义事件

    首先要说的是，这里并不是说自定义事件可以真的自定义跟mouseout、click等一样性质的“事件”。这里的自定义事件在执行的时候还是需要依赖已有的键盘、鼠标、HTML等事件来执行，或者又其他函数“触发”执行，这里的“触发”是指直接调用自定义事件中声明的某个接口方法，来轮询的执行全部相关的添加到自定义事件中的函数。

    自定义事件内部有一个“事件”存储器，根据添加的事件的类型的不同，来储存各类的事件执行函数，这样再出发这类事件的时候，就轮询执行添加到该类型下的函数。“自定义事件背后的概念是创建一个管理事件的对象，让其他对象监听那些事件”来自《Javascript高级程序设计第二版》的解释。基于自定义事件的原理，可以想象自定义事件很多时候是用于“订阅—发布—接收”性质的功能。

文章写的有点多了，但是上面介绍的Javascript高级技巧还远不止这些，特别是在Ajax方面的一些模式和技巧都还没有介绍，何况是客户端和服务端结合的一些技巧（比如压缩、Minify、服务器“推技术”等等）。更多的有待以后了解了介绍一二。

在前端基本技术方面，Javascript、HTML、CSS等大家都是已经掌握的差不多了，但是利用这些已有的基本技术，能否创造出不一般的应用和模式呢？这个才是在掌握了基本的能力之后接下来需要掌握的，比如下面是本人在每天晚上睡觉之前所总结的几点：

1. 学会重构代码的技术，有计划性的重构下自己之前所编写过的一些代码，加强自己掌控代码的能力。
2. Code review。这里说的review，并不是指个人，而是对团队来说的，一个人编写的代码的想象空间有限，如果在自己编写代码完成之后，邀请其他团队内的伙伴来查看你的代码，及时发现问题以及提出更好的解决方案，这也不失为一种即时重构的方式，提高代码的质量。
3. 编写具体的功能代码之前，首先设计代码、规划代码、组织代码的模式。
4. 在代码的质量、性能、大小之间能作出合理的权衡。
5. 编写阅读性良好、一目了然、扩展性、可维护性良好、重复利用的代码，也是一门艺术。
6. 关注web前端的性能优化，包括Javascript、HTML、CSS、客户端、服务端、前端、后端等整体性的优化。
7. 最后一点或许也是最重要的：善于总结。这点比上面的任何一点都来的重要，因为上面的每一点都是出自这点的积累。

上面我总结的几点，也是后期自己要着重提高的能力，当然了，在实际的编码方面，还有很多的东西还需要去挖掘和了解。继续革命吧，将互联网革命进行到底……

查看了Jet的使用方式之后，首先不禁冒出了一个词“复制”。是的，Jet复制了YUI3的编写方式，提供了“包”的概念package：

[javascript]
Jet().$package(function(J){
//code here…
};
[/javascript]

采用的也是颗粒化的方式，将负责不同功能的代码整理到独立的js文件里，比如：DOM、string、Event、http、fx、ui等等，不过Jet方法里并不能像YUI3那样直接导入该包的js文件，查看它的DEMO，需要自由组合几个js文件来实现想要的功能，做到了无缝的插入包，这个就得益于Jet中的微内核—jet.core.js。

上面是第一个“复制”，在查看jet.base.js这个文件源码的时候，看到了很多熟悉的函数呀：$try、clone、timedChunk、bind、random等等，这些都还是似乎直接复制。这个base文件包含了微内核、dom、browser、event、date、Class（用于继承和扩展的相关方法和属性）。但是，感觉看Jet的源码很爽，读起来很顺畅，整体来看Jet的各个文件的组织是：微内核来提供包以及仿照YUI3的这种操作方式，而其他的dom、event、browser等则是作为工具代码包的概念组织起来的。这就更像是一种函数功能集合，在各个包里对提供的各种接口API，也是过程函数的编写方式，增加、删除、修改都非常的容易，颗粒化的程度较高，这点非常赞~。核心逻辑简单了，代码组合的方式也就简单的多了。

Jet中Class的继承方式还是比较简单的，并且只提供原型的继承，对于父类中的使用this声明的方法和属性则不继承。这点不知道开发人员是怎么考虑的。

还有一个非常赞的地方，是event包中addEventListener、removeEventListener在IE下的处理方式。在IE下使用一个包装函数来对事件event对象做属性扩展，来使得跟W3C的事件的属性接口达成统一。同时通过一个事件储存容器，来储存每一个事件，在window设置了unload的情况下，删除全部已注册的事件。onDomReady原理跟我之前所写的类似，通过定时器来检测document、document.body、document.getElementById、document.getElementsByTagName是否可用来实现。

在代码的编写方式上也有值得借鉴的地方：在包的开头将全部的功能函数用变量声明了，之后实现每一个功能函数，最后把功能函数注册到包的命名空间下面。这样组织代码，看起来比较清晰，对实现代码的颗粒化也是有很大帮助。

不过在代码的细节上，还是有很多可以优化的地方：包括减少属性查询、执行语句，字符串的处理，以及在一些功能的实现上等等也都可以使用比较优雅的方式来实现的。但整体上来说是：简洁、代码组织有序、在兼容性方面做的也不错……

翻完了《Javascript高级程序设计第二版》，对其中的最佳实践认同度很高。整体来说，看了这本书，对作用域、原型、构造函数、解耦、分离等等理解都有了另一种体会，原来测试中发现的很多疑问，在书中都能够找到答案，很阔然开朗。来聊聊内容、行为、表现分离吧。

或者也可以说是：结构、数据、行为、表现相分离，因为内容具体的就是指结构和数据，而这点是比较容易误解的：数据和结构也一定程度上需要保持分离。而数据和结构分离的一种应用场合就是模板技术，模板提供结构，后端提供数据，前端或者后端技术提供模板解析行为，CSS控制表现。

行为和结构、数据容易造成混淆的原因之一就是在js中使用了innerHTML包含了一段html字符串。在当前应用中可能实现了很多功能，也很稳定，但是后期的维护以及页面的调试可就会造成问题了，因为是动态生成的一段HTML代码，在源代码中查看不到（但是通过firebug、DOM Inspector等都可以查看到）。在后期的代码反反复复的修改中，可能就存在问题了。而且，使用innerHTML的一个性能问题是：在调用了innerHTML方法后，会启动一个新的HTML parser来解析html字符串。同理，使用eval、setTimeout/setInterval、new Function来执行一个字符串类型的js代码的时候，也会启动一个新的js parser来解析js代码，都会造成一个性能问题。一种解决方案是：在页面中先生成那段innerHTML，在CSS中设置为display:none，当需要显示的时候，就通过js来显示该html片段（但是这样也存在可用性问题，当js被禁用的时候，就无法再查看该内容了）。还有一种情况，就是使用js的createElement、appendChild来生成一大段HTML片段并插入到页面中，这种情况后期的维护更艰难，谁知道哪天要修改这个HTML结构了，那时候就痛苦了，解决方案可以是在服务端来生成这样的一段HTML，通过js动态插入到相应的位置；或者使用Ajax的方式，来将整段HTML片段插入到页面中。

行为和样式混淆的一种原因是在js中使用了style、cssText等属性动态给DOM元素生成行内样式，这存在同样的问题。js应该只负责功能，而CSS负责表现。所以解决方案就可以是通过className或者动态嵌入一个css文件来实现。

在书中的最佳实践中提到的代码维护，也是说的很在理的，不过这些都是通用性的组件、大型应用、将会经常维护更新的项目才会涉及到的。“对于不是自己维护的对象/类，千万不要随意去修改它的任何方法和属性。”确实如此，因为你不知道这个对象或者类，你就不知道它嵌入到了那些对象/类/方法中，稍微的一点修改可能造成其他功能的崩溃。也可能出现的情况是其他人不知道这个对象/类修改了，而是用了原来没修改前的方法/属性。但是原来的对象/类所拥有的方法已经不能满足你的需求，那么就使用适配器吧，切勿修改接口。

上面所说的代码维护的方法，也是从重构的角度去考虑问题的：解决今天的问题之后，能不能也解决下预期内的明天的问题。比如，你要在原来的代码的基础上添加新功能（或者说是新方法），可是发现在当前的代码的模式下，扩展性很不好，突然想到如果修改修改，那么扩展性就好多了，后期的添加其他的功能也可以更容易，那么重构就开始了。一段代码，今天看起来很爽，明天再看起来，可能就很糟糕了。

并不是处处都需要把重构挂在脑边，重构也有它的使用场合以及何时不能使用重构。当添加新特性、修改bug等等的时候，可以考虑下代码是否需要重构，使得后期的维护可以花费更少的成本。当然了，如果添加一个新特性，上头要求要尽快完成，时间不用了，重构要花费一段时间，那么这时候就不需要考虑重构了，实现功能优先级更高，这也从中说明你的上头是“重进度”，而不是“重质量”的类型。

因此，重构有一个三次原则：第一次编写代码实现一个功能的时候，无须考虑重构；第二次做这个功能类似的重复性的工作的时候，会有些恶心，而你也可能不打算去重构，第三次又重复性的对这个功能做修改的时候，那么这时候，就该考虑重构了。

重构更重要的是：给你一种重构的思想，以及进行重构的技巧。别把它当作一个“银弹”，而是要深入到你编写的代码中。

有多少人会回过头来看自己写过的代码呢？

需要安装插件、新版的现代浏览器才支持的方案都存在很大的缺陷，在可用性方面得不到最大的保障，如果能充分利用各大浏览器都普遍支持的方案来实现，这样才能更加符合大部分应用的需求，window.name能在当前页面刷新或者在当前窗口跳转到其他页面的时候仍然存在（试试吧），不过不能跨窗口传值；还有User Data在IE下也支持完好（缺点是：只能在相同目录下的页面之间共享数据）；再加上HTML5提倡的localStorage方案来实现其他支持它的现代浏览器，来做到渐进增强、稳步退化。这是经常会使用的方式，来做到一个比较好的权衡。

但是有一点必须注意：不宜在客户端存储敏感的信息。使用window.name、localStorage、globalStorage等在客户端存储的信息都非常的容易暴露，所以建议在完成数据存储或者设定一个过期时间清除掉来保证用户帐号等的安全。

从上面的所说的出发，使用window.name、User Data在IE6、7上实现存储、IE8+等现代浏览器使用localStorage或者globalStorage来实现，得到了一个比较权衡的兼容，但是缺点仍然存在：IE6、IE7下使用User Data不能跨目录读取存储的数据，这时候就可以使用window.name来实现跨页面的存储数据；localStorage或者globalStorage就可以实现跨页面、跨目录的读取存储的数据，但是都不能跨域。下面是使用示例：

[javascript]
storeLocalData.setItem("test1","shafeng00453sfsdfsd1");
//storeLocalData.setItem("test","supersha001");
//storeLocalData.removeItem("test");
alert(storeLocalData.getItem("test1"));
toreLocalData.setItem("test2","fsd1");
alert(storeLocalData.getItem("test2"));
//================================
//storeLocalData.clear(); //clear all data
//alert(storeLocalData.getItem("test1"));
//alert(storeLocalData.getItem("test2"));
//================================
//还可以添加"onchange事件"，来检测指定name的值是否改变，并执行事件函数。
storeLocalData.setItem("test1","shafeng00453sfsdfsd1",function(k,v){
alert("you have change the value");
});
storeLocalData.setItem("test1","shafeng00453sfsdfsd1"); //这个就会“触发”所谓的onchange事件了
[/javascript]

来测试看看咯：开始存储–>另外的页面来读取–>跨目录的读取–>你可以在关闭浏览器之后再浏览这个。

源码展示：

[javascript]
var storeLocalData = function(g){
var storageEvents={},docElement,w3cStorage,storage,names=[];
!document.all ? (w3cStorage = true,storage = g.localStorage || g.globalStorage[location.hostname] ) : (docElement = document.documentElement) && docElement.addBehavior(‘#default#userdata’);
return {
"setItem":function(key,value,onchange,isow){
var evt = null;
if(onchange){
storageEvents[key]={};
storageEvents[key]["onchange"]=onchange;
}
if(this.getItem(key) && (this.getItem(key) != value)){
(evt=storageEvents[key]) && evt["onchange"] && evt["onchange"](key,value);
}
if(w3cStorage){
var ls = localStorage[key];
storage[key] = !isow ? value : ls ? ls : value;
}else{
docElement.setAttribute(‘value’, value);
docElement.save(key);
names.push(key);
}
},
"getItem":function(key){
return w3cStorage ? storage[key] : (docElement.load(key),docElement.getAttribute(‘value’));
},
"removeItem":function(key){
w3cStorage ? storage.removeItem(key) : (docElement.removeAttribute(‘value’),docElement.save(key));
},
"clear":function(){
if(w3cStorage){
storage.clear();
}else{
for(var i=0,l=names.length;i<l;i++){
this.removeItem(names[i]);
}
}
},
"setWinName":function(value){
g.name=value;
},
"getWinName":function(){
return g.name;
}
}
}(this);
[/javascript]

暂时还没找到更好的方案来解决IE6、IE7下的跨目录的读取存储数据。有待观察……

扩展阅读：http://diveintohtml5.org/storage.html，常用浏览器本地存储的几种方案对比

当初利用三元运算符来代替多个if的逻辑，使得代码看起来简单，虽然牺牲了一点代码可读性，但是代码看起来没有那么臃肿了。对于if逻辑多的时候，可以使用switch来代替众多的if…else if逻辑，但是对于每一个分支比较复杂或者是很类似的时候，看到switch…case一连串，也感觉不爽，那么就是用字面量对象来代替吧，就如我下面所写的那样：

[javascript]
var checkFn=function(operation){
return {
‘=’:function(e) { return (e.getAttribute(attr) == attrValue); },
‘~’:function(e) { return (e.getAttribute(attr).match(new RegExp(‘\\b’+attrValue+’\\b’))); },
‘|’:function(e) { return (e.getAttribute(attr).match(new RegExp(‘^’+attrValue+’-?’))); },
‘^’:function(e) { return (e.getAttribute(attr).indexOf(attrValue) == 0); },
‘$’:function(e) { return (e.getAttribute(attr).lastIndexOf(attrValue) == e.getAttribute(attr).length – attrValue.length); },
‘*’:function(e) { return (e.getAttribute(attr).indexOf(attrValue) > -1); },
‘a’:function(e) { return e.getAttribute(attr);}
}[operation];
}
[/javascript]
上面就可以避免使用switch来罗列基于operation的分支了，代码简洁多了。很多时候，利用字面量对象可以很巧妙地去处理if等判断逻辑，使得程序无需判断，就可以直接通过字面量对象得到想要的结果。下面是摘自MoolTools库开头的一段代码，读起来很顺畅，也很巧妙：
[javascript]
//用于给对象添加静态方法
Native.genericize = function(object, property, check){
if ((!check || !object[property]) && typeof object.prototype[property] == ‘function’) object[property] = function(){
var args = Array.prototype.slice.call(arguments);
return object.prototype[property].apply(args.shift(), args);
};
};
//用于给对象添加type属性
Native.typize = function(object, family){
if (!object.type) object.type = function(item){
return ($type(item) === family);
};
};
//具体的实现过程
;(function(){
var natives = {‘Array’: Array, ‘Date’: Date, ‘Function’: Function, ‘Number’: Number, ‘RegExp’: RegExp, ‘String’: String};
for (var n in natives) new Native({name: n, initialize: natives[n], protect: true});

var types = {‘boolean’: Boolean, ‘native’: Native, ‘object’: Object};
for (var t in types) Native.typize(types[t], t);

var generics = {
‘Array’: ["concat", "indexOf", "join", "lastIndexOf", "pop", "push", "reverse", "shift", "slice", "sort", "splice", "toString", "unshift", "valueOf"],
‘String’: ["charAt", "charCodeAt", "concat", "indexOf", "lastIndexOf", "match", "replace", "search", "slice", "split", "substr", "substring", "toLowerCase", "toUpperCase", "valueOf"]
};
for (var g in generics){
for (var i = generics[g].length; i–;) Native.genericize(natives[g], generics[g][i], true);
}
})();
[/javascript]

别看上面的代码多，也别看它这样做是否合理，其实它已经很好的处理了使用相应的原型的方法来实现静态方法，它的实现方式感觉不错，看起来有种恍然一亮的感觉，思维上可以借鉴的地方很多。

字面量对象还可以做很多其他的事情，来简化代码的编写，有待你去发觉，^_^。

扩展阅读：《Organizing Javascript code》、《How I write JavaScript Widgets》、《http://www.klauskomenda.com/code/javascript-programming-patterns/（需要翻墙）》

1. Separation of concerns
   即是我们平时挂在嘴边的行为、样式、结构分离（Content-markup、Presentation-CSS、Behavior-JavaScript），这在代码的扩展性、可维护性、易迁移性方面都可以得到很大的提升
2. Literals，JSON，namespace
   Literals指的是codding尽量字面量化，对象字面量、数组字面量、函数字面量、正则字面量等等，这些都比使用new来实例Object、Array、Function性能上更好，甚至也推荐使用变脸的形式来声明函数，避免直接使用function来声明一个函数。
   JSON提供一种更简洁、更直观的数据传输，在大小和解析方面都胜于XML。
   namespace是尽量将每一个APP封装在一个独立的命名空间下，避免跟其他的APP模块产生耦合，产生错误。“低耦合”是namespace的一个终极目标。
3. Self-executing functions
   顾名思义，就是指自定义函数，它用的比较多的场合是在闭包中，提供给code一个纯净的上下文执行环境，而不会造成全局变量泛滥
4. Callbacks
   回调函数，用过“鸡查询(jQuery)”的人都知道，在执行完一个函数之后，再调用回调函数进行下一步的操作，做到了“流畅的执行流”。
5. Borrowing methods
   别看Borrowing这个单词是“借”的意思，感觉有点高深，其实就是利用了apply和call两个方法来借用其他类或者对象的方法来实现功能，比较多的场合是借用数组的一些方法，比如slice、join等等，比如：[].apply(arguments,[1,3])。这只是普通用的比较多的情况，但是它还可以用在这样的一个场合，类似于“继承”：我首先使用一个“基类”—即是一个包含通用的方法和属性的对象，之后其他的结构跟它类似的对象就可以通过apply或者call来“借用”这个“基类”的方法，说的可能有些枯燥，上点代码：
   [javascript]
   var Base={
   name:"",
   "getName":function(){
   return this.name;
   },
   "setName":function(name){
   this.name=name;
   }
   }
   //有了上面这个“骨架”之后，接下来就可以“借用”了
   //比如从服务器端获得了这样的一个JSON结构：
   var json={
   "test1":{ "name":"lilei","age":22},
   "test2":{ "name":"Sam","age":30},
   "test3":{ "name":"Susa","age":15}
   }
   //这样我们就可以这样来调用了:
   alert(Base.getName.call(json.test1));
   ///////////////
   ////////这只是个简单的例子，实用性并不高，提供的是一种设计思路，在某种场合或许就可以利用它
   [/javascript]
6. Functions returning functions
   在函数中再返回函数，这也是比较普通的了，为特定的场合所使用
7. Functions overwriting themselves
   函数重写它自己，这点或许很多人都知道怎么回事，但是怎么去利用它，还比较模糊。它的一个非常适用的场合就是处理浏览器兼容性的判断，也就是所谓的“Lazy Definition”。它就是在第一次执行的时候就根据不同的条件进行判断，来重写自身函数，这样在第二次之后的调用中就可以直接调用，而无需再判断兼容性等等，比如：
   [javascript]
   var addEvent=function(el,type,fn){
   addEvent=el.addEventListener ? function(el,type,fn){
   el.addEventListener(type,fn,false);
   }:function(el,type,fn){
   el.attachEvent("on"+type,fn);
   };
   return addEvent(el,type,fn);
   }
   [/javascript]
8. Function properties
   这个就是给函数添加属性，通常使用这个无非是为了临时储存数据或者在这个函数的命名空间下在执行期间一直储存数据。比如cache的实现等。其实这里的Function可以延伸到DOM节点等任何可以设置属性的对象上。不知道大家有没有看过John Resig写的那两个addEvent和removeEvent方法，就是在DOM中临时储存数据来实现在IE下正确的removeEvent。
9. Configuration object
   看过或者使用过YUI的，都知道它其中的对象、类、方法中都充斥着config参数，这里说的Configuration object多多少少就是这种应用，不过一种比较好的说法是“在参数列表中，如果参数数目多，那么将必须的参数独立起来，其他的可选参数都放到一个字面量对象里，即是Config参数”，这是有一定合理性的，一来代码看起来比较直观，明确区分了必须的参数和可选的参数，同时使得可选的参数无需按照顺序罗列出来。
10. Constructor return values
    在构造函数中返回值。这里就有一点误区了：如果返回的值是对象，那么new实例化的时候，实例对象就是该返回的对象，如果是普通的数值（字符串、数字、布尔值等），就忽略该返回的值，按照正常的方式实例化。
11. Forgeting new
    把new给“忘记”了吧。这里的“忘记”并不是说不去使用new，或者忽略它的存在，它在很多场合下还是得用（比如继承、一些带变量的正则对象等），这里的Forgeting的意思也是从继承等的角度去说的，尽量避免去使用new来实例化对象，道格拉斯曾经提出一种“伪函数化”的继承方式，例如：
    [javascript]
    var Base = function(name){
    var that = {};
    that.name=name;
    return that;
    }
    var subClass=function(name,age){
    var that = Base(name);
    that.age=age;
    return that;
    }
    //例如上面的例子，“继承”的方式就是利用了一个字面量作为载体，进行添加、删除、修改属性和方法等等，这样就可以给不同的子类扩展不同的方法和属性。
    [/javascript]
12. Chaining
    链式调用，“鸡查询”库可谓是开创了先河，它的简易性和便利性使得它的用户群猛彪，使得Prototype、ExtJs、YUI等不得不也借鉴它的方法调用的方式。
13. Inheritance
    继承。对，这里说的就是继承，面向对象思想中的其中之一，其实在一般的程序中，很少用到继承的方式来实现功能，但是如果从代码的扩展性、维护性等方面考究，以及从库、框架的角度来架构的时候，可能就需要继承这个技巧来实现整个代码的编写了。
14. Mixins
    这个词不好理解，YUI中的augment函数或许有些人看过它的源码，基本的应用场合是扩展对象，例如：
    [javascript]
    /* Augment function, improved. */
    function augment(receivingClass, givingClass) {
    if(arguments[2]) { // Only give certain methods.
    for(var i = 2, len = arguments.length; i < len; i++) {
    receivingClass.prototype[arguments[i]] = givingClass.prototype[arguments[i]];
    }
    }
    else { // Give all methods.
    for(methodName in givingClass.prototype) {
    if(!receivingClass.prototype[methodName]) {
    receivingClass.prototype[methodName] = givingClass.prototype[methodName];
    }
    }
    }
    }
    [/javascript]
    之前我也写过一片博文《享元类ShareClass》，原理跟这个差不多。
15. Private variables
    私有变量。“保持全局环境变量的干净”，这个被说的很多了。JavaScript可以模拟出私有成员、特权函数（即是静态方法），而实现这个仅仅需要一个闭包函数作为上下文执行环境，来于闭包外部的执行环境区分开来。静态方法仅仅需要给该对象或者构造函数添加方法，这样就使得该方法具有独享性。
16. Dynamic script tags
    动态添加script标签。这个主要是用于异步动态加载外部的js文件，使得js的加载和执行不会阻塞后续资源的加载。这里罗列了七种加载js的方式：http://www.ilovejs.net/lab/loadjs/。不过有一点值得说明的是：浏览器解析过的script标签，浏览器不会重新去解析，即使你通过text属性修改了script标签内的代码，或者修改了script标签的src属性，浏览器也不会去重新解析它。
17. Modules
    模块，也叫做组件。模块化开发已经广泛为前端界的人所知晓了，它并不是一个很新的东西，而是一种代码设计的思维，从代码的可维护性、独立性、松散耦合方面来设计代码。这个就跟面向对象的思想一样，都是一种设计方式，来适用于不同的场合。

query2中查询方式也是从左到右，这个是比较普通也容易实现的方式，有人说从右到左进行查询的话，效率会比较高，查询的复杂度较低。我想这就要开具体的selector了，如果是这样的“.test p”，那么从右到左的话复杂度就更高一些了，可能还得递归到document.body节点查询父元素的className是否等于test。所以双方面都有利有弊。

但是从左到右的查询方式还有一个比较苦恼的问题，就是“去重”（这是昨天跟瓶子吃饭的时候他提及到的问题），比如：

[html]
<div>
<div>
<p>Hello world</p>
</div>
</div>
[/html]

这时候如果使用“div p”来查询p标签元素的时候，如果不去重，就会导致使用getElementsByTagName查询到两个p元素，如果是在查询结果后给p标签添加事件，那么问题就大了。所以再进行查询的时候，必须得去重。

query2加入的去重的功能，同时还支持querySelectorAll（注意：对于不符合CSS指定的selector，querySelectorAll会报错），它最大的功能，就是可以DIY属于自己的selector，可以根据自己的需求来指定selector，具体示例可以查看谈谈松散耦合、颗粒度中给出的代码例子。源码展示如下：

[javascript]
;(function(g){
var D = document,fqueryAll=true;
var _tag = function(tag,p){
return p.getElementsByTagName(tag || "*");
}
var contain=function(a,b){
return a.contains ? a!=b && a.contains(b) : (a.compareDocumentPosition(b)==20);
};
var _queryMethod = {
"#":function(q,p){
var bits = q.split("#"),
tagName = bits[0],
id = bits[1],
element = document.getElementById(id);
return tagName && element.tagName.toLowerCase() != tagName ? [] : [element];
},
".":function(q,p){
var bits = q.split("."),
tagName = bits[0],
cn=bits[1],
elems = null,
returnEl = [],
index = 0,
reg = new RegExp("\\b"+cn+"\\b");
for(var i=0,l = p.length;i<l;i++){
elems = _tag(tagName,p[i]);
var tmp = null;
for(var j =0,m = elems.length;j<m;j++){
if(!/\S/.test((tmp = elems[j]).nodeValue)) continue;
if(reg.test(tmp.className)){
returnEl[index++] = tmp;
}
}
}
return returnEl;
},
"_tag_":function(q,p){
var found,returnEl = [],index=0;
for(var i=0,l=p.length;i<l;i++){
found = _tag(q,p[i]);
for(var j =0,m=found.length;j<m;j++){
returnEl[index++] = found[j];
}
}
return returnEl;
},
"]":function(q,p){
q.match(/^(.*)\[(\w+)([=~\|\^\$\*]?)=?"?([^\]"]*)"?\]$/);
var returnEl = [],
index=fIndex=0,
op=RegExp.$3,
tag=RegExp.$1,
attr=RegExp.$2,
attrvalue=RegExp.$4,
found = query(tag,p);

var checkFn = {
‘=’:function(e) { return (e.getAttribute(attr) == attrValue); },
‘~’:function(e) { return (e.getAttribute(attr).match(new RegExp(‘\\b’+attrValue+’\\b’))); },
‘|’:function(e) { return (e.getAttribute(attr).match(new RegExp(‘^’+attrValue+’-?’))); },
‘^’:function(e) { return (e.getAttribute(attr).indexOf(attrValue) == 0); },
‘$’:function(e) { return (e.getAttribute(attr).lastIndexOf(attrValue) == e.getAttribute(attr).length – attrValue.length); },
‘*’:function(e) { return (e.getAttribute(attr).indexOf(attrValue) > -1); }
}[op] || function(e) { return e.getAttribute(attr);};

for(var i=0,l=found.length;i<l;i++){
if(checkFn(found[i])){
returnEl[fIndex++] = found[i];
}
}
return returnEl;
}
}
//去重
var pureMutil = function(els){
var returnEl=[],index=0,tmp=els[0];
for(var i=1,l=els.length;i<l;i++){
if(!contain(tmp,els[i])){
returnEl[index++]=tmp;
if(i==l-1) {returnEl[index++]=els[l-1];break;}
}else if(i==l-1){
returnEl[index++]=els[i];
break;
}
tmp=els[i];
}
return returnEl;
}

g.query = function(q,p){
var elems = p || [D],reg=new RegExp(g.query.config.reg),tmp;
if(fqueryAll && D.querySelectorAll){
try{
return D.querySelectorAll(q);
}catch(e){fqueryAll=false;}
}
var tokens = q.split(‘ ‘),token,m;
for(var i=0,l=tokens.length;i<l;i++){
token = tokens[i];
m=token.match(reg);
tmp = _queryMethod[(m&&m[0]) || "_tag_"](token,elems);
if(l==1) {elems=tmp;break;}
elems = (i<l-1)? pureMutil(tmp) :tmp;
}
return elems;
}
g.query.config={
reg:"(\\])|(\\.)|(#)",
addSelector:function(mark,fn){
if(!mark || !fn){return;}
_queryMethod[mark]=fn;
mark = mark.replace(/(\.|\||\[|\]|\^|\\|\$|\?|\*|\+|\{|\}|\(|\))/g,"\\\\$1");
this.reg += this.reg.indexOf(mark)!=-1? "" : "|("+mark+")";
},
queryMethod:_queryMethod
}
})(this);
[/javascript]

jQuery是毒药 —— 很多人都这么说。本人也举得，从一个程序员的成长来看，jQuery是弊大于利。我们更应该做的是学习它的原理和架构，而不是拿来用而已。

一个很经常会发生的问题：我只需要用到一个javascript库中的几个方法，却需要加载整个库的体积，而整个库封装的又十分复杂，拆分起来十分繁琐，怎么办？自己写呗……

一个javascript库的本意虽然说是为了提高开发效率、解决浏览器的兼容性问题、统一开发规范以及解决安全隐患等等。但是在设计javascript库的时候，我们是不是应该多留多点空间给使用者去DIY它的具体的功能，让使用者多点接触到javascript的本质，以及非常容易的缩减库的体积呢？就从这几点出发，YUI3是比较符合“松散耦合”、“颗粒度”的原则的，虽然说jQuery可以通过fn方法来扩展，但都是基于它整个已经封装好的库来说的。但是YUI3也有它的缺点：学习成本高、整体体积庞大、可能一步小心在use方法里多加载几个文件，或者使用”*”，那么需要异步加载的js文件也是很多的、以及它内部组件之间的依赖关系也是比较复杂的。

为了说明我的想法，首先从我编写的query鸡查询函数（目前还没完善，先拿来做例子）开始说起，我的想法是：只在query里实现最基本的selector查询，比如ID、class、tag、属性，之后用户可以自定义selector添加到查询函数当中，来实现自己特定的查询需求，从这点出发，改写了之前所写的query代码（之前的query.js），目前它只集合了ID、class、tag、属性选择器（或者也可以干脆连这些使用者都可以重新定义自己的功能函数，自己来实现，DIY很爽~），其他的自定义选择器都可以自己DIY，并且编写它的实现方式（留给使用者更多的编写底层代码的空间，爱怎么实现就怎么实现，方法是多样的），比如：给selector添加“:first”和“:l”来实现CSS3中的:first-child和:last-child的功能：

[javascript]
//q:表示当前的selector，比如“div p:first”，就是div和p:first，使用split通过空格切分的单个selector
//p:表示是上一级查询的结果，是数组类型的。
query.config.addSelector(":first",function(q,p){
var tagName = q.split(":first")[0],
returnEl = [],
index=0,
tmp=null;
for(var i=0,l=p.length;i<l;i++){
(tmp=query(tagName,[p[i]])) && (returnEl[index++]=tmp[0]);
}
return returnEl;
});
///////////////////////////////////////////////////////////
query.config.addSelector(":l",function(q,p){
var tagName = q.split(":l")[0],
returnEl = [],
index=0,
tmp=null;
for(var i=0,l=p.length;i<l;i++){
(tmp=query(tagName,[p[i]])) && (returnEl[index++]=tmp[tmp.length-1]);
}
return returnEl;
});
[/javascript]

通过这样的方式，使得core核心代码尽可能的小，可扩展性强，同时也提供给使用者更多的编码空间，了解javascript这门语言的核心知识。目前经过压缩过后的query2-min.js和未压缩的query2.js提供浏览。并附带实例：《点点看呗》

扯谈完毕，欢迎拍砖~

[javascript]
//第一：
eval("onmessage=function(str){alert(str);}");
onmessage("shllo");
//第二：
var s = document.createElement("script"),h=document.getElementsByTagName("head")[0];
s.text="onmessage=function(str){alert(str);}";
h.appendChild(s);

onmessage("hello");
[/javascript]

说到这个，还发现一点很容易造成失误的地方：在浏览器解析过的script中的代码，浏览器不会重新对该script标签内的行内脚本、外联脚本执行，就算是重新给script标签定义行内脚本或者修改它的src来链接到其他的javascript脚本，浏览器都不会重新解析。

——————- 提IE8 eval的兼容性分界线 ——————–

从上一篇文章《Web Worker浅析》中，我们了解到Worker的思维是跟Ajax类似的，包括它也不支持跨域调用javascript文件，这说明底层的数据交互还是跟Ajax的模式类似（也有可能就是使用了Ajax的方式）。但是由于IE8及以下版本都不支持Worker，所以IE就不能充分利用Worker的优点来优化浏览器执行javascript代码的性能了。但是既然Worker跟Ajax类似，那么就让IE使用Ajax的方式来实现吧，这也不是不行的。

在IE中实现Worker机制，一个比较棘手的问题是postMessage、onmessage在主页面和Worker之间的调用问题，从代码上看，主页面是通过Worker类的实例化对象来调用postMessage、onmessage，而Worker里是直接声明和调用。所以在IE里，就可以模拟Worker的操作方式了。下面是我在IE下实现的方式：

1. 在IE下重新定义Worker类，并且带有一个postMessage方法，这样就的话不会跟支持Worker的浏览器相冲突
2. 使用Ajax的方式来加载外联的javascript文件，并通过eval执行返回的代码
3. 通过一个全局的字面量对象，来实现两个文件之间的数据传输
4. 不能改变标准的Worker类的编写方式，这个是一定要做到的

从上面的几点思路出发，编写了下面的实现代码：
[javascript]
(function(g){
if(!document.all) return;

var xhr=function(){
var x = null;
try{
x = new ActiveXObject("Msxml2.XMLHTTP");
}catch(e){
x = new ActiveXObject("Microsoft.XMLHTTP");
}
return x;
}

g.postMessage = function(data){
g._evt_.data = data;
}

var Worker = function(url){
this.url = url;
}

Worker.prototype={
postMessage:function(data){
g._evt_={};
g._evt_.data=data;
var x=xhr(),t=this;
x.open("GET",this.url,true);
x.onreadystatechange=function(){
if(x.readyState === 4 && (x.status === 304 || x.status === 200)){
//直接使用eval(x.responseText)在IE8下会提示错误，很奇怪，可能跟eval函数有关了
//为此不得不使用这种不太牢固的方法
eval(x.responseText.replace("onmessage","var onmessage"));
onmessage(g._evt_); //执行Worker中定义的onmessage方法
t.onmessage(g._evt_); //执行主页面中的onmessage方法
g._evt_ = null;
}
}
x.send();
}
}
g.Worker = Worker;
})(this);
[/javascript]
在使用上有一点得注意，虽然在代码上没改变，但是在主页面中postMessage和onmessage的顺序得保持：先写onmessage、接着写postMessage方法，主要是为了在IE下能兼容。比如：
[javascript]
var worker = new Worker("js.js");

worker.onmessage = function(evt){
alert(evt.data);
}
//注意postMessage方法一定要在onmessage后面声明，否则会导致代码只会有一次有效。
worker.postMessage("supersha");
[/javascript]

到目前为止，测试还算良好，《测试页面》，在各个浏览器下都能够跑起来。

目前这个只是个简单的实现方案，代码上还是比较简单的，有待进一步的完善……

但是对于动画来说，overflow:hidden是必须要设置的，否则里面的文本不会被遮盖。

———===========—– 即时更新分界线 ——===========———–

最近接到个需求，在搜索结果中添加下拉动画，高度和透明度都需要渐变。在测试过程中，遇到这样的一个问题：在一个div容器中包含了几个p标签，而且全在默认样式的情况，这样通过offsetHeight，clientWidth，scrollHeight等等获得div的高度，之后动态设置div的overflow样式属性为hidden，这样上面所获得的高度不准确了，《点击测试吧》，这样的后果就是动画被和谐了。

从这里的overflow:hidden对div的高度的差异可以看出：容器包含内容的解析原理。正常默认情况下，比如div包含一个p标签，这样div的宽高是会忽略p标签默认的margin值；但是一旦给div设置了overflow:hidden之后，div的实际宽高就需要加上p的margin值了。不过值得庆幸的是，在给div设置了overflow:hidden之后，通过offsetHeight等来获取div的宽高，是准确的。

从上面的分析中对于开头遇到的问题，就可以有三种方法来解决了：第一、在动态设置overflow:hidden之后来获取容器的高度，《点点测试吧》；第二、将p标签的margin清0处理，《再点点呗》；第三、干脆就不要使用p标签，改用没有默认margin的div吧，很勉强的方法，《最后点击测试下》。

Tip: 经过测试发现，设置overflow属性为hidden、auto都存在上面所说的情况。