xuanchi/XCEngine
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
b68e5141549b2a2cfab94f045a38194208076e7b
XCEngine/docs/plan/Unity绝区零开发文档还原版.md
ssdfasd e5cb79f3ce chore: sync workspace state
2026-03-29 01:36:53 +08:00

43 KiB
Raw Blame History

Unity《绝区零》开发文档还原版

更新时间：2026-03-26 分析对象：D:\Program Files\ZenlessZoneZero Game 文档性质：基于安装目录、版本清单、日志、元数据字符串和原生插件信息的“开发细节还原”。 方法边界：本文不是源码审计，也不是反编译报告；凡是直接由文件、日志、版本信息证明的内容，标为“可确认”；凡是由多个证据合成出来的工程判断，标为“高概率推断”。

0. 为什么这份文档值得写

只看安装目录，很多人最多能得出“这是个 Unity 游戏”。但《绝区零》这个客户端的目录信息量其实非常大，已经足够暴露出：

  1. 它的引擎基底是哪一代 Unity LTS。
  2. 它是不是 IL2CPP、是不是重度原生插件化。
  3. 它的渲染层是不是 SRP 风格、有没有现代 PC 图形能力栈。
  4. 它是不是靠 Addressables/AssetBundle 直出，还是有独立的内容块分发系统。
  5. 它的资源是不是按业务模块分包，尤其是主线、教程、活动、卡池、视频表现。
  6. 它有没有成熟的内部工具链，例如世界图、镜头序列、预加载配置、棋盘玩法插件、体素相关工具等。
  7. 它的平台层是不是已经和 WebView、SDK、ABTest、翻译热更、遥测、Crash、保护驱动深度耦合。

换句话说，这个目录足够说明它不是“Unity 默认工作流做出来的大包”，而是一套建立在 Unity 之上的产品化工程栈。

1. 执行摘要

先把最重要的结论放前面：

1.1 可确认结论

  1. PC 客户端使用 Unity 2019.4.40 LTS。
  2. 脚本后端是 IL2CPP，不是 Mono。
  3. 客户端重度依赖原生插件，接入了 Wwise、CRI Mana、KCP、WebView/CEF、遥测、Crash、反作弊/保护等多个子系统。
  4. 资源分发不是简单的 Unity Bundle 直发，而是 .blk 块资源 + .usm 视频资源 + .pck 音频资源 + 独立版本清单 的多通道体系。
  5. file_category_launcher 证明客户端把大量视频媒体资源明确映射到业务分类号，说明启动器/内容系统在“剧情页、教程、活动、卡池、登录页、章节视频”等层面做了分包设计。
  6. 元数据中可直接看到 NapResources、ScriptConfig、JsonBytes、WorldGraph、NapCameraSequence、ChessboardPlugin、VoxelArray、MeshStreamingBuildStates 等命名，说明工具链深度很高。

1.2 高概率推断

  1. Windows 版本的主渲染后端大概率是 D3D12 优先，但 Vulkan 代码路径被完整编入并维护。
  2. 项目在 Unity 之上实现了 自定义 SRP 风格渲染管线，而不是纯 Built-in Render Pipeline。
  3. 项目内部存在 ECS 风格运行时框架 或至少采用 ECS 命名和句柄系统，但未必等于 Unity 官方 DOTS。
  4. data_version 很像独立于大资源通道之外的 小型高频热更通道。
  5. 当前启动器显式面向用户或内容侧暴露的“分包单元”主要集中在视频媒体层，而大体量内容层走块资源系统。

2. 调查方法与证据来源

本次还原主要依赖以下几个证据面：

2.1 二进制与根目录结构

根目录存在的关键文件包括：

  • ZenlessZoneZero.exe
  • UnityPlayer.dll
  • GameAssembly.dll
  • nvngx_dlss.dll
  • nvngx_dlssg.dll
  • sl.dlss.dll
  • sl.reflex.dll
  • amd_fidelityfx_upscaler_dx12.dll
  • amd_fidelityfx_framegeneration_dx12.dll
  • telemetry.dll
  • Astrolabe.dll
  • HoYoKProtect.sys
  • mhypbase.dll
  • config.ini
  • version_info
  • file_category_launcher

只看这一层已经可以初步判断：

  1. 这是标准 Unity Windows 原生壳 + IL2CPP 业务层。
  2. 这是面向现代 PC 图形能力的版本，而不是纯移动移植壳。
  3. 平台层明显带有米哈游的完整发行/SDK/安全/运维组件。

2.2 StreamingAssets 与 Persistent 目录

关键目录：

  • ZenlessZoneZero_Data\StreamingAssets
  • ZenlessZoneZero_Data\Persistent
  • ZenlessZoneZero_Data\Persistent\LogDir

这些目录提供了最重要的资源与热更证据。

2.3 IL2CPP 元数据

关键文件：

  • ZenlessZoneZero_Data\il2cpp_data\Metadata\global-metadata.dat

虽然没有源码，但 metadata 中残留了大量：

  • 场景名
  • 资源路径
  • 类型名
  • 配置资产名
  • 内部工具类名
  • 某些运行时系统的符号

这是还原内部工程结构的核心来源之一。

2.4 运行日志

关键目录：

  • ZenlessZoneZero_Data\Persistent\LogDir

日志直接暴露了：

  • 场景切换链路
  • SDK 初始化链路
  • WebView 初始化方式
  • ABTest 地址
  • 多语言翻译热更 URL
  • 部分渲染和运行时开关
  • 资源系统的异常与配置信息

3. 引擎与运行时层

3.1 引擎版本与脚本后端

可确认事实：

  • ZenlessZoneZero.exe 文件版本：2019.4.40.14369230
  • UnityPlayer.dll 文件版本：2019.4.40.14369230
  • 存在 GameAssembly.dll
  • 存在 ZenlessZoneZero_Data\il2cpp_data\Metadata\global-metadata.dat

这说明：

  1. 引擎版本是 Unity 2019.4.40 LTS。
  2. 脚本后端是 IL2CPP。
  3. 项目不是 HotReload/C# Mono 为主的轻量工程，而是完整 AOT 化的大型正式版客户端。

3.2 启动配置

boot.config 中至少可以确认：

  • wait-for-native-debugger=0
  • vr-enabled=0
  • hdr-display-enabled=0
  • single-instance=

这些信息本身不惊人，但结合整个项目体量，它反映的是：

  1. 客户端使用标准 Unity 启动流程，但做了平台化的参数控制。
  2. HDR 至少在当前这份启动配置中没有默认开启。
  3. VR 不是目标运行模式。

3.3 当前版本与渠道

直接来自 config.ini 与 version_info：

  • game_version=2.7.0
  • channel=1
  • sub_channel=1
  • cps=mihoyo
  • version_info = CNPRODWin2.7.0

最稳妥的结论是：

  • 当前安装目录对应 国服 Windows 正式环境 2.7.0。

之前日志痕迹还显示过 2026-03-24 左右从 CNPRODWin2.6.0 升级到 CNPRODWin2.7.0 的过程，因此这份安装目录并不是“首包静态镜像”，而是经历过真实更新链路的客户端。

3.4 基础框架命名

元数据与日志中反复出现：

  • MoleMole.*
  • Foundation.*
  • MiHoYo.SDK.*

这说明 Unity 只是底座，业务层上面还有一层相当厚的内部基础框架。

3.5 场景结构

从 metadata 中可直接提取出的场景：

  • Assets/Scenes/Logic/FrontendGame.unity
  • Assets/Scenes/Logic/Launcher.unity
  • Assets/Scenes/Logic/Real_ECS.unity
  • Assets/Scenes/Login/Login_MainCityWorkshop.unity
  • Assets/Scenes/Scene_Dev/DevLevel.unity

可推断的工程含义：

  1. Launcher 与 FrontendGame 分开，说明启动入口和主要业务逻辑不是单场景一把梭。
  2. Real_ECS 是非常强的内部命名证据，说明存在面向实体系统或 ECS 风格的逻辑分层。
  3. DevLevel 说明正式构建中仍残留研发/验证用场景引用。
  4. Login_MainCityWorkshop 暗示登录链路、主城演出和专门的场景工作流紧密相关。

3.6 是否存在 ECS 风格运行时

当前可确认的证据：

  • 场景名包含 Real_ECS
  • metadata 中出现 EntityHandle
  • metadata 中出现 ListEntityHandle

高概率判断：

  • 项目内存在一套 ECS 风格或实体句柄驱动的运行时框架。

需要谨慎的点：

  • 这不能直接等同为 Unity DOTS/Entities Package。
  • 更可能是米哈游内部的“实体句柄 + 数据驱动系统 + 运行时图”式框架。

4. 渲染与图形后端

4.1 为什么可以判断不是纯 Built-in RP

日志和元数据中能看到以下关键证据：

  • UnityEngine.Rendering.RenderPipelineManager:DoRenderLoop_Internal
  • disableSRPHelper:0
  • disableSRPInstancing:0
  • disableAsyncSRPSubmit:0
  • ShaderCustomData 无效配置路径 ...

如果只是普通 Built-in 渲染项目，这几个特征同时出现的概率很低。它们组合起来，更像：

  1. 项目基于 Unity 的 RenderPipeline 管理链运行。
  2. 团队实现了自己的 SRP 风格辅助层。
  3. Shader 数据和配置路径不是全靠 Unity 默认材质面板，而是有单独配置系统。

4.2 现代图形特性开关

日志中可见：

  • disableRayTracing:0
  • disableMeshLet:0
  • disableAsyncUploadJob:0
  • disableFlatbufferNativeArrayOpt:0
  • disableVKPSOJob:0
  • enablePhyManagerJob:0

这些开关说明的不是“这些功能一定默认打开”，而是：

  1. 这些能力在工程层面被明确纳入了可控项。
  2. 团队在渲染/资源/原生数据层做过较多开关治理。
  3. PC 版至少在架构层已经考虑过 Ray Tracing、MeshLet、异步上传、Vulkan PSO 作业化等问题。

4.3 PC 原生图形能力栈

根目录的原生 DLL 明确显示接入了：

  • NVIDIA DLSS
  • DLSS Frame Generation
  • NVIDIA Reflex
  • NIS
  • AMD FSR / FidelityFX Upscaler
  • AMD Frame Generation
  • AMD AGS

这组 DLL 几乎可以直接说明：

  • 这是一个认真做 PC 高端显示链路适配的版本，而不是随便把移动端资源抬到 PC。

4.4 Vulkan 证据

在 GameAssembly.dll 中可检索到大量 Vulkan 相关字符串，包括 vkCreate* 系列与 PSO/交换链相关内容。再结合日志中出现的 disableVKPSOJob，可得出比较稳的推断：

  • Vulkan 路径被完整编入并维护。

更进一步的工程判断：

  • Windows 正式服的大概率主力图形后端仍是 D3D12，Vulkan 更像兼容、实验或特定平台路径，但不是“没写完的残留代码”。

4.5 对渲染架构的整体推断

高概率架构如下：

  1. Unity 2019 LTS 提供平台与底层渲染承载。
  2. 项目在其上实现自定义 SRP 风格框架。
  3. Shader 管线、预热、配置、特效和材质属性存在独立数据层。
  4. PC 版本在原生层桥接 DLSS/FG/Reflex/FSR 等现代能力。
  5. Vulkan 与 D3D12 两条路径至少在代码层被同时维护。

5. 资源组织、版本清单与热更体系

这是这份安装目录里信息量最大的一层，也是最能体现“工程成熟度”的部分。

5.1 StreamingAssets 顶层结构

ZenlessZoneZero_Data\StreamingAssets 下可见：

  • Blocks
  • Video
  • Audio
  • MiHoYoSDKRes
  • APMConfig.json
  • res_version
  • data_version
  • audio_version
  • res_revision
  • data_revision
  • audio_revision
  • silence_version
  • silence_revision

这套命名非常像独立于 Unity 默认资源系统之外的发行系统。尤其是 *_version 与 *_revision 双文件模式，典型用于：

  1. 比较本地与远端版本。
  2. 决定差量下载。
  3. 区分资源通道。
  4. 支持启动器或游戏内更新器。

5.2 StreamingAssets 实体资源体量

从实际目录统计得到：

类别 数量 体积
Blocks 8276 45.182 GB
Video 1991 13.343 GB
Audio 94 6.705 GB

这一层已经能看出几个非常重要的结论：

  1. 真正的大头不是音频，而是 块资源 + 视频资源。
  2. 视频资源占比极大，这说明项目对视频表现依赖远高于普通 Unity 游戏。
  3. 音频在安装目录内不是全部内容，完整音频清单还要看 audio_version。

5.3 res_version：主资源通道

对 ZenlessZoneZero_Data\StreamingAssets\res_version 的结构化解析结果：

  • 文件数：10246
  • 总体积：58.352 GB
  • 顶层前缀分布：
    • Blocks：8255
    • Video：1991
  • 带 packages 字段的条目数：1991
  • 不带 packages 字段的条目数：8255

这说明：

  1. 主资源清单只维护两类核心资源：Blocks 与 Video。
  2. 当前版本中，所有显式带业务包号的条目正好等于视频条目数。
  3. 块资源没有在这个清单层直接暴露业务包号，而是以内容块形式存在。

这其实非常关键，因为它说明资源系统分成了两层：

  • 一层是“面向分发和业务管理”的视频媒体包。
  • 另一层是“面向运行时加载”的哈希块/内容块系统。

5.4 res_version 的 tag 组合

res_version 中的 tag 组合分布如下：

tag 组合 数量
3 7731
3,5 1905
2 504
2,5 58
1,5 28
1 18
<none> 2

目前还不能精确破译 1/2/3/5 的语义，但可以做比较稳的工程推断：

  1. tag 不是简单的布尔开关，而是资源层级/安装阶段/下载策略的编码。
  2. 视频经常与 5 联动，说明 5 高概率和“视频媒体分发层”或某类可选分包策略有关。
  3. 大多数主资源是 3，说明 3 很可能是当前正式主内容层。
  4. 少量 1 和 2 更像首包/基础包/过渡层，或者历史分层残留。

5.5 data_version：小型数据通道

对 data_version 的解析结果：

  • 文件数：21
  • 总体积：0.173 GB
  • 路径全部位于：Blocks/Data/*.blk

抽样可见条目示例：

  • Blocks/Data/3749079225.blk
  • Blocks/Data/632827999.blk
  • Blocks/Data/2397209110.blk
  • Blocks/Data/297117219.blk
  • Blocks/Data/133733816.blk

以及 tag 组合里同时出现了 1、2、3 和空值。

这层非常像：

  • 独立于大资源通道之外的小体量配置/逻辑/表格数据热更层。

这种拆法的工程意义非常大：

  1. 可以高频更新小量关键数据。
  2. 不需要动 58GB 的主资源清单。
  3. 可以缩短更新链路与校验时间。
  4. 对长线运营版本非常友好。

5.6 audio_version：音频完整包与最小安装包分离

对 audio_version 的解析结果：

  • 文件数：271
  • 总体积：17.426 GB
  • 前缀分布：
    • Audio/Windows/Full：270
    • Audio/Windows/Min：1
  • tag 组合分布：
    • 3,4：270
    • 1,4：1

这几乎可以直接翻译成工程现实：

  1. 音频资源被拆成 完整音频包 与 最小启动音频包。
  2. Minimum.pck 是最小安装音频集。
  3. 大量的正式语音、环境、SFX、流式音频都位于 Full 层。

从目录结构还能看到 Full 下存在语言目录：

  • Cn
  • En
  • Jp
  • Kr

这意味着：

  • 国际化语音不是单独打补丁凑出来的，而是版本体系天然支持的一级资源维度。

5.7 silence_version：存在但当前为空

对 silence_version 解析结果：

  • 文件数：0
  • 总体积：0

这说明“silence”这一通道在当前版本中是预留态或暂未启用态。它可能意味着：

  1. 曾经设计过静默下载/静默资源层。
  2. 该版本没有启用。
  3. 或者仅保留了协议/版本结构，但无实际内容。

5.8 .blk 的工程含义

虽然目前没有真正解开 .blk 内部格式，但从目录结构和清单行为已经能判断：

  1. .blk 不是随意命名的一堆松散文件，而是项目主内容承载格式。
  2. 它大概率用于封装游戏运行时真正的大宗资源。
  3. 它和 Unity 默认 AssetBundle 的“直接暴露路径”风格不同，更像内容块或资源块系统。
  4. 这类设计通常对应更好的：
    • 断点续传
    • 差量校验
    • 合并更新
    • CDN 分发
    • 运行时缓存与淘汰

5.9 Persistent 目录揭示客户端下载后的二次落地

ZenlessZoneZero_Data\Persistent 中可以看到：

  • Blocks
  • Audio
  • Video
  • Bundles
  • LogDir
  • SDKCaches

已知统计结果：

类别 数量 体积
Persistent\Blocks 49 0.241 GB
Persistent\Audio 2 0.053 GB
Persistent\Video 8 0.268 GB
Persistent\Bundles 0 空

这个现象说明：

  1. 客户端确实支持安装后继续获取和缓存资源。
  2. 缓存形态延续了 Blocks/Audio/Video 三通道设计。
  3. Bundles 在当前版本里不是核心载体，至少不是主要的实际补丁落地点。

5.10 为什么说这不是普通 Addressables 项目

能看到 AssetBundle 相关词不代表它就一定以 Unity Addressables 作为主分发层。相反，从当前目录结构看，更强的证据是：

  1. 主清单完全自定义：res_version / data_version / audio_version。
  2. 主格式是 .blk / .usm / .pck，不是直接暴露的 bundle 目录。
  3. Persistent 落地也延续这一结构。
  4. 业务分类文件单独维护：file_category_launcher。

更稳妥的判断是：

  • 项目就算内部某处仍可能使用 AssetBundle，也已经被一层更上位的 自研发行/热更/分包系统 包住了。

6. file_category_launcher 暴露出的业务分包体系

这是本次调查里最有价值的文件之一。它的每一行都把一个具体资源文件映射到一个业务分类号，例如：

  • Launch/CutScene_StandbyVideo.usm -> 30400
  • LoginBangumi/Ad_01_mux.usm -> 30500
  • Battle/TutorialAvatarVideo1011_1.usm -> 31002
  • Gacha/Gacha_Anbi.usm -> 40100

这意味着客户端不是把所有视频混成一个大仓，而是显式把它们挂到业务包上。

6.1 高频分类号统计

当前提取到的高频分类号如下：

分类号 数量
20101 487
20103 156
31002 131
31008 105
30600 89
30800 66
31006 62
20207 53
31003 47
31001 45
72001 38
30200 36
31004 32
10115 28
31007 26
30500 25
40100 24
20102 23
10100 20
30700 20

高频号本身就能说明：

  1. Hollow / Transfer / Tutorial / Activity / Gacha / DailyChallenge 这些系统在视频资源层都有显式分包。
  2. 客户端大量内容是“带业务标签的媒体资源”，而不是统一的大资源堆。
  3. 教学内容资源规模远超一般游戏，说明项目在“系统教学可视化”上投入很大。

6.2 明确可识别的分类号

示例：

  • Video/HD/Launch/CutScene_StandbyVideo.usm
  • Video/HD/Launch/LogoPerform_CHS.usm

这层就是首启或启动页表现资源。

30500：登录电视/广告素材

示例：

  • Video/HD/LoginBangumi/Ad_01_mux.usm
  • Video/HD/LoginBangumi/TV_TurnOff.usm

说明登录页的电视播放内容完全走独立资源包。

20101：Hollow 主体资源

示例：

  • Video/HD/Hollow/Event/General/HollowToBattleBangboo.usm
  • Video/HD/Hollow/AnimFlow/Black_Switch.usm
  • Video/HD/Hollow/Avatar/Chat/EventVideoAnbi_Chat.usm

它不是单一功能点，而是一个很大的 Hollow 相关表现集合。

20102：Hollow 背景包

示例：

  • Video/HD/Hollow/Background/Boss/ChallengeDeadEndButcherBackground.usm
  • Video/HD/Hollow/Background/Metro/MetroBackground.usm

说明 Hollow 的背景表现还被单独拆层。

20103：Transfer / 切换层 / 假加载

示例：

  • Video/HD/Transfer/General/TransferBattleFakeLoading.usm
  • Video/HD/Transfer/General/BattleToHollowLoading.usm
  • Video/HD/Transfer/General/TransferNoiseLoading.usm

这体现出项目把“切换体验”和“加载包装”当成独立表现系统处理。

30200：Inter-Knot / 站内帖子视频

示例：

  • Video/HD/InterKnotPost/InterKnotPostVid_1020.usm
  • Video/HD/InterKnotPost/InterKnotPostVid_11004.usm

这说明“站内内容流/帖子视频”不是脚本临时拼接，而是有独立媒体层。

30600：武器或装备展示视频

示例：

  • Video/HD/Weapon/WeaponSpecialVideo_ZhenZhen.usm
  • Video/HD/Weapon/Weapon_A_1011.usm

这说明装备/武器系统有专门的视频包装资源，不是仅靠模型转台或 UI 动画。

30700：日常挑战/训练房

示例：

  • Video/HD/DailyChallenge/DailyChallengePageBg.usm
  • Video/HD/DailyChallenge/TrainningRoomLayerLoop.usm

说明日常挑战体系具备独立的背景/流程媒体资源。

31001：基础战斗教学

示例：

  • TutorialAidAttack_*
  • TutorialBattleBase.usm
  • TutorialBeHit.usm
  • TutorialCounter.usm
  • TutorialEnemyInformation.usm

说明基础战斗教学不靠文字说明，而是媒体资源驱动。

31002：角色专属教学

示例：

  • TutorialAvatarVideo1011_1.usm
  • TutorialAvatarVideo1031_2.usm
  • TutorialAvatarVideo1521_3.usm

这里数量高达 131，说明很多角色都有自己的动作/机制演示视频。

31003：邦布/特殊玩法教学

示例：

  • Tutorial_BangbooInLevel_1_1.usm
  • ActivityBattle_StylishMode_Banyue_001.usm

31004：棋盘/空洞/特殊规则教学

示例：

  • ChessboardChapter25_Tutorial_1.usm
  • ChessboardGame_Tutorial_1.usm
  • Hollow/TutorialHollowRechallenge.usm

31006：主城/线索/系统教学

示例：

  • TutorialMaincityVideo02.usm
  • LimboClueSystem_Clue.usm
  • LimboClueSystem_SpecialArea.usm

31007：额外教学/修复性内容集合

示例：

  • FishMasterColorBlock_1.usm
  • Hollow/ClassicMovement.usm
  • TutorialDataFix1.usm

31008：活动机制/特殊战斗教学

示例：

  • Activity/MazingerGoldenBomb_Ability_01.usm
  • TutorialEtherBarrier_01.usm
  • Tutorial_ActivityBattle_1.usm

这一组说明活动玩法经常伴随独立教学视频包。

40100：角色卡池展示

示例：

  • Video/HD/Gacha/Gacha_Anbi.usm
  • Video/HD/Gacha/Gacha_Anton.usm
  • Video/HD/Gacha/Gacha_Ben.usm

40300：卡池通用 OP/通用基底

示例：

  • Video/HD/Gacha/Gacha_Bangboo_Default.usm
  • Video/HD/Gacha/Gacha_OP_1.usm
  • Video/HD/Gacha/Gacha_OP_1_Base.usm

说明卡池展示分成“角色个体资源”和“通用演出基底”。

50300：街机/小游戏体系

示例：

  • Video/HD/Arcade/ArcadeScreen/ArcadeCompanionIntro_1.usm
  • Video/HD/Arcade/ArcadeScreen/ArcadeHoundStart.usm
  • Video/HD/Arcade/ArcadeScreen/ArcadeMach25Intro_1.usm

72001：影院活动

示例：

  • Video/HD/ActivityCinema/CinemaFilm_10_Openning.usm
  • Video/HD/ActivityCinema/CinemaFilm_11_Playing.usm

72104：机甲活动

示例：

  • ActivityNewMecha_MoveTutorial1.usm
  • ActivityNewMecha_MoveTutorial8.usm

72106：联机合作活动

示例：

  • Activity/Coop/CoopMatchingBackground_1.usm
  • Activity/Coop/CoopMatchingBackground_10.usm

6.3 主线章节媒体包的强证据

以下分类号和路径对应关系非常明确：

分类号 典型路径 还原结论
30101002 MainStory/PageVideo/Chapter02/* 主线第 2 章页面视频包
30101004 MainStory/PageVideo/Chapter03/* 主线第 3 章页面视频包
30101005 MainStory/PageVideo/Chapter04/* 主线第 4 章页面视频包
30101008 MainStory/PageVideo/Chapter06/* 主线第 6 章页面视频包
30101009 MainStory/PageVideo/Chapter07/* 主线第 7 章页面视频包

这说明媒体资源至少在主线页面层已经按章节分包。它的工程价值包括：

  1. 控制首包体积。
  2. 便于预下载未上线章节媒体。
  3. 允许某章节内容独立更新。
  4. 运营与版本管理更清晰。

6.4 101xx 看起来像“流程章节/过场编号包”

提取到的样本如下：

  • 10100 -> Procedure/C000_*
  • 10105 -> Procedure/C040_*
  • 10106 -> Procedure/C050_*
  • 10110 -> Procedure/C210_*
  • 10111 -> Procedure/C220_*
  • 10112 -> Procedure/C230_*
  • 10113 -> Procedure/C240_*
  • 10114 -> Procedure/C250_*
  • 10115 -> Procedure/C260_*
  • 10117 -> Procedure/C280_*

这说明项目的流程过场视频很可能按内部章节/节点编号系统单独打包。

6.5 这一层最关键的工程判断

file_category_launcher 最重要的意义不在于“知道几个包号”，而在于它证明了：

  1. 启动器或资源系统不是只认文件哈希，它同时认业务语义。
  2. 客户端内容至少在媒体层已经高度产品化，能按玩法、章节、活动、卡池拆分。
  3. 视频表现资源不是附属物，而是主流程中的一等资源。

7. 音频、视频与表现系统

7.1 音频：Wwise 已深入到时间轴/表现层

音频侧有几个强证据：

  • AkSoundEngine.dll
  • AkMotion.dll
  • AkWaapiClient.dll
  • metadata 中出现 MoleMole.Timeline.WwiseAudioTrack
  • 日志中出现 Wwise 生命周期记录

这比“项目用了 Wwise”更进一步。它说明：

  1. 音频被集成到了表现/Timeline 系统里。
  2. 团队可能使用 Wwise 管理大量复杂 BGM、事件、流式音频和演出同步。
  3. Unity Timeline 或其自定义扩展在音频上有专门轨道。

7.2 视频：CRI Mana 不是点缀，而是核心表现依赖

视频侧证据：

  • cri_mana_vpx.dll
  • cri_ware_unity.dll
  • 资源中存在 1991 个 .usm

从文件类别看，视频被用于：

  1. 启动 Logo
  2. 登录页电视/广告
  3. 场景切换和假加载
  4. Hollow 与主城表现
  5. 卡池角色展示
  6. 主线章节页面视频
  7. 街机活动
  8. 联机活动
  9. 角色/机制教学

这说明项目的视频依赖不是边角料，而是 UI 包装、流程演出和玩法教学的重要构成部分。

7.3 表现工具链命名

metadata 中可以看到：

  • NapCameraSequence
  • NapCameraSequenceHandle
  • Assets/NapResources/Data/ScriptConfig/Perform/LevelPerformConfig.asset
  • Assets/NapResources/Data/ScriptConfig/Camera/ConfigFocusCamera.asset
  • Assets/NapResources/Data/ScriptConfig/AnimatorStateLength/ConfigAnimatorStateLength.asset
  • Assets/NapResources/Data/ScriptConfig/Comic/BubbleResources
  • Assets/NapResources/Data/ScriptConfig/Photo/FrameOuter
  • Assets/NapResources/Data/ScriptConfig/Photo/FramePhoto

这说明表现系统至少包含：

  1. 自定义镜头序列。
  2. 关卡表现配置。
  3. 相机聚焦配置。
  4. 动画状态长度或状态时序配置。
  5. 漫画泡泡、摄影框架等特殊 UI/叙事表现资源。

8. SDK、WebView、ABTest、运维与安全层

8.1 WebView/CEF 证据非常扎实

定位到的相关文件：

  • ZenlessZoneZero_Data\Plugins\x86_64\zf_cef.dll
  • ZenlessZoneZero_Data\Plugins\x86_64\ZFGameBrowser.exe
  • ZenlessZoneZero_Data\Plugins\x86_64\ZFEmbedWeb.dll
  • ZenlessZoneZero_Data\Plugins\x86_64\ZFProxyWeb.dll

其中 zf_cef.dll 版本是：

  • 100.0.24+g0783cf8+chromium-100.0.4896.127

这说明客户端带的是一套比较完整的桌面嵌入浏览器栈，而不是随手塞个系统 WebView。

8.2 日志中的 WebView 初始化链

最新日志中可以直接看到：

  • PreLoadSWURL: https://sdk.mihoyo.com/sw.html?...
  • Init with offScreen: False
  • InitUI with offScreen: False
  • mihoyosdk webview created: ...
  • web view render method: box config use optimization! request ab
  • read ab test config from combo config
  • read webview render method scene: MiHoYo.SDK.WebViewRenderMethodScene
  • Get ABTest: plat - https://data-abtest-api.mihoyo.com/...

这几行直接暴露出：

  1. SDK WebView 不是固定策略，而是可走 ABTest 分流。
  2. WebView 的渲染方式可以由服务端配置决定。
  3. WebView 和 Native UI 栈之间存在完整事件交互。

8.3 多语言翻译热更

日志中还能看到：

  • Request to set language:zh-cn
  • Update region translation resources:zh-cn
  • regionTranslationVersionCheck URL:https://webstatic.mihoyo.com/admin/mi18n/...-version.json

这说明：

  1. 本地语言资源之外，还有在线翻译资源更新链。
  2. 多语言文本并非完全固化在客户端包内。
  3. 运营层可以对区域文本进行版本化更新。

8.4 遥测与 Crash 体系

日志与文件显示存在：

  • telemetry.dll
  • APMCrashReporter
  • MiHoYoSDKUploader.dll
  • TelemetryInterface path:...\SDKCaches
  • InitCrashSDKConfig

这基本可以判断：

  1. 客户端具备成熟的异常与性能/行为上报链路。
  2. SDKCaches 不只是 SDK 静态文件目录，还是部分运行时缓存和上报链路落地点。
  3. 客户端是围绕长线在线运营构建的，不是离线单机式打包。

8.5 安全与保护层

根目录存在：

  • HoYoKProtect.sys
  • mhypbase.dll
  • Astrolabe.dll

这说明正式版客户端带有较明确的保护/反作弊/底层守护组件。对工程层的意义是：

  1. 引擎层与平台层不是纯用户态逻辑。
  2. 正式发行链路包含安全侧部署。
  3. 构建和安装流程考虑过驱动/保护组件的分发。

9. 内部工具链与数据驱动架构

这是最能说明“这不是普通 Unity 项目”的部分。

9.1 NapResources：统一资源命名空间

metadata 中反复出现 Assets/NapResources/...。这说明：

  1. 团队维护了一套统一的资源命名空间，而不是让资源散落在各个场景和 prefab 里。
  2. 很多系统都围绕 NapResources 组织，说明它更像项目级资源根，而不是临时目录。
  3. 命名上 nap 与 nap_cn、日志中的 bundle_id=nap_cn 彼此呼应，说明这不是无关命名。

9.2 ScriptConfig 根目录样本

从 metadata 中提取到的 ScriptConfig 根包括：

  • Activity/ActivityLiveHouse
  • Activity/ConfigHotPotFoodAssets.asset
  • Activity/ConfigHotPotForceFields.asset
  • AnimatorStateLength/ConfigAnimatorStateLength.asset
  • AttackPropertys/AttackPropertyLibrary.asset
  • Audio/BasePaths
  • Camera/ConfigFocusCamera.asset
  • Camera/Library
  • Camera/Photo
  • Camera/PhotoWall
  • Comic/BubbleResources
  • Comic/ImgStyle
  • EtherEyes/ConfigEtherEyes.asset
  • Level/LevelAddonConfig.asset
  • LevelNpcGroupData/BladeIllusionNPCDisplayConfig.asset
  • MaterialPropertyModifier/AutoGen
  • Perform/LevelPerformConfig.asset
  • Preload/PreloadLevelConfig.asset
  • Preload/PreloadUIAssetsConfig.asset
  • PreloadConfig/PreloadStreamingGameConfig.asset
  • Preload/ShaderVariantCollection-
  • ScreenEffects/AutoGen
  • ShaderCustom/
  • UI/ConfigUIActivityRhythmClick.asset
  • UI/ConfigUIUrbanMap.asset

这几乎把项目的工程气质说透了：

  1. 活动不是脚本散件，而是有独立配置资产。
  2. 相机、摄影、漫画泡泡、音频路径、材质属性修改、屏幕特效都经过工具化配置。
  3. AutoGen 目录表明不少配置是自动生成的，而不是纯手工维护。
  4. Preload* 与 ShaderVariantCollection 显示预加载和 Shader 变体治理已经进入正式管线。

9.3 JsonBytes 根目录样本

从 metadata 中提取到的 JsonBytes 根包括：

  • ArcadeGame/Cp
  • AreaData
  • ChessboardPlugin
  • HollowEntity
  • LevelWorld
  • NewAbility

这说明项目存在明确的“编辑器数据 -> 字节化运行时数据”路径。其工程含义：

  1. 运行时不会只依赖 Unity 原生反射式序列化。
  2. 很多系统用的是更轻、更可控的数据载入路径。
  3. Hollow、能力系统、关卡世界、棋盘玩法等核心模块都被放进了这一层。

9.4 MessagePack 的直接证据

metadata 中直接出现：

  • MessagePack.Resolvers.DynamicUnionResolver
  • MessagePack.Resolvers.DynamicContractlessObjectResolver
  • MessagePack.Resolvers.DynamicEnumResolver
  • MessagePack.Resolvers.DynamicObjectResolver

这几乎可以确认：

  • 项目在运行时或工具链的某一层明确使用了 MessagePack。

这和 JsonBytes、EntityHandle、WorldGraph 放在一起，很像典型的大项目数据链：

  1. 编辑器阶段维护结构化对象。
  2. 构建阶段导出字节化数据。
  3. 运行时以句柄、图结构、表结构快速加载。

9.5 世界/流程/玩法工具链痕迹

metadata 中能够看到的一些极有信息量的名字：

  • WorldGraph
  • Assets/NapResources/Data/WorldGraph/Bytes
  • node_config.bytes
  • ChessboardPlugin
  • ChessboardPluginInnerWorldConverter
  • VoxelArray
  • Assets/Code/Logic/Data/ScriptObject/Stage/MonoZone3D/Terrain/VoxelArray/UpdateVoxelArrayForOverlay.compute
  • Assets/Code/Logic/Data/ScriptObject/Stage/MonoZone3D/Terrain/VoxelArray/VoxelArrayForOverlayDebugDisplay.mat

这几条证据背后的工程信息非常多：

  1. WorldGraph 表明世界/流程/节点关系很可能不是硬编码，而是图配置驱动。
  2. node_config.bytes 说明图配置会烘焙成运行时字节数据。
  3. ChessboardPlugin 说明棋盘/网格玩法不是零散逻辑，而是插件化模块。
  4. ChessboardPluginInnerWorldConverter 暗示棋盘玩法与关卡真实世界之间有转换层。
  5. VoxelArray 与相关 compute/material 名称说明至少存在某类基于体素或覆盖层的空间数据处理与可视化手段。

9.6 预加载、Shader 变体与 Mesh Streaming

metadata 中还可以直接看到：

  • PreloadStreamingGameConfig
  • PreloadUIAssetsConfig
  • PreloadLevelConfig.asset
  • ShaderVariantCollection
  • MeshStreamingBuildStates
  • Assets/Editor Default Resources/MeshStreamingBuildStates
  • MeshStreamingRoot

这说明项目已经把以下问题工具化处理：

  1. 游戏流式预加载。
  2. UI 资源预加载。
  3. Shader 变体收集和预热。
  4. Mesh Streaming 的构建状态管理。

这一点非常重要，因为很多 Unity 项目到后期才会被这些问题反噬，而《绝区零》从安装目录上看已经把它们纳入正式流程。

9.7 镜头、表现与关卡表现配置

直接证据包括：

  • NapCameraSequence
  • NapCameraSequenceHandle
  • LevelPerformConfig.asset
  • ConfigFocusCamera.asset

这说明：

  1. 镜头系统不是零碎 Timeline 片段堆出来的，而是存在独立序列抽象。
  2. 关卡表现可能通过配置驱动，而不是仅靠场景对象硬连。
  3. 镜头和关卡表现有机会在构建阶段被烘焙、索引和统一管理。

9.8 Redmoon 痕迹

metadata 中能看到：

  • Redmoon_Android_Source
  • Redmoon_IOS_Source
  • Redmoon_Android_NetRes
  • Redmoon_IOS_NetRes
  • Redmoon_Android_Preload
  • Redmoon_IOS_Preload
  • __RedmoonCoroutines__
  • __RedmoonGlobals__

当前不能精确确认 Redmoon 是什么，但比较稳的判断是：

  1. 它与跨平台资源构建、预加载或网络资源体系相关。
  2. 它不是 PC 独占的临时名，而是面向 Android/iOS 的通用构建概念。
  3. 这再次说明整个项目是多平台共享大部分工具链的工程，而不是 PC 版临时分支。

10. 从这些痕迹反推研发组织方式

虽然目录不会直接写“团队怎么分工”，但它会留下很明显的工程组织痕迹。

10.1 图形/引擎侧

能推断至少有人持续负责：

  • 渲染管线维护
  • SRP 相关系统
  • 原生图形能力接入
  • D3D12/Vulkan 路径维护
  • PSO/Shader/Mesh Streaming/预加载等性能议题

10.2 资源与构建侧

能推断至少有人持续负责：

  • 块资源打包与校验
  • 视频资源与业务分包映射
  • 音频语言包与最小包策略
  • 版本清单生成
  • Revision/version 体系
  • Persistent 落地与更新器行为

10.3 工具链侧

能推断至少有人持续负责：

  • ScriptConfig 资产规范
  • JsonBytes/MessagePack 导出
  • 世界图/棋盘插件/能力系统配置导出
  • 预加载配置和 Mesh Streaming 构建状态
  • 相机与表现系统工具

10.4 平台与运营侧

能推断至少有人持续负责：

  • SDK 接入
  • WebView 与 Native UI 栈
  • ABTest 平台对接
  • 文本翻译热更
  • Telemetry/Crash 链路
  • 安全/保护组件集成

换句话说，这个客户端从目录侧看，是一支分工比较清晰的大型团队产物，而不是少量程序维护的 Unity 项目。

11. 结合日志还原一次运行链路

最新日志片段可以串出一条很像正式版真实运行流程的链：

  1. Startup RegisterInputSystem.
  2. HTTP interceptors initialized
  3. CreateMainCityClientServerManager.OnCreate
  4. 语言与地域翻译资源初始化。
  5. LoadSceneGame
  6. loaded addtiveScene
  7. Load scene finish
  8. OnAllLoadingFadeOut
  9. EnterScene
  10. SceneSwitch ... 完成切换
  11. SDKInit
  12. Set Game Version: CNPRODWin2.7.0
  13. InitSDK Success
  14. PreLoadSWURL: https://sdk.mihoyo.com/sw.html?...
  15. mihoyosdk webview created
  16. 读取 WebView ABTest 配置。

这说明客户端启动顺序大概是：

  1. 引擎和输入系统起起来。
  2. 网络拦截器与客户端管理器先初始化。
  3. 场景切换到主流程。
  4. 之后再完成 SDK 与 WebView 链路。

这里特别值得注意的是：

  • CreateMainCityClientServerManager.OnCreate

这条日志说明“主城客户端-服务端管理器”这种概念在架构上是显式存在的。换句话说，主城逻辑并不是简单本地场景，而是带有明确联机/协议/状态管理边界的系统。

12. 目前最值得相信的总体开发画像

综合全部证据，我对《绝区零》开发形态的还原如下：

12.1 引擎画像

  • Unity 2019 LTS 作为底座。
  • IL2CPP 作为正式版运行时。
  • 上层存在重度自研基础框架。

12.2 渲染画像

  • 自定义 SRP 风格渲染框架。
  • PC 原生高端特性接入完整。
  • D3D12 很可能是主后端，Vulkan 被完整保留。

12.3 资源画像

  • 主资源走块化分发。
  • 视频是业务分包核心资源。
  • 音频有最小包和完整包。
  • 存在小体量独立数据热更通道。

12.4 工具链画像

  • 强配置驱动。
  • 强字节化数据导出。
  • 世界图、棋盘玩法、镜头序列、体素/覆盖层、预加载、Mesh Streaming 等都有工具化痕迹。

12.5 运营画像

  • SDK、WebView、ABTest、翻译热更、遥测、Crash、保护都深度集成。
  • 明显是长线在线运营产品，而不是一次性交付的客户端。

13. 还不能下死结论的部分

下面这些点我认为目前还不能写成铁事实：

  1. Real_ECS 是否对应完整 ECS Runtime，还是内部一套混合架构场景名。
  2. .blk 内部是否封装 Unity AssetBundle、定制归档、压缩块索引，还是多种资源混合容器。
  3. res_version/audio_version 中 tag 1/2/3/4/5 的精确定义。
  4. Redmoon 的确切职责边界。
  5. Vulkan 在 Windows 正式服中的启用策略。

14. 下一步继续深挖应该怎么做

如果继续往下做，我建议按以下顺序：

14.1 最高优先级：解 .blk

这是整个资源系统最关键的黑箱。只要把 .blk 文件头、索引、压缩方式、内容类型摸清，就能把：

  • 资源粒度
  • 依赖组织
  • 是否有 bundle 内嵌
  • 更新策略
  • 缓存策略

大幅说透。

14.2 第二优先级：把分类号表彻底补完

当前已经识别出大量分类号，但还可以继续做成完整索引，尤其是：

  • 主线章节包全表
  • 各活动包全表
  • 各系统教学包全表
  • 各卡池通用与角色专属媒体表

14.3 第三优先级：继续抽日志和 metadata

重点继续找：

  • SRP 初始化链
  • ShaderCustomData 的实际配置路径
  • Vulkan/D3D12 选择逻辑
  • KCP/网络管理器更多细节
  • Hollow / WorldGraph / LevelWorld / NewAbility 的更多类型名

14.4 第四优先级：针对 Persistent 做版本前后对比

如果能抓到一次完整更新前后 Persistent 的变化，就能更准确地反推：

  • 哪些资源是首包内置
  • 哪些资源是首次进入某系统才下载
  • 哪些资源是活动时再拉取
  • 哪些资源会被清理或覆盖

15. 最终结论

如果只从安装目录出发，我对《绝区零》开发形态的最终判断是：

  • 它是一个建立在 Unity 2019 LTS 之上的、重度工程化的大型在线游戏客户端。
  • Unity 在这里主要提供平台底座和基础生产力，而不是全部开发方式。
  • 真正决定它产品形态的，是叠在 Unity 上面的那一层：
    • 自定义渲染与图形接入
    • 自定义资源分发与版本系统
    • 强配置、强字节化的数据管线
    • 丰富的视频表现资源体系
    • SDK/WebView/ABTest/遥测/安全等长线运营基础设施

如果让我用一句话概括这次调查结果：

《绝区零》不是“用 Unity 做出来的一个游戏”，而是“用 Unity 作为底座承载的一整套产品化引擎栈”。

16. 附录：本轮调查中最关键的直接证据索引

为方便后续继续深挖，先把最关键的直接证据列在这里：

16.1 版本与引擎

  • ZenlessZoneZero.exe -> 2019.4.40.14369230
  • UnityPlayer.dll -> 2019.4.40.14369230
  • config.ini -> game_version=2.7.0
  • version_info -> CNPRODWin2.7.0

16.2 WebView/中间件

  • zf_cef.dll -> 100.0.24+g0783cf8+chromium-100.0.4896.127
  • ZFGameBrowser.exe
  • ZFEmbedWeb.dll
  • ZFProxyWeb.dll
  • AkSoundEngine.dll
  • cri_ware_unity.dll
  • kcp.dll

16.3 场景与工具链

  • Assets/Scenes/Logic/FrontendGame.unity
  • Assets/Scenes/Logic/Launcher.unity
  • Assets/Scenes/Logic/Real_ECS.unity
  • Assets/Scenes/Login/Login_MainCityWorkshop.unity
  • Assets/Scenes/Scene_Dev/DevLevel.unity
  • Assets/NapResources/Data/ScriptConfig/...
  • Assets/NapResources/Data/JsonBytes/...
  • WorldGraph
  • NapCameraSequence
  • ChessboardPlugin
  • VoxelArray
  • MeshStreamingBuildStates
  • PreloadStreamingGameConfig
  • PreloadUIAssetsConfig

16.4 资源与版本系统

  • ZenlessZoneZero_Data\StreamingAssets\res_version
  • ZenlessZoneZero_Data\StreamingAssets\data_version
  • ZenlessZoneZero_Data\StreamingAssets\audio_version
  • file_category_launcher
  • ZenlessZoneZero_Data\Persistent\Blocks
  • ZenlessZoneZero_Data\Persistent\Audio
  • ZenlessZoneZero_Data\Persistent\Video

16.5 关键日志线索

  • CreateMainCityClientServerManager.OnCreate
  • LoadSceneGame
  • SceneSwitch 完成切换
  • SDKInit
  • InitSDK Success
  • PreLoadSWURL: https://sdk.mihoyo.com/sw.html?...
  • Get ABTest: plat - https://data-abtest-api.mihoyo.com/...
  • regionTranslationVersionCheck URL:https://webstatic.mihoyo.com/admin/mi18n/...

17. 继续深挖：.blk 文件头的新增发现

这是在文档主体写完之后继续向下钻出来的新证据，价值很高。

17.1 .blk 不是裸 UnityFS

我直接读取了两个 .blk 的前 96 个字节：

  • ZenlessZoneZero_Data\StreamingAssets\Blocks\1000337454.blk
  • ZenlessZoneZero_Data\StreamingAssets\Blocks\Data\3749079225.blk

两者的共同特征都是：

  • 文件头前 4 字节为 6D 68 79 31
  • 对应 ASCII 即：mhy1

这说明：

  • .blk 至少在容器头层不是裸露的 Unity 资源格式，而是 米哈游自定义的 mhy1 容器头。

这条证据非常关键，因为它把判断从“像自定义块格式”推进到了“文件头层面已经确认是自定义容器”。

17.2 主内容块里能看到 Unity 资源痕迹，但被包在 mhy1 容器里

对主内容块快速做可打印字符串扫描时，可以看到：

  • archive:/CAB-85ea42baeef21686dd408a87d00e9877.res
  • archive:/CAB-b6525d3ab1c368cdf59db6b227027457.res
  • archive:/CAB-48c29ccf0721f09a645bfcc0401e0446.res
  • 1437729915099733045.bund

这里的 CAB-... 形式非常像 Unity 资源系统内部常见的 archive / CAB 命名痕迹。这带来一个更精细的判断：

  1. .blk 外层不是 UnityFS。
  2. 但 .blk 内部很可能封装了 Unity 资源对象、Unity archive，或者与 Unity bundle 体系相邻的资源块。
  3. 换句话说，.blk 更像“米哈游自定义外层容器 + Unity 资源载荷”，而不是完全脱离 Unity 资源生态的全新格式。

17.3 data_version 对应的数据块表现不同

对 Blocks\Data\3749079225.blk 做同类扫描时：

  • 同样有 mhy1 文件头。
  • 但没有快速扫到明显的 UnityFS 或 CAB- 字样。

这意味着两种可能：

  1. Blocks/Data 通道里的负载和主内容块不同，可能更偏配置/表数据/序列化数据。
  2. Blocks/Data 使用了不同的压缩、加密或布局方式，导致字符串特征更少。

这和前面基于 data_version 得出的判断是相互印证的：

  • Blocks/Data 很可能确实不是普通美术资源大块，而是更偏轻量逻辑数据通道。

17.4 现阶段关于 .blk 最稳妥的结论

截至目前，我认为最稳妥的描述是：

  • .blk 是 带 mhy1 文件头的自定义内容块容器。
  • 主内容块内部至少包含与 Unity archive / CAB 命名体系相关的资源载荷。
  • Blocks 与 Blocks/Data 很可能共用同一外层容器协议，但内部负载类型不完全相同。

这比“可能是自定义块格式”更进一步，已经接近可以围绕文件头和偏移去继续逆向解析了。

Reference in New Issue View Git Blame Copy Permalink