解读

国内Unity项目面试问“补丁策略”时，面试官真正想听的是：你能否在包体大小、下载时长、CDN费用、回滚风险之间做权衡，并给出可落地的工程方案。Chunk Based与File Based是热更新（Lua/ILRuntime/Addressable）必须二选一的底层策略，答不出差异=直接暴露“没做过线上版本”。

知识点

1. File Based：以单个文件为最小粒度，对比新旧文件MD5，差分后生成*.zip/*.7z补丁包。
2. Chunk Based：把文件按固定或可配置块大小（常见64 KB～256 KB）切分，对比块级哈希，只下发变更块；Unity Addressable的Catalog+Content Archive模式即属此类。
3. 国内CDN计费方式：按流量+请求次数双重计费，File Based在文件数多时会拉高请求数，Chunk Based在块大小过小时会拉高请求数。
4. 断点续传：File Based需自己维护多文件断点状态，Chunk Based天然支持块级断点，弱网场景更稳。
5. 回滚策略：File Based直接替换整包即可回滚；Chunk Based需保留基线版本块池，否则回滚需重新拉取旧块。
6. 资源冗余：File Based容易出现**“只改1字节却整包重下”；Chunk Based只重下变更块，但块索引表会引入5%～8%额外头部开销**。
7. 加密与校验：File Based可对整文件AES加密；Chunk Based需逐块加密+HMAC，否则中间人可替换单块。
8. 国内合规：iOS渠道若使用企业证书OTA，File Based整包>150 MB容易被苹果限流；Chunk Based可把首包压到80 MB以内，后续块按需下载，过审更稳。

答案

“我们在上线项目中把两种策略混合使用：
首包资源采用File Based，直接整包下载，减少首次块索引解析带来的卡顿；
后续热更切换到Chunk Based，把Addressable的AssetBundle按128 KB切块，利用XXHash64做块级校验，CDN只推送差异块。
这样首包可控在版号审核要求的100 MB以内，日常更新平均下载量下降62%，同时单块失败只需重拉128 KB，弱网1%丢包场景下更新成功率从87%提升到98.7%。
回滚时，我们在CDN保留最近3个全量块池快照，通过版本号+块索引即可在5分钟内完成全服回滚，满足国内渠道**“4小时内必须可回退”**的合规要求。”

拓展思考

1. 如果项目资源量级达到30 GB+（开放世界），可引入Rolling Hash做可变长Chunk，进一步压缩差分率，但需权衡CPU占用。
2. 国内安卓渠道强制**“双包体”**（32/64位），可把so库单独拆Chunk，玩家只下载对应架构块，节省15%～20%流量。
3. 微信小游戏平台禁止文件级热更，可把Chunk编码成Base64切片后走WX.FileSystemManager.writeFile，实现**“块级缓存”**绕开限制。