2022新年五福项目中，为了支持单一主线向多元化玩法的升级，给用户增添科技感和新鲜感，同时响应XR应用讲究的科技&商业时代脱颖而出，我们的终端业务和营销团队，在团队和算法团队的大力支持下，一起推出了两款AR玩法——AR写祝福和AR打年兽。我想从这篇文章开始跟大家分享一下架构思考、挑战、实现过程中的经验以及背后的支付宝交互引擎。

1. AR玩法实现总结

1.1 效果回顾

1.2 用户侧响应

我们先来看看上述AR玩法的技术指标：

1.3 技术指标

1.4 主要挑战

1.4.1 位图矢量化

在AR中写祝福的前半部分是在2D上写2D祝福。在将2D转换为3D的过程中，需要将2D图像转换为平滑且可拉伸的矢量笔画，并通过挤压算法挤压矢量的厚度和圆角。 ，并赋予一定的材质和灯光效果。

由于二维汉字“福”的面积较大，提取图像格式后像素也较大，因此前端同学尝试了js端的位图矢量化，这在低端机上显然比较耗时且不可控。经评估，这类高计算量的工作适合用C/C++实现，在编写应用程序时有需求。正好有一个js绑定机制，可以高效自由的扩展js api。后来通过集成一个算法，并作为内置的特征能力（.）提供，输出路径格式为，前端生态系统对其提供了更好的支持。位图矢量化时间也减少至 1 毫秒。

背景：支付宝交互渲染组实现了独立于浏览器的能力。

1.4.2 2D祝福转3D祝福过渡特效

节点关系：

转场特效的核心难点不是特效本身，而是转场，需要将原始正交相机渲染的结果转移到透视相机渲染的结果。完成这一步后，后续的所有变换都是任意的。具体思路是通过正交和透视相机的配准，找到手写祝福和贴纸在空间中合适的位置，这样就可以掩盖整个过程，而无需太多其他技巧。大致分为三个阶段：

第一阶段：正交相机二维祝福书写及贴贴

第二阶段：AR相机透视投影和3D转换

问题就变成了寻找正交相机和透视相机的固定点。在这个固定点，两个相机的结果是相同的。从几何角度来看，如果将正交相机和透视相机的视锥体堆叠在一起，必然存在一个相交深度，使得这个深度处的物体在两个相机的作用下尺寸会相等。

但由于贴纸是有厚度的，所以我唯一能保证的是贴纸模型空间中z=0的平面不会变大，前后仍然会被拉伸，所以还是需要正交和透视相机来插值使这种更加自然，但由于没有尺度变化，用户很难察觉。

接下来我们将推导出具体的表达式。我们不考虑轮换。两种投影下的缩放比例相同，因此只考虑平移，因此 MV 矩阵为：

在模型空间中，朝向相机的坐标为：

在正交投影下我们可以得到：

在透视相机下你可以得到：

我们的目标是使任何 a 和 b、x 和 y 相等。因此，如果式中a和b的系数相等：

在正交相机中

所以上面两个公式其实是一样的，所以我们可以得到z的值：

这样就可以得到贴纸的深度，然后将3D字“福”稍微放在后面，通过z可以计算出s、x、y的量，从而确定整个模型的位置。有了这些，就可以处理过渡切换的过程。

第三阶段：相机与模型分离，特效不受约束

在上面的过程中， 和 的变换是一致的，看起来 的子节点和 的子节点是一样的。在这种特殊情况下，没有任何作用，推导出上面一系列的事情。这保证了切换的那一刻，它们看起来完全一样。那么开启一系列特效就没有什么关系了。

以上引自转场效果作者杨峰老师1.4.3内存和CPU优​​化

16M

20.39M

内含4M

18.94M

‍‍ 应用层需要提供一个，有几个（最少4个）线程来消费这里的任务。 IMU计算的线程的CPU占用率很高（IMU数据频率过高），导致CPU整体占用率较高，导致机器发烫。目前我们调查了包括论坛在内的行业惯例，发现针对这个问题的投诉较多。这是视觉算法的刚性开销。苹果没有提供针对性的建议，也没有应用层进行调整和干预的接口。项目中我们主要依靠减少实例的活跃时间，不再需要时就回收。

附上相关内存和CPU使用详情，希望对各位旅友有所帮助。

背景知识：主要提供基于视觉惯性里程计VIO原理的SLAM实现，主要由图像捕捉（）和运动管理（）模块组成。

1、总量130M左右

2. 线程1（45.11M）： - 占用20.39M，占用16.60M ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

3.线程(24.29M)，占用大容量为22.45M，：672k

4.线程2（22.23M）：批量占用也是18.94M，ccdn占用2.03M

5、线程3（11.97M）：批量占用也分别为9.52M、1.16M、1.27M。

沉浸式风格

支持横屏；各种加载控件、分享、RPC交互必须保证底部导航栏和顶部标题栏状态栏不被唤起。

填补系统能力差距

以下系统图像解码不支持webp；

实现对音频和视频录制的支持； （以下系统错误）

接下来介绍一下AR玩法背后的交互引擎：

2.支付宝交互引擎——

它是一款移动优先、高性能、跨终端的交互引擎，采用Web 3D研发模式。目前优先研发领域：移动AR和小游戏。

建筑背景

除了小程序和原生AR（Kit）之外，为什么还需要新的解决方案？

首先需要分析AR和游戏的技术构成，比较一下以上选项的区别：

1、虚实结合：AR技术依托计算机技术，将文字、图片、视频、音频、网站链接、三维模型、三维动画、全景信息等与物理世界相结合，将物理世界融为一体世界和虚拟物体。

2、虚实同步：AR实现虚拟世界与物理世界的实时同步，让用户在物理世界中真实体验虚拟空间模拟的事物，增强用户体验。

3、自然交互：可以使用手部动作和手势来控制读取的3D模型的移动和旋转，通过语音、眼动、体感等方式与虚拟物体进行交互。

AR技术组件

技术选型评价维度：

1、模块复用：AR技术一般分为现实世界记录、虚实融合、真实场景输出三个部分。其中，游戏引擎充当总指挥，根据业务玩法设计基于环境理解的空间数据，将虚实数据融合并输出。因此，游戏引擎在AR技术中一般扮演着渲染引擎的角色。

2、体验和渲染特点：实时渲染、高实时性是AR和游戏的共同特点，都追求真实感和沉浸感；小程序和GUI类似，除了动画，大部分都是静态的2D UI

3、研发模式：3D内容的构建、测试、调整、模拟均以游戏引擎和编辑器（如编辑器、编辑器、编辑器、苹果）为中心，编程模型为组件化、场景化；而小程序/Web开发都是前端技术栈，编程模型基于页面/文档。

交互引擎的研发模式为：Web 3D研发模式。 Web保证了低准入门槛和充足的后备研发团队。游戏保证领域研发效率，尊重领域习惯。

4、算法可行：AR体验的沉浸感是基于人的感受。人类的直觉大脑对空间和方位的感知其实是非常快的。这就要求用于支持环境理解的算法必须非常高效且稳定。目前，它是（接近）移动 AR 上最好的 SLAM 算法实现。该标准不包括与算法相关的标准和实现。三方SLAM算法的c/c++版本只能通过WASM进行移植。开发成本高，首次加载时间长，无法实现低延迟体验。

5、高效相机：一般使用相机需要一个传输时间，在实际测量中会产生额外的开销。

6、跨端：为iOS上的AR提供了一整套环境理解（）、渲染引擎（Kit）、模型重构（）、内容创建（）以及全新的ECS（）编程模型；为平台提供环境理解，渲染引擎留给开发人员自己。使用各平台原生AR框架需要两端独立开发。除了3D内容的复用之外，整体复用性较低。以五福项目基于交互引擎的空中写祝福的代码为例： 多行代码中，只有 7 点判断是否是 iOS 平台（其中 2 点是由于缺少等效的 SLAM 模块） ）。

它全面解决了上述小程序、原生AR的选择上的不足，简而言之，它是一个移动优先、Web+游戏开发模式、高性能、跨终端的交互引擎。其技术架构如下：

需要强调的是：

1.第三方生态介绍

为了吸引现有的游戏内容，我们在中间件层提供了第三方引擎模块。 和 Laya 等运行自己的开发者生态系统的引擎通过使用 API 来实现此适配器，从而提供游戏编辑器的发布。到了支付宝小游戏的能力。

2. 移动优先

在高效的原生技术（原生相机、原生算法）的支持下，其他能力通过客户端中心实现，提供符合移动终端特性和用户习惯的高效实现。

3.内置SLAM和空间定位功能（正在进行中）

在过去与第三方业务对接的过程中，我们发现从业务层完成端缺失SLAM能力的成本是非常高的。即使拥有自研SLAM算法的公司想要在小程序/小游戏中实现，也只需短短半年的时间，涉及大空间定位场景下3D点云配准的联调成本也依然存在高的。所以我们2022年针对这个痛点有两个规划点：

1.内置SLAM和空间定位功能

2、能够将录制的视频帧和IMU数据按照时间戳进行对齐（已申请知识产权），方便业务方现场一次采集数据，返回研发站反复离线验证算法。

由于游戏引擎有图形抽象层，基于这个图形抽象层实现自己的3D渲染和2D UI不需要浏览器的DOM能力，因此引擎是通过自研的w3c（无需浏览器内核）开发的为游戏引擎提供图形功能。它在启动速度和便携性方面具有一定的优势。当然，这种选择也有一定的缺点，详见后面iOS独立JSC的限制。

业务架构

研发流程

生产关系图

限制

我一生中的大部分时间都在研究什么样的事情会失败，然后尽一切可能避免它们。 ---芒格

iOS 独立 JSC 限制

iOS 独立 JSC 使用 .而不是 / 中的 JSC。这两个 JSC 在版本、功能和性能上有所不同。

而这个限制显然会影响到所有需要定制js环境的性能敏感场景：、小程序（在框架中、在API实现中）。这会影响此类应用程序的性能上限。

没有 WASM 问题

目前，iOS 缺乏独立的 JSC WASM 能力。交互与渲染团队基于JS绑定机制和WAMR VM以插件的形式实现并暴露给小程序。是算法密集型的小程序/AR/小游戏（比如室内AR导航、室外AR）可以跨终端使用WASM能力，打通了可行性。

没有 JIT 问题

首先是一些背景：

由于没有JIT，iOS上的其他类型的VM，例如WAMR和VM，都是解释的。

一些业界解决方案：

RN的解决方案是实现一个JS引擎进行场景深度适配，但不通用（JS功能有限，没有场景鲁棒性）。但同时，其中的JSC目前并不比其他解释型VM慢，并且切换到其他通用JS并没有明显的好处。

另一个想法：使用示例作为js。因为里面的jsc是不能直接扩展的。只能与外部功能异步通信。这种通信机制在通信频率高、图像较大的场景下表现较差。 JS执行性能优势很容易被基于链接的跨语言互调（JS/）所蚕食。

总结：无JIT问题目前只能等待1）升级或者2）以WASM的形式实现计算密集型js进行优化。回到当前场景，由于游戏引擎中存在特殊的物理引擎（通过WASM或c/c++），相当于方案2），无JIT的问题目前并不突出和紧迫。

能力标准化

目前，移动研发的技术标准主要有两类。第一类事实上的技术标准是iOS和SDK，主要通过商业模式来维护。第二种事实上的技术标准是W3C，即Web标准。它是以领先领域的专家合作的形式建立的（当然，专家也属于商业组织）。它已被广泛采用，并需要向前发展。兼容性，确保旧网站在新时代仍然可用。

对于一项技术来说，技术标准是影响开发者介入的门槛、跨模块、跨系统集成的成本以及是否具有生态活力的重要因素。

基于这样的考虑，即强大的定制能力和可扩展性不仅能够快速支撑业务、体现架构灵活性和性能优势，而且在设计上也可能是专有的，对于长期演进可能是不足的，所以我们非常重视能力标准化。目前里面的能力已经实现了w3c能力的90%左右。

未来，XR相关接口将与标准接轨。相机界面将与 HTML 6 中的相机标准保持一致，从而降低生态互操作性成本并减少长期技术演进负担。

2D UI 功能和逼真的遮挡

目前写祝福、拍照的贴纸、画笔、照片等UI都是以原生面板的形式实现，并不是游戏引擎内部提供的（资源和规划优先级问题，非技术能力无法实现） ）。同时，3D内容与现实世界也没有遮蔽关系。我们期待在 2022 年提供可与原生媲美的 2D UI 功能和逼真的遮罩效果。

同时，编辑器作为进入3D世界的重要工具，也将于2022年底公开发布。

我们企业以及整个XR行业，让我们共同努力，共同展望未来！