作者:addy(许斌),前端开发工程师,文艺青年一枚,写得了文章,编得了代码。
作为开发,不仅仅是前端,优化总是你绕不开的事,我们的目标就是要产品变得更快。优化的对象不仅仅指产品本身,还有我们日常的开发流程。从加入团队到现在,大概有一半左右的时间花在了优化上,期间遇到了很多问题,回过头看,优化这件事情并不是那么简单,也是些很琐碎的事情,要打造一个无痛的开发流程,并且能够相对轻松的对产品持续优化真的不轻松。没有银弹,任何项目都要花很多时间和精力。但任何值得改善的地方能够有所提升都让我们觉得努力没白费。有时候只想懒一点,从枯燥的重复中解放出来。
刚进来时,加上我团队中一共3个人专职前端开发。项目比较简单,前人已经做好了模块化,只是觉得还不够彻底。后来项目慢慢变得庞大,加上重构同学,人员最多的时候达到了13人。这个过程中遇到了很多问题,前端框架演变了三次,都是因为遇到了一些棘手的问题,而不得已做出调整,没有绝对的好坏,只有合不合适。
1
1.0时代
前期模块化已经做的不错了,至少不必花大量时间去重构代码。模块划分如下图,逻辑层次上还是比较清晰。
前端模块化依赖的主流库也就数国内的Seajs和国外的requirejs,这里就不陈述。采用了Seajs作为模块管理器,zepto作为基础库文件,lib主要包含了项目中用到的主流第三方库文件。
我们知道模块化带来的最大弊端便是HTTP请求数增加,所以上线的时候必须合并文件。下图中的package模块是文件大集合,打包了很多个JS模块,除去上图中的基础库文件和业务模块层,在上线的时候大部分文件都被打包在package.js里。
大部分页面的JS请求是这样的:
细心点的同学可能注意到两个问题:文件的大小和加载时间。刚才的截图还是在PC端截取的,手机和不同网络环境的表现会更加糟糕。
现在来看下目录
不敢想象如果10+人的团队一起在这种模式下开发,会是怎样的场面。
2
2.0时代
由第一个版本引起的问题,着实让人很蛋疼,每次开发版本就是一次阵痛,尤其是测试、发布环节。所以就开始慢慢着手解决。随着业务扩展,人员增多,就诞生了下面这个图。
一切看起来很美好,但是好景不长,因为新的问题又来了。
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
3
3.0时代
为了解决上述问题,流程需要进一步优化,简单点就是让自动化程度更提高。
前期在方案选择上也做过一些讨论,自己完全从底层写时间上不允许。之前折腾过Grunt发现并不是那么好用,后来发现百度的前端解决方案FIS能够满足我们的需求。
能做到这几点基本就满足了我们的需求。前期的一切都是未知的,不太明白会遇到什么大问题。乍看起来非常好用,如果简单的页面,确实会很简单,只要简单几行配置就可以搞定,但到现在FIS的配置文件200+行。一些特性很难满足,需要二次开发。上手简单,要深入难,必须要看源码改源码,写插件,这大概就是用FIS的心得。
前期想了要怎样把开发——测试——预发布——发布这个流程依赖工具流畅的跑起来,大概构思如下:
注:
工程化进展却不是想象中的顺利,实践中遇到了一些问题,也只能硬着头皮咬着牙去解决。
这一系列的问题如山倒,组内的开发同学已经没法愉快的开发了。
开发构建 (单位ms )
发布构建 (单位ms)
用户网络类型(粗略)
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 0.0015793,外联的下载时间:
下载时间不到200ms,但相对来说已经是很长了,才8.7kb。
我们知道,DOMContentLoaded事件的触发基本意味着页面已经渲染完成,JS已经执行(异步的除外),已经达到可交互的状态了,具体可参考这篇文章。下面看下内联与外联对DOMContentLoaded的影响:
蓝色线条是外联的JS,时间明显要比内联的高出一些,大概200ms。由此可见,将小量的JS文件内联到页面,能够提高速度。但大的JS文件适不适合内联,目前还没有实验。这里需要在减少HTTP请求和利用缓存之间把握一个平衡,很多时候优化准则是并不是那么容易实施,因为可能自相矛盾,也可能和工程本身相矛盾。优化不是按照准则照本宣科的做,需要灵活变通。
优化措施 按照雅虎优化的14条准则,把还没做到的都处理了。
max-age=15552000
感觉速度还是不够快,再充分利用本地缓存和APP提供的缓存能力
调试、测试、体验流程
反向代理+白名单控制策略,域名对外访问是403,公司内网可访问。不用代理,手机直接连接wifi访问。环境分为开发——测试——预发布——正式(每个环境对应一个独立域名),任何角色(开发、测试、设计、产品)都可随时访问。
APP的debug包,可任意切换上面四种环境进行调试、测试、体验。
这是过去一年工作的总结,一直都没静下来梳理。回过头想,自己是不是把这个流程变得更加复杂了。可能都有一个从简单到复杂再到简单的过程,坚持优化一直没有停下来,只要能够变得更好一点点,都会去尝试,所谓生命不息,折腾不止。