京东小程序接入 ARVR 的技术方案和性能调优 | 京东云技术团队
作者:京东零售 戴旭
京东小程序是一个开放技术平台,正在被越来越多的头部品牌选择,用于站内私域流量的营销和运营。诸如各种日化、奢侈品等品牌对 ARVR 有较多的诉求,希望京东小程序引擎提供一些底层能力,叠加品牌自主的个性化开发和定制,以支持更加丰富的场景和玩法,比如 AR 试妆、试戴等。
我们小程序引擎联合 ARVR 团队,在双方产研测的努力和协作下,完成了相关能力的设计和开发。整体功能于京东 APP11.6.6 版本发布上线,期待为更多的商家和品牌赋能。
体验路径和效果(负责相关模块的产品小姐姐友情录屏)
技术方案
这里以人脸识别为例,先介绍整体的技术方案。
概念介绍
技术关键词:相机、实时帧、AR 算法、同层渲染、WebGL。
这几个关键词里面,前三个比较好理解,人脸识别,会用相机采集人脸的实时帧数据,调用 AR 算法,获取计算结果,把数据传输给小程序前端。
后面两个关键词和小程序的场景有关系,WebGL 技术是小程序为了支持游戏、ARVR 等高性能渲染的需求,采用原生的 OpenGL 实现了一套 WebGL 的接口。小程序页面是 WebView 渲染,而我们既然提到了采用 OpenGL 原生渲染,就需要把原生组件,正确的插入到 Web 的视图层级,同层渲染就是将原生组件和 WebView DOM 元素放在一起进行混合渲染的技术,能够保证原生组件和 DOM 元素在渲染层级、滚动、触摸事件处理等方面保持一致。
总体流程
小程序引擎在底层原生支持了相机、实时帧、AR、WebGL 等能力,同时暴露了若干 js 的 api。小程序开发者通过相关 api 的调用,执行开启相机、获取实时帧数据,调用 AR 接口,获取计算结果数据,进行 WebGL 渲染等操作。简要的流程如下:
分层设计
从分层的角度看整个技术方案的设计,大致如下:
其中在 AR 引擎这一层,分为内置和外部 AR 引擎,也是由于小程序本身是开放的技术平台,我们采用了接口协议化的设计,支持第三方宿主采用自主的 AR 引擎,同时提供了相机、实时帧、WebGL 等原子化能力,小程序服务商可以构建专有的 AR 引擎为上层业务赋能。
技术挑战
WebGL 技术原理的篇幅过大,它也不仅仅是为了 ARVR 这个场景服务,所以包括 AR 算法之内,都不在本篇的详细介绍范围之内。
在这部分,我们专注于小程序和 ARVR 叠加的领域:内存和帧率的优化。
我们知道在欣赏电视和电影画面时,只要画面刷新率达到 24 帧/秒,就能满足人们的需求,也就是说我们至少要在中端甚至中低端的机器上达到 24 帧以上的帧率。
为了保证基本的画质,相机实时帧的分辨率设置为 1280*720,以 RBGA 格式存储,那么每一帧的数据是 1280*720*4=3686400Byte,约 3.5MB,每秒 24 帧以上的帧率,这个是不小的数据量。总的来说,在性能优化上,我们遇到的主要挑战如下:
**挑战 1,**数据从原生传输到 js,在从 js 传递到原生,如此大的数据量将会成为 js 和原生通信的瓶颈;
**挑战 2,**在 iOS 平台上,相机 output 只能指定 BGRA 格式,因为原始相机实时帧 CMSampleBufferRef 对象内包含 CVPixelBuffer 对象,CoreVideo 对象不支持 RGBA 格式,参考官方文档
https://developer.apple.com/library/archive/qa/qa1501/_index.html
而 WebGL 标准的接口不支持 BGRA 格式,参考文档:
https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/texImage2D,数据格式的转换会加重性能的负担;
**挑战 3,**即便以 24 帧为标准,每一帧的处理时间大约只有 41ms,需要经历原生相机生产、数据格式转换、数据双向传输、ar 算法、webgl 绘制等流程,每一环节都很重,我们需要考虑如何利用并发调度优势,并且保证实时帧的时序不会发生错乱,因为时序一旦乱了,影像虽然一直在输出,但是视觉感受是混乱的。
针对上述挑战,进行了一系列的优化,最终在中低端手机(iPhone8 Plus)上达到平均 26~27 帧的帧率,整体体验较为流畅,具体调优下面详细介绍。
性能调优
1、数据传输优化
原生和 js 之间传输大量的数据会成为性能的瓶颈,数据传输优化就是减少数据传输频次,最好是数据保留一份,只传递数据的标记。
我们设计了一个 NativeBuffer 缓存来优化这个问题。主要流程如下
但是在 js 环境中,最终还是要使用 js 对象,原生相机实时帧的数据需要被转换为 js 对象。那么如何做才能让数据只保留一份呢?
NO COPY
iOS 端选择运行小程序的 js 框架是 JavaScriptCore,JavaScriptCore 提供了一些 C 语言的接口方法,可以以 NO COPY 的方式,把一个 void 类型的二进制数据指针作为 backing store,创建相对应的 js 对象,一般类型是 ArrayBuffer 或者 TypeArray。也就是说原生和 js 对象背后的数据是同一份,共享这部分内存。
这样一来我们只需要保证缓存的原始相机实时帧的数据不释放,那么 js 对象引用的这部分数据就会一直有效。那这部分数据要在什么时候去清理呢?
销毁
在创建 js 对象的时候,可以指定一个 C 的函数指针作为入参。当 JavaScriptCore 检测到这个 js 对象销毁的时候,会自动触发该 C 函数的调用。我们需要按照指定的函数原型实现一个 C 的方法,在这个函数里去做缓存的清理,可以看一下这个函数的原型:
该函数有 2 个参数,第一个 bytes 是原始相机实时帧的二进制数据,第二个是上下文环境,这里我们传的是 NativeBuffer 管理类的实例,在这个函数的具体实现中,我们去匹配 NativeBuffer 管理的缓存地址,找到相关数据进行清理。
写入优化
前面我们说过,数据流转是双向的。原生把相机的数据传输到 js 侧,js 调用 ARVR 的人脸检测接口,还需要把这份数据在传输到原生。因为相机和人脸检测是相互独立的接口,js 拿到相机数据不一定非要调用人脸检测,调用人脸检测的数据也不一定非要来自于相机,还可以是一个本地的图片。
相对应的,我们在 NativeBuffer 的设计中,提供数据双向传递的接口,getNativeBuffer:id 和 setNativeBuffer:id。在原生传递到 js 的数据中,我们用了 NO Copy 的方式去做优化,那么在 js 传递到原生的数据,由于我们不知道数据来源,所以需要开辟一份新的内存空间,调用 memcpy 复制数据。但是实际上,我们在做数据复制之前,可以用 JavaScriptCore 提供的接口,从 js 的 ArrayBuffer 对象中提取到真实数据的内存地址,然后在 NativeBuffer 缓存池中查找,如果找到了则无需再做数据复制。这样保证了数据始终只有一份。
数据类型
在实践的过程中,js 端在选择二进制对象的数据类型的时候,可能会用 ArrayBuffer 或者 TypeArray。一旦 js 端进行了数据类型转换,比如 ArrayBuffer 转 TypeArray,引擎在调用 setNativeBuffer 的时候,传递的是转换后的数据类型,将会导致 setNativeBuffer 内部的写入优化失效,进而在低端机上带来明显的卡顿。在这里,我们统一使用一致的数据类型,不能随意的转换数据类型。
2、相机实时帧格式转换
在技术挑战中我们提到,iOS 平台上,相机 output 只能指定为 BGRA 格式,而 WebGL 标准的接口不支持该格式。如果不进行格式转换,会导致红蓝颜色颠倒,红色物体呈现蓝色,蓝色物体呈现红色。所以在数据缓存和传输之前,要做格式转换,我们需要找到一个快速低成本的方法。
要想做数据格式转换,需要了解一些基本的图像数据在内存中的布局情况,如下图所示。
这里我们选取的 BGRA 和 RGBA 格式都是 32 位,也就是每一个像素点是 4 个字节。
真实图像数据由于内存对齐的原因,大小并不一定是 width*height*4 个字节,CoreVideo 框架提供了获取相机数据宽高的方法,我们要计算出待处理的字节大小,每 4 个字节做一次循环,把第一位和第三位做一个调换,就能无需 malloc 内存,把 BGRA 转换为 RGBA 格式。
3、并发调度
在技术挑战中还提到,每一帧的处理时间大约只有 41ms,需要经历原生相机生产、数据格式转换、数据双向传输、ar 算法、webgl 绘制等这么多流程,如何利用并发优势,并且保证实时帧的时序不会发生错乱呢?
我们为了保证 UI 主线程的流畅,要尽可能把更多的环节放到子线程执行,这个时候哪怕写入缓存这样一个轻量的操作放到主线程都可能会带来画面的卡顿。
实时帧的处理、AR 算法分别放在不同的线程,为了保证实时帧时序,均采用串行队列。
采用了多线程之后,NativeBuffer 数据的存储和清理需要加上线程安全保护。
这样整体利用了多核的优势,并保证了调用时序。线程调度和处理流转如下图所示:
4、资源管理
理想情况下,原生相机产生一个实时帧数据,JS 消耗一个,在中高端机器上,性能能够满足需求,整体表现较为平稳,但是在低端机器中,线程抢占非常频繁,当主线程和子线程发生线程抢占的时候,会导致供需不匹配,一旦实时帧数据消耗不及时,内存会产生爆炸式的增长,所以需要限定缓存池的容量,这个一般可以根据实际调试的情况指定一个数值即可。
还有一旦出现内存警告或者当缓存满的时候,需要去清理缓存池,buffer 如果正在被使用,就不能去清理,否则可能会出现白屏的现象,我们给 buffer 加了一个是否被消费的标记,当一个 buffer 被消费后,它不能以常规的方式清理,需要等待 js 消费完成之后清理,这个在上面也有介绍。
在页面退出的时候,引擎需要监听相关的事情,确保实时帧的监听被停止,否则会出现多个 js 相机的监听事件并存,一个数据被多次消费而引发异常。
结语
京东小程序致力于打造卓越的技术开放平台,我们在提升性能、用户体验上不断努力,我们也在建设和完善小程序的各种能力,欢迎大家提供宝贵的建议。
版权声明: 本文为 InfoQ 作者【京东科技开发者】的原创文章。
原文链接:【http://xie.infoq.cn/article/459a1706f88b3b25947edceec】。文章转载请联系作者。
评论