EXTJS的渲染优化以及JS同步的模拟

      最近在看一个项目中的优化问题,项目是用extjs写的.面临的问题是项目中的页面打开时的显示时间让人头疼,看了下它的编码.发现它在EXT的基础上又包装了自己写一层渲染的结构方法,而HTML页面里的BODY居然是空的!!!它的页面显示全是在JS中进行执行来输出的,这个方式自然会因为JS的执行以及输出之间的阻塞而导致页面的显示时间的变慢.

      我个人其实比较崇尚页面编写的傻瓜化,象基础的页面框架可以用HTML+CSS来代替,而只在使用对应功能的时候来使用JS框架的UI.但是要别人去重构也是不太可能.对于页面的优化,再对一个最明显的页面进行测试和分析后,发现对EXT组件的渲染操作只在一句代码中发生,这就意味着这句代码将所有的EXT组件运算转换成HTML+CSS并输出到页面中.就这句话的时间平均就有2S多!!.用户体验极其差,看着空白的页面我自己都要抓狂了.所以决定重构它的渲染方式,采取按区域逐步渲染的方式向页面输出来减少页面空白的时间.

     但是在IE中发现逐步渲染的方式一点效果没有,页面上还是一次的输出.JS是单线程的语言,执行和输出阻塞了.那就只有在每次渲染后进行延时停顿来让页面更新,问题又来了,JS中的延时方法是异步的.在网上转了转,发现大家给的方案大多都是在一个循环里面执行一些操作来达到延时的目的.这简直太傻太天真,不仅占用率CPU而且可能让浏览器崩溃!!还发现了一种方法是借助AJAX请求的同步,在一个循环里不断发送同步的JAX请求来达到延时的目的.这个方法与在循环中执行JS运算的原理一样,但比JS运算更能达到CPU空转的目的,但是网络请求太多也不太好.最后,还是用最原始的延时方法来实现这个同步延时的方法,就是将所有的执行代码都使用延时来控制延时和代码的执行顺序来达到同步延时的目的.效果还是不错的,希望能起到抛砖引玉的作用.

      最后还是觉得网络应用不要太依赖框架,需要结合网络传输以及用户前台体验适当进行判断和取舍.