一次不成功的性能优化

把原型图写成页面容易,写成一个易于维护,html结构优雅的页面,不容易; 把需求堆成业务逻辑容易,实现的性能优秀,代码优雅就不容易了; 所以说,能做出东西的程序员很多,但是能把东西做好的,就不多了; 我还处于第一阶段,要学的东西还很多,我很着急,我很焦虑; —-题记

快展做到现在,页面上的控制器越来越多,模板越来越多,逻辑也越来越多; 加载速度不知不觉的慢到令人难以忍受的地步; 之前做简单的元素动画性能优化的一点经验明显不够调一整个页面用的;

在调动画性能的时候,由于动画的过程并不复杂,只要尽量减少js调用,减少定时器,应用一些3d的transform样式, 避免元素重排和重绘,将动画交给GPU处理,就可以达到在PC端和移动端都流畅的效果,并且fps也可以控制在30上下; 但是现在到了整个页面的加载,里面有数据请求,资源请求,样式计算,重绘,不了解的东西一大堆,不知道瓶颈到底在哪里;

首先想到的是减少请求数:上面说过,页面里有很多引入的模板引擎,就是ng-include,这个路径,同事写成了action的形式, 所以会先请求一遍php后台,然后后台再返回这个文件给前台,相当于一个后天模板引擎的流程,但是填充数据和渲染又是放在 前台的.我记得刚开始搭建项目的时候,我是直接在页面的src中写模板页相对于当前页面的相对路径的,但是引入不了,当时问同事, 同事说不能直接请求静态资源,我也没多想,就学着同事的写法,写action请求后台,然后在后台加对应的display方法,就为了返回 个html模板,就这样,用这种写法从四月份开始项目,一直持续到现在;

这两天我突然反应过来了,那个include的路径之所以直接写相对路径引入不进来,不是不能引用静态资源,而是相对的对象不对! 这个相对路径,并不是主页面和被引入的html的相对路径,而应该是ng-include所在的Controller与被引入的html文件的相对路径. 比如,

主页面是 project/Tpl/main.html

要引入的页面是 project/Tpl/partial.html

ng-include所在块的控制器是 project/js/someController.js

那么ng-include的src应该是 ../Tpl/partial.html;

原理是,

页面中<ng-include src=”somePath”></ng-include>

对应的是Controller中的一个变量:$scope.somePath=xxxxx

而如果写成<ng-include src=”‘somePath’“></ng-include>,

其实效果是这样的:

页面:<ng-include src=”a”></ng-include>

控制器:$scope.a=’somePath’

所以这个变量不管写成变量还是字符串常量,都是要到Controller里去解析的,所以这个路径就是控制器相对于带引入的那个html的路径;

想明白这个问题之后,所有的路径都可以改写成直接请求静态资源的路径,就避免了请求php后台造成的开销; 顺便说一下,从时间线上来看,请求的资源从php过一手与直接返回静态资源来比,相差的时间还是很大的,大概一两个数量级, 整个请求时间从1s上下变成几十ms,主要是等待时间; 这样,页面中引入的10多个html,节省了10多个后台请求; 然而,从效果上看,性能并没有提升 = =|||

然后同事说,竞品是把一些页面模板写成angular模块,也就是变成了js文件,然后合并了之后传到前台的, 这样,很多个html又能合并成很少的一两个js文件,这样对静态资源的请求又减少了; 但是这么做的话,纯手工的情况下不仅工作量大,而且代码也不好维护; 于是,我在网上找到了这个帖子:

ng-template寄宿方式

经过研究,又找到了一个html2js的一个插件,正好顺便把gulp环境也搭起来了; 少许配置,跑了个任务,10多个html就合成了两个js文件; 请求数又少了一堆; 然并卵;

这次有变化确实是有变化,原来是主页面很快加载进来,子面板从空白状态逐渐变为加载完成; 合并之后变成主页面直接空白3S左右,然后全部面板直接可用,也就是说,请求主页面的时间变长了,看了下timeline,貌似是XHR的过程中 有很多的js调用,导致了性能问题,这个还不确定; 看到性能不行,只能把代码退回去了;

退回到请求html的状态吧,毕竟请求php太说不过去了,然后有考虑到,既然能在客户端直接请求到html,那么相当于项目目录下的所有东西 都暴露给用户了,这个不是很好,于是又用回html2js的方式了. 还有一点,之前对比性能的时候,是用快展的编辑页和竞品的首页做对比,当然性能差的很多,后来和竞品的编辑页比较,发现快展的性能倒是比竞品 强了不少;

不过依然不安心,还是不知道如何优化性能,如何使用chromeDevTools. 还得继续研究;

Written on August 27, 2015