经过几个晚上的一点点升级，将之前搞的perl编译脚本进行了重构，并添加了一些功能，包括文件嵌套编译、添加对html文件的简单压缩、添加Google Compiler的压缩模式、修改了文件输出的方式等等。（具体的教程，可以查看：自动化工具提高工作效率中的描述） 在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。
网上看到的一篇文章，说的是js脚本优化的十条细则，看了下文章，优化的知识都很普通，搞前端的人都知道，罗列一下，增强记忆吧： 定义局部变量。对于当前函数作用域内，如果需要使用这个作用域外部的一些变量，那么就尽量使用局部变量储存外部的变量吧，特别是对于嵌套多级的作用域查询，这个耗时也是比较严重的。还有就是获取DOM节点、NodeList、HTMLCollection等等，可以将NodeList、HTMLCollection转化为数组的形式进行操作，减少DOM即时更新所造成的性能消耗。 不要使用with语句。with语句会在当前作用域下面增加作用域链，造成当前作用域下面变量的遍历性能消耗更大。 对于闭包的使用，节省点，不要太过多了。闭包就是提供一个所谓的“封闭式”的作用域，只允许向包含它向别人访问，而不允许别人访问它。但是声明一个闭包的代价比声明普通的函数的代价是要更高的，况且还有IE下内存泄漏的危险。 获取字面量对象的属性和数组的项比获取变量更慢。如果你要获取一些数据的时候，使用变量比用数组、字面量对象的索引来访问来的更快。在循环中经常会需要访问数据，使用变量存储一下，来的更快。 在数组中不要嵌套的过深。js中没有二维数组的概念，但是可以自己编写一个二维数组，并且可以无限的嵌套下去，json很经常就是这么干的。但是嵌套的越深，访问数组中的项就更难了，级数和性能消耗成正比的。 少用for-in循环。众所周知，for-in用于遍历对象的属性和方法，它所要消耗比for、while、do-while更多的性能。在for-in循环中，对于每一个循环，javasript需要创建一个函数来处理每一个循环，这就带来这么两个性能问题：函数创建、销毁的过程；这个函数在创建之后，又会储存它直接上级的作用域的活动对象。 对于循环，合并控制循环的语句，以及控制变量变化方式。在一个控制循环的语句中，比如循环结束条件、索引的递增等等，如果可以优化这些操作，那么对于整个循环的性能是有帮助的。比如对于结束循环条件：for(var i =0;i
javascript的加载方式，总得来说是在页面上使用script来声明，以及动态的加载这些方式，而动态的加载，在很多js库中都能够很好的去处理，从而不至于阻塞其他资源的加载，并与其并行加载下来。这样的动态异步的加载方式罗列起来有：Ajax的方式、DOM Element Insert、Iframe、document.write、defer等等。这些都能够很好的处理js在加载的时候不会阻塞资源加载的问题，但是，js的执行仍然会阻塞浏览器的渲染。或许这是不得不需要付出的代价，有没有一些方式去缓解js在执行的时候对浏览器的渲染所造成的延迟的影响呢？ 首先，让我们从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，如此这样的一个相应顺序。
Fetch resources on-demand，中文意思大概就是按需加载资源，而这里的资源不只是CSS、JS文件，Image、swf、Content等都可以利用这种方式。特别是当前Yahoo的首页：http://www.yahoo.com，几乎页面的每一个模块都体现了按需加载的技巧：左边的导航（用户可以定制、点击异步请求更多资源）、中间的新闻、图片tab、右栏的第三方资源等等。 按需加载表面理解起来很简单，但是怎么个按需法呢？我所理解的按需，包括两个方面：一个是按用户的需要；另一个是网站本身的需要。按需加载主要解决的问题就是加快页面的初始化以及在页面初始化的时候最大化减少HTTP请求，因为有些模块比如：图片导航tab、多级菜单、内容导航等等，这些在初始化页面的时候有很多内容都是处于隐藏状态，用户是看不到的，那么这些内容对不同的用户来说有不同的需求，那么这些就可以从页面的初始化中剥离出来，按用户的需求通过异步通信来加载内容和资源。对于网站本身的需要来加载后续资源，比如Google首页对于结果页的一些js、image等资源的pre-fetch的方式，通过分析用户可能会产生的行为，为后续的页面提前加载内容，加快后续页面的初始化速度，从缓存中读取页面所需要的资源。
Js学的也差不多了，该是来总结一下Js中一些比较高级的智慧结晶了。基于Js的动态性、对象都是易变的、函数是第一对象等等其他语言所不包含的特性，可以在使用Js的时候创造出更高效、组织性更好的代码。下面提到的一些概念，是不是很熟悉： 分支、惰性实例化、惰性载入函数、单例的两种模式、享元类、函数绑定（纠正函数一个执行上下文）、函数curry化、高级定时器、保护上下文的构造函数、函数节流、自定义事件…… js中的继承、原型、构造函数这些都是老生常谈的了。但是对于构造函数式继承和原型式继承的优缺点，还是有必要了解一下的。原型式继承的主要优点就是共享方法和属性，使得从原型对象中继承出来的子对象都可以在内存中共享全部的方法和属性，这如果是在大型的继承链中将会大大的改善性能和减少内存的使用量。
腾讯内部使用的js库也开源了— JET(Javascript Extension Tools – Javascript 扩展工具包)，很难得的一件事情，赶紧下了Jet 1.1.1版本的整个源码，包括说明文档来看看源码，看看腾讯强大的前端技术的后面会有一个怎样的js库来支撑的。http://code.google.com/p/j-et/wiki/JET 查看了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。