英文原文：5 Myths About Mobile Web Performance 最近我们听到一些关于移动HTML性能的一些秘籍，实际上它们并不是很准确。和好的“城市秘籍”一样，它们听起来令人信服的和可信。但是这些秘籍是基于，不正确的前提和对本地和网络软件栈之间关系的误解，以及曲解数据的散点。 我们认为重要的是，要对这些秘籍进行验证，使用用我们已经收集了多年来关于性能的数据和我们自己的做的移动 Web 应用程序性能的经验。

秘籍1：移动网络性能主要是由运行在CPU上的JavaScript性能决定
现实：大多数网络性能是由渲染管线的优化程度，GPU加速程度，DOM交互速度三者制约。更快的JavaScript总是有用的，但它很少是决定因素。

秘籍2：因为硬件不停的升级，CPU越快，JavaScirpt执行的也会越快(又称摩尔定律)

事实上：在过去四年间，移动设备上的JavaScript的渲染提速都是通过软件的优化来实现的，而不是通过硬体的加速。尽管单线程渲染JavaScript的速度有所提升，但是大多数网络程序还是尽可能采用多线程来提升JavaScript整体性能。

秘籍3：移动设备浏览器已经优化的相当好了，没有多少提升的空间了

事实上：每一个移动设备浏览器都有自己的优势，有时甚至会超过对手10-40倍。Surface在SVG方面比iPhone好30倍。iPhone在DOM交互方面胜过Surface10倍。看来，和对手优点比较后还是有明显提升空间的。

秘籍4: 未来的硬件提升不太可能转变为web app的性能增益

现实：过去三年中每一代硬件都带来了显著的JavaScript性能提升。手机上的单线程性能将会持续改进，浏览器开发人员也将会提升软件平台，通过减轻负载与多线程，充分利用增强的GPU速度，更快的内存总线 与多核。许多浏览器已经能利用并行的优势，以减轻主UI线程的负载，例如：Firefox 分离合成工作; Chrome 分离一些 HTML 解析; 以及 IE 分离 JavaScript JIT编译。

秘籍 5: JavaScript 垃圾搜集对移动app是一个性能杀手

现实:这是真实的但有点过时。在2011年，Chrome已经自Chrome 17开始具有一个增量的垃圾搜集器。Firefox是去年开始具有的 。这缩减了GC停顿约200ms到10ms —— 或者说从一个掉帧 到一个明显的停顿。避免垃圾回收事件能对性能有显著的改进，但如果你主要使用的是桌面web开发模式或者用的是老的浏览器，它通常会成为一个杀手。在Fastbook（传享网），我们的移动HTML5版的Facebook克隆网站中，一个核心的技术就是循环利用一批DOM节点，以避免创建新节点的开支（以及对老节点GC回收的相关开支）。非常有可能写出一个糟糕的垃圾搜集器（参看老的Internet Explorers），但是并没有本质上限制垃圾搜集的语言，像JavaScript (或 Java)。

总结一下：

首先，让咱看看一些基本常识。总而言之，浏览器是个运行在OS上有着非常复杂抽象层的程序。是用HTML，JavaScript和CSS创造抽象层的混合体。不同的抽象层会有不同的效果。有些抽象层运行的很快是因为它潜在调用OS调用或是用接近系统库的库(在MacOS上又称Canvas2D)。有些抽象层很慢因为他们很少用OS调用，而且他们本身太复杂(DOM树，或是原型链)。

有关Sencha，我们知道，优秀的程序员创造的程序会很快，甚至出乎我们意料之外，因为他们都用一些移动网络技术和一些流行的框架如Sencha Touch。

很少有移动设备作为计算中心，就像没人会在iPhone上计算DNA序列。大多数移动应用程序都会合理响应用户操作。当用户有所操作时，移动应用程序会以每秒30帧或者更快的速度来予以响应，大概用数百毫秒来完成。只要程序达到用户的目标，不是说用更多的硅片就能达到的。这就像是我们突然转移话题说我们烹饪和饮食。

有关Sencha，我们知道，优秀的程序员创造的程序会很快，甚至出乎我们意料之外，因为他们都用一些移动网络技术和一些流行的框架如Sencha Touch。在过去的3年间我们以此而受到鼓舞。我们喜欢在此分享这些数据。

我们的意思不是说移动网络应用程序 总比本地程序快，或是总和桌面网络应用程序做比较。这是不切实际的，移动设备的硬件要比桌面硬件设备慢5-10倍：CPU更弱，缓存等级更低，网络链接延迟更大。而且任何层次的程序(如浏览器)都有很大的消耗。这不是程序员的问题(我喜欢这一句，译者注)。iOS开发程序员会给你说iOS CoreGrapics在Retina iPad跑会很慢，因为他们都得直接用OpenGL进行开发。

深入探讨秘籍

在多年为Sencha Touch的数据驱动的应用程序的性能优化工作中，我们可以满怀信心地说，我们很少有人被JavaScript性能优化所困扰。唯一的重大案件迄今为止是Sencha触摸布局系统,我们在发现界面切换到Flexbox后，JavaScript在Android 2. X运行过于缓慢。更多的时候，我们碰到的问题是与DOM交互，浏览器渲染引擎和垃圾事件有关。所有这些问题都是每个浏览器的架构师和开发人员创建的，与 Javascript或Javascript引擎的固有特性无关。作为一个例子，当我们与浏览器厂商在性能优化方面合作时，我们已经看到了在一个40倍的改善在浏览器一个操作（颜色属性变化操作），这个操作是我们的滚动列表实现的速度瓶颈，这只是其中的一例。

JavaScript 在IOS和android上的性能

尽管我们说JavaScript在移动设备上的性能不是那么的重要，但是我们要反驳这段始终没有得到改善的神话。以下是通过IOS的模型和版本展示出了历史四年来SunSpider在IOS的数据得分（分数越低越好）。（幸运的是，SunSpider是一个用的非常广泛的测试工具，它记录了所有的IOS版本的网络数据）。在2009年， 最初运行IOS3的IPhone 3GS有得到一个已经超过了15000的分值——是如此低的性能，与2009年的桌面浏览器有20倍的差距。

然而，如果你把Iphone 3GS升级到了IOS4,5或者6，你将会在相同的硬件设备上提升4倍的JavaScript性能。（性能提高最大的是使用Nitro引擎的IOS4 和IOS5之间）SunSpider继续在性能不断提升的SunSpider上测试，但我们任低于那些NDA。与当今的桌面浏览器相比，边缘的移动浏览器的约慢5倍——与2009年相比却有30倍的提升

想了解更多ISO软硬件方面的改进，参见去年十月AnandTech的评论。

Android平台也有类似层次的改进。在我们的实验室里，我们组建了一个过去的三年里Android平台的集合，我们认为它们代表了典型的高端配置。我们测试了四部手机：

• Samsung Captivate Android 2.2 (2010年7月发布)
• Droid Bionic Android 2.3.4 (2011年9月发布)
• Samsung Galaxy Note 2 Android 4.1.2 (2012年9月发布)
• Samsung Galaxy S4 Android 4.2.2 (2013年4月发布)

正如你在下面看到的，这是一张过去的四年里SunSpider得分曲线，一个戏剧性的改善。从Android 2.x到Android 4.x性能有3倍的改善。

在这两种情况下，改进都比我们依据摩尔定律预测的好得多。在过去的3年里，我们期待一个4倍的提升（2倍每18个月），所以软件肯定是导致性能的改善的要因。

其它翻译版本 (1) 加载中 本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务