谈谈JavaScript代码优化

概述:

  • 案例:Cesium打包流程,相关技术点和大概流程
  • 原理:代码优化的意义:压缩 优化 混淆
  • 优化:如何完善Cesium打包流程

关键字:Cesium gulp uglifyjs

字数:2330 | 阅读时间:7min+

1 Cesium打包流程

如果没有记错,Cesium从2016年初对代码构建工具做了一次调整,从grunt改为gulp。作为一名业余选手,就不揣测两者的差别了。个人而言,gulp和Ant的思路很相似,通过管道连接,都是基于流的构建风格,而且gulp更像是JS的编码风格,自带一种亲切感。

gulp.task('task1',['task0'], function() { return fun_task1(); });

Task语句是gulp中最常见的,懂了这句话,就等于你看懂脚本了。这句话的意思是,要执行task1,需要先执行task0,而task1的具体工作都在fun_task1方法中。这就是之前说的基于流的构建风格。有了这句话,在命令行中键入:gulp task1,回车执行该指令即可。

先安装Node,环境变量等,并安装npm包后,即可使用gulp打包工具,这里推荐cnpm。环境搭建好后,命令行中键入gulp minify开始打包。完整的过程是build->generateStubs->minify

Cesium打包流程

build:准备工作,创建Build文件夹;将glsl文件转为js形式;最主要的是createCesiumJs方法,遍历Source中所有js脚本,将所有Object记录到Source/Cesium.js;其他的是范例,单元测试相关模块。

generateStubs:用于单元测试,略。

minify; 首先combineJavaScript主要做了两件事情,打包Cesium和Workers脚本,这是打包的最终结果。Gulp根据指令的不同,比如minify下采用uglify2优化,而combine对应的参数为none,生成路径为CesiumUnminified。

另外,细心的人会发现,combineCesium的实现中有这样一句话path.relative('Source',require.resolve('almond')),这是一个小优化,almond是requirejs的精简包,因此,最终的Cesium.js中包含'almond脚本,内置了requirejs的主要方法。

如上是Cesium打包的主要流程,简单说主要有3+1类个指令:

  • Clean
    • 清空文件
  • minify
    • 打包&压缩
  • combine
    • 只打包,不压缩
  • JScoverage
    • 单元测试覆盖率,不了解

2 代码优化

对流程有了一个大概了解,下面,我们详细了解一下uglify2过程都做了哪些代码优化,一言以蔽之,压缩,优化,混淆。

uglify2主要有三个参数:-o,-c,-m,-o参数必选,指定输出文件,-c压缩,-m混淆变量名。如下分别为combine、(uglifyjs -o)、(uglifyjs –c -m -o)的文件对比,单位是k:

uglify2的压缩对比

都在一个屋檐下,差距怎么就这么大呢?我们简单说一下从1~2,2~3之间青取之于蓝而胜于蓝的过程。

1~2的过程其实很简单,就是干了三件事,去掉注释, 去掉多余的空格(换行符),去掉不必要的分号(;)。就这三件事情,文件一下子小了一半多,换句话就是平时你写的代码有一大半都是废话,此时你旁边的AI程序员可能会喃喃道来“你们人类好愚蠢~”。

2~3则是很多小细节的综合应用:

  • 去掉一些实际没有调用的函数(Dead code);
  • 将零散的变量声明合并,比如 var a; var b;变为var a,b;
  • 逻辑函数的精简,比如if(a) b(); else c()变为a ? b() : c();
  • 变量名的简化,比如var strObject;变为var s;
  • ……

这些小技巧有很多,具体要看不同的压缩工具的考虑优劣,但有些压缩高效的工具并不稳定,可能会破坏语法规范或语意,所以没必要为了几个kb承担过多的风险,目前比较成熟的工具主要有三个uglify2,google closure以及yuicompressor,具体优劣得自己来体会了,我是按照自己的理解给出的先后顺序。最终的效果如下:

Cesium脚本效果

这样的代码只能用单位“坨”来形容了,人类是无法直接读懂的,那浏览器能读懂吗?这是一个好问题!如下是V8引擎对JS语法解析的大概流程:

V8引擎解析JS脚本

下面是在我本机Chrome解析Cesium.js脚本花费时间(脚本从下载完到浏览器解析完的时间差),单位毫秒,因为只测试了一次,可能会有误差,但基本吻合期望值:

JS脚本解析时间对比

首先因为是本机测试,脚本无论是最大的8M还是最小的2.4M,下载速度都很快,因此我们不讨论(但实际应用中要考虑)脚本下载所需时间。

其次,如上图,多了一个source,这是源码情况下,这个时间水分比较大,因为是零散的文件,可以做到按需下载,但因为文件比较琐碎,性能也不高。

结论是,这种JS脚本优化策略对浏览器的影响不大,浏览器看到优化后的代码,可能会愣一会神,但很快就克服了。

3实战

知道了代码优化的大概原理,回顾一下代码优化的目的(压缩,优化,混淆),匹配一下结果是否符合期望值。嗯,其一,脚本小了,其二,效率优化了,其三,别人看不懂了。似乎该做的都已经做了,这个脚本已经很完美了。

Format后的效果

毛爷爷说,与人斗其乐无穷。确实,前两点的目的达到了,但第三点,还差很多。如上,和刚才的脚本是同一个文件,我只是用Chrome的调试工具format而已。这就是理想和现实之间的差距。

可见,Cesium默认打包工具在压缩和优化上都没有问题,但在混淆上并不充分,当然Cesium本身是开源的,也没必要搞这些。客观说,JS脚本是明码的,所以反编译只是时间和能力的问题,所以不妨换个态度来看待这个问题,增加反编译的成本,当该成本大于购买成本即可。

抱歉,下面的内容因为一些顾虑,不方便开放,如果感兴趣可以留言单聊,当然如果你认可超图的技术,欢迎加入超图研发WebGL团队。

Beneath this mask, there is more than flesh. Beneath this mask, there is an idea. And ideas are bulletproof.

原文发布于微信公众号 - LET(LET0-0)

原文发表时间:2017-02-18

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏VMCloud

【解析向】腾讯云的Windows Server日志配置收集工具是个什么鬼?(2)

继上一篇,上一篇重点介绍了腾讯云Windows Server日志收集工具的“场景”功能,那么场景功能究竟是以什么标准来分级的呢?

4257
来自专栏技术换美食换不换

picu后端架构总结

首先我们项目的定位是一个图片,音频为主体的分享应用,于是服务器对于大资源的存储有了常规数据库,nginx静态资源存储和对象存储服务的选型问题.常规数据库(如my...

1282
来自专栏携程技术中心

干货 | Android工程模块化平台的设计

1763
来自专栏后端技术探索

另一篇mysql防止库存超卖

今天王总又给我们上了一课,其实MySQL处理高并发,防止库存超卖的问题,在去年的时候,王总已经提过;但是很可惜,即使当时大家都听懂了,但是在现实开发中,还是没这...

1551
来自专栏腾讯Bugly的专栏

《手Q Android线程死锁监控与自动化分析实践》

手Q每个版本上线以后研发同学都会收到各种问题反馈。在跟进手Q内部用户反馈的问题时,发现多例问题,其表象和原因如下:

9938
来自专栏Java后端技术栈

面试必备:如何将一个长URL转换为一个短URL?

前几天整理面试题的时候,有一道试题是《如何将一个很长的URL转换为一个短的URL,并实现他们之间的相互转换?》,现在想起来这是一个绝对不简单的问题,需要考虑很多...

4282
来自专栏SDNLAB

SDN实战团分享(三十一):Nutanix超融合之架构设计

超融合平台 针对于超融合的概念有着不同的理解,因为组件不同(虚拟化、网络等)而理解不同。然而,核心的概念如下:天然地将两个或多个组件组合到一个独立的单元 中。在...

3967
来自专栏FreeBuf

子域名枚举的艺术

写在前面的话 当我们在查找某个域名的有效子域名时,我们通常需要使用子域名枚举这项技术。但是,除非DNS服务器暴露了完整的DNS空间(涉及到AXFR协议),否则我...

4359
来自专栏tiane12

通过抓包获取ActiveX控件通信数据时的一点心得

1392
来自专栏求索之路

从零开始仿写一个抖音App——日志和埋点以及后端初步架构本项目的 github 地址:MyTikTok

拿 Java 来说:比如我们有两个服务 A、B 在两个服务器上,此时我们要在 A 上调用 B 的服务获取其上的数据 Foo。那么在 A 中可以写成 Foo f ...

5055

扫码关注云+社区

领取腾讯云代金券