原副标题：天猫小业务流程网络连接ARVR的控制技术计划和操控性Listary

译者：天猫零售业 东凯努瓦县

他们小业务流程发动机联手ARVR项目组，在两方产研测的不懈努力和协同下，完成了有关能力的设计和合作开发。整体功能于天猫APP11.6.6版发布上架，期盼为更多的店家和国际品牌借力。

新体验方向和效用（负责管理有关组件的产品上恩亲情录屏）

控制技术计划

这里以人脸为例，先如是说整体的控制技术计划。

基本概念如是说

技术关键字：照相机、动态帧、AR演算法、南埃尔普图形、WebGL。

前面两个关键字和小业务流程的情景有关系，WebGL控制技术是小业务流程为了全力支持格斗游戏、ARVR等高操控性图形的需求，选用原生植物的OpenGL实现了两套WebGL的USB。小业务流程网页是WebView图形，而他们难道提及了选用OpenGL原生图形，就需要把原生植物组件，恰当的填入到Web的快照层次，南埃尔普图形就是将原生植物组件和WebView DOM 原素放到一起展开混和图形的控制技术，能够确保原生植物组件和 DOM 原素在图形层次、慢速、轻触阿提斯鲁夫尔谷等方面完全一致。

整体业务流程

原始数据数据，展开WebGL图形等操作。概要的业务流程如下表所示：

分层设计

从分层的角度看整个控制技术计划的设计，大致如下表所示：

其中在AR发动机这一层，分为内置和外部AR发动机，也是由于小业务流程本身是对外开放的控制技术网络平台，他们选用了USB协议化的设计，全力支持第三方宿主选用独立自主的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标准的USB不全力支持BGRA格式，参考文档：

https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/texImage2D，数据格式的转换会加重操控性的负担；

**挑战3，**即便以24帧为标准，每一帧的处理时间大约只有41ms，需要经历原生植物照相机生产、数据格式转换、数据双向传输、ar演算法、webgl绘制等业务流程，每一环节都很重，他们需要考虑如何利用并发调度优势，并且确保动态帧的时序不会发生错乱，因为时序一旦乱了，影像虽然一直在输出，但是视觉感受是混乱的。

针对上述挑战，展开了一系列的优化，最终在中低端手机（iPhone8 Plus）上达到平均26~27帧的帧率，整体新体验较为流畅，具体Listary下面详细如是说。

操控性Listary

1、数据传输优化

原生植物和js之间传输大量的数据会成为操控性的瓶颈，数据传输优化就是减少数据传输频次，最好是数据保留一份，只传递数据的标记。

他们设计了一个NativeBuffer缓存来优化这个问题。主要业务流程如下表所示

但是在js环境中，最终还是要使用js对象，原生植物照相机动态帧的数据需要被转换为js对象。那么如何做才能让数据只保留一份呢？

NO COPY

iOS端选择运行小业务流程的js框架是JavaScriptCore，JavaScriptCore提供了一些C语言的USB方法，可以以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的人脸检测USB，还需要把这份数据在传输到原生植物。因为照相机和人脸检测是相互独立的USB，js拿到照相机数据不一定非要调用人脸检测，调用人脸检测的数据也不一定非要来自于相机，还可以是一个本地的图片。

相对应的，他们在NativeBuffer的设计中，提供数据双向传递的USB，getNativeBuffer：id和setNativeBuffer：id。在原生植物传递到js的数据criptCore提供的USB，从js的ArrayBuffer对象中提取到真实数据的内存地址，然后在NativeBuffer缓存池中查找，如果找到了则无需再做数据复制。这样确保了数据始终只有一份。

数据类型

在实践的过程中，js端在选择二进制对象的数据类型的时候，可能会用ArrayBuffer或者TypeArray。一旦js端展开了数据类型转换，比如说ArrayBuffer转TypeArray，发动机在调用setNativeBuffer的时候，传递的是转换后的数据类型，将会导致setNativeBuffer内部的写入优化失效，进而在低端机上带来明显的卡顿。在这里，他们统一使用一致的数据类型，不能随意的转换数据类型。

2、照相机动态帧格式转换

在控制技术挑战中他们提及，iOS网络平台上，照相机output只能指定为BGRA格式，而WebGL标准的USB不全力支持该格式。如果不展开格式转换，会导致红蓝颜色颠倒，红色物体呈现蓝色，蓝色物体呈现红色。所以在数据缓存和传输之前，要做格式转换，他们需要找到一个快速低成本的方法。

要想做数据格式转换，需要了解一些基本的图像数据在内存中的布局情况，如下表所示图所示。

这里他们选取的BGRA和RGBA格式都是32位，也就是每一个像素点是4个字节。

处理的字节大小，每4个字节做一次循环，把第一位和第三位做一个调换，就能无需malloc内存，把BGRA转换为RGBA格式。

3、并发调度

在控制技术挑战中还提及，每一帧的处理时间大约只有41ms，需要经历原生植物照相机生产、数据格式转换、数据双向传输、ar演算法、webgl绘制等这么多业务流程，如何利用并发优势，并且确保动态帧的时序不会发生错乱呢？

他们为了确保UI主线程的流畅，要尽可能把更多的环节放到子线程执行，这个时候哪怕写入缓存这样一个轻量的操作放到主线程都可能会带来画面的卡顿。

动态帧的处理、AR演算法分别放到不同的线程，为了确保动态帧时序，均选用串行队列。

选用了多线程之后，NativeBuffer数据的存储和清理需要加上架程安全保护。

这样整体利用了多核的优势，并确保了调用时序。线程调度和处理流转如下表所示图所示：

4、资源管理

理想情况下，原生植物照相机产生一个动态帧数据，JS消耗一个，在中高端机器上，操控性能够满足需求，整体表现较为平稳，但是在低端机器中，线程抢占非常频繁，当主线程和子线程发生线程抢占的时候，会导致供需不匹配，一旦动态帧数据消耗不及时，内存会产生爆炸式的增长，所以需要限定缓存池的容量，这个一般可以根据实际调试的情况指定一个数值即可。

还有一旦出现内存警告或者当缓存满的时候，需要去清理缓存池，buffer如果正在被使用，就不能去清理，否则可能会出现白屏的现象，他们给buffer加了一个是否被消费的标记，当一个buffer被消费后，它不能以常规的方式清理，需要等待js消费完成之后清理，这个在上面也有如是说。

在网页退出的时候，发动机需要监听有关的事情，确保动态帧的监听被停止，否则会出现多个js照相机的监听事件并存，一个数据被多次消费而引发异常。

结语

天猫小业务流程致力于打造卓越的控制技术对外开放网络平台，他们在提升操控性、用户新体验上不断不懈努力，他们也在建设和完善小业务流程的各种潜能，欢迎大家提供宝贵的建议。

责任编辑：