1. 先把你要做哪一类AR这件事定下来第一次让一个虚拟方块稳稳停在自己家茶几上大概是想入门AR开发的人最想体验的那个瞬间。但真正动手之后你会发现卡住你的从来不是增强现实这四个字背后的数学而是工程配置、版本对齐、真机调试这些看起来毫无美感的部分。我带过几批零基础的同学做AR练手项目最后放弃的人里九成不是因为算法没搞懂而是因为打包出来黑屏、或者地面上那个方块一直漂来漂去找不到人问。所以这篇内容我想按真正能跑起来的顺序来讲而不是按教科书的顺序。适合谁看有最基础的编程概念知道变量、函数、事件循环是什么、没做过三维开发、也没接触过AR的人。看完你应该能独立做出一个扫描桌面、点一下屏幕、在桌面上放一个物体、用手势缩放旋转它的完整小应用并且知道为什么每一步要这么做。在装任何软件之前有个问题必须先回答清楚你到底要做哪一类AR。这个问题不问清楚后面装环境大概率白装。AR不是一个单一技术它是一组能力不同能力对硬件、对框架版本、对设备的要求完全不一样。选错路线的典型表现是教程跟着做了三天最后发现你要的效果所在的那套能力你手上这台测试机根本不支持或者你选的框架压根没提供这个接口。1.1 四条常见路线以及它们各自吃什么硬件我通常把零基础能接触到的AR需求拆成四条路线这个分法不一定学术上严谨但工程上非常好用。第一条是平面检测加物体放置也就是识别地面、桌面这些水平或垂直面然后在上面摆东西。这条路的本质是同步定位与地图构建SLAM设备一边估计自己在空间里的位置一边构建环境地图顺便把地图里近似平坦的区域拟合成平面。它吃的是设备的摄像头、惯性测量单元IMU和算力绝大多数中端以上的手机都支持不需要特殊硬件。第二条是图像/标记跟踪识别一张特定的图片、海报、卡片识别到之后在图片上方叠内容。它的原理是预先对目标图片做特征提取运行时用相同算法提取摄像头画面的特征做匹配。这条路对硬件要求最低甚至老机型也能跑缺点是必须见过这张图光照太暗或者角度太斜就认不出来。第三条是面部跟踪识别面部关键点和表情通常用于虚拟试戴、滤镜。它需要人脸检测能力深度摄像头是加分项但不是必须。第四条是WebAR不装App浏览器打开链接就能用。它的优势是传播成本极低劣势是能力和性能都被浏览器限制复杂的三维渲染基本别想。我列个表把这几条路线的关键差异摆在一起你做选型的时候可以直接对着看。路线核心能力硬件门槛跨端表现典型适用场景平面检测空间定位、平面拟合、锚点中端以上手机深度传感器可选iOS/Android 两端都有原生能力家具摆放、虚拟量尺、互动展陈图像跟踪特征匹配、六自由度姿态估计很低两端支持良好包装盒互动、说明书、卡片游戏面部跟踪关键点检测、表情系数中等两端支持良好虚拟试戴、滤镜、互动玩偶WebAR依赖浏览器的有限能力看浏览器实现差异最大扫码即玩的营销页、轻量演示需要提醒一句这四条路线在工程上不是互斥的一个应用里可以同时开平面检测和图像跟踪但每多开一项能力性能预算和调试复杂度都会上一个台阶。零基础阶段我强烈建议只挑一条走通别一上手就全都要。1.2 选路线时我常问的三个判断问题与其纠结技术名词不如回答三个具体问题答案基本能推出路线。第一个问题你的内容需要知道自己在空间里的哪个位置吗如果只是把一张海报变成会动的动画内容不需要知道自己离墙多远那图像跟踪就够了别碰SLAMSLAM的调试成本是它的好几倍。反过来如果你要把一个虚拟沙发摆进客厅并且能从不同角度走过去看那就必须走平面检测这条线没有第二条路。第二个问题用户是专门打开你的应用还是扫个码就看前者可以接受装App、接受权限弹窗、接受请缓慢移动设备的引导流程后者不行用户从扫码到看到内容如果超过五秒流失率会非常难看。这个判断直接决定你是做原生应用还是做WebAR。第三个问题你的目标设备清单里最老的那台是什么这一条最容易被忽略。AR应用不是开发机跑得动就行你要考虑用户手里那台用了三年的中端机。平面检测在低端机上的表现是平面识别慢、物体漂移明显、发热严重。如果你的用户群设备跨度大要么降低效果预期要么在应用里做能力检测和降级。提示能力检测不是可选项。上线前一定要在代码里判断当前设备是否支持AR会话不支持时给出明确提示而不是让用户对着黑屏发呆。1.3 为什么我建议小白从平面检测起步虽然图像跟踪技术门槛更低、更容易一次跑通但我仍然建议零基础的人从平面检测开始练手理由不是它简单而是它把AR开发里最核心的几个概念一次性暴露给你会话Session、跟踪对象Trackable、锚点Anchor、姿态Pose、射线检测Raycast。这几个概念在面部跟踪、图像跟踪里同样存在只是名字和用法略有差异。你把这套心智模型建立起来换能力只是换API。反过来如果从图像跟踪入门你很可能会写出一个能跑但完全不理解为什么能跑的Demo等到要加平面检测的时候之前那套代码几乎全部要重写。我在实际项目里见过太多这种返工。另外还有一个现实原因平面检测的调试反馈最直观。物体放上去稳不稳、漂不漂、跟着手机转的时候跟不跟得住肉眼一看就知道。这对建立调试直觉非常重要。2. 开发环境搭建真正容易卡住人的三个环节环境搭建这部分网上的教程普遍写得太顺好像点几下就装好了。实际情况是零基础的人在这一步花掉整个项目一半时间都很正常。我把常见的卡点归成三类硬件与系统、版本对齐、工程配置。这三类问题的排查思路完全不同混在一起想会非常痛苦。2.1 硬件与系统那些教程里不会写的隐性要求先说测试设备。移动端AR开发必须用真机模拟器和编辑器里的预览都不能替代真机验证因为摄像头、IMU、以及底层的空间定位能力在编辑器里都是模拟的模拟数据不会告诉你平面识别到底准不准。这一条没有例外。设备选择上有个细节值得说带深度传感器比如飞行时间传感器或激光雷达的机型在平面检测的启动速度和低光照表现上明显更好因为它有额外的深度信息辅助。但你的应用不能依赖深度传感器因为大部分用户手里没有。开发阶段用带深度的机器调试会给你过于乐观的体验建议至少留一台不带深度传感器的中端机做对照测试。系统版本方面Android端平面检测能力对系统版本有下限要求一般要求7.0以上iOS端也有对应的下限。这不是框架的限制是底层运行时能力的限制改代码解决不了。所以工程里的最低系统版本一定要设对设低了运行时会直接失败。还有一个隐性要求是摄像头权限和传感器可用性。有些设备虽然系统版本够但摄像头被其他应用占用、或者系统里禁用了某些传感器AR会话会启动失败。这类失败在日志里的表现通常很含糊后面第4节我会给出具体的排查顺序。2.2 引擎与AR框架的版本对齐这是最大的坑零基础做AR最省事的组合是一个跨平台三维引擎 一个跨平台AR框架。跨平台AR框架的价值在于它把iOS和Android两套完全不同的底层AR能力抽象成同一套接口你写一份代码两端都能跑。如果不做这层抽象你得写两套完全不同的实现零基础基本不可能。但跨平台框架有个代价它和引擎版本是强绑定的。框架的每个大版本都要求引擎在某个版本区间内装错了就是一堆编译错误或者运行时找不到接口。我见过最多的场景是跟着一个两年前的教程做教程里的框架版本和老引擎配套而你装了最新引擎结果组件名字都变了教程里的步骤根本对不上。下面这张表是我整理出的常见配套关系做项目时可以直接对照具体小版本号以官方发布说明为准这里给的是大方向引擎版本线配套AR框架大版本需要特别注意的地方2021.3 LTS5.x教程资料最多组件命名是旧的一套2022.3 LTS5.x 或 6.x6.x 在该版本线上支持有限保守选5.x2023.2 及以上6.x核心组件已改名老教程全部对不上这张表里最值得盯的是最后一行的那句核心组件已改名。在框架5.0之后原来那个负责管理AR相机和设备姿态的组件旧名是 ARSessionOrigin被替换成了新的命名XR Origin结构调整过。这意味着你从网上找到的任何一篇2021年前后的教程里面让你新建一个ARSessionOrigin的步骤在新版本里是找不到的。这不是你操作错了是版本变了。提示安装框架时优先用引擎自带的包管理器安装别手动往工程里拖压缩包。手动拖入的包不会参与依赖解析后续升级或卸载会留下大量孤立文件报错信息还特别难读。2.3 一个最小工程的必开配置清单环境装好之后新建工程接下来的配置项是决定能不能跑起来的关键。我把它们列成清单逐条核对不要跳。第一组包与插件。在包管理器里装好AR框架本体。然后打开工程设置里的XR插件管理XR Plug-in Management在对应平台页签下勾选AR插件。这一步漏掉的表现是场景里一切正常打包出去一片黑日志里提示没有可用的AR提供方。这个坑几乎每个新手都会踩一次。第二组渲染管线。用内置渲染管线还是通用渲染管线URP会影响AR相机背景画面的显示方式。用URP的话需要额外处理相机背景否则会出现虚拟物体正常但看不到真实世界的现象。零基础阶段如果只是想跑通用内置管线最省事如果要做正式项目建议一开始就上URP因为后面做后处理和性能优化会方便很多晚改的成本更高。第三组平台设置。Android端要把脚本后端切到IL2CPP、目标架构勾选ARM64、最低API等级设到AR能力要求的版本之上。iOS端要在打包设置里填好相机权限的用途说明否则应用一启动请求相机权限就会直接崩。这两条都是硬性的缺一个都跑不起来。第四组场景结构。一个能跑的最小场景里必须有四样东西会话组件负责启动和停止AR会话、相机管理组件负责把虚拟相机和真实设备姿态对齐、平面管理组件负责接收并管理检测到的平面、以及一个用来接收点击的逻辑脚本。这四样缺一个要么没画面要么点不动。配置完这四组先别急着做交互直接打包到真机跑一次。这一步的目的不是看效果是验证环境通了。如果此时能看到真实世界的画面哪怕什么都没有说明相机链路、权限、插件全部正常后面出问题就可以排除掉一大片范围。这个先验证最小闭环的习惯能帮你省掉大量时间。3. 第一个能跑通的Demo从平面检测到物体落位环境通了之后我们来做真正的功能。这一节我会把为什么这么写讲清楚因为平面检测这块有太多人抄了代码但完全不知道自己在抄什么一旦效果不对就无从下手。3.1 平面检测到底在做什么很多人以为平面检测是识别出桌子这个物体。不是的。它的实际过程大致是三步。第一步从摄像头画面里提取特征点。特征是画面中那些有明显纹理差异的角点、边缘交汇处比如桌角的木纹、地砖的缝隙。纯白的墙面几乎没有特征点所以你在白墙前面怎么晃都识别不出平面这不是bug。第二步靠特征点在连续帧之间的位移结合设备的加速度计和陀螺仪数据反推出相机自身在空间中的运动轨迹。这一步就是SLAM里的定位部分也是为什么框架会反复提示你缓慢移动设备——移动太慢特征点位移不明显移动太快特征点匹配不上都会导致跟踪丢失。第三步把积累下来的三维特征点做平面拟合找出那些近似共面的大片区域输出成平面对象附带位置、朝向、边界多边形和尺寸。理解这三步之后很多玄学问题就有解释了为什么识别慢因为特征点积累需要时间。为什么在纯色桌面上一放就漂因为特征点太少位置估计不稳。为什么光照太暗效果差因为特征点提取依赖图像对比度。3.2 射线检测与锚点物体为什么能钉在地上平面检测出来之后用户点屏幕我们需要知道他点的是空间里的哪个位置。做法是从屏幕点击位置发一条射线穿过AR相机和已经检测到的平面求交交点就是目标位置。这就是射线检测。但只在交点位置实例化一个物体是不够的。你会发现物体放上去之后随着你走动它会慢慢偏移走得越远偏得越多。原因是每帧的空间定位都有微小误差误差会累积。解决方式是给物体挂一个锚点锚点告诉系统这个虚拟物体和现实世界里的这块区域是绑定的请你在每次重新定位时把它一起修正。有了锚点物体就会跟着平面的位姿更新而更新稳定性会好很多。下面这段是放置逻辑的核心实现基于跨平台AR框架的常见API你可以直接对照自己的版本改using System.Collections.Generic; using UnityEngine; using UnityEngine.XR.ARFoundation; using UnityEngine.XR.ARSubsystems; using UnityEngine.EventSystems; public class PlaceOnPlane : MonoBehaviour { public GameObject prefab; private ARRaycastManager raycastManager; private ARAnchorManager anchorManager; private readonly ListARRaycastHit hits new ListARRaycastHit(); void Awake() { raycastManager GetComponentARRaycastManager(); anchorManager GetComponentARAnchorManager(); } void Update() { if (Input.touchCount 0) return; Touch touch Input.GetTouch(0); if (touch.phase ! TouchPhase.Began) return; // 点在UI上时不要触发放置否则按钮和放置会同时响应 if (EventSystem.current ! null EventSystem.current.IsPointerOverGameObject(touch.fingerId)) return; // 只和平面多边形内部求交避免打到平面边缘外侧 if (!raycastManager.Raycast(touch.position, hits, TrackableType.PlaneWithinPolygon)) return; ARRaycastHit hit hits[0]; ARPlane plane hit.trackable as ARPlane; if (plane null) return; // 关键一步把物体挂到锚点上而不是直接放在世界坐标 ARAnchor anchor anchorManager.AttachAnchor(plane, hit.pose); if (anchor null) return; Instantiate(prefab, anchor.transform.position, anchor.transform.rotation, anchor.transform); } }这段代码里有三个地方值得单独说。第一个是TrackableType.PlaneWithinPolygon这个过滤条件。如果不加过滤射线可能打到平面的无限延伸面上也就是打到桌子边缘外面悬空的空气里用户会觉得我明明点在桌子外面怎么东西飘在半空。加上这个条件只有真正落在已识别平面多边形内部才算命中。第二个是UI穿透判断。没有这段判断你在屏幕上放一个重置按钮点按钮的同时也会在地上放一个物体。这是新手最常见的体验问题而且很难自己想明白原因。第三个是AttachAnchor的返回值必须判空。在某些情况下比如平面刚被系统合并或移除锚点创建会失败。不判空直接使用会得到一个空引用异常而这个异常在真机上往往表现为偶尔点一下没反应或者应用直接闪退非常难查。3.3 交互层缩放、旋转与选中反馈物体放上去之后如果只能看不能动体验会很怪。基础的交互我建议就做三个单指拖动移动、双指捏合缩放、双指旋转。实现思路上有个简单可靠的做法单指拖动时不要直接改物体的世界坐标而是重新做一次射线检测把物体移动到新的交点位置。这样物体永远贴在平面上不会出现拖到半空的情况。双指缩放则取两指间距离的变化比例直接乘到物体的缩放上同时做一次上下限钳制避免缩到看不见或者大到穿模。缩放这里有个容易忽略的问题缩放比例要以物体的初始尺寸为基准而不是每帧累乘。累乘的写法在手指移动快的时候会失控因为触摸采样和渲染帧率不同步。正确做法是记录手势开始时的初始缩放值每帧用初始值 × 当前距离 / 起始距离来赋值。选中反馈也值得花十分钟做一下。最简单的方式是选中时给物体加一个描边或者换一个材质颜色同时把之前选中的物体恢复。别小看这个没有选中反馈的AR应用用户完全不知道自己操作的是哪一个物体。4. 真机调试阶段的典型故障与排查链路这一节是我认为整篇内容里最有价值的部分。前面所有步骤照着做大概率能过但真机调试阶段的问题千奇百怪而且网上的答案往往互相矛盾。我的建议是按链路顺序排查不要凭感觉猜。4.1 打包后黑屏或摄像头无画面一条固定的排查顺序黑屏是最高频的问题。我按从外到内的顺序排前面的排除了再往后走这样不会乱。第一层权限。应用启动时有没有弹出相机权限请求如果没有弹窗说明权限声明没配对。Android端要检查清单文件里的相机权限声明是否被自动注入iOS端要检查打包设置里的相机用途说明是否填写。权限声明缺失的表现就是启动后立刻失败不会有任何画面。第二层AR插件是否启用。打开工程设置里的XR插件管理确认当前目标平台对应的AR插件处于勾选状态。注意这里是按平台分别配置的你在Android页签勾了切到iOS页签还得再勾一次。切平台后忘记重新勾选是昨天还好好的今天就不行了的经典原因。第三层最低版本与架构。Android的最低API等级如果低于AR能力要求AR会话会创建失败。目标架构如果只勾了32位某些依赖库会加载失败。这两个都在打包设置里一次配好不用再动。第四层场景里的会话组件是否被禁用。有时候为了调试其他功能把会话组件临时关掉了忘了打开。表现就是有相机画面但没有AR跟踪。第五层渲染管线配置。如果用的是URP检查AR相机背景的渲染方式是否配置正确。配置错误的表现比较特殊能看到虚拟物体但背景是纯色而不是真实画面。这五层里前两层能解决八成以上的黑屏问题。如果五层都排除了还是黑屏去看真机日志日志里通常会明确写出没有可用的AR提供方或者会话创建失败这类关键词直接搜这几个词比逐行看日志效率高得多。4.2 平面识别慢、物体漂移成因不同解法也不同这两个现象经常被混为一谈但成因完全不同。识别慢指的是对着桌面晃了半天还不出平面。常见原因有三个环境太暗或太亮导致特征点提取困难桌面是纯色或反光材质玻璃桌面是重灾区因为反光和透明都会破坏特征匹配设备移动方式不对要么太快要么太慢。前两个只能换环境第三个可以在界面上加引导——用一个动画提示用户缓慢平移设备这个小小的引导能显著提升首次使用成功率成本几乎为零。还有一个容易忽略的原因是平面管理组件的检测模式设置。有些模式会主动合并相邻平面合并过程需要更多观测数据表现就是平面出来得晚。如果你追求快速反馈可以调成更激进的检测模式代价是平面边界可能不够精确。物体漂移指的是物体放上去之后会慢慢移动、或者跟着视角变化游走。这个问题的成因通常不在平面检测而在锚点没有被正确使用。很多Demo代码直接在世界坐标实例化物体省掉了锚点那一步在小空间里短时间看不出问题一旦走动起来就原形毕露。检查方式很简单把物体实例化成锚点的子物体看漂移是否明显改善。如果用了锚点还是漂那就要看平面本身是不是稳定。平面在被系统重新识别、合并、分割的时候位姿会更新挂在上面锚点的物体自然跟着动。这个现象在小尺寸平面上尤其明显比如一张A4纸大小的区域因为小平面观测数据少位姿估计不稳定。解决办法是引导用户扫描更大面积或者等平面稳定几秒后再允许放置。4.3 两端表现不一致从我这儿好好的到可控跨平台开发里最消耗耐心的一类问题是同一份代码一端正常一端异常。我遇到过几种典型情况列出来供你对照。现象常见原因处理方向一端能识别平面另一端完全没反应目标平台的AR插件未启用或系统版本低于要求检查该平台的插件勾选与最低版本设置一端物体贴地另一端悬空或陷进地面两端对平面朝向的约定不同代码里没做归一化检查放置时的旋转处理别写死某个固定朝向一端流畅另一端卡顿掉帧两端渲染配置或纹理压缩格式差异统一渲染管线配置纹理按平台选压缩格式一端手势灵敏另一端迟钝触摸事件坐标系或屏幕DPI处理不同手势阈值用屏幕比例计算不要用固定像素值最后一行那条特别值得说。我见过一个项目缩放的手势阈值写的是固定像素距离结果在高分辨率设备上手感极好在低分辨率设备上要手指张很大才开始缩放。正确的做法是把阈值和屏幕尺寸挂钩比如用屏幕短边的百分比作为阈值单位。提示跨端问题最有效的排查手段是在同一时刻、同一环境下、两台设备并排跑。分别跑的时候你会怀疑是不是环境光线变了并排跑能立刻排除掉这个变量。5. 从能跑的Demo到敢给人用的应用Demo能跑和能交给别人用中间隔着的距离比想象中大。这一节讲三件我认为最关键的事光照、性能、内容资产。5.1 光照估计虚拟物体落地的关键虚拟物体漂不漂亮是一回事像不像真的在场景里是另一回事。决定像不像的第一因素不是模型精度是光照匹配。AR框架一般提供光照估计能力从摄像头画面里估计出环境光的亮度和色温然后你去调整场景里主光源的强度和颜色去匹配它。启用之后的效果差异非常明显——虚拟物体不再是一个亮度和环境脱节的贴纸而是会随着真实环境变暗、变暖。更进阶的一步是环境探针Environment Probe和实时反射。它能让虚拟物体表面的高光反射出周围环境的颜色这个在金属材质和玻璃材质上效果拔群。但如果你的目标设备跨度大我建议做成可开关的选项因为它对性能有一定要求。还有阴影。真实物体是投影的没有阴影的虚拟物体看起来永远是浮在地上的。移动端的实时阴影开销不小一个性价比很高的折中方案是用一张预先烘焙的圆形软阴影贴图贴在物体正下方的平面上。它不精确但视觉心理上足以让物体站住几乎零开销。等性能有余量了再换真阴影。5.2 移动端性能预算怎么定性能这块我给一个我常用的预算表按中端机的目标来你可以对着自己的设备调整。项目建议预算说明目标帧率稳定30帧优先掉帧会让跟踪抖动比画质低更影响体验单场景三角面总数控制在10万以内模型堆到几十万面在手机上必然卡同屏绘制调用数尽量少于100用材质合批和贴图集来压纹理单边尺寸不超过2048移动端再大收益很小内存却涨得厉害实时阴影光源数最多1个多个实时阴影光源在移动端基本不可接受后处理谨慎启用抗锯齿优先其他效果按需这张表里最容易超标的是绘制调用数。零基础的人做AR习惯一个物体一个材质场景里放十几个模型绘制调用就炸了。压制的办法是尽量共用材质、把多张小图合到一张贴图集里、静态的装饰物合并成一个网格。这些操作在引擎里都有现成工具花半天学一下收益很大。另外还有一个AR特有的性能陷阱平面可视化对象本身的开销。为了让用户看到我识别到平面了大家都会给平面加一个半透明的可视化网格。检测到的平面越多这些网格就越多开销会悄悄涨上去。建议做成一个扫描时显示、放置后自动隐藏的逻辑既省性能又让画面更干净。5.3 模型资产的来源与瘦身零基础的人最容易在模型上下载一堆高精度资源导进引擎之后帧率断崖式下跌。移动端AR的模型我的经验标准是单个物体的三角面尽量控制在几万以内纹理用压缩格式动画尽量用骨骼动画而不是逐帧。模型来源有几个方向一是自己用建模软件做学习成本高但可控二是用程序化生成的几何体方块、圆柱这类先验证功能功能性Demo完全不需要精细模型三是使用开放授权的模型资源注意看清授权范围特别是商用场景。不管从哪里来导入后都要做一遍瘦身删掉看不见的内部结构、合并同材质部件、降低纹理分辨率、烘焙掉不需要的实时光照。还有一个常被忽略的点是默认姿态。不同来源的模型坐标系朝向和缩放单位各不相同导入后常常出现物体躺着、或者尺寸像一栋楼。建议在代码里做一层归一化读取模型的包围盒按目标真实尺寸自动缩放这样换模型不用改代码。6. 走通第一个Demo之后接下来练什么跑通平面放置之后很多人会陷入下一步做什么的迷茫。我给一个简单的练手顺序从易到难每一步都能独立成为一个小作品。第一步做图像跟踪。找一张有丰富纹理的图别用纯色别用大面积重复图案预先处理成识别库运行时识别到就在图上叠一个内容。这一步能让你理解识别库和实时匹配的关系工作量不大但效果很直观。第二步做多物体管理与状态持久化。在一个场景里放置多个物体能选中、能删除、能拖动并且退出应用再进能恢复之前放的东西。这一步会逼你处理数据结构和序列化是Demo到应用的必经之路。第三步做一次完整的用户引导流程。包括启动时检测设备是否支持AR、提示用户移动设备扫描环境、检测到平面后提示可以放置、跟踪丢失时提示恢复。这套引导看起来是体验设计实际上它对成功率的提升比任何算法优化都大因为AR应用的失败大多发生在最初的十秒。第四步尝试加一个轻量的服务端能力。比如让两个设备看到同一个虚拟物体摆在同一位置多人共享空间锚点或者把放置结果保存下来同步到另一个设备。这一步会引入网络同步和坐标系对齐的问题难度明显上一个台阶但做完之后你对AR的理解会完全不一样。最后分享一个我在实际操作中体会到的小技巧每加一个新功能都先在只有几何体的极简场景里验证验证通过再往正式场景里搬。AR的调试链路很长编辑器、打包、真机、环境光线在复杂场景里排查一个新功能的问题你会同时面对十几个变量。用几何体搭一个实验室场景能让你把变量一个个摘出来。这个习惯我保持了几年每次都能省下大量时间。 零基础AR开发入门：平面检测、锚点放置与真机调试实战
1. 先把你要做哪一类AR这件事定下来第一次让一个虚拟方块稳稳停在自己家茶几上大概是想入门AR开发的人最想体验的那个瞬间。但真正动手之后你会发现卡住你的从来不是增强现实这四个字背后的数学而是工程配置、版本对齐、真机调试这些看起来毫无美感的部分。我带过几批零基础的同学做AR练手项目最后放弃的人里九成不是因为算法没搞懂而是因为打包出来黑屏、或者地面上那个方块一直漂来漂去找不到人问。所以这篇内容我想按真正能跑起来的顺序来讲而不是按教科书的顺序。适合谁看有最基础的编程概念知道变量、函数、事件循环是什么、没做过三维开发、也没接触过AR的人。看完你应该能独立做出一个扫描桌面、点一下屏幕、在桌面上放一个物体、用手势缩放旋转它的完整小应用并且知道为什么每一步要这么做。在装任何软件之前有个问题必须先回答清楚你到底要做哪一类AR。这个问题不问清楚后面装环境大概率白装。AR不是一个单一技术它是一组能力不同能力对硬件、对框架版本、对设备的要求完全不一样。选错路线的典型表现是教程跟着做了三天最后发现你要的效果所在的那套能力你手上这台测试机根本不支持或者你选的框架压根没提供这个接口。1.1 四条常见路线以及它们各自吃什么硬件我通常把零基础能接触到的AR需求拆成四条路线这个分法不一定学术上严谨但工程上非常好用。第一条是平面检测加物体放置也就是识别地面、桌面这些水平或垂直面然后在上面摆东西。这条路的本质是同步定位与地图构建SLAM设备一边估计自己在空间里的位置一边构建环境地图顺便把地图里近似平坦的区域拟合成平面。它吃的是设备的摄像头、惯性测量单元IMU和算力绝大多数中端以上的手机都支持不需要特殊硬件。第二条是图像/标记跟踪识别一张特定的图片、海报、卡片识别到之后在图片上方叠内容。它的原理是预先对目标图片做特征提取运行时用相同算法提取摄像头画面的特征做匹配。这条路对硬件要求最低甚至老机型也能跑缺点是必须见过这张图光照太暗或者角度太斜就认不出来。第三条是面部跟踪识别面部关键点和表情通常用于虚拟试戴、滤镜。它需要人脸检测能力深度摄像头是加分项但不是必须。第四条是WebAR不装App浏览器打开链接就能用。它的优势是传播成本极低劣势是能力和性能都被浏览器限制复杂的三维渲染基本别想。我列个表把这几条路线的关键差异摆在一起你做选型的时候可以直接对着看。路线核心能力硬件门槛跨端表现典型适用场景平面检测空间定位、平面拟合、锚点中端以上手机深度传感器可选iOS/Android 两端都有原生能力家具摆放、虚拟量尺、互动展陈图像跟踪特征匹配、六自由度姿态估计很低两端支持良好包装盒互动、说明书、卡片游戏面部跟踪关键点检测、表情系数中等两端支持良好虚拟试戴、滤镜、互动玩偶WebAR依赖浏览器的有限能力看浏览器实现差异最大扫码即玩的营销页、轻量演示需要提醒一句这四条路线在工程上不是互斥的一个应用里可以同时开平面检测和图像跟踪但每多开一项能力性能预算和调试复杂度都会上一个台阶。零基础阶段我强烈建议只挑一条走通别一上手就全都要。1.2 选路线时我常问的三个判断问题与其纠结技术名词不如回答三个具体问题答案基本能推出路线。第一个问题你的内容需要知道自己在空间里的哪个位置吗如果只是把一张海报变成会动的动画内容不需要知道自己离墙多远那图像跟踪就够了别碰SLAMSLAM的调试成本是它的好几倍。反过来如果你要把一个虚拟沙发摆进客厅并且能从不同角度走过去看那就必须走平面检测这条线没有第二条路。第二个问题用户是专门打开你的应用还是扫个码就看前者可以接受装App、接受权限弹窗、接受请缓慢移动设备的引导流程后者不行用户从扫码到看到内容如果超过五秒流失率会非常难看。这个判断直接决定你是做原生应用还是做WebAR。第三个问题你的目标设备清单里最老的那台是什么这一条最容易被忽略。AR应用不是开发机跑得动就行你要考虑用户手里那台用了三年的中端机。平面检测在低端机上的表现是平面识别慢、物体漂移明显、发热严重。如果你的用户群设备跨度大要么降低效果预期要么在应用里做能力检测和降级。提示能力检测不是可选项。上线前一定要在代码里判断当前设备是否支持AR会话不支持时给出明确提示而不是让用户对着黑屏发呆。1.3 为什么我建议小白从平面检测起步虽然图像跟踪技术门槛更低、更容易一次跑通但我仍然建议零基础的人从平面检测开始练手理由不是它简单而是它把AR开发里最核心的几个概念一次性暴露给你会话Session、跟踪对象Trackable、锚点Anchor、姿态Pose、射线检测Raycast。这几个概念在面部跟踪、图像跟踪里同样存在只是名字和用法略有差异。你把这套心智模型建立起来换能力只是换API。反过来如果从图像跟踪入门你很可能会写出一个能跑但完全不理解为什么能跑的Demo等到要加平面检测的时候之前那套代码几乎全部要重写。我在实际项目里见过太多这种返工。另外还有一个现实原因平面检测的调试反馈最直观。物体放上去稳不稳、漂不漂、跟着手机转的时候跟不跟得住肉眼一看就知道。这对建立调试直觉非常重要。2. 开发环境搭建真正容易卡住人的三个环节环境搭建这部分网上的教程普遍写得太顺好像点几下就装好了。实际情况是零基础的人在这一步花掉整个项目一半时间都很正常。我把常见的卡点归成三类硬件与系统、版本对齐、工程配置。这三类问题的排查思路完全不同混在一起想会非常痛苦。2.1 硬件与系统那些教程里不会写的隐性要求先说测试设备。移动端AR开发必须用真机模拟器和编辑器里的预览都不能替代真机验证因为摄像头、IMU、以及底层的空间定位能力在编辑器里都是模拟的模拟数据不会告诉你平面识别到底准不准。这一条没有例外。设备选择上有个细节值得说带深度传感器比如飞行时间传感器或激光雷达的机型在平面检测的启动速度和低光照表现上明显更好因为它有额外的深度信息辅助。但你的应用不能依赖深度传感器因为大部分用户手里没有。开发阶段用带深度的机器调试会给你过于乐观的体验建议至少留一台不带深度传感器的中端机做对照测试。系统版本方面Android端平面检测能力对系统版本有下限要求一般要求7.0以上iOS端也有对应的下限。这不是框架的限制是底层运行时能力的限制改代码解决不了。所以工程里的最低系统版本一定要设对设低了运行时会直接失败。还有一个隐性要求是摄像头权限和传感器可用性。有些设备虽然系统版本够但摄像头被其他应用占用、或者系统里禁用了某些传感器AR会话会启动失败。这类失败在日志里的表现通常很含糊后面第4节我会给出具体的排查顺序。2.2 引擎与AR框架的版本对齐这是最大的坑零基础做AR最省事的组合是一个跨平台三维引擎 一个跨平台AR框架。跨平台AR框架的价值在于它把iOS和Android两套完全不同的底层AR能力抽象成同一套接口你写一份代码两端都能跑。如果不做这层抽象你得写两套完全不同的实现零基础基本不可能。但跨平台框架有个代价它和引擎版本是强绑定的。框架的每个大版本都要求引擎在某个版本区间内装错了就是一堆编译错误或者运行时找不到接口。我见过最多的场景是跟着一个两年前的教程做教程里的框架版本和老引擎配套而你装了最新引擎结果组件名字都变了教程里的步骤根本对不上。下面这张表是我整理出的常见配套关系做项目时可以直接对照具体小版本号以官方发布说明为准这里给的是大方向引擎版本线配套AR框架大版本需要特别注意的地方2021.3 LTS5.x教程资料最多组件命名是旧的一套2022.3 LTS5.x 或 6.x6.x 在该版本线上支持有限保守选5.x2023.2 及以上6.x核心组件已改名老教程全部对不上这张表里最值得盯的是最后一行的那句核心组件已改名。在框架5.0之后原来那个负责管理AR相机和设备姿态的组件旧名是 ARSessionOrigin被替换成了新的命名XR Origin结构调整过。这意味着你从网上找到的任何一篇2021年前后的教程里面让你新建一个ARSessionOrigin的步骤在新版本里是找不到的。这不是你操作错了是版本变了。提示安装框架时优先用引擎自带的包管理器安装别手动往工程里拖压缩包。手动拖入的包不会参与依赖解析后续升级或卸载会留下大量孤立文件报错信息还特别难读。2.3 一个最小工程的必开配置清单环境装好之后新建工程接下来的配置项是决定能不能跑起来的关键。我把它们列成清单逐条核对不要跳。第一组包与插件。在包管理器里装好AR框架本体。然后打开工程设置里的XR插件管理XR Plug-in Management在对应平台页签下勾选AR插件。这一步漏掉的表现是场景里一切正常打包出去一片黑日志里提示没有可用的AR提供方。这个坑几乎每个新手都会踩一次。第二组渲染管线。用内置渲染管线还是通用渲染管线URP会影响AR相机背景画面的显示方式。用URP的话需要额外处理相机背景否则会出现虚拟物体正常但看不到真实世界的现象。零基础阶段如果只是想跑通用内置管线最省事如果要做正式项目建议一开始就上URP因为后面做后处理和性能优化会方便很多晚改的成本更高。第三组平台设置。Android端要把脚本后端切到IL2CPP、目标架构勾选ARM64、最低API等级设到AR能力要求的版本之上。iOS端要在打包设置里填好相机权限的用途说明否则应用一启动请求相机权限就会直接崩。这两条都是硬性的缺一个都跑不起来。第四组场景结构。一个能跑的最小场景里必须有四样东西会话组件负责启动和停止AR会话、相机管理组件负责把虚拟相机和真实设备姿态对齐、平面管理组件负责接收并管理检测到的平面、以及一个用来接收点击的逻辑脚本。这四样缺一个要么没画面要么点不动。配置完这四组先别急着做交互直接打包到真机跑一次。这一步的目的不是看效果是验证环境通了。如果此时能看到真实世界的画面哪怕什么都没有说明相机链路、权限、插件全部正常后面出问题就可以排除掉一大片范围。这个先验证最小闭环的习惯能帮你省掉大量时间。3. 第一个能跑通的Demo从平面检测到物体落位环境通了之后我们来做真正的功能。这一节我会把为什么这么写讲清楚因为平面检测这块有太多人抄了代码但完全不知道自己在抄什么一旦效果不对就无从下手。3.1 平面检测到底在做什么很多人以为平面检测是识别出桌子这个物体。不是的。它的实际过程大致是三步。第一步从摄像头画面里提取特征点。特征是画面中那些有明显纹理差异的角点、边缘交汇处比如桌角的木纹、地砖的缝隙。纯白的墙面几乎没有特征点所以你在白墙前面怎么晃都识别不出平面这不是bug。第二步靠特征点在连续帧之间的位移结合设备的加速度计和陀螺仪数据反推出相机自身在空间中的运动轨迹。这一步就是SLAM里的定位部分也是为什么框架会反复提示你缓慢移动设备——移动太慢特征点位移不明显移动太快特征点匹配不上都会导致跟踪丢失。第三步把积累下来的三维特征点做平面拟合找出那些近似共面的大片区域输出成平面对象附带位置、朝向、边界多边形和尺寸。理解这三步之后很多玄学问题就有解释了为什么识别慢因为特征点积累需要时间。为什么在纯色桌面上一放就漂因为特征点太少位置估计不稳。为什么光照太暗效果差因为特征点提取依赖图像对比度。3.2 射线检测与锚点物体为什么能钉在地上平面检测出来之后用户点屏幕我们需要知道他点的是空间里的哪个位置。做法是从屏幕点击位置发一条射线穿过AR相机和已经检测到的平面求交交点就是目标位置。这就是射线检测。但只在交点位置实例化一个物体是不够的。你会发现物体放上去之后随着你走动它会慢慢偏移走得越远偏得越多。原因是每帧的空间定位都有微小误差误差会累积。解决方式是给物体挂一个锚点锚点告诉系统这个虚拟物体和现实世界里的这块区域是绑定的请你在每次重新定位时把它一起修正。有了锚点物体就会跟着平面的位姿更新而更新稳定性会好很多。下面这段是放置逻辑的核心实现基于跨平台AR框架的常见API你可以直接对照自己的版本改using System.Collections.Generic; using UnityEngine; using UnityEngine.XR.ARFoundation; using UnityEngine.XR.ARSubsystems; using UnityEngine.EventSystems; public class PlaceOnPlane : MonoBehaviour { public GameObject prefab; private ARRaycastManager raycastManager; private ARAnchorManager anchorManager; private readonly ListARRaycastHit hits new ListARRaycastHit(); void Awake() { raycastManager GetComponentARRaycastManager(); anchorManager GetComponentARAnchorManager(); } void Update() { if (Input.touchCount 0) return; Touch touch Input.GetTouch(0); if (touch.phase ! TouchPhase.Began) return; // 点在UI上时不要触发放置否则按钮和放置会同时响应 if (EventSystem.current ! null EventSystem.current.IsPointerOverGameObject(touch.fingerId)) return; // 只和平面多边形内部求交避免打到平面边缘外侧 if (!raycastManager.Raycast(touch.position, hits, TrackableType.PlaneWithinPolygon)) return; ARRaycastHit hit hits[0]; ARPlane plane hit.trackable as ARPlane; if (plane null) return; // 关键一步把物体挂到锚点上而不是直接放在世界坐标 ARAnchor anchor anchorManager.AttachAnchor(plane, hit.pose); if (anchor null) return; Instantiate(prefab, anchor.transform.position, anchor.transform.rotation, anchor.transform); } }这段代码里有三个地方值得单独说。第一个是TrackableType.PlaneWithinPolygon这个过滤条件。如果不加过滤射线可能打到平面的无限延伸面上也就是打到桌子边缘外面悬空的空气里用户会觉得我明明点在桌子外面怎么东西飘在半空。加上这个条件只有真正落在已识别平面多边形内部才算命中。第二个是UI穿透判断。没有这段判断你在屏幕上放一个重置按钮点按钮的同时也会在地上放一个物体。这是新手最常见的体验问题而且很难自己想明白原因。第三个是AttachAnchor的返回值必须判空。在某些情况下比如平面刚被系统合并或移除锚点创建会失败。不判空直接使用会得到一个空引用异常而这个异常在真机上往往表现为偶尔点一下没反应或者应用直接闪退非常难查。3.3 交互层缩放、旋转与选中反馈物体放上去之后如果只能看不能动体验会很怪。基础的交互我建议就做三个单指拖动移动、双指捏合缩放、双指旋转。实现思路上有个简单可靠的做法单指拖动时不要直接改物体的世界坐标而是重新做一次射线检测把物体移动到新的交点位置。这样物体永远贴在平面上不会出现拖到半空的情况。双指缩放则取两指间距离的变化比例直接乘到物体的缩放上同时做一次上下限钳制避免缩到看不见或者大到穿模。缩放这里有个容易忽略的问题缩放比例要以物体的初始尺寸为基准而不是每帧累乘。累乘的写法在手指移动快的时候会失控因为触摸采样和渲染帧率不同步。正确做法是记录手势开始时的初始缩放值每帧用初始值 × 当前距离 / 起始距离来赋值。选中反馈也值得花十分钟做一下。最简单的方式是选中时给物体加一个描边或者换一个材质颜色同时把之前选中的物体恢复。别小看这个没有选中反馈的AR应用用户完全不知道自己操作的是哪一个物体。4. 真机调试阶段的典型故障与排查链路这一节是我认为整篇内容里最有价值的部分。前面所有步骤照着做大概率能过但真机调试阶段的问题千奇百怪而且网上的答案往往互相矛盾。我的建议是按链路顺序排查不要凭感觉猜。4.1 打包后黑屏或摄像头无画面一条固定的排查顺序黑屏是最高频的问题。我按从外到内的顺序排前面的排除了再往后走这样不会乱。第一层权限。应用启动时有没有弹出相机权限请求如果没有弹窗说明权限声明没配对。Android端要检查清单文件里的相机权限声明是否被自动注入iOS端要检查打包设置里的相机用途说明是否填写。权限声明缺失的表现就是启动后立刻失败不会有任何画面。第二层AR插件是否启用。打开工程设置里的XR插件管理确认当前目标平台对应的AR插件处于勾选状态。注意这里是按平台分别配置的你在Android页签勾了切到iOS页签还得再勾一次。切平台后忘记重新勾选是昨天还好好的今天就不行了的经典原因。第三层最低版本与架构。Android的最低API等级如果低于AR能力要求AR会话会创建失败。目标架构如果只勾了32位某些依赖库会加载失败。这两个都在打包设置里一次配好不用再动。第四层场景里的会话组件是否被禁用。有时候为了调试其他功能把会话组件临时关掉了忘了打开。表现就是有相机画面但没有AR跟踪。第五层渲染管线配置。如果用的是URP检查AR相机背景的渲染方式是否配置正确。配置错误的表现比较特殊能看到虚拟物体但背景是纯色而不是真实画面。这五层里前两层能解决八成以上的黑屏问题。如果五层都排除了还是黑屏去看真机日志日志里通常会明确写出没有可用的AR提供方或者会话创建失败这类关键词直接搜这几个词比逐行看日志效率高得多。4.2 平面识别慢、物体漂移成因不同解法也不同这两个现象经常被混为一谈但成因完全不同。识别慢指的是对着桌面晃了半天还不出平面。常见原因有三个环境太暗或太亮导致特征点提取困难桌面是纯色或反光材质玻璃桌面是重灾区因为反光和透明都会破坏特征匹配设备移动方式不对要么太快要么太慢。前两个只能换环境第三个可以在界面上加引导——用一个动画提示用户缓慢平移设备这个小小的引导能显著提升首次使用成功率成本几乎为零。还有一个容易忽略的原因是平面管理组件的检测模式设置。有些模式会主动合并相邻平面合并过程需要更多观测数据表现就是平面出来得晚。如果你追求快速反馈可以调成更激进的检测模式代价是平面边界可能不够精确。物体漂移指的是物体放上去之后会慢慢移动、或者跟着视角变化游走。这个问题的成因通常不在平面检测而在锚点没有被正确使用。很多Demo代码直接在世界坐标实例化物体省掉了锚点那一步在小空间里短时间看不出问题一旦走动起来就原形毕露。检查方式很简单把物体实例化成锚点的子物体看漂移是否明显改善。如果用了锚点还是漂那就要看平面本身是不是稳定。平面在被系统重新识别、合并、分割的时候位姿会更新挂在上面锚点的物体自然跟着动。这个现象在小尺寸平面上尤其明显比如一张A4纸大小的区域因为小平面观测数据少位姿估计不稳定。解决办法是引导用户扫描更大面积或者等平面稳定几秒后再允许放置。4.3 两端表现不一致从我这儿好好的到可控跨平台开发里最消耗耐心的一类问题是同一份代码一端正常一端异常。我遇到过几种典型情况列出来供你对照。现象常见原因处理方向一端能识别平面另一端完全没反应目标平台的AR插件未启用或系统版本低于要求检查该平台的插件勾选与最低版本设置一端物体贴地另一端悬空或陷进地面两端对平面朝向的约定不同代码里没做归一化检查放置时的旋转处理别写死某个固定朝向一端流畅另一端卡顿掉帧两端渲染配置或纹理压缩格式差异统一渲染管线配置纹理按平台选压缩格式一端手势灵敏另一端迟钝触摸事件坐标系或屏幕DPI处理不同手势阈值用屏幕比例计算不要用固定像素值最后一行那条特别值得说。我见过一个项目缩放的手势阈值写的是固定像素距离结果在高分辨率设备上手感极好在低分辨率设备上要手指张很大才开始缩放。正确的做法是把阈值和屏幕尺寸挂钩比如用屏幕短边的百分比作为阈值单位。提示跨端问题最有效的排查手段是在同一时刻、同一环境下、两台设备并排跑。分别跑的时候你会怀疑是不是环境光线变了并排跑能立刻排除掉这个变量。5. 从能跑的Demo到敢给人用的应用Demo能跑和能交给别人用中间隔着的距离比想象中大。这一节讲三件我认为最关键的事光照、性能、内容资产。5.1 光照估计虚拟物体落地的关键虚拟物体漂不漂亮是一回事像不像真的在场景里是另一回事。决定像不像的第一因素不是模型精度是光照匹配。AR框架一般提供光照估计能力从摄像头画面里估计出环境光的亮度和色温然后你去调整场景里主光源的强度和颜色去匹配它。启用之后的效果差异非常明显——虚拟物体不再是一个亮度和环境脱节的贴纸而是会随着真实环境变暗、变暖。更进阶的一步是环境探针Environment Probe和实时反射。它能让虚拟物体表面的高光反射出周围环境的颜色这个在金属材质和玻璃材质上效果拔群。但如果你的目标设备跨度大我建议做成可开关的选项因为它对性能有一定要求。还有阴影。真实物体是投影的没有阴影的虚拟物体看起来永远是浮在地上的。移动端的实时阴影开销不小一个性价比很高的折中方案是用一张预先烘焙的圆形软阴影贴图贴在物体正下方的平面上。它不精确但视觉心理上足以让物体站住几乎零开销。等性能有余量了再换真阴影。5.2 移动端性能预算怎么定性能这块我给一个我常用的预算表按中端机的目标来你可以对着自己的设备调整。项目建议预算说明目标帧率稳定30帧优先掉帧会让跟踪抖动比画质低更影响体验单场景三角面总数控制在10万以内模型堆到几十万面在手机上必然卡同屏绘制调用数尽量少于100用材质合批和贴图集来压纹理单边尺寸不超过2048移动端再大收益很小内存却涨得厉害实时阴影光源数最多1个多个实时阴影光源在移动端基本不可接受后处理谨慎启用抗锯齿优先其他效果按需这张表里最容易超标的是绘制调用数。零基础的人做AR习惯一个物体一个材质场景里放十几个模型绘制调用就炸了。压制的办法是尽量共用材质、把多张小图合到一张贴图集里、静态的装饰物合并成一个网格。这些操作在引擎里都有现成工具花半天学一下收益很大。另外还有一个AR特有的性能陷阱平面可视化对象本身的开销。为了让用户看到我识别到平面了大家都会给平面加一个半透明的可视化网格。检测到的平面越多这些网格就越多开销会悄悄涨上去。建议做成一个扫描时显示、放置后自动隐藏的逻辑既省性能又让画面更干净。5.3 模型资产的来源与瘦身零基础的人最容易在模型上下载一堆高精度资源导进引擎之后帧率断崖式下跌。移动端AR的模型我的经验标准是单个物体的三角面尽量控制在几万以内纹理用压缩格式动画尽量用骨骼动画而不是逐帧。模型来源有几个方向一是自己用建模软件做学习成本高但可控二是用程序化生成的几何体方块、圆柱这类先验证功能功能性Demo完全不需要精细模型三是使用开放授权的模型资源注意看清授权范围特别是商用场景。不管从哪里来导入后都要做一遍瘦身删掉看不见的内部结构、合并同材质部件、降低纹理分辨率、烘焙掉不需要的实时光照。还有一个常被忽略的点是默认姿态。不同来源的模型坐标系朝向和缩放单位各不相同导入后常常出现物体躺着、或者尺寸像一栋楼。建议在代码里做一层归一化读取模型的包围盒按目标真实尺寸自动缩放这样换模型不用改代码。6. 走通第一个Demo之后接下来练什么跑通平面放置之后很多人会陷入下一步做什么的迷茫。我给一个简单的练手顺序从易到难每一步都能独立成为一个小作品。第一步做图像跟踪。找一张有丰富纹理的图别用纯色别用大面积重复图案预先处理成识别库运行时识别到就在图上叠一个内容。这一步能让你理解识别库和实时匹配的关系工作量不大但效果很直观。第二步做多物体管理与状态持久化。在一个场景里放置多个物体能选中、能删除、能拖动并且退出应用再进能恢复之前放的东西。这一步会逼你处理数据结构和序列化是Demo到应用的必经之路。第三步做一次完整的用户引导流程。包括启动时检测设备是否支持AR、提示用户移动设备扫描环境、检测到平面后提示可以放置、跟踪丢失时提示恢复。这套引导看起来是体验设计实际上它对成功率的提升比任何算法优化都大因为AR应用的失败大多发生在最初的十秒。第四步尝试加一个轻量的服务端能力。比如让两个设备看到同一个虚拟物体摆在同一位置多人共享空间锚点或者把放置结果保存下来同步到另一个设备。这一步会引入网络同步和坐标系对齐的问题难度明显上一个台阶但做完之后你对AR的理解会完全不一样。最后分享一个我在实际操作中体会到的小技巧每加一个新功能都先在只有几何体的极简场景里验证验证通过再往正式场景里搬。AR的调试链路很长编辑器、打包、真机、环境光线在复杂场景里排查一个新功能的问题你会同时面对十几个变量。用几何体搭一个实验室场景能让你把变量一个个摘出来。这个习惯我保持了几年每次都能省下大量时间。