解读

面试官问“DHE差分更新”并不是想听一句“只下发变化脚本”就结束，而是考察你对HybridCLR热更新链路的整体把控：

1. 差分算法在AOT+Interpreter混合模式下的落地细节；
2. 如何把元数据一致性、方法体地址重映射、资源依赖三件事同时做对；
3. 国内iOS过审、Android多渠道、资源加密、CDN回退策略等工程级坑点是否踩过。
   答得越贴近线上真实版本管理流程，越能体现“资深U3D”价值。

知识点

1. HybridCLR三层结构：AOT主包（il2cpp）+ Interpreter热更dll（Assembly-CSharp-Hotfix.dll）+ 元数据补充（metadata.dat）。
2. DHE（Delta Hotpatch Encoding）：基于函数级IL字节码差分+元数据增量补丁的混合算法，输出最小patch包。
3. 差分键值：以方法体Token+IL哈希为Key，过滤掉AOT已内联或裁剪的方法；对泛型实例化方法使用GINST哈希二次校验，防止IL2CPP裁剪导致的运行时MissingMethodException。
4. 地址重映射：Interpreter模块加载后，通过HybridManager.SetHotfixOffsetMap把热更函数地址注入到AOT跳转表，保证il2cpp与interpreter无缝切换；差分包只含新函数偏移量，不整包覆盖。
5. 元数据对齐：差分包附带metadata.dat.diff，采用Google Courgette思想，对TypeDef、MethodDef、CustomAttribute三张核心表做行级增删，加载时内存原地patch，避免反射缓存重建造成的卡顿。
6. 版本回退：CDN同时保留全量包（full）与差分包（delta），客户端本地记录baseVersion，若patch应用失败（如校验码不匹配），秒级回退拉取全量包，保障灰度发布稳定性。
7. iOS合规：差分包仅含IL字节码，不含任何可执行机器码，符合App Store 3.3.2“不下载脚本改变App行为”条款；同时通过LLVM混淆+IL加密双保险，降低被静态扫描风险。

答案

DHE差分更新是HybridCLR在函数级粒度上做的IL+元数据双差分方案：

1. 打包机对比上一版本hotfix.dll与当前版本hotfix.dll，生成token→IL增量映射表，剔除AOT已内联的方法；
2. 对metadata.dat做行级二进制diff，输出metadata.dat.diff；
3. 客户端启动时，先校验baseVersion与本地patch.info，若命中差分包，则流式解压并原地patch元数据，再通过HybridManager.LoadHotfixAssembly把新IL注入Interpreter；
4. 若差分应用失败（如哈希对不上），自动回退拉取全量hotfix.dll，保证玩家无感知；
5. 整个流程不触碰AOT机器码，iOS审核无虞，且patch体积可压缩到全量的15%以内，90秒完成百万DAU更新。

一句话总结：DHE通过函数级IL差分+元数据增量patch，在HybridCLR的AOT+Interpreter架构下实现最小体积、秒级回退、合规上线的热更新。

拓展思考

1. 泛型爆炸场景下，差分包可能因GINST哈希冲突导致运行时MissingMethodException，可通过预生成AOT泛型引用表+运行时GINST日志回传提前发现。
2. Android渠道包多达200+，若每个渠道都生成差分包，CDN存储翻倍；可引入母包差分+渠道资源分离策略，脚本部分统一差分，资源部分走传统AssetBundle差分，整体带宽节省60%。
3. WebGL平台因无法动态加载dll，HybridCLR官方不支持，但可在CI阶段把热更IL预编译成WASM片段，通过Emscripten dlopen模拟实现**“伪差分”，适合数字孪生**这类强需求场景。