HTML5游戏会比Native App更快吗

Posted 2023-02-24

如果C++引擎和javascript做同样的任务，C++很有可能领先于JavaScript。但这里仍提出了一个很有趣的课题：使用“快”的语言（比如C++）并不能保证比“慢”的语言（JavaScript）有更好的性能。

 

这周，我对电脑进行了系统升级，采用Windows 8操作系统，全新的nVidia GetForce GTX 660显卡。一切就绪后，我进行了性能测试，浏览器是Chrome Canary 25，结果表明 Construct2的WebGL渲染器明显快于Native的C++ DirectX 9——基于Construct Classic引擎开发。

 

WebGL的测试结果是141911个sprite，而Construct Classic为109280。显然，WebGL比Native快了将近30%。

系统环境配置：Windows 8 RTM（64位）系统、Intel Core i5-2500 @ 3.3GHz (quad core)、8GB RAM、nVidia GeForce GTX 660 (driver v306.97)。然而，此结果并不能在Windows 7上复制，使用AMD Radeon芯片驱动（没有在Windows 8上试过）。WebGL在Firefox 19上却比Native慢很多，而IE根本就不支持WebGL。

这里也有些测试结果表明，WebGL是没有这个能力的，所以，它总是呈现Canvas 2D渲染。这次在Chrome Canary 25上的得分是3821，而之前的结果竟比它快37倍。

为什么会出现如此好的结果？据理解，它可能把WebGL的安全检查交由硬件处理，WebGL的操作规范要求浏览器必须在使用时正确检查所有的缓冲区，而不是在访问前或后。使用长缓冲区来渲染大量的sprites，为了保证安全使用，CPU采用排水作业的方式检查缓冲区。然而，一些GPU厂商可能会在GPU的硬件上检查缓冲区。或许，这仅仅适用于一些特定的OS，在驱动和硬件设备支持的情况下，否则，CPU仍然会做这些检查。这或许就是快的原因吧！

这儿还有另外一个重要原因：WebGL渲染器的设计比Construct Classic系列的C++ DirectX 9更加高效。当使用C++编写时，它的速度很容易降下来，虽然C++速度很快，但这并不表明编写任何C++代码都可以运行很快。当把引擎移到JavaScript上时，在大多数的基准测试中，它要比C++的慢好几倍。这驱使我们更加密切地关注性能并且采取更加明智的整体策略。当对每个精灵进行渲染时，经典的Native引擎会计算顶点位置（对象角落）。在使用collisions engine中已经把所识别的位置信息进行了计算和储藏。这就阻止了Construct 2重新计算——它们只需复制collisions engine中的计算。所以JavaScript只需做很少的事情。这可能会稍微缩小彼此间的差距。

这就解释了为什么只有在特定的环境下，JavaScript引擎才能领先于不那么高效地C++引擎。如果C++引擎和JavaScript做同样的事情，C++很有可能领先于JavaScript。但这里却提出了一个很有趣的课题：使用“快”的语言（比如C++）并不能保证比“慢”的语言（JavaScript）有更好的性能。这也表明会有一些更加灵巧的JavaScript/WebGL渲染引擎会打败Native引擎。这就预示着未来移动端的html5游戏也能像Native引擎一样，达到同样的基准测试结果（或者更多！）。

希望这个结论不是什么技术错误或者故障。另一方面，如果该结果是真实的，那么它会让人欣喜若狂的。大多数时候，人们会抱怨把本地游戏移植到HTML5上是多么的慢，那么它很快就会结束！

参考技术A 如果程序需要经常性更新、HTML5 就占上风。