BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Zef Hemel 关注 0 他的粉丝 ,译者 李彬 关注 1 他的粉丝 发布于 2013年7月17日. 估计阅读时间: 6 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

在一篇深入的实质性文章中,某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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

第一次在这上面留言 by 晓 龙

这个论坛人似乎不多呀

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT