作者：京东零售 戴旭

京东小程序是一个开放技术平台，正在被越来越多的头部品牌选择，用于站内私域流量的营销和运营。诸如各种日化、奢侈品等品牌对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框架是java scriptCore，java scriptCore提供了一些C语言的接口方法，可以以NO COPY的方式，把一个void类型的二进制数据指针作为backing store，创建相对应的js对象，一般类型是ArrayBuffer或者TypeArray。也就是说原生和js对象背后的数据是同一份，共享这部分内存。

这样一来我们只需要保证缓存的原始相机实时帧的数据不释放，那么js对象引用的这部分数据就会一直有效。那这部分数据要在什么时候去清理呢？

销毁

在创建js对象的时候，可以指定一个C的函数指针作为入参。当java scriptCore检测到这个js对象销毁的时候，会自动触发该C函数的调用。我们需要按照指定的函数原型实现一个C的方法，在这个函数里去做缓存的清理，可以看一下这个函数的原型：

typedef void (*JSTypedArrayBytesDeallocator)(void* bytes, void* deallocatorContext);

该函数有2个参数，第一个bytes是原始相机实时帧的二进制数据，第二个是上下文环境，这里我们传的是NativeBuffer管理类的实例，在这个函数的具体实现中，我们去匹配NativeBuffer管理的缓存地址，找到相关数据进行清理。

写入优化

前面我们说过，数据流转是双向的。原生把相机的数据传输到js侧，js调用ARVR的人脸检测接口，还需要把这份数据在传输到原生。因为相机和人脸检测是相互独立的接口，js拿到相机数据不一定非要调用人脸检测，调用人脸检测的数据也不一定非要来自于相机，还可以是一个本地的图片。

相对应的，我们在NativeBuffer的设计中，提供数据双向传递的接口，getNativeBuffer：id和setNativeBuffer：id。在原生传递到js的数据中，我们用了NO Copy的方式去做优化，那么在js传递到原生的数据，由于我们不知道数据来源，所以需要开辟一份新的内存空间，调用memcpy复制数据。但是实际上，我们在做数据复制之前，可以用java scriptCore提供的接口，从js的ArrayBuffer对象中提取到真实数据的内存地址，然后在NativeBuffer缓存池中查找，如果找到了则无需再做数据复制。这样保证了数据始终只有一份。

数据类型

在实践的过程中，js端在选择二进制对象的数据类型的时候，可能会用ArrayBuffer或者TypeArray。一旦js端进行了数据类型转换，比如ArrayBuffer转TypeArray，引擎在调用se