3DGS 重建吃算力采集吃便携性这两件事很难在同一台设备上做到最好。手机拿着拍方便但重建耗时 12-15 秒用户等得发慌平板算力大重建快但举着平板环绕拍摄手感很差。我们想做的链路是手机采集、平板重建、手机渲染——三台设备各干各的擅长的事。这条链路看着简单真跑通要解决数据传输和坐标系对齐两个硬问题。能力面跨设备数据传输的两条路HarmonyOS 跨设备传输有两条路可走分布式数据同步和文件直传。两条路我们都试了结论是重建结果用文件直传采集素材用分布式数据同步。分布式数据同步distributedDataObject适合小数据量、需要实时同步的场景。我们一开始用它传重建结果PLY 文件约 30-50MB结果超时频繁。分布式数据同步的设计目标是 KV 数据和轻量对象传大文件不是它的强项。文件直传走的是分布式文件系统distributedFile或 Socket 直连。大文件传输稳定性好得多但没有分布式数据同步那种自动同步的便利要自己管理传输状态。// ArkTS跨设备文件直传import{distributedDeviceManager}fromkit.DistributedKit;import{fileIo}fromkit.CoreFileKit;// 1. 发现对端设备constdeviceManagerdistributedDeviceManager.createDeviceManager({bundleName:com.example.recon});constdevicesdeviceManager.getAvailableDeviceListSync();// 2. 通过分布式文件系统发送重建结果asyncfunctionsendReconResult(filePath:string,targetDeviceId:string):Promisevoid{// distributedFile 走设备间直连适合大文件constdistributedFileawaitfileIo.createDistributedFile({localPath:filePath,targetDeviceId:targetDeviceId,targetPath:/data/storage/el2/base/files/recon/result.ply});awaitdistributedFile.transfer({onProgress:(sent:number,total:number){// 传输进度回调用于 UI 反馈constpercentMath.floor(sent/total*100);updateTransferProgress(percent);},timeout:30000// 30 秒超时50MB 文件够用});}采集素材视频或图像序列从手机传到平板我们走分布式数据同步。原因是采集素材需要在两台设备间实时可见——手机拍的时候平板要能看到拍摄状态引导拍摄。这种实时同步用分布式数据同步方便数据量也不大预览帧缩放到 480p 传原始素材拍完再文件直传。约束面传输耗时与坐标系对齐跨设备链路的两个硬约束传输耗时和坐标系对齐。传输耗时数据大小传输方式耗时备注采集预览帧~0.2MB/帧分布式数据同步50-80ms/帧缩放到 480p采集素材视频80-120MB文件直传8-15s取决于网络重建结果PLY30-50MB文件直传3-6s不含 SH重建结果PLY 含 SH45-75MB文件直传5-9s含 SH渲染控制指令1KB分布式数据同步20-50ms视角、缩放等数据在手机和平板间跑的两台设备距离 0.5 米以内Wi-Fi Direct 连接。传输耗时波动比较大采集素材传输 8-15 秒的范围是因为视频编码不同——H.264 编码的 80MB 传 8 秒未编码的图像序列 120MB 传 15 秒。端到端延迟的瓶颈是采集素材传输不是重建。手机拍完到平板开始重建中间有 8-15 秒的传输空等。这段时间用户盯着进度条体验很差。我们试过边拍边传流式传输但 3DGS 重建需要完整素材没法增量重建流式传了也要等传完才能开始重建。坐标系对齐这是更隐蔽的坑。手机采集时的坐标系是手机相机坐标系平板重建结果的坐标系基于平板对素材的解析。如果两台设备对素材的元数据EXIF 方向、视频旋转标记解析不一致重建结果的坐标系就会差一个旋转。我们遇到的情况手机拍的视频带 90 度旋转标记竖屏拍摄平板重建时没读旋转标记重建结果的上方向变成了侧方向。渲染出来模型侧躺着。更麻烦的是渲染端的坐标系。手机渲染时手机的 IMU 和相机位姿决定渲染视角。如果渲染用的坐标系跟重建结果的坐标系不一致渲染视角对不上用户转头时场景转错方向。// ArkTS坐标系对齐——传重建结果时附带坐标系元数据interfaceReconResultWithMeta{plyData:string;// PLY 文件路径coordinateSystem:{upAxis:Y|Z;// 上轴方向handedness:left|right;// 左右手系rotationOffset:{// 相对采集设备的旋转偏移x:number;y:number;z:number;w:number;};};captureDeviceOrientation:number;// 采集时设备方向0/90/180/270}// 渲染端根据元数据校正坐标系functionapplyCoordinateCorrection(gsNode:spatialRender.GSNode,meta:ReconResultWithMeta[coordinateSystem]):void{// 重建结果坐标系跟渲染端不一致时旋转 GSNode 校正gsNode.rotationmeta.rotationOffset;// 如果上轴是 Z 而渲染端期望 Y额外转 90 度if(meta.upAxisZ){gsNode.rotate({x:1,y:0,z:0,w:Math.cos(Math.PI/4)});}}这个对齐逻辑看着不复杂但调对花了我们两天。主要困难是不知道坐标系差了多少——重建结果不会告诉你它的坐标系是什么要自己拿一个已知物体试出来。我们用一只正方体盒子做标定物重建后看盒子哪个面朝上反推坐标系偏移。场景落地手机采集→平板重建→手机渲染完整链路分五步分布式同步预览文件直传素材文件直传 PLY拍摄指引分布式同步视角手机采集视频平板实时引导拍摄平板重建 3DGS手机加载渲染平板同步预览第一步手机采集平板引导手机开始拍摄预览帧通过分布式数据同步实时发到平板。平板上显示预览画面和拍摄引导覆盖度提示、路径指引。这一步用分布式数据同步因为预览帧小、要实时。// ArkTS手机端采集预览同步import{distributedDataObject}fromkit.DistributedKit;// 创建分布式数据对象同步预览帧到平板constsessiondistributedDataObject.create({bundleName:com.example.recon,sessionId:recon_session_001});// 预览帧回调里同步camera.on(frame,(frame:image.PixelMap){// 缩放到 480p 减少传输量constpreviewresizeToPreview(frame,480);constbase64encodeToBase64(preview);// 写入分布式数据对象平板端自动收到session.put(previewFrame,base64);session.put(captureProgress,computeCoveragePercent());});第二步素材传输拍摄完成后原始视频文件通过文件直传发到平板。这是端到端延迟的大头8-15 秒。我们在手机端显示正在传输素材到平板的进度条平板端显示等待素材到达。试过压缩视频再传能缩到 40-60MB传输降到 5-8 秒。但压缩后的视频重建质量下降SSIM 从 0.89 掉到 0.82。权衡后我们选不压缩接受 8-15 秒传输因为重建质量对我们更重要。第三步平板重建平板收到素材后开始重建。平板是麒麟 9030 Pro重建耗时比手机9030快约 30%。设备芯片重建耗时重建内存峰值手机麒麟 903014.2s1.8GB平板麒麟 9030 Pro10.1s1.6GB手机旧款麒麟 902022.5s2.1GB重建耗时波动 ±2 秒跟素材复杂度有关。内存峰值差异主要来自芯片内存带宽9030 Pro 带宽大峰值反而低一些中间数据不用频繁换出。注意一个硬约束同一时刻只允许一个重建 session。如果平板上已经有别的重建在跑新的 session 创建会失败。我们在平板端做了请求队列排队等重建资源。第四步重建结果传回手机重建结果PLY 文件通过文件直传发回手机。30-50MB 文件3-6 秒传完。这一步比素材传输快因为文件小。传输时附带坐标系元数据前面说的ReconResultWithMeta手机端加载时做坐标系校正。第五步手机渲染手机收到 PLY 后用loadGSNode加载渲染。加载耗时 0.5-0.8 秒跟文件大小有关。加载完成后用户可以在手机上交互式查看重建结果。渲染视角由手机 IMU 驱动用户转头场景跟着转。这里坐标系对齐就关键了——如果重建结果的前方向跟手机的前方向对不上用户面向物体时看到的是物体的侧面。端到端延迟汇总阶段耗时备注素材传输8-15s端到端延迟大头平板重建10-14s取决于芯片结果传输3-6sPLY 文件手机加载0.5-0.8s可忽略总计22-36s从拍完到可渲染22-36 秒的端到端延迟体验上不算好。用户拍完要等半分钟才能看到结果。我们试过在传输和重建阶段都显示进度条但用户反馈等太久。后来加了一个拍摄完成后自动开始处理的选项让用户放下手机等通知比盯着进度条体验好一些。踩坑与取舍坑 1分布式数据同步传大文件超时一开始我们用分布式数据同步传重建结果PLY 50MB频繁超时。分布式数据同步内部把大对象分片传输但分片机制对 50MB 这种量级处理不好网络抖动一下就整片重传。改成文件直传后稳定多了。文件直传底层走的是分布式文件系统有断点续传网络抖动影响小。教训分布式数据同步用来同步状态和轻量数据大文件走文件直传不要混用。坑 2坐标系没对齐导致渲染偏移前面说的竖屏拍摄旋转标记问题。手机竖屏拍的视频带 90 度旋转标记平板重建时没读这个标记重建结果侧躺着。渲染到手机上用户正面看物体物体侧面朝前。修复方法是在传输重建结果时附带采集设备的方向信息渲染端根据方向信息校正。但调对这个校正花了不少时间因为物体侧躺这个现象有多个可能原因——坐标系偏移、相机初始位姿错误、渲染视角设置错误——要逐个排除。坑 3设备掉线导致传输中断跨设备链路最怕设备掉线。手机放到口袋里信号断了或者平板息屏后 Wi-Fi Direct 断开传输中断重建结果丢了。我们加了断点续传和本地缓存。传输中断后已传的部分不丢设备重连后从断点继续。重建结果在平板上保留一份缓存手机重连后可以重新拉取。但这个机制增加了复杂度断点续传的边界 case 不少文件被部分覆盖、缓存过期等调试花了几天。坑 4两台设备时钟不同步分布式数据同步依赖设备间时钟同步。我们遇到一次时钟偏差 3 秒的情况导致分布式数据对象的版本号混乱手机端收到的是旧数据。HarmonyOS 有自动时钟同步机制但不是实时的偶尔会有几秒偏差。我们的解决方法是不依赖时钟做版本判断改用自增序号。这个坑不常遇到但遇到了很难排查因为现象是数据偶尔不对不是稳定复现的 bug。取舍什么时候值得跨设备跨设备链路引入了传输延迟和复杂度不是所有场景都值得用。我们的判断标准场景是否跨设备原因小物体重建摆件不跨设备手机重建 14 秒可接受大场景重建展厅跨设备到平板手机重建 60 秒不可接受批量重建跨设备到平板平板算力大排队快实时预览重建不跨设备传输延迟太大实时性做不到高质量存档重建跨设备到平板平板重建质量略好小物体在手机上直接重建就行14 秒等得起。大场景必须跨设备手机重建 60 秒以上用户等不了。批量重建比如商品目录里几十个物体要重建适合跨设备平板算力大排队快。小小注意一下下哦大文件传输用文件直传不用分布式数据同步采集预览帧用分布式数据同步实时性要求高数据量小跨设备链路必须处理坐标系对齐附带元数据设备掉线要有断点续传和本地缓存不能丢重建结果同一时刻平板只允许一个重建 session多请求要排队端到端延迟 22-36 秒产品层面要给用户合理预期素材传输是延迟大头压缩可降延迟但牺牲重建质量不依赖设备时钟做版本判断用自增序号我们在试两个优化方向。一是采集素材边拍边传拍完的同时素材也传完了省掉传输等待。技术上可行需要手机端边录边推流平板端边收边缓存。难点是视频流式传输的完整性校验断帧了重建会失败。二是重建结果在平板端预渲染低精度版本先传回手机高精度版本后台传。用户先看到模糊结果再逐步清晰。这个方案跟 Tiled 3DGS 的思路类似但跨设备实现复杂度更高目前还在验证阶段。如果端到端延迟能从 30 秒压到 15 秒以内跨设备链路的体验就过得去了。目前还在 22-36 秒区间继续调。