移动Web应用性能的5个秘籍

　　秘籍 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进行开发。