🙋🏻‍♀️ 编者按：本文作者是蚂蚁集团客户端开发工程师希德，分享了 2022 年新春五福项目中 AR 写福和 AR 打年兽落地过程中的架构思考、挑战、经验，以及背后沉淀的支付宝互动引擎-Paladin。

在 2022 年新春五福项目中，为了支撑单一主线升级到多元化玩法、为用户增添科技感和新鲜感、同时呼应 XR 应用呼之欲出的技术 & 商业时代，咱们端业务与营销团队，在 Oasis 团队和算法团队的鼎力支持下一起落地了两个 AR 玩法——AR 写福和 AR 打年兽。开此文向大家分享下落地过程中的架构思考、挑战、经验和背后沉淀的支付宝互动引擎-Paladin。

一、AR 玩法落地总结

1.1 效果回顾

1.2 用户侧的反响

咱们先看下上述 AR 玩法的技术指标：

1.3 技术指标

• 机型覆盖率：72%
  
• 稳定性：1/10w 量级
  
• 启动耗时 Android 1.1s，iOS 439ms，达到秒开体验
  
• 复用率：一套 Paladin 方案跨双端支撑了 AR 打年兽、AR 空中写福、手写福回放、手写福录制视频需求
  

1.4 关键挑战

1.4.1 位图矢量化

AR 写福的前半段是在 2D canvas 上写一个 2D 福，在 2D 转成 3D 过程中需要将 2D 图像转成平滑、可拉伸的矢量笔划，并将矢量通过挤压算法挤出厚度和圆角，并赋予一定的材质、光照效果。

由于 2D 福字面积较大，提取出图像格式后像素较大，前端同学在 js 侧尝试下来位图矢量化耗时明显，在低端机上更不可控。评估下来，这类高计算量的工作适合用 c/c++ 来实现，且在写字类应用里都有需求，恰好 paladin 有 js 绑定机制，可以高效、自由地扩展 js api，后边通过在 Paladin 侧集成一个 trace 算法，并作为 canvas 的一个内置特性能力提供出来（Canvas.toCurveData），输出的 path 格式是 geojson，前端生态对之提供了较好的支持。而位图矢量化耗时也降到了 1 ms。

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

1.4.2 2D 福到 3D 福转场特效

scene node 关系：

转场特效的核心难点，并不是特效本身，而在于转场，即要求在原始正交相机渲染的结果，转移到透视相机渲染的结果上。完成这一步之后，后面的所有变换都是任意的。具体的思路，就是通过正交和透视相机的配准，寻找手写福和贴纸在空间中合适的位置，使得整个过程不需要太多别的障眼法就能够掩盖过去。大致分为三个阶段：

第一阶段：正交相机2D写福，摆放贴纸

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

问题变成了寻找正交相机和透视相机的不动点。在这个不动点上，两个相机作用后的结果是一样的。从几何上来看，就是把正交相机和透视相机的视锥体叠在一起，一定会有一个交叉的深度，使得在这个深度上的物体，在两种相机的作用下是等大的。

但由于贴纸是有厚度的，所以我唯一能够保证的是贴纸模型空间中 z=0 的那个平面不会变大，前后还是要拉伸了，所以还是需要正交和透视相机进行插值来让这个过度更加自然，但是由于没有尺度的变换，所以用户感官上很难发觉。

下面我们就来推导具体的表达式，我们不考虑旋转，尺度缩放在这两种投影下都是一样的，所以只考虑平移，所以MV矩阵就是：

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

在正交投影下可以得到：

在透视相机下可以得到：

我们的目的是使得任意的a和b，x和y都会相等，所以，式子当中a和b的系数如果相等即可：

正交相机中

所以上面两个式子其实是一样的，于是就可以得到z的值：

通过这种方式就可以得到贴纸的深度，然后把3D福字放的稍微后面一点，就可以通过z来算出s，x，y这几个量，整个模型的位置全部确定。有了这些，就可以处理转场切换的过程了。

第三阶段：相机和模型分离，天马行空的特效

上面的过程中，groupEntity和camerEntity的变换都是一致的，看上去就是grounpEntity的子节点是cameraEntity的子节点一样。在这种特殊的情况下，ViewMatrix没有作用，并且推导出了上面一系列东西。这样保证了切换的一瞬间，看上去是一模一样的。然后再开启一系列特效，就与cameraEntity无关了。

以上引用自转场特效作者 Oasis 杨丰老师

1.4.3 内存、CPU 优化

• 主屏 canvas 支持resize，分机型档次适配分辨率；
  
• ARSession 设置相机分辨率（针对2k屏等手机设置1080p）；
  
• 视频录制设置宽高（分辨率降内存）；
  
• request API 支持arraybuffer（请求3d模型文件，大数据base64序列化/反序列化消耗）；
  
• 福字贴纸上传方式优化
  
• 降低不必要的链路（端智能、动画、容器）叠加
  
• ARKit 相关内存占用：    
  

    AppleCV3D 16M

    AppleCV3D 20.39M

    包含 ImageBuffer 4M

    CMCapture 18.94M

ARKit 需要 app 层提供一个 dispatch_queue，有若干个（最低4个）线程来消费这个 queue 里的任务。IMU 计算的线程 CPU 占用率很高（IMU 数据频率太高），导致整体 CPU 占用很高，机器发烫。这块目前调查了业界的做法，包括 stackoverflow 及 Unity 论坛，抱怨这个问题的多，属于视觉算法的刚需开销，苹果也未提供针对性建议，应用层也无调校介入的接口。项目中我们主要依靠降低 ARSession 实例的活跃时间，一旦不需要就尽快回收。

ARKit 相关内存、CPU 占用细节附上，期望帮助到同路人。

背景知识：ARKit 里边主要提供了基于视觉惯性里程计 VIO 原理的 SLAM 实现，主要有图像捕获（CMCapture）和运动管理（CMMotion）模块构成。

1.dispatch worker 累计在 130M左右

2.dispatch 线程1 （45.11M）: AppleCV3D - ARKit 占用 20.39M， CMCapture占用 16.60M

3.start_routine 线程（24.29M），大头占用在CMCapture，22.45M， ARKit：672k

4.dispatch 线程2（22.23M） ：大头占用同样在 CMCapture ，18.94M，ccdn占 2.03M

5. dispatch 线程3（11.97M） ：大头占用同样在 CMCapture，AppleCV3D，CoreVideo，分别在9.52M，1.16M, 1.27M  

沉浸式风格

支持横屏；各种加载控件、分享、rpc 交互都要确保不将底部导航条、顶部标题栏状态栏唤起。

弥补系统能力缺口

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

SampleBufferLayer 实现支持 Canvas音视频录制；（iOS12以下系统bug）

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

二、支付宝互动引擎——Paladin

Paladin 是移动优先、采用 Web 3D 研发模式、高性能、跨端的互动引擎。目前优先针对的研发领域：移动 AR、小游戏。

架构背景

为什么需要在 WebAR、小程序、原生 AR （ARCore、Reality Kit）之外，有一个新的 Paladin 方案？

首先有必要剖析下AR、游戏的技术构成，并横向对比下以上各种选型的差异：

1. 虚实结合：AR技术依靠计算机技术构建出文字、图片、视频、音频、网站链接、三维模型、三维动画、全景信息等和物理世界的结合，让物理世界和虚拟对象合为一体。

2. 虚实同步：AR实现虚拟世界和物理世界的实时同步，满足用户在物理世界中真实地感受虚拟空间中模拟的事物，增强用户体验效果。

3. 交互自然：可以使用手部动作与手势控制所读出的3D模型移动旋转，以及通过语音、眼动、体感等更多的方式来与虚拟对象交互。

AR 技术构成

技术选型评估维度：

1. 模块复用：AR 技术总体分为真实世界记录、虚实融合、实景输出三块。其中游戏引擎在其中作为总导演，根据业务的玩法设计基于环境理解的空间数据做虚实融合并进行输出。所以游戏引擎一般在 AR 技术里承担渲染引擎的角色。

2. 体验以及渲染特征：实时渲染，高实时性是 AR、游戏的共性，同时都追求真实感、身临其境感；小程序与 GUI 类似，除动画外大部分是静止 2D UI

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

Paladin 互动引擎的研发模式是：Web 3D 的研发模式，Web 确保上手门槛低和充足的后备研发队伍，游戏确保领域研发效能和尊重领域习惯。

4.算法可得行：AR 体验中的沉浸式是以人的感觉为标准，人直觉脑的空间、方位感其实速度是非常快的，这就要求用于支持环境理解的算法必须非常高效且稳定。目前 ARKit、ARCore （接近）是移动端 AR 上最好的 SLAM 算法实现。而 WebXR 标准下都并未包含算法相关的标准和实现，只能通过 WASM 方式去移植 c/c++ 版本的三方 SLAM 算法，开发成本高且首次加载耗时长，达不到低延迟的体验。

5.高效相机：WebAR 中一般使用相机需要走 WebRTC 中转一次，实测下来有额外的开销。

6.跨端：Apple 为 AR 在 iOS 上提供了全套的包含环境理解（ARKit）、渲染引擎（Reality Kit）、模型重建（Object Capture）、内容创作（Reality Composer）以及崭新的 ECS（Entity Component System）编程模型；Google 为 Android 平台提供了 ARCore来做环境理解，渲染引擎留给开发者自己来解决。使用各自平台原生 AR 框架，需要双端各自开发，除 3D 内容能复用外，整体复用度较低。以五福项目基于 Paladin 互动引擎完成的空中写福代码为例：50000 多行代码中，仅 7 处判断了是否是 iOS 平台（其中 2 处因 Android 没有对等的 SLAM 模块带来）。

而 Paladin 综合地解决了上述小程序、WebAR、原生 AR 任一选型上存在的不足，概括地说，Paladin 是移动优先、采用 Web + 游戏研发模式、高性能、跨端的互动引擎。其技术架构如下：

需要高亮下的是：

1.三方生态导入

为了吸引存量游戏内容，我们在中间件层提供了一个三方引擎Adapter的模块，运营自己开发者生态的 Cocos、白鹭、Laya 等引擎通过使用 PaladinX 的 API 来实现这个适配器，从而提供从他们的游戏编辑器里发布到支付宝小游戏的能力。

2.移动优先

由高效原生技术（原生相机、原生算法）支撑，其他能力都经由客户端中台提供最高效、最符合移动端特性和用户习惯的实现

3.内置提供 SLAM、空间定位能力（进行中）

我们在过去对接三方业务的过程中发现，从业务层补全 Android 端缺失的 SLAM 能力成本很高，即便有自研 SLAM 算法的企业想要在小程序/小游戏内落地也短则半年，涉及到大空间定位场景下的 3D 点云配准时联调成本也居高不下。所以我们在 2022 年针对这个痛点有两个规划点：

1. 内置提供掉 SLAM、空间定位能力

2. 按时间戳对齐录制视频帧和IMU数据的能力（已申请知识产权），方便业务侧现场采一次数据，回到研发驻地反复、离线地验证算法

由于游戏引擎都有图形抽象层，基于这个图形抽象层再去实现自己的 3D 渲染和 2D UI，并不强需要浏览器中的 DOM 能力，所以 Paladin 引擎里是通过自研的 w3c canvas （而没有浏览器内核）向游戏引擎提供了图形能力。在启动速度和可移植性上有一定优势。当然这一选择也有一定劣势，见后文 iOS 独立 JSC 限制。

业务架构

研发流程

生产关系图

限制

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

iOS 独立 JSC 限制

iOS 独立 JSC 即使用 JavascriptCore.framework 提供的 JSC，而非 WKWebView/Safari 里边的 JSC，这两个 JSC 在版本、特性、性能上存在不同。

且这个限制较为明显的影响到所有性能敏感但又需要自定义 js 环境的场景：React Native、小程序 Worker（框架里的、Worker API 实现中的）。影响到了此类应用的性能天花板。

no WASM 问题

目前 iOS 独立 JSC WASM 能力缺失，互动与渲染团队基于 JS 绑定的机制、WAMR VM 以外挂的形式做了实现并暴露到了小程序当中，为算法密集型的小程序/AR/小游戏（譬如在室内 AR 导航、室外 AR）能跨端地使用到 WASM 能力打开了可行性。

no JIT 问题

先交代个背景：

因为 no JIT，所以 iOS 端其他类型的 VM，比如 WAMR、quickjs、Hermes 都是解释型的。

业界的一些解法：

Facebook RN 的解决方案是为 React Native 场景深度适配实现一个 JS 引擎 Hermes，但并不具备通用性（JS 特性受限、无场景鲁棒性）。但同时 JavaScriptCore framework 里的 JSC 目前暂时不比其他解释型 VM 慢，切到其他通用 JS Engine 没有明显收益。

另一个思路：用 WKWebView 实例来当 js worker 用。由于 WKWebView 内的 jsc 并不直接具备可扩展性。只能以 bridge 的方式来与外部能力异步通信。这种 bridge 通信机制在高通信频率、且带有较大图像 buffer 的场景下表现不佳，js 执行性能优势容易被链路上基于 bridge 的跨语言互调（JS/Native Interop）吃掉。

综述：no JIT 问题目前只能等 1）苹果升级或 2）将计算密集型 js 以 WASM 形式实现来优化。回到 Paladin 目前面临的场景，由于游戏引擎里有专门物理引擎（通过 WASM或 c/c++ buildin）的存在，相当于走了解法 2），no JIT 问题眼下并不突出和紧迫。

能力标准化

目前移动研发里，存在两类较大的技术标准，第一类事实技术标准就是 iOS、Android SDK，主要靠商业模式维持。第二类事实技术标准就是 W3C，也就是 Web 标准，它是以头部领域专家们（当然专家也较多地属于商业组织）以协作的形式订立下来，得到了广泛的采纳，且要求向前兼容，确保最早的网站在最新的时代仍然可使用。

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

基于这个考虑，即自定义能力、扩展能力强既能快速支援业务体现出架构灵活性和效能优势，又有可能在设计上是私有的导致长期演进捉襟见肘，所以我们非常重视能力标准化工作。目前 Paladin 里边的 Canvas 能力已大约实现了 90% 的 w3c canvas 能力。

后续会将 XR 相关接口向 WebXR 标准对齐。相机接口会向着 HTML 6 中的相机标准去靠齐，降低生态互通成本，减少技术长期演进负债。

Oasis 2D UI 能力 & 真实感遮挡

目前写福中选贴纸、笔刷、拍照等 UI 都是以原生面板的方式来实现，并未由游戏引擎内部提供（资源及规划优先级问题，非技术能力达不到），同时 3D 内容与真实世界也没有遮罩关系。期待 Oasis Engine 能在 2022 年提供媲美原生的 2D UI 能力和真实感遮罩效果。

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

我们端业务和 Oasis 以及整个 XR 行业，一起加油，看见未来！