移动Web应用的性能及其未来趋势-InfoQ



 写点什么

在一篇深入的实质性文章中，某 iOS 开发公司的老板 Drew Crawford 表示他认为目前移动 Web 应用运行迟缓，而且并不指望能在不久的将来看到重大改善，并列出了以上观点的全部原因。该文章是此前某篇博客文章的后续之作——在那篇文章中，他指出：与桌面系统中的表现相比，JavaScript 在移动设备上的性能有着量级上的差距。由于那篇文章遭到了严重的批评，因此 Drew 撰写了这篇更详细的文章以作为回应。对于糟糕的性能和缺乏改善由此归为以下三类：

处理器性能差异：移动设备 ARM 处理器 vs. 桌面 x86 处理器
JavaScript 引擎的性能趋势
垃圾回收方面的内存消耗

Drew 所列出的两个瓶颈在于 CPU 和内存。其中，CPU 密集型任务涉及两方面：CPU 的能力和执行效率。Drew 指出，现阶段 x86 处理器比 iPhone 和高端 Android 设备使用的 ARM 处理器快 _ 十倍 _。

虽然不是硬件工程师，但我曾经为一家主流半导体公司工作，那里的人们告诉我，现在性能主要依赖于工艺水平（例如，他们用“纳米”来衡量的那些东西）。iPhone5 能够具有令人瞩目的性能，很大程度是由于工艺水平从 45 纳米提升到 32 纳米——接近 1/3 的提升。不过要想再次获得这样的效果，苹果必须将其工艺水平进一步提升到 22 纳米。

由于大部分缩减晶体管尺寸方面的知识和投入都掌握在 Intel 手中，Drew 认为：在可以预见的未来，ARM 不大可能迎头赶上；实际上，更大的可能是 Intel 生产一款 x86 处理器，并杀入低能耗市场与 ARM 进行竞争，而不是 ARM 弥补性能差距。

有关性能的第二个方面是 _ 效率 _。CPU 周期的利用率如何，也即是，机器指令获得 JavaScript 代码生成指令的效率如何？

这也正是许多能干的软件工程师马失前蹄的地方。其思维过程类似于这样：JavaScript 已经变快了，而它将继续变快！

这句话的前半部分正确。JavaScript 的速度确实得到了显著提升。但是对后半句来说，我们已经身处 JavaScript 的顶峰，从今以后它的速度将不会再有大幅提升了。

下面是 Chrome v8 在我的 Mac 上（能够运行的最早版本，来自 2010 年 12 月），与现在的 v26 进行对比的结果。

看不出什么区别？这是因为本来就没有多少差别。对于 CPU 密集型 JavaScript 程序来说，近来没有任何重大进步。

而如果说有人觉得现在访问 Web 比 2010 年快多了，那很可能是因为电脑性能的进步，而与 Chrome 的改进无关。

在 Drew 看来，近期 JavaScript 的性能没有显著提升的原因非常明显：

问题在于，JavaScript 的 JIT 化是一个有着 60 年历史、并经历了长达 60 年研究的理念，期间人们使用各种可以想象的编程语言进行了成千上万次实现，以验证这是一个好的想法。但是现在我们已经完成了这一工作，并且榨干了它的价值。兄弟们，就是这样，演出结束了。或许我们可以开始寻找适用于下个 60 年的另一条妙计。

移动 Web 的第二条制约因素是 _ 内存 _。内存使用方面也有两大因素：可用的 _ 内存总量 _，与内存 _ 使用效率 _。

尽管现代移动设备拥有相当数量的内容（一般为 512MB 或 1GB），然而操作系统限制每个应用的使用量。操作系统自身消耗了许多内存，此外还有许多同时运行的应用（多任务）也在消耗内存：

[……] 基本上，当 iPhone4S 上的应用使用 40MB 内存时会出现警告，而消耗 213MB 内存时应用进程会被杀死。在 iPad 3 上，警告出现在应用消耗 400MB 内存时，而当消耗量达到 550MB 时系统将杀死应用进程。

Drew 提到，以 iPhone 4S 的分辨率，单张照片包含的位图数据将达到 30MB。这意味着最多在内存里存放 7 张照片，超过这一数量操，作系统就会因为应用耗尽了它所享有的内存而杀死它的进程。因此，如果某个应用用来处理图形或视频等多媒体文件，那么它必须非常谨慎地规划在内存中存放哪些内容，以及存放多长时间——因为内存是 _ 非常有限的 _。

内存方面的第二个因素在于效率。JavaScript 带有垃圾回收机制，因此开发者无需手动管理内存——这一特性正是为了减轻开发者的工作。然而，内存回收是有其代价的，而且这种代价在内存受限的环境下呈指数增长。

这张图意味着“如果我们拥有的内存是我们真正需要的 6 倍，那么一切安好。但如果少于需要的 4 倍那可就惨了。”

实际上，在内存受限环境中，垃圾回收机制的性能呈指数下降。如果我们编写 Python、Ruby 或 JS 应用并在桌面计算机中运行，那么很可能整个体验都处在图表右侧，而永远不会遇到缓慢的垃圾回收器。不过，让我们在图表左侧花些时间，看看我们需要面对的其他问题。

这一表现或许可以解释，为何苹果永远不会让 iOS 上的 Objective-C 带有垃圾回收器，而是用 ARC（同时在 iOS 和 MAC 中出现）来代替它。

虽然 Drew 在文章中列出了一些有趣的内容，但就像 Brendan Eich 在 Tweeter 中所说的一样，不是所有的应用都是 CPU/ 内存密集型的。只有一些特定类型的应用会遇到这些问题，例如游戏和多媒体应用。尽管如此，对任何有兴趣了解移动 Web 性能的人来说， Drew 的“万言书”依旧值得一读。

查看英文原文： The Current and Future Performance of the Mobile Web