BT

专访英特尔(中国)开源技术中心:HTML5要如何达到原生性能

作者 姚梦龙 发布于 2016年2月23日 |

编者按:HTML5应用被视为让本地软件云端化的利器,HTML5游戏也被视为一片新的蓝海,然而,HTML5远逊于原生的性能让众多开发者望而却步。本次InfoQ中文站便就此问题采访了英特尔(中国)开源技术中心负责crosswalk runtime和H5优化、硬件加速的两位工程师。

InfoQ:请先做个简单的自我介绍

余枝强:我是英特尔中国开源技术中心的软件技术经理余枝强,主要负责HTML5引擎 -Crosswalk在安卓平台的开发, 以及一些新兴Web技术的研发
顾扬:我是英特尔中国开源技术中心web研发经理顾扬,负责web图形相关功能(CSS, Canvas2D和WebGL等)的实现和优化

InfoQ:大家都很期待H5达到原生性能,那么从硬件层面和浏览器层面来说,H5能否达到原生性能呢?

余枝强:其实现在轻度、中度游戏/应用如果能够通过一些全栈式的优化(包括应用层,软件库,Web引擎层),某些场景下可能还需要一些Hybrid实现, 这样,HTML5应用接近或达到类似原生应用的性能应该问题不大。但重度、计算量大的应用(比如复杂的3D游戏,包括物理引擎等)目前确实还是有不少差距的。

我这里可以分享几个例子,它们都是一开始性能有较大的差距,但通过相应的优化性能达到了质的提升。
其中一个例子是和腾讯Alloy团队合作的,针对HTML5图像处理库的优化。原先这个图像处理库在移动端性能不理想,比如说对一副图像实现一个木雕效果需要十几秒甚至几十秒的时间(其中涉及到较为复杂的计算),后来我们在应用里引入并行 (WebCL, 它可以利用CPU 以及GPU中的多核的能力),通过对图像处理库相应的部分用WebCL重新实现,另外在Crosswalk引擎里加入WebCL的支持以及相应优化,最后这个图像处理时间在安卓平台上从几十秒降低到2秒以内。
另外一个例子是和触控科技合作了, 针对一个游戏-“进击的小怪物”的 HTML5版本做优化,其中涉及到比较酷炫的消除/爆炸效果,而这些效果在最新的Chrome里跑只有十几的fps 。通过引入Crosswalk 的游戏模式,把上层相对耗时的API通过原生的实现再桥接到HTML5引擎中,使得酷炫效果的性能比Chrome好5倍左右。

另外最近我们在调研一种典型的用户场景:大规模的图片的加载和滑动的性能问题, 以及和原生应用的性能区别。经过初步的调研,我们发现性能的差距有几个方面的原因:没有做更好的缓存,没有利用系统服务,不必要的事件处理,不必要数据转换,以及大量的数据缺少高效的数据传输机制,这中间有很多开销,会影响到用户体验。我们打算做一个参考实现来解决这种类型应用的性能问题。

总结来说, HTML5的性能问题,可能是多重原因组成,比如应用本身设计不合理,加了不必要的事件,没有用更好的缓存等等,另一方面引擎也可能有问题,比如数据传递,比如没有利用上更好的硬件特性。再加上Javascript语言的动态性,相对不容易写出优化的代码。这些问题,如果能够有全局的角度出发做相应优化,性能会有机会提升非常明显。
另外对应用开发者来说,尽量用一些成熟的框架,最好也要对对底层引擎有一定的了解从而避开javacript 里的坑。成熟的框架相对来说已做了一些Javascript层面的优化,再通过引擎本身针对应用的场景做相应优化,同时让Web引擎更好的利用到底层的硬件能力,这些层面做好了,就容易有好的体验。

顾扬:从我的理解来说,native应用直接跟硬件打交道,web应用则是通过web引擎跟硬件打交道,多了web引擎这个中间层。正因为这个中间层,带来了一些性能差异:
1, web引擎相对native发展来说还很年轻,对CPU,GPU这样的计算资源还不能充分应用。
2,web引擎是一种通用平台,日益增强的能力也带来了日益复杂的架构和更多的overhead。当然除却web引擎带来的性能损失,JS语言本身也有一些局限性,比如数据类型不明确,不支持多进程等。我们的优化主要针对web引擎的上述两个短板:
1, 充分发挥硬件,主要是CPU和GPU的能力。比如充分利用Intel CPU的特殊指令集,GPU的特殊extension。
2, 因为我们熟悉web引擎的各个阶段,通过对典型应用场景的性能评估,了解瓶颈所在,从而优化引擎逻辑。

InfoQ:顾扬可否再详细地介绍下你们所做的优化?

顾扬:目前的很多web引擎都是基于Chromium项目。我们的优化工作基本都是直接提交到Chromium,而且跟图形相关。具体涉及的软件仓库,主要是Skia和Chromium(Blink已经跟它融合)。

Skia方面优化 :
1,很多操作还是通过CPU进行的,Intel CPU有特殊指令集,用好这些指令集会有很多性能提升。
2,我们会做图形也是因为web的趋势是越来越多地用GPU而不是CPU来渲染。移动平台的GPU能力,近年来增长非常快,很多以前只有CPU能完成的任务,现在都能用GPU完成,而且性能更好。Skia代码中有些GPU的逻辑,要么有bug,要么还不够优化,我们消除了很多这样的正确性和性能问题,从而可以顺利的从CPU切换到GPU。
3,对路径渲染的一些优化。
4, CSS的很多优化,比如transform,box-shadow。

Chromium方面优化:
1,针对特殊场景的优化。比如Canvas2D被用在轻量级应用时,一些overhead可以忽略。但当用于一些heavy的游戏,比如一帧要画成百上千的东西时,引擎的一些overhead就突然成了瓶颈。
2,针对WebGL的各种优化,比如上传canvas/video到WebGL,GPU到GPU的纹理拷贝等。
3,一些场景下DOM操作的优化。
4,针对反锯齿效果性能的优化。

InfoQ:很多游戏厂商不使用现有的引擎,可能会选择自己写一个。对于这些开发者,有没有什么可以分享给他们的性能优化方法呢?

余枝强:的确有这个现象,有很多HTML5游戏引擎厂商都是自定义的一套 API,实现上其实是完全绕过了HTML5引擎,直接调到了底层的库。开发者就围绕这些API来开发,这在某些情况下的确有更好的性能,但也丧失了HTML5的一些优势,包括通用性,以及与HTML5 API的交互能力 (比如DOM)。不过这也是一种做法,但我觉得另一种可能更好的路是把HTML5 和 原生实现更高效的融合起来, 在把HTML5 本身的优势发挥出来,把标准的API以及丰富的HTML5 库利用起来,同时也能有和原生实现类似的性能。

InfoQ:对于浏览器而言,有无什么可从Web 引擎借鉴过来的优化理念?

余枝强:这个是有的。但首先我们要理解一下浏览器和独立的Web 引擎之间的区别。比如对于浏览器,你不知会访问哪个页面,所以为了防止潜在的恶意代码,在安全方面需要做很多检查,增加额外的开销,不同的页面也需要做相应的隔离。同时,浏览器需要更通用一点,来满足不同应用的需求,而通用也就意味着不容易做一些特定的优化。而作为一个独立应用,代码是可控的,场景是特定的,相对容易做一些针对性的优化。另外,在交互方面,比如浏览器里网页前进后退、手势,这些对于独立应用是不需要甚至有冲突的,这方面也是不小的区别。
但对于基础渲染,GPU加速等,浏览器和web引擎的基本是一致的. 还有,比如说把指令级的并行如SIMD带入到Web平台,这个也是通用的。SIMD.JS最先是在Crosswalk中有完整的实现,然后变成一个web标准,目前主流的浏览器厂商比如Google/Microsoft等都在加入相应支持。

InfoQ:因为IOS上无法使用第三方runtime,所以有开发者觉得使用runtime会减少很多用户。对于IOS这个问题,有没有什么解决办法?

余枝强:对于runtime会提供打包工具,可以将H5应用可选地打包成Android或IOS应用,所以不会减少用户。 只是在IOS上实际使用的是它自身的WKview引擎,而不是我们的加速引擎。但是考虑到IOS硬件不错,自带引擎加速也还可以,所以其实IOS上的H5性能问题没那么严重。

InfoQ:CSS和DOM操作算H5一个瓶颈吧?这方面的性能优化可否再具体讲讲?

顾扬:我们在这两块做的优化不算多,主要针对一些特殊场景。比如上面提到CSS有个效果是box-shadow,计算非常耗资源。我们通过cache机制,把中间相对通用的计算结果保存下来,这样很多后续运算就不需要从头来过,很好的提升了性能。当然,做好这样的优化,需要做大量实验,对数据的典型性有很好的把握,也要对Skia的cache机制有很好的了解,并做很多增强。DOM的一些优化也是针对某些场景。比如在packaged app里,可以节省一些cache获得很大的性能提升。

InfoQ:关于H5的优化和硬件加速,还有什么需要补充的吗?

顾扬:优化是很难做的,我们从12年开始做优化,碰到的最大问题不是怎么修复瓶颈,而是压根不知道哪是瓶颈。你想,H5有很多关于功能的标准,但却没有关于性能的。H5涉及的面很广,包括JS,CSS,Canvas2D,WebGL,Web Audio, Web Video等。这些领域在不同的硬件配置,比如CPU,GPU,内存,屏幕尺寸和分辨率上,表现都会有很大不同。怎么设计benchmark,既cover典型的应用场景,又能充分测出每个领域的瓶颈所在,是最难的事。我们从一开始就做好了长期作战的准备,比较系统的为优化做准备。我们收集,开发和评估各种benchmark,不断积累测试方法,自主开发一系列工具帮助我们自动化测试和明确问题。在这些benchmark帮我们明确了问题之后,就需要依赖我们对web引擎的了解,分析问题所在。有些问题是比较好解决的,比如有些局部代码写的不好,或者说有些regression,也就是说以前是好的,现在不好。另一些问题是比较系统性的,解决它们需要大量的改动,甚至改动底层架构。我们通常会积极跟upstream讨论,寻求最佳的解决方案。
这是我们整体做优化的一个思路,一个过程。优化不是一蹴而就的,需要长期的积累和很多很琐碎的工作。

InfoQ:再问一下,对于耗电,该如何优化?

顾扬:耗电和性能,很多时候是一对矛盾,需要很好的权衡。
有的时候很少的性能损失或者不损失,就能省很多电。比如通常的web应用,每帧的显示通常要经过CPU处理,然后交由GPU渲染。如果GPU是瓶颈,那么CPU再快也没有用。这个时候可以通过一些聪明的调度算法,减少CPU端的操作。再比如有些video的解码工作,交给GPU处理不仅快,还能大大节省整体耗电。
但决定并不是每次都这么容易。当省电的代价是比较大的性能损失时,就需要很好衡量了。有时可以在web引擎里面设置一些启发式规则,根据系统当时的情况,作出合适的选择。

InfoQ:对未来的展望?

顾扬:web发展很快,越来越多的人贡献idea和code。这些贡献主要在两方面,能力和性能。
能力方面,很多native的能力正在很快的加到web中,像蓝牙,NFC,AR,VR等。我们想要打通native和web的界线,native能做的,web都要做到。之前web是在追赶native的能力,今后要慢慢lead这些能力。世界不断发展,不断有新技术出现,这些新技术以后先在web还是先在native落地,则看谁基础更好,实现更经济了。哪边发展快,哪边就能引领行业发展。
第二类是性能。上面已经谈的比较多,主要是JS语言本身的性能,以及web引擎本身的性能。至于能不能达到native性能,坦白说很难,但可能有了足够好的性能之后,这个问题就不那么重要了。比如说web有个常用的指标FPS(一秒几帧),对人眼来说60FPS就已足够好,再高人也不易察觉了。所以如果web可以达到60帧一秒,native可以到80帧,虽然web还是不如native,但已经足够好。这个时候,web在其他方面的优势,比如统一的标准,高效的开发,方便的更新等,将秒杀这些很小的劣势。web就会变成一个很适宜开发的成熟平台。所以性能发展的目标,不一定是要达到native,而是足够好。

InfoQ:有言论说,随着从C/S到B/S的转变,未来我们只需要浏览器就足够了,客户端软件会被浏览器上的云端软件取代,你怎么看?

顾扬:我做web这么多年,非常热爱web,也对它很有信心。但是我认为世界上的统一是不可能的,也是不适合发展的。总有需要native存在的领域,比如有些对性能要求非常高的地方。做个类比,我们看一下计算机语言的发展历史,高级语言在慢慢侵蚀低级语言的地盘,从汇编到C/C++,Java,以及很多的脚本语言,但低级语言并没有消失。在很多底层库中,还用了大量的汇编,C/C++有更多的领域在使用,更不用说Java之类了。
web的使命,不是彻底取代native,而是补充了多样性,把应用这个蛋糕做大了。以前的人,哪有这么多应用可以用。可预测的是,在经历了高速发展期后,它跟native的在应用中的比例会趋于一个稳定的状态,native仍会有相当可观的比例。

被访者简介

余枝强,目前是英特尔开源技术中心的软件技术经理。 主要负责HTML5 引擎 – Crosswalk 在安卓平台的开发,以及一些其他和Web有关的新兴技术的研发工作(如HTML5 并行技术, HTML5 游戏优化,3D Camera等)。他坚信Web是未来, 也非常希望和大家一起努力,让这个未来能够更快更好的到来。

顾扬,英特尔中国开源技术中心web研发经理,负责web图形相关功能(CSS, Canvas2D和WebGL等)的实现和优化。2003年硕士毕业于浙江大学,后加入Intel从事编译器开发5年,转而主攻web。在web领域,带领团队完成Android Chrome 32位到64位的移植,负责英特尔移动平台web支持,更是贡献400多个patch到Chromium Upstream (包括Chromium, Blink, Skia等)和Khronos Github,实现和优化图形相关功能。业余爱好羽毛球,曾任上海英特尔羽毛球俱乐部主席7年,获奖颇丰。

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

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

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

已经优化很多了 谢谢 by 张 鑫

RT

允许的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 讨论
提供反馈
错误报告
商务合作
内容合作
Marketing
InfoQ.com及所有内容,版权所有 © 2006-2016 C4Media Inc. InfoQ.com 服务器由 Contegix提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司 京ICP备09022563号-7 隐私政策
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.