转Ext性能优化
前一阶段由于页面上的性能出了问题，于是进行了一次性能上的优化，时间也过了一阵了，想总结出一些东西来，可是一直没有时间，今天下班早一些，赶紧整理一下思路，以免以后忘记了。
我们的框架配置：Struts2+Spring+Ext2.1
页面布局：主页面＝menu+toolbar+tabPanel ，每一个模块一个TAB页的形式展现出来。（很传统）
我们经历的三次重构：
1. 从普通的JSP＋HTML＋自定义TAG －－》 EXT
2. 多个JSP的TAB页面嵌套－－》One Page One Application
3. JS全部一次性加载－－》JS依赖关系懒加载＋JS压缩
这三次重构的方案实际上是我们在EXT开发过程中的不断的犯错误中的教训总结。
下面我就从这三次重构中总结一下每一次的出发点及动机，经历的磨难，最后的成效。
第一次，从JSP＋HTML＋TAG －－》 EXT2.1
这一次的重构在我们项目来看是一次历史性的变革。项目在进行过程中，前期大量的需求调研，并与客户进行拍板定需求，可是客户都是打太极的高手，他们不会告诉你他要什么，他也不会拍些板来说这个就这么做了，所以我们对于需求上的定义始终是模糊的。他们对系统的要求也是相当的高，会要求在BS上的架构上进行数据实体的连线，会要求多种多样的表现形式。
我们先从静态页面进行了初期的规划，画了一版静态页面，然后客户对些不发表任何意见，要求一个能连贯起来的系统。于是我们以最快的速度在短时间内使用JSP＋一些自定义的TAG＋HTML＋CSS画出了一些有较多功能性的模块，在这过程中，客户对页面不断的提出要求，要更多的用户体验，对我们所画出来的列表，表格，树以及布局都提出了较高的要求，并一再的埋怨我们的页面过于死板。在客户的不断压力下，领导提出了一个相当有风险的提议。使用当前国内界内用户量并不是很大，使用也不是很成熟的EXT。
我在以前的项目使用过一段时间，只有少量的经验，这个决定很超出我的想像。在这一点上，我有很多东西需要向领导们学习。领导给我们的预研时间是一个星期。由于成手很缺少，于是项目内组织几个以前有过页面开发经验的一年的员工进行技术预研。这一周时间里，我们的预研人员数量还是不错，将EXT的版本定义在2.1这个相对较新的版本，将各个类型的控件分配到下面的每一个人手里，一周的时间里，大家对各自的控件都有了一定的了解。
其实这里差一点忘了一个更大的风险，我们的框架也是在这个时间里诞生的，之前公司内推的技术框架被领导贬的一文不值，于是我们有了搭建新的框架的想法。我们在这两周里，将框架的层次，各个层次的交互，异常的处理，事务的控制以及数据库的操作都定义出来了。其他的设计机制我们是在接下来的时间里完成的，但是前面所说的这几样最基本的模型是在这段时间里产生的。
经历了这两周的时间的预研过程，我们在新的框架上建立了一个相对较完整的DEMO，将各个层次之间也一起串联起来了。
时间很短，这里面领导的开发经验和天赋很让我佩服，我主要的工作是在前后台的交互，异常的处理和DEMO的开发上，并主要负责指导其他开发人员使用EXT的预研。
总结一下这一阶段的主要开发思路，其实这一阶段主要将EXT的使用进行普及，使所有的开发人员可以基本熟练的使用EXT进行业务模型的实现，并解决处理业务中的一些问题。所以这一次重构基本谈不上优化，只是一次功能与业务在新框架上的迁移。
第二次，将多页面的EXT模块开发转为one page one application
我们新搭建的框架在根本上还是以JSP和JAVA做为开发语言，虽然前台使用了EXT，大量的使用了AJAX的调用，但是JSP在服务端的编译还是避免不了。
同时，由于我们系统的特殊性，我们的业务的复杂性，我们在整个系统中，嵌套了多个页面，拥有多个JSP的嵌套。我们在第一阶段的时候，所有的模块的嵌入方式就是以iframe来进行嵌套。因此在这里，由于系统的复杂性，在最复杂的一个页面上，竟然嵌套了六层iframe。加上JSP的编译时间，再加上每一个页面上都引入了ext-all.js 和ext-base.js ，以及一些公共的JS文件，怎么可能不慢。我们粗略的计算了一下。最慢的页面打开要超过两分钟，客户端的硬件配置如果糟一点就更慢了。
在这种环境下，我们不得不进行第二次的页面重构，进行性能的调优。
分析一下这一次的重构，其实我们主要的问题在于业务的复杂性，数据量大，以及开发人员开发过程中的经验不足。
从框架的设计上来说也是有着严重的不足，其中大量的使用iframe就是一个问题，经过一些专业的测试软件测试，发现很多的iframe关闭后 ，该页面所持有的DOM节点并未释放，后来做了特殊的处理，也同样是无法全完释放页面上的内存占用。每一个页面上都引了ext-all.js，就单单这一个JS的基础类库文件，就足足有近500K，虽然多个页面引用后下载只下载一次，从缓存文件中读取，但是每一个页面要想正确的加裁EXT的控件，是需要对这个基础类库进行编译的。这样的话，多个页面进行嵌套的时候，就面临着这巨大的性能问题。
结合上述的问题所在，我们进行第二次的重构。主要的方案就是将过多的iframe进行合并处理，大量的iframe进行整合，减少ext-all.js的加载次数，并精减掉iframe。这样就从很大程度上减少了js文件的编译时间，重复JS编译时间。
最后我们精减后的页面框架是主页面上有一个JSP，上面加载了所有的JS，以前用iframe来框起来的页面都用Ext的panel来代替，从页面的编译时间上来看，是大大的减少了这方面的消耗。同时在副页面上，原来的多层的JSP也都使用panel来代替，其中将activeX控件也放在了panel中。
经过了重构后的系统，在JS下载及编译的时间上大大的减少了，jSP的引用数量少了，编译时间也缩短了。于是在性能上有了一个飞越。
可是好景不长，我们在重构基本完成的时候，性能问题再度暴露。
第三次，从首次完全加载，到动态加载JS。
由于使用了one page one application的思想，我们的页面减少了，可是JS并没有减少，一个页面上引用了大量的JS，其中算上基础的ext-all.js等文件，我们在一个页面上加载了170＋个JS文件，其数量真是可观，其性能也足以想像得到了。
由于这个企业应用的复杂性，我们的JS想减少是不太可能了，我们现在就是按功能点进行划分JS对象的。其中很多JS也都进行了合并。但是数量依然不减。
分析一下这次重构的原因，JS的数量过多，第一次加载页面的时候，会非常慢，但是加载过后，操作会较快，这个其实也是当初预料到的一个风险，但是没有想到会这么严重。有些低估了。同时，由于都在一个页面上，这个页面加载的DOM节点超级多，用监控软件可以看到节点的递增，并有部分节点不能正常释放，这个也是EXT官方论坛上公认的一个问题。要想从根本上去把这个问题解决了我们没有这个精力，也没有这个能力和时间。
后来，我们为此特意组织了一个性能优化小组，单凭我一个人是解决不了了，毕竟人多力量大。经过几次会议和几种方案的验证，我们做了如下的计划和方案。
1. 将JS进行合并压缩。
使用yahoo的yui-compress.jar进行压缩JS，去掉过多的空格和注释，并合并，减少IO的支出。
2. 将前后台传输的数据进行GZIP压缩。
大数据量的数据传输，通过GZIP的压缩方案，可以减少到25%，有些数据可能会更多。
3. 对大量的JS分析依赖关系，进行动态加载。
这个是关键，通过分析所有的JS中的依赖关系，减少了JS加载的数量。从很大程度上提高了性能。
4. 另外对部分页面进行缓存，而非真正的关闭。
对于Ext的消毁不能完全释放节点，那我们就不消毁他，进行对象的缓存，并在重新打开该功能的时候进行数据的重新加载和重置功能，对象重用。
经过上述的四种方案后，我们的页面性能有了大幅度的提升，由原来的35+秒，提升到首页面加载只需要3秒之内。
其中将依赖关系进行分析后，我们定义了依赖关系映射文件，将首页面上首先要加载的JS进行压缩合并，分块显示，同时将不需要一进入页面就要显示的模块进行懒加载，在使用的时候再从服务端DOWN下来进行编译，同时使用了数据的GZIP压缩，页面也进行了缓存。
还有一个外部的因素，由于系统使用的客户机环境上的复杂，我们在多个浏览器上进行了测试，只有IE是最慢的，尤其是IE6，后来发现不是IE6要比IE7慢，是因为发现MS发布了脚本引擎cscript 5.7, 而大部分的ie6系统都装的是5.6, 这个版本上的升级，不仅仅是修改了BUG，在JS的执行速度上也有了较大的提升，于是我们在环境因素上又加上了一条，要求客户安装cscript5.7，也大大的提升了页面的打开时间。
经过了上述的三次页面重构，我们的系统基本上在页面的性能上趋于稳定，基本上满足了客户对于性能及用户体验度上的要求。为此特定总结如下，感兴趣的朋友可以参见一下，有不明白的地方我们多交流，随着时间的推移，我会将这次项目中的很多经验都写出来，与大家分享。