ARFoundation实战：从平面检测到渲染融合的避坑指南

去年我把一个AR展示类Demo从ARKit迁移到ARFoundation在真机上跑了不到三分钟虚拟展品就慢慢漂到了墙角。同事说AR都这样忍忍就好但我知道不是——那些卡顿、漂移、平面检测半天不出结果、模型一看就是贴上去的背后全都对应着一堆可查的原因。这篇文章就把这一路踩进的坑、试错过程、以及最终沉淀下来的通用做法完整拆开讲。如果你正准备用Unity做AR或者已经在ARFoundation里挣扎希望能帮你少走几个月的弯路。文章按选型→坐标系→平面检测→渲染融合→多平台→性能→排查方法的顺序写前半部分偏原理后半部分偏实操你可以按需跳读。1. 为什么绕了一圈最后还是回到ARFoundation怀抱1.1 三个方案摆在面前我最初选错了我最早的项目是想做一个室内空间展示应用需要在真实的桌面和地面上摆放虚拟家具、查看替换效果。当时摆在面前的有三条路直接用iOS原生ARKit、直接用Android原生ARCore、用Unity的ARFoundation封装层。我一开始想的是原生性能最好结果写了两周就发现事情没那么简单。原生ARKit要从零搭渲染管线、处理相机纹理、自己做触摸交互ARCore那边又是另一套API和Java/OpenGL的写法。更重要的是同一个应用需要同时发布iOS和Android光是把两套平台的生命周期、锚点恢复、光照估计逻辑对齐就够熬几个通宵。那时候我才意识到对一个小团队来说跨平台方案的收益远大于那一点点原生性能收益。后来也看了Vuforia、EasyAR这类第三方SDK。Vuforia在图片识别、模型识别上确实强但它的SLAM平面跟踪能力和ARKit/ARCore相比差了半代而且定价模式对个人开发者不太友好License限制比较多。国产第三方SDK接入国内平台方便但部分高级功能需要联系商务授权文档和社区也相对封闭踩坑时很难找到答案。最后定下来用ARFoundation核心原因很直白它在架构上把ARKit和ARCore统一成了一套C# API可以做到一套代码、双端编译同时保留了通过底层扩展访问平台专属能力的空间。我不用再维护两套原生工程也不用在面对平面检测、锚点、光照估计这些基础能力时重复造轮子。1.2 ARFoundation到底帮你封装了什么很多人以为ARFoundation就是直接把ARKit和ARCore的Android/iOS工程合并了实际不是。它的架构核心是Subsystem子系统机制每个平台通过实现一堆XRSDK接口把自己的SLAM能力插进Unity的XR系统里。平时打交道最多的几个子系统大概是这样子系统职责常见操作XRCameraSubsystem提供相机图像、跟踪姿态、光照估计控制相机纹理、读取trackingStateXRPlaneSubsystem负责平面检测、更新、合并订阅平面的added/updated/removed事件XRAnchorSubsystem管理锚点让物体钉在真实世界里创建/移除/持久化锚点XRRaycastSubsystem把屏幕坐标转换为3D空间位置执行命中测试XRSessionSubsystem整个AR会话的生命周期管理启动/暂停/恢复会话每个子系统在运行时会通过Loader挂到对应的原生SDK上。所以在Unity编辑器里你不需要装完整的ARCore/ARKit环境也能写业务逻辑但真要跑起来必须有真机或相应的Remote调试工具。一个特别烦人也特别重要的点Unity的XR Plug-in Management设置会直接决定构建出来的APK/IPA能否正常运行。我曾经在升级ARFoundation后忘了同步切换Active Input Handling裸手在PC端正常一到Android上触摸事件全部失灵。这类问题不是代码问题是工程配置问题后面第5章会展开讲。1.3 版本选择的教训4.x还是5.xARFoundation在4.x时代还叫ARSessionOrigin到5.x统一改成了XROrigin。这是一个非常容易踩的兼容性坑很多老教程写的是ARSessionOrigin你新建的5.x工程里根本没有这个组件网上搜索复制下来的代码报错又带着一堆类型不匹配。我在一开始搭建工程时被这个坑卡了整整一个下午。建议是新项目直接选ARFoundation 5.x Unity 2022 LTS或更高版本不要再从4.x起步了。5.x把ARSessionOrigin换成了XROrigin之后坐标系的语义更清晰而且官方后续的更新也都会集中在5.x。另外版本升级时不要只看ARFoundation本身还要看依赖的包XR Core Utilities、XR Interaction Toolkit、Universal RP版本也要一起兼容。因为这些包的API之间存在耦合只升级其中一个往往会在运行时暴露出另一个的旧行为。我建议直接用Package Manager里当前Unity版本对应的Verified版本别为了某个新功能强行上Preview包——除非你做好了随时拆掉重来的准备。提示如果你用的是Unity 2021装ARFoundation 4.2Unity 2022及以上直接上ARFoundation 5.x。别用4.2的包强行挂到Unity 2022工程里我实测过Android构建能过但运行时会频繁出现相机纹理不更新的问题。2. ARFoundation里最容易翻车的坐标系与跟踪状态2.1 坐标系漂移是怎么发生的ARFoundation中所有虚拟物体的位置都以**Session Space会话空间**为参照。你可以把Session Space理解成从AR会话启动的那一刻起设备在真实世界里的相对位置关系。漂移的根本原因是AR系统并不能精确知道设备在真实世界里的绝对坐标它是通过摄像头画面里的特征点和手机内置的IMU加速度计、陀螺仪数据做视觉惯性里程计估算出来的。简单类比你蒙着眼在一个装满相似家具的房间里走路只能靠手去摸墙壁来判断自己走到了哪摸到一块修正一点一旦摸空了你对位置的判断就会产生偏差。在以下几种场景下漂移会特别严重周围是低纹理环境白墙、纯色地板、光滑桌面视觉特征点太少算法摸不到墙。光线变化剧烈从窗口走进阴影区或者夜间开灯瞬间画面亮度突变会让特征匹配失败。快速移动或旋转SLAM短时间内丢帧IMU数据不够平滑位姿估计就会跳。这是SLAM类AR的物理天花板不是ARFoundation的bug。理解了这一点你就不会花大量时间去寻找什么消除漂移的魔法参数了。正确思路是在用户交互层面去规避比如在APP里提示用户缓慢移动手机扫描周围环境或者干脆构建一个初始化阶段让用户先转两圈让系统建立特征地图。2.2 跟踪丢失时你到底该不该冻结场景ARFoundation里跟踪状态主要由ARCameraManager和ARSession的状态共同决定。它不是一个开关而是一个三态状态机None、Limited、Tracking。None表示会话还没初始化或彻底丢失Limited表示还能工作但缺少足够的信息往往带有原因的枚举比如LimitedReason.Initializing、LimitedReason.LowLight、LimitedReason.ExcessiveMotionTracking是正常状态。我会建议你在业务层显式监听这个状态而不是等到视觉上已经崩了再反应。注册一个回调private void OnEnable() { _cameraManager.frameReceived OnFrameReceived; } private void OnFrameReceived(ARCameraFrameEventArgs args) { var sessionSubsystem _session.subsystem; if (sessionSubsystem null) return; switch (sessionSubsystem.trackingState) { case TrackingState.Tracking: // 正常状态可以正常渲染业务物体 _arContainer.SetActive(true); break; case TrackingState.Limited: // 有限跟踪提示用户请缓慢移动手机 // 同时可以隐藏对精度敏感的元素只保留UI _arContainer.SetActive(false); break; case TrackingState.None: // 丢失跟踪冻结交互 break; } }一个小经验丢失时不要立刻把所有物体Destroy最好把它们留在原地等跟踪恢复后再通过锚点找回。如果直接Destroy等系统恢复时你会发现之前放好的虚拟物体全没了用户会疯掉。正确做法是暂停业务逻辑 把已放置物体的位置保留缓存恢复后再通过ARAnchorManager去重建。2.3 虚拟物体抖动不是玄学是参数和姿势问题虚拟物体在真机上抖得厉害是我收到最多的求助。这类问题我习惯按下面这个顺序排查现象可能原因处理手段物体原地高频微抖依赖了过多的视觉特征点而手机本身手持不稳开启ARPlaneManager的平面平滑或改用锚点固定平面检测稳定后物体仍然随相机移动物体没有挂到锚点上而是挂到了某个平面GameObject下平面随帧更新位置放置时创建ARAnchor并挂到Anchor下放置后过几秒发生明显偏移平面合并/删除后旧的父节点失效订阅平面removed事件把物体重新挂到保留的锚点上只在某几台手机上抖设备IMU差异或系统版本差异拉出该设备的日志结合跟踪状态一起判断还有一个非常典型的操作错误每帧都用Raycast去校正虚拟物体位置。Raycast的命中点本身是有噪声的你用带噪声的结果直接给物体的transform赋值等于把噪声放大到坐标系里。更好的做法是命中测试成功时创建一个ARAnchor。把虚拟物体作为Anchor的子物体。之后完全不要每帧更新它的位置让ARFoundation的锚点系统去管。只有需要在平面移动时才会考虑平滑追踪比如放置家具后允许它在桌面拖动这时也要用插值平滑而不是直接欧拉角/位置赋值。3. 平面检测、命中测试以及物体放不上/放歪的真相3.1 平面检测不是你想的那样自动ARFoundation的平面检测看起来自动出现网格但它的原理是系统在点云图里找共面特征点然后把它们拟合一个多边形出来。这个过程需要时间而且平面网格不是一次就稳定的——它会不断更新、合并、拆分。所以你在桌面上撒一把虚拟物体如果桌面网格还在更新物体位置就会漂移式地跟着变。平面检测相关配置主要在ARPlaneManager上detectionMode控制检测水平面、垂直面还是两者都检测。如果你只需要桌面别开Both性能会白白损耗一半。planeFindingModeUnity 5.x之后细化了找平面方向。假设你只关心朝上的水平面可以设置为HorizontalUpward能有效减少误检测。normal对齐拿到平面网格后判断平面法线的方向是否符合你的业务需求。如果用户把手机横过来对着墙面它可能会检测出一大堆垂直面而你只想让物体放在桌面上就需要过滤。我在做一个桌面植物摆放应用时初始版本检测出墙面的垂直平面导致植物长在了墙上后来增加了法线角度过滤问题直接消失。// 简单过滤只接受法线接近朝上的平面 if (plane.normal.y 0.8f) { // 可以放置 }3.2 命中测试的正确姿势先射向点云再落回平面把虚拟物体放到真实世界的操作专业术语叫命中测试Hit Testing。新手最常见的错误是用Unity物理系统做Physics.Raycast然后发现什么都射不中——因为真实世界不是Unity物理引擎里的ColliderARFoundation的平面网格默认也不带Collider虽然可以勾选Generate MeshCollider但我不推荐。正确做法是用ARRaycastManagerprivate void HandleTouch(Vector2 screenPos) { var hits new ListARRaycastHit(); if (_raycastManager.Raycast(screenPos, hits, TrackableType.PlaneWithinPolygon | TrackableType.FeaturePoint)) { // 优先取平面命中 var targetHit hits[0]; var anchor _anchorManager.AddAnchor(new Pose(targetHit.pose.position, targetHit.pose.rotation)); // 把虚拟物体挂到anchor下 _spawnedObject.transform.SetParent(anchor.transform, false); } }这里有一个非常重要的细节TrackableType之间用|组合表示允许多种命中类型。为什么不能只写TrackableType.PlaneWithinPolygon因为在这个平面还没被系统完整识别出来之前你永远等不到平面命中的结果表现就是怎么点击都没反应。配合FeaturePoint之后即便平面还没生成也能命中一个稀疏特征点作为临时落脚点体验会顺滑很多。另外不要用Physics.Raycast去判断屏幕点击是否命中AR平面有两个原因一是性能浪费二是坐标系不一致屏幕点是2D像素坐标世界射线需要经过Camera换算。除非你要自己实现复杂的3D交互比如旋转手柄、拖动否则直接用ARRaycastManager就够。3.3 虚拟物体的锚点ARAnchor 和平面边界的爱恨纠葛平面检测出来的Plane会随着环境变化被合并、拆分、删除而ARAnchor则是独立的、不会因为平面变化而消失的钉子。把虚拟物体挂到Plane子节点下的坏处很直接如果系统更新了平面网格把原来的Plane划分成了两个或多个挂在旧Plane下的物体会直接丢到错误的位置。把物体挂到ARAnchor下就稳得多因为Anchor一旦创建系统会全力维护它相对于真实世界的位置。不过ARAnchor也不是万能的。如果已经创建的Anchor长时间处于跟踪丢失状态它可能也会在系统内部被移除。所以稳妥的兜底方案是在ARAnchorManager.anchorsChanged事件里订阅removed回调对被移除的Anchor做善后处理比如重建Anchor并把物体的位置插值过来。4. 光照估计与渲染融合让模型不再一眼假4.1 环境光和主光方向ARFoundation到底给了你什么AR里的虚拟物体像贴上去的绝大多数原因是光照方向、色温跟真实环境不一致。ARFoundation的光照估计接口把这个数据暴露在了ARLightEstimationData里。字段含义ARKitARCoreambientIntensity环境光强单位lux支持支持ambientColor环境光的颜色色温相关支持支持mainLightDirection真实世界主光源方向支持ARKit 3部分支持mainLightIntensity主光源强度支持部分支持mainLightColor主光源颜色支持部分支持我用它来实时调整场景中Directional Lightprivate void ApplyLightEstimation(ARLightEstimationData data) { if (data.ambientIntensity.HasValue) { _sceneLight.intensity data.ambientIntensity.Value / 1000f; } if (data.ambientColor.HasValue) { _sceneLight.color data.ambientColor.Value; } if (data.mainLightDirection.HasValue) { _sceneLight.transform.rotation Quaternion.LookRotation(data.mainLightDirection.Value); } }这段代码虽然简单但实测下来能把塑料感降低一个档次。注意不同设备返回的数值范围有差异建议做一次归一化处理别直接用原始值。4.2 阴影问题为什么AR里的物体没有影子或者影子乱飘Unity阴影问题这个热搜词背后AR场景里有两种典型情况。第一种物体没有影子。真实世界里桌面上应该投射出虚拟物体的影子但默认设置下ARFoundation的平面网格往往把ShadowCastingMode设成了Off导致物体的影子无法被投射到现实表面上。解决办法是给检测到的平面MeshRenderer设置阴影参数var planeRenderer plane.GetComponentMeshRenderer(); if (planeRenderer ! null) { planeRenderer.shadowCastingMode UnityEngine.Rendering.ShadowCastingMode.Off; planeRenderer.receiveShadows true; }第二种影子方向不对。你可能在场景里加了一个Directional Light阴影是有了但影子的方向和真实光源完全不一致看起来非常怪异。这就是上面光照估计里mainLightDirection要派上用场的原因——把主光的旋转跟随光照估计的方向影子方向才能跟真实环境对上。注意ARFoundation自带的平面网格毕竟是实时重建的它的几何精度有限。如果你要渲染非常精细的阴影建议用一层半透明的投影接收平面去做或者考虑在Shader里用Blob Shadow假阴影贴花来模拟移动端性能更友好。4.3 材质和渲染队列融合的最后一公里光照方向对了还有一个容易被忽略的点Unity标准着色器Standard/URP Lit的默认材质球太油亮了。真实世界中很少有纯镜面物体而默认材质的高光参数往往太高导致AR物体自带塑料感。调了几个核心参数后效果立竿见影Smoothness从默认的0.5降到0.2左右削弱不自然的反光。Metallic尽量保持0或接近0除非目标是金属表面。开启Perceptual Roughness或者使用带纹理的PBR贴图让材质有更真实的微表面变化。另外渲染顺序也很重要。AR场景里如果同时存在半透明模型和不透明模型要保证不透明物体先绘制、半透明物体后绘制否则会出现半透明遮挡世界的情况。在URP里把不透明队列和半透明队列分开处理就可以避免大部分问题。纯技术层面如果你想让物体融入环境而不是悬浮在实际空间中还有一个技巧是加一个环境反射探针把周围真实环境的反射注入到材质里。ARFoundation没有直接暴露完整的反射探针数据但可以借助环境光探针或者自定义的Cubemap做折中方案。这块属于进阶优化先把前面的光照方向、材质参数改好视觉提升就已经非常明显了。5. 多平台落地Pico4、WebGL、安卓碎片化并不好啃5.1 在Pico4上做MR要绕开ARFoundation吗很多想同时吃AR和VR的红利的人会把目光投到Pico4这类头显上希望用同一套ARFoundation的代码跑到Pico上。这里要泼一盆冷水Pico4是VR设备它的彩色透视模式走的是OpenXR的Passthrough能力底层并不是ARCore/ARKit那套SLAM栈。ARFoundation在传统手机上依赖的是单目相机配合IMU的SLAM。头显的透视相机虽然也能提供彩色画面但它的深度来源、跟踪方式都和手机SLAM不完全一致而且Pico的透视模式属于平台私有能力。所以如果你硬把ARFoundation工程切到Pico4上大概率发现相机显示的是黑屏或者扭曲的透视频道。Pico上更稳妥的路线是走Unity OpenXR插件启用Passthrough 手部追踪借鉴ARFoundation的交互设计理念但技术栈要独立维护。这个结论可能让很多人失望但提前知道总比花了三周发现无解要好。至于MR切换VR本质上就是在一套OpenXR工程里动态启用/禁用Passthrough混合现实能力跟ARFoundation关系不大。5.2 WebGL上跑AR别被惯性思维骗了ARFoundation有一个非常迷惑人的地方它支持多个平台Unity也支持WebGL发布但ARFoundation本身并不支持WebGL因为WebGL浏览器里没有原生ARKit/ARCore可供调用。如果你确实要在网页里做AR一般有几个方向WebXR浏览器原生AR/VR的Web标准支持范围依设备而定安卓Chrome可以通过WebXR调用ARCore。8th Wall商业WebAR引擎在浏览器里的SLAM效果不错但按项目收费。Zappar、MindAR等做轻量级WebAR体验适合图片识别和简单叠加。这里顺带说一个WebGL的坑跟AR无关但经常一起出现Unity WebGL默认使用IndexedDB做持久化存储在部分浏览器尤其是隐私模式下会报idbfs 写入失败的错。这个错误的本质是Unity把文件系统映射到了IDBFSIndexedDB文件系统浏览器没给写入权限。网上大部分方案都指向用Asyncify重编操作复杂且体验一般如果你只是临时存进度数据改用WebStorage或者后端接口更实在。5.3 安卓设备的兼容性清单Android端最大的敌人不是Unity是设备碎片化。这里列几个实测过的关键点ARCore服务手机需要安装Google Play Services for AR旧称ARCore。华为等部分机型无法使用ARCore因为它们自己有AREngine。开发时最好在启动时检测并给出明确提示而不是等相机黑屏了让用户干瞪眼。OpenGLES和VulkanARCore要求设备支持OpenGLES 3.0以上。Unity的Player Settings里Graphics API如果同时勾选Vulkan和OpenGLES不同机型会走不同的渲染路径可能出现同一份Shader表现不一致。建议只保留OpenGLES 3.0稳定优先。动态权限摄像头权限、存储权限在Android 13后必须运行时请求。如果ARFoundation初始化前没拿到Camera权限会话会启动失败且不报明显错误只在日志中留下一行。我第一次发布时就是被这个坑折磨了整整一天别人手机上正常我的测试机上黑屏一查是权限没有弹窗请求。装机量大的中低端机小米、vivo、三星的中低端机型SLAM的表现会有肉眼可见的差距特别是平面检测速度和跟踪稳定性。发布前至少要准备一台低端设备做回归测试别只用万元的旗舰机自测。5.4 Input System的迁移阵痛Unity新版Input System和ARFoundation的配合是一个不用不知道用了想退货的坑。ARFoundation的官方示例工程很长一段时间都假设你用的是旧版Input Manager如果工程切到新Input System很多示例代码里的Input.GetTouch、Input.mousePosition会直接编译报错。我的做法是在Player Settings Active Input Handling中选择Both让新旧Input都能工作兼容老插件和老代码。多指手势用EnhancedTouch的Touch.activeTouches来读取它是Input System原生支持的接口。处理UI点击时避免触摸事件同时穿透过UI和AR场景加一层EventSystemGraphicRaycaster的判断。热搜里那个unity input system的问题十有八九就是切换新旧输入模式引发的连锁反应。我的建议是AR项目没有历史包袱的话直接用新Input System从第一天就按新API写有历史包袱就在工程层面开Both过渡期至少能跑通。6. 性能、发热、包体决定AR应用能不能活下来6.1 30帧够用但你不能只锁帧率很多刚做AR的开发者会被必须60帧的执念绑架。实际上移动端AR应用的主流做法是锁30帧。原因不是性能不够而是AR的相机跟踪、平面检测、渲染都在同时抢CPU/GPU把帧率拉高会直接换来更高的发热和更快的电量消耗而AR内容本身并不是竞技类FPS30帧对最终体验的影响微乎其微。但锁30帧不是简单在QualitySettings里设置vSyncCount 1那么简单。更有效的做法是关闭垂直同步设置Application.targetFrameRate 30。渲染分辨率按设备等级动态调整。Unity里可以通过ScalableBufferManager控制动态分辨率缩放低端机可以降到0.8x甚至0.7x。如果相机图像本身已经很清晰适当调低AR背景相机的分辨率对发热改善非常明显。6.2 图像与Shader层面的优化优先级AR应用里性能优化顺序跟你预想的可能不太一样。按收益从高到低启用URP替换掉传统内置渲染管线。ARFoundation对URP的支持已经很成熟URP的合批效率和渲染速度在移动端远好于Built-in管线。减少屏幕后处理。Bloom、HDR、抗锯齿在AR背景上不仅重而且容易把相机画面搞得油腻。除非你是做高美术质量的展示项目否则都建议关掉。控制Shader复杂度。移动端像素填充率高复杂的Shader一上帧率瞬间崩。推荐用Shader Graph或URP Lite版的PBR避免用包含反射探针、全局光的超高开销材质。关闭不必要的渲染特性实时阴影距离不要全屏遮罩层尽量用Stencil或后处理替代。6.3 发热与耗电的排查与应对AR应用最大的槽点不是功能不齐而是手机变暖手宝。发热的根本原因是CPU/GPU长时间高负载运行加上SLAM算法本身需要持续访问相机、IMU数据。实际项目里我一般用阶梯式降载策略第一级降低渲染分辨率到0.9x关掉高开销的粒子特效。第二级帧率从30降到24只保留核心交互。第三级不再进行平面扫描暂停非必要子系统如人脸跟踪、环境光反射更新。这个降载逻辑可以用一个简单的配置类做出来根据设备温度阈值或者帧率历史数据动态切换。手机厂商自己的API比如Android的Thermal Service可以读但在Unity C#层不方便更常见的做法是统计最近几秒钟的耗时如果平均帧时间连续超过预期就自动降档。6.4 包体瘦身与启动速度AR应用打出来动辄200MB很大程度是因为同时包含了Android和iOS的ARCore/ARKit原生依赖。下面几个瘦身建议都是实测有效的用AssetBundle按需加载3D资源首包只放最核心的模型和UI。贴图全部走ASTC压缩能明显减包。不同平台的资源单独打包别把iOS的资源也塞进Android包。关掉不用的模块如果项目不用PhysicsUnity的托管桥依然会占大小能在Build Settings里剔除的尽量剔除。启动速度方面AR应用有个特殊性用户打开APP到AR会话可用中间有一段初始化时间。我习惯用ARSession的启动回调来做一个加载中遮罩等trackingState变成Tracking再隐藏。否则用户盯着一个白屏/黑屏会以为应用死了。7. 把这些坑串起来我自己沉淀的排查顺序与工具链7.1 一条能通用的排查链路AR相关的问题我见过太多人一上来就怀疑是Unity版本、SDK版本或者代码逻辑的问题然后盲目改参数最后浪费时间。我的排查顺序基本固定现象第一步干什么第二步第三步相机黑屏检查Camera权限查ARSession.state日志查X Plug-in Management配置物体抖动看是否挂Anchor看TrackingState是否稳定看低端机是否掉帧平面检测不出来看光照是否太暗看是否长时间不动看detectionMode是否正确触摸无效检查Input Handing检查EventSystem检查是否同时存在新旧Input代码模型颜色怪异检查光照估计检查材质Metallic/Smoothness检查URP渲染管线设置7.2 常用的调试工具与辅助手段ARFoundation本身没有特别完善的调试面板但我们可以自己搭一个轻量级的运行时在UI上显示ARSession的状态和trackingState。显示当前帧的耗时毫秒和帧率。显示当前平面检测数量、锚点数量。在Scene视图里打开Gizmos实时查看平面网格和张量点云。写一个简单的DebugView脚本挂到Canvas下用Text组件每帧刷新就好。别用Log刷屏因为AR场景一帧会刷出大量跟踪数据日志输出本身就会拖慢性能。7.3 一个提升稳定度的小技巧最后分享一个让我少踩无数坑的代码习惯所有通过Raycast获取的Pose都先平滑插值再送给游戏逻辑而不是直接赋值。拿放置家具举例触摸命中拿到Pos和Rot后物体不要直接瞬移过去而是用Vector3.Lerp和Quaternion.Slerp做一个小阻尼运动。这样即使命中点有几厘米的抖动用户感知上依然非常稳定。private void Update() { if (_target null) return; _currentPos Vector3.Lerp(_currentPos, _target.position, 0.3f); _currentRot Quaternion.Slerp(_currentRot, _target.rotation, 0.3f); transform.SetPositionAndRotation(_currentPos, _currentRot); }这个技巧属于不加功能但体验提升一倍的做法。在AR里用户对虚拟物体是否稳定的敏感度远高于虚拟物体是否精美。你先保证稳定再追求画面方向就不会错。AR这条探坑之路走到最后发现真正让你掉坑里的往往不是那些高深算法而是坐标系、状态机、版本配置、渲染顺序这些最基础的点。希望这篇文章能帮你把这些基础点一次性打通少走我当初走过的那些弯路。