我们知道，如果要对JS代码进行保护，最普遍的做法是进行混淆加密。

很多人会有担忧：混淆加密后，会不会造成性能影响？JS混淆会带来多少性能损失？

理论而言，混淆加密会使JS 代码量增加，那么执行时理应有性能影响。

重点是：会带来多少性能损失，是否会严重影响执行效率？

为了验证这一问题，本文通过实测的方式寻求真相，揭示JS混淆加密究竟会带来多少性能影响。

准备

1、JS代码混淆加密，使用JShaman代码保护平台，这是国内知名的商业JS代码混淆服务平台。

实验使用JShaman的通用版保护。

2、验证性能影响，我们使用console.time()和console.endtime()方法，在node环境下执行，通过打印出代码执行时间，比较混淆前后的执行时间差，得出具体的影响结果。

为了分别验证不同代码量下的影响情况，实验将分三次进行，分别使用少量代码、中等代码量、大量代码。

实验一、小量代码测试

准备一小段代码，并运行，如下：

把上述代码，提交到JShaman平台进行混淆。

注：使用默认的混淆选项，后面的测试也都使用此相同配置：

混淆后，代码量增加了不少：

再次运行，如下：

混淆后代码执行时间慢了约0.2毫秒。带来的性能影响基本可忽略。

实验二、中量代码测试

写一个功能代码，用于获取CPU使用率：

用同样的方式，经JShaman对代码进行混淆，再次运行测试：

惊人的一幕发生了：混淆后的代码执行效率竟然更高？！真是令人难以置信，所以不敢相信的连续运行了三次，然而三次运行结果都比混淆前更快。

注：如上图，混淆前，代码执行时长：1045.935毫秒。混淆后，三次运行时长都小此此值。

为什么会发生这种情况？混淆后代码量增大了，执行效率反而提升了？

粗略的猜想：是由于混淆的过程，对数据进行了优化，将数据统一命名，又对执行顺序（AST树）进行了优化？

带着疑惑，继续进行测试。

实验三、大量代码测试

由于是测试，虽说要大量代码，但不会真太多，是相对上面两组代码而言。

这里使用base64算法进行测试，代码量160多行。

还是用相同的方式，通过JShaman对其混淆：

混淆后运行：

可以看到，运行时长在16.8毫秒到21.1毫秒之间。比之前的13.7毫秒慢了2.9到8.4毫秒之间。

感觉慢一些才是合理的，不惊慌、也不奇怪。这组的性能损失完全能接受。

到此，感觉测试结果跟想像的很不同，本以为混淆会带来很大的性能影响才对。疑惑感更重了，为此，再加一组测试，将JShaman的混淆强度提高：

这个混淆强度已很高，已经达到了商用级，可以满足绝大多数的保护要求。

再次混淆，可以看到这个强度的混淆后，文件已经由6K增大到了24K，体积的增加，说明代码量增大了，代码量增大后，运行速度应该会很受影响吧？

运行，看结果：

代码执行时长仅在约18毫秒到23秒之间。又一次令人意外！这个效能是完全可以接受的。

总结：

说实话，这个测试结果着实令人意外。本以为混淆会严重影响执行性能。而实验结果证明：少量的代码混淆，几乎是不会带来执行性能损失。大量的代码混淆，确实带来一定的性能影响，但其影响很小，是完全可以接受的。

那么，当我们有比较重要的JS代码在公开发布、或提供给他人时，使用混淆加密是种很好的代码保护方案，可以有效的防止分析、复制、盗用等，而且不必太担心性能影响问题。

前端JS、app、h5、后端nodejs代码，都是可以用的噢。

混淆的效果如何？能起到保护效果吗？可参见另一篇文章：JS混淆是不是纸老虎？