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

  • Zef Hemel
  • 李彬

2013 年 7 月 16 日

话题:JavaScript移动语言 & 开发架构

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

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

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

JavaScript移动语言 & 开发架构