当前位置:首页 > 新闻中心 > 互联网动态
前端开发,你的优化要跟得上时代的变更责任编辑 :李飞    文章来源 :星翼创想(www.iswweb.com)    发布时间 :2015-10-27    阅读次数:720

系统开发,不仅仅要关注前端的设计,系统或产品的更新更加要跟得上时代的变化。优化的对象不仅仅指产品本身,还有我们日常的开发流程。如果不做优化,那么要么是你的产品过时了,要么是你的开发效率太低,开发的技术也会跟不上时代的节奏。因此,作为系统开发/产品开发的成员,我们必须有敏锐的触觉和快速的优化变身的能力,不然只会被淘汰在茫茫的互联网大海之中。

下面我们一起跟着深圳市星翼创想网络科技有限公司来阅读以下文章,看看做前端开发优化究竟都经历了什么吧!


11.0时代

前期模块化已经做的不错了,至少不必花大量时间去重构代码。模块划分如下图,逻辑层次上还是比较清晰。

性能优化 网站优化 网站代码优化 网站性能优化

前端模块化依赖的主流库也就数国内的Seajs和国外的requirejs,这里就不陈述。采用了Seajs作为模块管理器,zepto作为基础库文件,lib主要包含了项目中用到的主流第三方库文件。

我们知道模块化带来的最大弊端便是HTTP请求数增加,所以上线的时候必须合并文件。下图中的package模块是文件大集合,打包了很多个JS模块,除去上图中的基础库文件和业务模块层,在上线的时候大部分文件都被打包在package.js里。

性能优化 网站优化 网站代码优化 网站性能优化

大部分页面的JS请求是这样的:

性能优化 网站优化 网站代码优化 网站性能优化

细心点的同学可能注意到两个问题:文件的大小和加载时间。刚才的截图还是在PC端截取的,手机和不同网络环境的表现会更加糟糕。

现在来看下目录

性能优化 网站优化 网站代码优化 网站性能优化

存在的问题:

  • 目录看起来算规范,但实际上是公共的和业务的混在一块。
  • 大部分文件合并在一个文件,合并策略不合理。
  • 由第二点引发的第三个问题,发布上线时,只要两人发布涉及到package文件,冲突必然发生。
  • 发布时需要down下上一次的文件,对照合并的新文件,以免发错。
  • 注意,第四点是人工。一不小心发错,或者把他人刚发布的文件覆盖了,这种事情发生10+次。
  • 只有一台测试机器,测试环境经常覆盖是常事。
  • 版本控制问题,不以SVN为版本,而是预发布机器上代码,管理混乱

不敢想象如果10+人的团队一起在这种模式下开发,会是怎样的场面。

 

22.0时代

由第一个版本引起的问题,着实让人很蛋疼,每次开发版本就是一次阵痛,尤其是测试、发布环节。所以就开始慢慢着手解决。随着业务扩展,人员增多,就诞生了下面这个图。

性能优化 网站优化 网站代码优化 网站性能优化

优化措施:

  • 调整模块,让共用的模块更加共用,业务模块跟随业务自身。
  • 更改模块合并策略,既然大了,我就分成小,一定程度缓解了冲突。
  • 替换原有的同步文件工具,包括测试与正式环境,接入ARS,提测发布流程顺畅多了。
  • ARS带有冲突检测功能,告别人工对照合并,覆盖不再容易发生。
  • 公共JS文件缓存在localstorage中,模拟manifest,带版本号控制。
  • 以SVN为板块控制工具,不再对照外网代码。

一些统计

localstorage本地缓存

性能优化 网站优化 网站代码优化 网站性能优化

localstorage缓存命中率

性能优化 网站优化 网站代码优化 网站性能优化

首屏时间

性能优化 网站优化 网站代码优化 网站性能优化

window.onload时间

性能优化 网站优化 网站代码优化 网站性能优化

一切看起来很美好,但是好景不长,因为新的问题又来了。

  1. 之前拆分package.js文件为多个文件,实际请求的时候则是合并了请求,包括JS文件和CSS文件。combo文件实际上会有延迟问题,在发布的时间节点上存在不同步的问题,直接导致页面挂了。
  2. 抛开combo文件不说,由于浏览器缓存的问题,每次更新版本的时候要手动加上一个时间戳,来规避缓存造成的错误。也是个很蛋疼的点。
  3. 随着业务增长,越来越多页面是放在APP里面访问。触屏页面已经不再是重点,如何更好的利用APP加速页面才是关注点。很多人想到了手Q的离线包,但听说实践起来也不是特别方便,我们就采用了客户端缓存hash文件的策略,告别304。所以这里又涉及到自动化。
  4. 雪碧图基本是手工;
  5. 代码混淆没有压缩;

CSS合并文件要手写地址,类似下面:

http://at.qq.com/min/f=cssv4/common/reset.css,cssv4/common/base.css,cssv4/module/btns.css,cssv4/module/tab.css,cssv4/module/app-list.css,cssv4/module/talk-bar.css,cssv4/module/popup.css,cssv4/page/game-detail.css,cssv4/page/talk.css,cssv4/module/comments-bar.css

 

33.0时代

为了解决上述问题,流程需要进一步优化,简单点就是让自动化程度更提高。

3.1 探索期

前期在方案选择上也做过一些讨论,自己完全从底层写时间上不允许。之前折腾过Grunt发现并不是那么好用,后来发现百度的前端解决方案FIS能够满足我们的需求。

  1. 生成以hash值(后缀)命名的文件,代码更改,生成新文件,且都会自动更新HTML中的引用(核心诉求),就像下图:
  2. 合并雪碧图
  3. 压缩混淆文件
  4. 文件合并(包括JS文件和CSS文件)

能 做到这几点基本就满足了我们的需求。前期的一切都是未知的,不太明白会遇到什么大问题。乍看起来非常好用,如果简单的页面,确实会很简单,只要简单几行配 置就可以搞定,但到现在FIS的配置文件200+行。一些特性很难满足,需要二次开发。上手简单,要深入难,必须要看源码改源码,写插件,这大概就是用 FIS的心得。

前期想了要怎样把开发——测试——预发布——发布这个流程依赖工具流畅的跑起来,大概构思如下:

性能优化 网站优化 网站代码优化 网站性能优化

注:

  1. 调试、发布代码与源代码分离
  2. 本地调试用代理如fiddler,或者上开发机
  3. deploy是构建工具同步文件的一个功能
  4. 保证源码的版本最新,发布代码走ARS。

工程化进展却不是想象中的顺利,实践中遇到了一些问题,也只能硬着头皮咬着牙去解决。

3.2 煎熬期

冲突问题

冲突问题一直存在,在2.0时代不那么明显罢了。原因是测试环境的JS已经被合并过一次。

时间问题

由于刚开始文件比较少,构建速度基本没啥问题。后来业务越来越多,参与的开发也越来约多。文件暴增到4000+,构建时间一步步增加。

开发调试耗时 3987ms

性能优化 网站优化 网站代码优化 网站性能优化

发布构建的时候因为要进行md5计算,文件压缩等,要181745ms!已经无法忍了。

ARS流程

用过ARS的同学肯定明白,流程还是比较蛋疼,要完成提交SVN,点击同步等等一系列操作,繁琐。

构建命令

命令比较长,参数多,难以记忆

产出文件多,发布麻烦

每改动一个字母,发布的时候就会生成一个新的文件,发布的时候真是在文件堆里找!!

性能优化 网站优化 网站代码优化 网站性能优化

这一系列的问题如山倒,组内的开发同学已经没法愉快的开发了。

 

3.3 深度优化

减少冲突问题

进一步解决的方案还是细分模块,测试环境不进行文件合并,这样冲突的概率几乎很小,因为公共库经过2.0的调整已经基本稳定。

缩短时间

构建时间这么长,这样发展下去是不行的。花了一些时间研究FIS源码,发现FIS监听的是整个项目文件,每一次构建都要扫描全部文件,这样时间必然会随着文件增加而变长。然后进行深度改造,变得不那么像FIS了。 进行一次又一次优化,改变构建策略。

依赖构建:当某个文件依赖另一个文件时,另一个文件才会被构建。假如a.html依赖了b.js ,在构建产出的文件就只有这两个文件,其他文件不会被构建,文件数也减少,时间大大缩短。

开发构建(单位ms )

性能优化 网站优化 网站代码优化 网站性能优化

发布构建(单位ms)

性能优化 网站优化 网站代码优化 网站性能优化

性能优化 网站优化 网站代码优化 网站性能优化

构建命令优化

输入命令麻烦,就用GUI界面,点点按钮就行。这里要感谢@koppthe@kolawang同学短时间内用node写的GUI。

性能优化 网站优化 网站代码优化 网站性能优化

产出文件多

依赖构建之后,只会产出相关文件,产出文件大大减少,发布难度减少很多。

ARS流程

修复bug的时候不用ARS同步,监听文件变化直接同步到测试环境。

性能优化 网站优化 网站代码优化 网站性能优化

只需要8ms!!!。 如果打开了同步按钮,修改的文件会立马上传到测试环境上,会不会有相互覆盖的问题。组内每个人负责的模块都不同,而且公共模块已经基本稳定,很难出现这样 的问题,在实践中很少发生这样的事情,相反小伙伴觉得简直获得解脱,相比找文件传文件这样繁琐的流程,这轻松了许多。

发布优化

构建工具会产出文件列表,点击就能打开文件夹,找到对应文件;列表对应SVN路径,直接贴到ARS就能提单。

雪碧图的优化

发布的时候所有引用的CSS文件会合并成一个,然后将引用的图标合并为雪碧图,有点粗暴。因为公共的CSS文件的图片单独合并为雪碧图会更加合理,公共的图片变动频率不会那么高。开发一插件,在CSS合并前雪碧图一次,合并后再雪碧图一次。

 

统计与优化

用户网络类型(粗略)

性能优化 网站优化 网站代码优化 网站性能优化

unknown是无法统计到的,理论上wifi还是占大部分。从其他四种类型看,wifi占据绝大部分,2g用户非常少。

PC VS Mobile

性能优化 网站优化 网站代码优化 网站性能优化

在JS下载和执行效率上,移动端明显要低于PC端。

JS优化

之前APP内部的JS文件都是通过seajs来下载文件,后来发觉何不直接干脆点直接写<script>下载就好了,优化后下载执行时间下降显著:

性能优化 网站优化 网站代码优化 网站性能优化

注:这里统计的时间,包括了下载JS和执行JS的时间。

JS内嵌与外联对比

在 考虑优化的时候,我们一种方案便是将外联的JS代码(仅业务代码)通过工具内嵌到页面。现在来对比下性能:

http://gqq.gtimg.com/static/mobile/js/v3/page/gift/list /inappand.a9a524eb.lc.js文件大小8.7kb,gzip压缩后3.3kb。

内联加载时间几乎为0.0015793,外联的下载时间:

性能优化 网站优化 网站代码优化 网站性能优化

性能优化 网站优化 网站代码优化 网站性能优化

下载时间不到200ms,但相对来说已经是很长了,才8.7kb。

我们知道,DOMContentLoaded事件的触发基本意味着页面已经渲染完成,JS已经执行(异步的除外),已经达到可交互的状态了。下面看下内联与外联对DOMContentLoaded的影响:

性能优化 网站优化 网站代码优化 网站性能优化

蓝 色线条是外联的JS,时间明显要比内联的高出一些,大概200ms。由此可见,将小量的JS文件内联到页面,能够提高速度。但大的JS文件适不适合内联, 目前还没有实验。这里需要在减少HTTP请求和利用缓存之间把握一个平衡,很多时候优化准则是并不是那么容易实施,因为可能自相矛盾,也可能和工程本身相 矛盾。优化不是按照准则照本宣科的做,需要灵活变通。

优化措施

按照雅虎优化的14条准则,把还没做到的都处理了。

  • 脚本域名切换,去cookie。
  • 文件合并
  • 利用浏览器缓存,无限增大缓存期max-age=15552000
  • 雪碧图
  • 减少HTTP请求,构建工具内嵌JS到HTML
  • 感觉速度还是不够快,再充分利用本地缓存和APP提供的缓存能力
  • 浏览器使用localstorage缓存脚本
  • APP缓存hash文件名脚本
  • 缓存HTML片段

调试、测试、体验流程

反向代理+白名单控制策略,域名对外访问是403,公司内网可访问。不用代理,手机直接连接wifi访问。环境分为开发——测试——预发布——正式(每个环境对应一个独立域名),任何角色(开发、测试、设计、产品)都可随时访问。

APP的debug包,可任意切换上面四种环境进行调试、测试、体验。

总结

这是过去一年工作的总结,一直都没静下来梳理。回过头想,自己是不是把这个流程变得更加复杂了。可能都有一个从简单到复杂再到简单的过程,坚持优化一直没有停下来,只要能够变得更好一点点,都会去尝试,所谓生命不息,折腾不止。


文章转载请保留网址:http://www.iswweb.com/news/industry/1525.html