作者：京东零售 戴旭
京东小程序是一个开放技术平台，正在被越来越多的头部品牌选择，用于站内私域流量的营销和运营。诸如各种日化、奢侈品等品牌对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帧的帧率，整体体验较为流畅，具体调优下面详细介绍。
原生和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的方法，在这个函数里去做缓存的清理，可以看一下这个函数的原型：
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复制数据。但是实际上，我们在做数据复制之前，可以用JavaScriptCore提供的接口，从js的ArrayBuffer对象中提取到真实数据的内存地址，然后在NativeBuffer缓存池中查找，如果找到了则无需再做数据复制。这样保证了数据始终只有一份。
数据类型
在实践的过程中，js端在选择二进制对象的数据类型的时候，可能会用ArrayBuffer或者TypeArray。一旦js端进行了数据类型转换，比如ArrayBuffer转TypeArray，引擎在调用setNativeBuffer的时候，传递的是转换后的数据类型，将会导致setNativeBuffer内部的写入优化失效，进而在低端机上带来明显的卡顿。在这里，我们统一使用一致的数据类型，不能随意的转换数据类型。
在技术挑战中我们提到，iOS平台上，相机output只能指定为BGRA格式，而WebGL标准的接口不支持该格式。如果不进行格式转换，会导致红蓝颜色颠倒，红色物体呈现蓝色，蓝色物体呈现红色。所以在数据缓存和传输之前，要做格式转换，我们需要找到一个快速低成本的方法。
要想做数据格式转换，需要了解一些基本的图像数据在内存中的布局情况，如下图所示。
这里我们选取的BGRA和RGBA格式都是32位，也就是每一个像素点是4个字节。
真实图像数据由于内存对齐的原因，大小并不一定是width*height*4个字节，CoreVideo框架提供了获取相机数据宽高的方法，我们要计算出待处理的字节大小，每4个字节做一次循环，把第一位和第三位做一个调换，就能无需malloc内存，把BGRA转换为RGBA格式。
在技术挑战中还提到，每一帧的处理时间大约只有41ms，需要经历原生相机生产、数据格式转换、数据双向传输、ar算法、webgl绘制等这么多流程，如何利用并发优势，并且保证实时帧的时序不会发生错乱呢？
我们为了保证UI主线程的流畅，要尽可能把更多的环节放到子线程执行，这个时候哪怕写入缓存这样一个轻量的操作放到主线程都可能会带来画面的卡顿。
实时帧的处理、AR算法分别放在不同的线程，为了保证实时帧时序，均采用串行队列。
采用了多线程之后，NativeBuffer数据的存储和清理需要加上线程安全保护。
这样整体利用了多核的优势，并保证了调用时序。线程调度和处理流转如下图所示：
理想情况下，原生相机产生一个实时帧数据，JS消耗一个，在中高端机器上，性能能够满足需求，整体表现较为平稳，但是在低端机器中，线程抢占非常频繁，当主线程和子线程发生线程抢占的时候，会导致供需不匹配，一旦实时帧数据消耗不及时，内存会产生爆炸式的增长，所以需要限定缓存池的容量，这个一般可以根据实际调试的情况指定一个数值即可。
还有一旦出现内存警告或者当缓存满的时候，需要去清理缓存池，buffer如果正在被使用，就不能去清理，否则可能会出现白屏的现象，我们给buffer加了一个是否被消费的标记，当一个buffer被消费后，它不能以常规的方式清理，需要等待js消费完成之后清理，这个在上面也有介绍。
在页面退出的时候，引擎需要监听相关的事情，确保实时帧的监听被停止，否则会出现多个js相机的监听事件并存，一个数据被多次消费而引发异常。
京东小程序致力于打造卓越的技术开放平台，我们在提升性能、用户体验上不断努力，我们也在建设和完善小程序的各种能力，欢迎大家提供宝贵的建议。