UGC2.0 交付基建：二进制制品、多端构建与 UI 自动化

这篇回答 UGC2.0 的交付侧深挖：编辑状态如何高效同步，作者数据为何要二进制化，ArtifactBuilder 如何生成确定制品，PC/Android/iOS/小游戏怎样共用语义，以及 UI 自动化怎样进入真实运行环境。

面试官：你在 UGC2.0 的交付基建做了什么？

30 秒回答

我主要做了四块：第一是页面状态按领域和 revision 同步，配合快照、增量和帧内合并控制跨语言成本；第二是把发布态作者数据接入带 Schema 的二进制格式，同时保留编辑态 JSON 和兼容回退；第三是稳定 ArtifactBuilder，从依赖收集、文件处理、确定性构建、覆盖安装到失败清理，并接入 Android、iOS、DS 和小游戏链路；第四是统一 PixUI 与原生 UI 的自动化可测试表面，提供 DOM/树适配、稳定业务 ID 和基础流水线。

90 秒回答

UGC2.0 的数据会经过三次形态变化。编辑时使用可读、易调试的作者数据；页面只订阅 selection、properties、scene、viewport 等状态域，首次拿快照，之后拿带 revision 的增量。发布时冻结作者快照，ArtifactBuilder 按处理器收集依赖、校验 Schema、生成二进制文件和 manifest，再把不可变制品交给不同平台加载。

这里最难的是“相同输入能否得到相同制品”和“跨环境是否加载同一语义”。我处理过打包工具自身不确定、覆盖安装残留旧文件、换行符变化、错误文件混入制品、大地图超时，以及客户端和 DS 部署配置不一致等问题。自动化侧则解决页面能显示但驱动找不到稳定节点的问题，把 PixUI DOM 和 PlayerGui/原生 UI 转成统一节点协议，再在客户端与 DS 集成测试中验证启动、交互和复制。

面试官：为什么页面状态要按域同步？

对象树、选择、属性面板和视口的变化频率与消费者不同。如果每次操作都发送整个编辑器快照，Lua 构造、序列化、C++ 转发、JS 解析和 React 渲染都会被重复放大。

因此把状态拆成稳定领域：

scene       对象树与结构变化
selection   当前选择集合
properties  当前对象属性
viewport    Gizmo、相机和显示状态
resources   资源搜索与加载结果

页面首次进入请求所需领域快照，后续只接收该领域的增量。每个领域独立维护单调 revision；旧版本丢弃，版本缺口时重拉该领域快照，不必恢复整个编辑器。

面试官：高频拖拽怎样优化？

拖拽时位置可能每帧变化，但对象树、属性定义和选择集合通常没有变化。优化顺序是：

1. 先停止发送与本次交互无关的领域。
2. 对同对象同属性按 key 帧内合并，只保留本帧终值。
3. 拖拽中发送轻量预览，结束时提交一次编辑事务和终态。
4. 页面只更新受影响组件，避免整棵 React 树重渲染。
5. 大对象树分页或懒加载，展开节点时再取子项。

这通常比“把 JSON 换成二进制”更先见效，因为无效消息即使编码很快，仍会产生跨层调度和渲染成本。

面试官：为什么还要做数据二进制化？

JSON 适合编辑、调试和版本演进，但发布态存在解析 CPU、字符串体积、类型弱和大量临时对象问题。带 Schema 的二进制格式可以让类型和字段编号稳定，减少运行时解析与分配，也便于构建阶段提前验证。

但二进制化不是把所有 JSON 一刀切。项目中保留了明确边界：编辑态和调试路径优先使用可读数据；发布态优先读取二进制制品；不存在二进制、版本不支持或验证失败时，按兼容策略回退，而不是把“文件存在”误判为加载成功。

面试官：Schema 怎样保证兼容？

原则

• 字段编号一旦发布不复用，删除字段保留编号。
• 新字段有缺省值，旧 reader 可忽略未知字段。
• 必需语义变化通过 schema/version 明确迁移。
• 文件头或 identifier 先验证格式，不能盲目尝试解析。
• JSON 与二进制转换使用同一逻辑模型，避免两套业务语义。

发布前批量转换已有作者数据时，要输出成功、跳过、回退和失败清单；失败项不能静默生成空文件。材质、预设、地图和资产记录可以使用不同 Schema，但 manifest 必须知道每个文件的类型与处理器版本。

面试官：ArtifactBuilder 的职责是什么？

ArtifactBuilder 是作者源与运行时之间的内容编译器，而不是复制目录的脚本。

flowchart LR
    SOURCE["冻结作者快照"]
    DISCOVER["依赖发现<br/>对象 / 脚本 / 资源"]
    PROCESS["文件处理器<br/>转换 / 二进制化 / 预加载记录"]
    VALIDATE["Schema / 引用 / 平台规则校验"]
    MANIFEST["生成 Manifest<br/>身份 / 摘要 / 版本"]
    STAGE["隔离暂存目录"]
    VERIFY["完整性与运行冒烟"]
    PUBLISH["原子安装 / 上传不可变制品"]

    SOURCE --> DISCOVER --> PROCESS --> VALIDATE --> MANIFEST --> STAGE --> VERIFY --> PUBLISH

每个处理器声明输入类型、输出、依赖和版本。构建结果只能写入任务独占的 staging，验证成功后再进入正式目录。失败清理以 staging 为边界，不能递归删除来源目录或上一个成功制品。

面试官：什么叫确定性构建？

同一份作者快照、工具版本、配置和平台，重复构建应得到相同的逻辑文件集合和内容摘要。否则缓存、增量发布、签名、回滚和问题复现都会失效。

常见不确定来源包括：目录遍历顺序、当前时间戳、绝对路径、随机临时名、换行符、压缩包元数据和工具自身生成的 PE/ZIP 信息。项目中实际处理过打包运行时写入当前时间、ZIP entry 顺序和时间不同导致字节不稳定的问题：固定可复现构建时间，按字节序排序 entry，并规范 ZIP 元数据，再用测试验证不同原始顺序产生相同结果。

面试官：你遇到过怎样的制品稳定性问题？

STAR：同一工具在不同环境出现 hash 与发布异常

现象： ArtifactBuilder 在本机、构建机和发布环境之间出现 hash 不一致、旧文件残留或 Windows 发布失败；有时工具能启动，但构建出的地图混入不应该进入包的文件。

拆解： 我把问题分成工具自身 bundle、安装目录、输入快照、文件处理器和最终制品五层，而不是继续追加 hash 白名单。结果发现有多种原因叠加：打包器写入时间与 ZIP 元数据导致工具 bundle 不确定；增量覆盖安装留下旧运行时；Git 换行符改变交付描述；工作目录和相对路径在构建机不同；文件收集规则过宽。

方案： 固定可复现构建环境并规范内部归档；安装时替换完整工具根目录而不是覆盖少数文件；路径进入处理器前绝对化；按 manifest 白名单收集并排除临时内容；构建、验证和冒烟都在隔离目录执行；失败保留阶段化诊断，成功才原子切换。

结果： 这套改造让问题从“发布机偶发失败”变成可由单元测试、bundle smoke 和文件清单定位的确定步骤。没有统一的最终失败率报告，因此不对外报百分比。

面试官：为什么覆盖安装比增量拷贝可靠？

工具升级可能删除或重命名模块。增量拷贝只会添加新文件，不会移除旧文件，运行时可能加载已经不属于当前版本的模块；hash 也无法说明实际安装目录与当前 bundle 相同。

覆盖安装的正确含义是：在经过路径边界检查的临时目录解包并验证，然后替换目标工具根目录。替换前确认目标目录名和父目录，不能对模糊路径做递归删除。失败时保留旧版本或回滚，不留下半安装状态。

面试官：构建很慢时怎样优化？

先测阶段，不先加并发。构建可以拆成依赖发现、读取、转换、写出、复制、压缩和上传。项目中把文件处理器拆开后发现部分文件不需要“读入内存再写出”，可使用文件系统复制；大地图也需要按输入规模设置合理超时，而不是用小样本固定值。

可并行的处理器必须输出独立文件，manifest 汇合时再排序；共享缓存要以内容摘要和工具版本为 key。并行不能破坏确定性，也不能让失败任务留下被下一次复用的脏产物。

面试官：PC、Android、iOS、小游戏怎样共用一套内容？

共享的是对象语义、Schema 和制品身份，不是要求所有平台使用完全相同的物理文件。manifest 可以给同一逻辑资源列出平台变体，运行时按能力选择。

构建矩阵必须记录代码版本、作者快照、工具版本、平台和 DS 版本。进入线上前还要做“客户端制品与 DS 制品是否来自同一内容版本”的握手校验。

面试官：多关卡跳转为什么也是构建问题？

多关卡不只是调用 travel。客户端和 DS 都要包含目标关卡需要的脚本、资源与 Schema，并使用一致部署配置。项目里出现过子构建脚本使用局部环境变量，客户端实际包含新引擎内容，Server 却沿用旧 DLL 的风险。

因此父脚本不能假设子脚本的临时环境会自动传回。构建结果应显式输出本次实际配置，Client/Server 编排器读取并校验；测试覆盖开关传递、环境隔离、失败处理和产物路径。运行时还要在切换前锁定输入、显示加载状态，并在失败时返回可恢复会话。

面试官：UI 自动化为什么需要产品代码配合？

PixUI 页面有 DOM，原生 PlayerGui 或 Widget 有另一棵树。如果自动化只用屏幕坐标和文本，分辨率、语言、布局或动画一变就会失效。稳定方案是让产品代码提供统一可测试表面：

Automation Node
  - stableTestId
  - role / type
  - visible / enabled
  - bounds
  - text or value
  - actions: click / input / scroll
  - children

PixUI adapter 从 DOM 生成节点，原生 UI adapter 从控件树生成节点；驱动只依赖统一协议。业务测试使用稳定 test ID，不使用数组下标、坐标或可能本地化的文本。

面试官：稳定 ID 怎样设计？

稳定 ID 表达业务角色，例如“发布确认按钮”或“对象树搜索框”，不能包含内存地址、创建序号和可变显示文本。重复列表项可以组合业务实体 ID，但要做脱敏并保证跨刷新稳定。

Prefab 或 GUI 克隆时，根业务 ID 与实例 scope 分开：组件模板有稳定语义，实例再加玩家或实体 scope。这样测试既能定位控件类型，也不会因克隆顺序变化失效。

面试官：自动化分几层？

项目中已接入 PixUI DOM、PlayerGui 稳定 ID，以及客户端/服务端启动、GUI 交互、角色移动、背包权威和配对状态复制等基础用例。覆盖率和长期稳定率仍需持续统计，不能把“接入流水线”直接说成“质量问题全部解决”。

面试官：你怎样定位跨端失败？

每次运行至少记录：代码版本、内容快照、ArtifactBuilder 版本、manifest hash、平台、设备、DS 版本、测试 case 和失败阶段。问题先区分构建失败、安装失败、启动失败、内容加载失败、协议失败和断言失败。

截图只能证明最终画面，不能解释中间链路。自动化还要采集节点树、客户端日志、服务端日志和关键版本握手，才能回答“页面不存在”“节点找不到”还是“业务状态没有到达”。

面试官：你个人负责的边界是什么？

我直接做过 JSON/二进制边界与批量转换接入、ArtifactBuilder 构建和安装稳定性、文件处理器与发布问题、多端构建和 Android 试玩恢复，以及 PixUI DOM、稳定 ID 和基础自动化流水线。完整对象模型、所有平台发布系统和全部测试框架不是我独立实现；我负责的是其中能串起作者数据、工具、宿主和流水线的关键链路。

快速背诵版

UGC2.0 的交付不是把编辑目录直接上传。页面侧先用按域快照、revision 增量和帧内合并控制跨语言状态成本；发布时冻结作者数据，ArtifactBuilder 发现依赖、按处理器转换成带 Schema 的二进制和平台资源，生成 manifest，在隔离目录验证后原子安装或上传。为了可复现，我处理过时间戳、ZIP 顺序、换行符、相对路径、旧文件残留和错误文件混入等确定性问题。多端共享内容身份与语义，允许物理制品不同；自动化则用统一节点协议把 PixUI DOM 和原生 UI 接起来，以稳定业务 ID 驱动客户端与 DS 测试。

责任边界

关联阅读

• UGC2.0 对象模型：Instance、Actor 与 Lua-C++ 边界
• UGC2.0 客户端基建：三 VM、PixUI 与跨语言通信
• UGC 客户端架构白板稿