用户随手拍两张就点重建，输入烂得没法看，重建出来的 3DGS 场景一堆浮点、墙面破洞、家具边缘飘出半空。这种垃圾结果用户不会怪自己拍得差，只会怪应用"重建效果不行"。我们在入口加了一道质量门禁，在重建开始前就把明显不行的输入挡回去。门禁的难点不是写检测代码，是把阈值定在"既不烦人也不放过垃圾"的那个窄区间里。

holdout 帧按视角均匀采样，不能只留正面帧，否则 SSIM 偏高不反映整体质量SSIM 用 8x8 块均值窗口替代 11x11 高斯窗口，精度损失 0.01 以内，耗时减半评估分辨率降到 512x512，原 1080p 算 SSIM 耗时 4 倍，数值变化 0.01 以内主判据用 SSIM，PSNR 仅辅助，PSNR 对几何漂移不敏感，单看会放过结构错误弱光场景 SSIM 阈值从 0.75

6 种失败要有统一处理入口OOM 降级必须从独立备份重新加载素材超时降级直接放弃 + 引导更好降级重试最多 1 次降级提示要明确告知损失设备不支持要在门禁阶段提前降级素材备份要有清理策略6 种失败降级路径跑通后，下一步收集线上数据看每种失败的实际占比。内测 500 次的数据线上分布可能不同——线上中端机占比更高，OOM 和超时占比可能翻倍。下一篇拆 9020 和 9030 性能差异。

session 是单例，destroy 是异步，resolve 之后仍有资源清理窗口销毁后创建需要保护延迟，时长按设备实测，120ms 在 9030 上够用快速切换场景必须用状态机，纯 Promise 链无法处理取消createReconSession 失败时状态必须回 IDLE，否则 manager 死锁应用切后台回前台要处理 INVALID_SESSION，强制重建 session长期不用的

isSupport只挡崩溃线，体验线要应用自己加capability level 是颗粒度更细的查询，但仍然不保证具体帧率9020 旗舰也存在热启降频，连续重建要给冷却间隔中端机即便放行也要降目标分辨率和帧数，否则重建耗时不可接受低端机直接挡，别让用户白等一场最后 OOM设备矩阵随固件更新会变，做成可配置而不是硬编码测性能数据要记录冷启/热启和机身温度，否则不可复现。

空间坐标系（3D）：原点在相机位置，x 向右、y 向上、z 向前（深度）。单位是米或 vp。3D 模型、空间面板用这套。屏幕坐标系（2D）：原点在屏幕左上角，x 向右、y 向下。单位是 vp。2D 组件、文字、列表用这套。两套坐标系在混合渲染里不是互斥的，是叠加的——2D 区域在屏幕上的位置（屏幕坐标）决定了 3D 区域的视锥边界，3D 区域的投影结果（屏幕坐标）决定了 3D 模型在屏幕上画在哪。

空间界面强依赖视觉深度感知——用户要靠双眼视差判断物体远近，靠视角变化感知空间布局，靠对比度识别层级关系。视力受限用户（低视力、单眼、色弱）这三条都打折：单眼看不出视差，低视力看不清远距离细节，色弱分不清对比度依赖的层级。我们做商品空间详情页时无障碍测试找了位低视力用户（视力 0.3），他戴上头显后完全无法判断商品在哪个深度，伸手去抓总是抓空。空间界面默认体验对这部分用户不仅不友好，是直接不可用。

2D 界面做性能预算有个简单经验——同屏 DOM 节点别超 500，list 虚拟滚动，基本不卡。到了空间界面这套经验失效，因为 3D 节点的开销构成完全不同：draw call、三角形数、纹理带宽、着色器复杂度，每个维度都能单独卡。我们做商品空间展厅第一版放了 200 个商品 3D 模型，真机帧率掉到 22fps，砍到 50 个反而稳 60fps，但 50 个复杂模型又比 200 个简单立方体卡

可见性 visible：组件是否在视锥内且未被裁剪。空间里可见性不是那种二值，而是"在视锥内 + 未被遮挡 + alpha > 0"三个条件合算。视锥裁剪由相机位置和朝向决定，组件自己改不了，只能监听。焦点 focused：组件是否是当前交互选中目标。空间焦点是 3D 的，带 z 坐标。同一时刻只能有一个组件 focused（单焦点模型，API 26 不支持多焦点）。深度 z：组件在 Z 轴的位置

团队接到空间商品详情页需求时第一反应是"复用 2D 组件库"——我们 2D 端有 80 多个组件，Button、List、Dialog、Tabs、Grid 之类的都验证过两轮了，重写一遍得两个月。结果搬过来一跑，Button 能用，List 滚不动，Dialog 飘在半空，Tabs 切换时焦点丢了。每个组件都有自己的炸法，没有统一规律。这篇把我们试过的 10 个常用 2D 组件在空间环境的表现列清