写点什么

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

  • 2016-02-22
  • 本文字数:5319 字

    阅读完需:约 17 分钟

编者按: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 年,获奖颇丰。

2016-02-22 16:334970

评论

发布
暂无评论
发现更多内容

第三周产品经理训练营总结

产品经理训练营

区块链与安全随想

CECBC

区块链

产品经理课程-第三周

novaln🍉

第三周小结:产品思维和产品意识收尾+解决方案

小匚

学习 深度思考 个人成长 产品经理 产品经理训练营

Spring 事务、异步和循环依赖有什么关系?

程序员小航

Java spring 源码 事务 循环依赖

anyRTC2020年 年终总结

anyRTC开发者

音视频 WebRTC RTC sdk

Stakeholder requests (order by priority)

顾远山

需求 排序 分析 利益相关者

关于自己的一个梦(飞翔)

Yuchen

阿里云发布CDN产品最佳实践图 全面解析行业应用

阿里云Edge Plus

CDN 边缘节点

产品训练营-第三周-作业

邹小胖

产品经理训练营

SpringCloud 从入门到精通16---Sentinel流控

Felix

【mybatis】- MyBatis基础篇

双木之林

新思科技:以DevOps的速度打造安全的软件

InfoQ_434670063458

DevSecOps 新思科技

三高(高并发,高可用,高性能)解决方案

Geek_0o5u34

英特尔高管解读赢得2亿用户信赖的秘诀——永远领先两步

E科讯

【并发编程的艺术】Java内存模型总结

程序员架构进阶

架构 Java内存模型 七日更 28天写作 2月春节不断更

HTTPS是怎么保证数据安全传输的?

面试 HTTP

2021年云计算面临的5大网络安全威胁

云计算 云安全

产品0期 - 第三周作业

曾烧麦

产品训练营

是的,奈学教育一周年了!

奈学教育

奈学教育

解决方案的设计

让我思考一会儿

华为18A架构师共享:Netty+Redis+zookeeper+高并发技术栈

996小迁

redis zookeeper 架构 Netty 高并发

产品训练营作业三

胡小湖

区块链企业发展面临的挑战及建议

CECBC

区块链

作业-第三周

eva

Week3作业

Geek_6a8931

后疫情时代,企业如何实现数字化增长?

字节跳动 Kubernetes 容器 云原生

产品训练营第三周作业

朱航

你的网站上还在用图片验证码来刁难用户么?一招教你彻底去除图片验证码!

香芋味的猫丶

短信验证码 短信防轰炸 短信防火墙 图片验证码 风控防火墙

最高法规范区块链证据,司法链将走向全国统一

CECBC

区块链

构建高并发高可用的电商平台架构实践

Geek_0o5u34

专访英特尔(中国)开源技术中心:HTML5要如何达到原生性能_HTML5_姚梦龙_InfoQ精选文章