1. 热更新链路到底在解决什么问题做过Unity手游的兄弟都清楚包体大小和版本迭代速度是一对天生的冤家。玩家在应用商店下载一个几百兆甚至上G的安装包每次改个活动配置、修个UI贴图、调个数值表都要重新走一遍渠道审核短则一天长则一周运营节奏根本扛不住。热更新这套机制就是为了打破这个僵局把可以动态替换的资源从主包里剥离出来运行时按需从远端拉取本地缓存命中就直接用没命中就下载后落盘。整条链路串起来就是打包 → 上传CDN → 客户端请求清单 → 比对版本 → 下载差异资源 → 写入本地缓存 → 加载生效。听起来很顺但真正上线之后你会发现问题几乎全出在“安全排查”这四个字上。CDN上的清单被人篡改过怎么办本地缓存被玩家手动替换成魔改资源怎么办下载到一半断网导致缓存文件损坏下次启动直接白屏怎么办这些都不是危言耸听我在实际项目里全都遇到过。所以这篇内容不是教你从零搭一套热更新框架而是聚焦在链路已经跑通之后怎么把CDN清单和本地缓存这两个关键节点排查干净让线上事故率降下来。适合谁看如果你已经用Unity做过至少一个上线项目对AssetBundle的打包和加载有基本概念但热更新上线后总出一些“偶发”“复现不了”的诡异问题那这篇就是写给你的。我会把清单校验、缓存完整性、版本回滚、异常兜底这些环节拆开讲每个点都配上我踩过的坑和实际验证过的处理方式。全程不聊虚的只讲能直接抄作业的操作。2. 整体方案设计与安全边界拆解2.1 为什么安全排查要分“清单”和“缓存”两层很多人做热更新注意力全放在“怎么下载快”“怎么压缩小”上安全校验往往是最后才补的。但从攻击面和故障面来看CDN清单是入口本地缓存是落脚点这两层任何一层出问题整个热更新链路就废了。CDN清单本质上是一个描述文件通常包含资源名、哈希值、文件大小、版本号、依赖关系。客户端启动时第一件事就是拉这个清单然后拿它跟本地已缓存的版本做比对。如果清单本身被篡改——比如有人通过某些手段替换了CDN上的文件把某个AssetBundle的哈希改成恶意资源的哈希——客户端会毫无防备地下载并加载被替换的内容。这不是理论风险早期很多项目清单就是明文JSON直接扔在CDN上连个签名都没有。本地缓存则是另一个战场。玩家设备上的缓存目录在Android上如果放在外部存储root过的机器或者某些文件管理器就能直接改。我见过玩家把角色皮肤贴图换成自定义图片的也见过因为缓存写入中断导致文件半截、加载时报CRC错误的。所以缓存层要解决的是完整性和防篡改两个问题前者保稳定后者保安全。2.2 清单校验的三种方案与选型逻辑清单校验我实际用过三种方案各有适用场景直接上对比表方案实现方式安全性性能开销适用场景明文JSON直接读取无校验极低几乎为零内网测试、单机Demo哈希校验清单内附带自身哈希或单独存放哈希文件中低一次哈希计算中小型项目、对安全要求一般签名校验用非对称加密对清单签名客户端用公钥验签高中验签耗时约几毫秒到几十毫秒正式上线项目、有对抗需求选型逻辑很简单看你的项目有没有被针对性攻击的价值。休闲小游戏用哈希校验足够了大型MMO或者有交易系统的项目签名校验是底线。我现在的习惯是哪怕项目不大也至少上哈希校验因为实现成本真的很低但能挡掉绝大多数“缓存文件损坏”类的低级问题。哈希校验的具体做法是打包时对清单文件本身计算一次SHA256把这个哈希值写到一个单独的.hash文件里或者直接硬编码在客户端的一个常量里。客户端拉取清单后先算哈希再比对不一致就直接拒绝使用走兜底逻辑。这里有个细节哈希值不要跟清单放在同一个CDN目录下否则被一锅端的风险还是存在。我一般会把哈希值放在客户端代码里或者通过另一个独立接口下发。2.3 本地缓存的目录结构与命名策略缓存目录的设计直接影响排查效率。我见过有的项目把所有AssetBundle平铺在一个文件夹里几千个文件堆在一起出问题了根本不知道哪个是哪个。合理的做法是按版本号资源类型分目录比如/Cache/ /1.2.3/ /ui/ login.ab main.ab /character/ hero_001.ab manifest.hash /1.2.4/ ...这样设计的好处是版本回滚时直接切目录不用逐个文件删排查时也能快速定位到某个版本的某类资源。命名上我建议保留原始AssetBundle的名字不要做额外映射否则日志里报错的名字和实际文件名对不上查起来很痛苦。还有一个关键点缓存目录要放在应用私有空间。Android上用Application.persistentDataPathiOS上用Application.temporaryCachePath或沙盒内的Documents目录。不要图方便放外部存储否则被篡改的概率会大幅上升。如果确实需要放外部存储比如某些渠道要求那至少要对每个缓存文件做完整性校验加载前先验哈希。3. 核心细节解析与实操要点3.1 清单文件的结构设计与字段含义一个健壮的清单文件字段设计要能支撑校验、比对、回滚三个动作。我常用的结构是这样的以JSON为例{ version: 1.2.4, timestamp: 1699999999, hash: a1b2c3d4..., assets: [ { name: ui/login.ab, hash: e5f6g7h8..., size: 102400, deps: [ui/common.ab], crc: 123456789 } ] }逐字段说明version是整包版本号用于快速比对timestamp是打包时间排查时能确认清单是不是最新的hash是清单自身的哈希用于自校验assets数组里每个资源都有自己的hash、size、deps和crc。deps字段特别重要AssetBundle的依赖关系如果处理不好会出现“资源加载了但贴图丢失”的问题排查时优先看这个字段有没有漏。crc是Unity在打包时可以生成的校验值加载时Unity自己会校验但前提是你打包时开启了Append Hash to AssetBundle Name或者手动记录了CRC。我建议两个都做清单里记一份加载时用AssetBundle.LoadFromFile的CRC参数再校验一次双保险。3.2 哈希算法选择与计算时机哈希算法我统一用SHA256不用MD5。原因很简单MD5已经被证明存在碰撞攻击的可能虽然实际项目中遇到刻意碰撞的概率极低但既然SHA256的计算开销在现代设备上完全可以接受没必要省那一点性能。实测在骁龙660级别的机器上对一个1MB的文件算SHA256大约耗时3到5毫秒一个清单文件通常也就几十KB开销可以忽略。计算时机有两个打包时和加载前。打包时计算是为了写入清单加载前计算是为了校验缓存文件有没有损坏。加载前的校验我建议只对关键资源做比如配置表、核心UI、角色模型不要对所有资源都做否则加载时间会明显变长。判断标准是这个资源如果被篡改或损坏会不会导致游戏无法正常运行或者产生不公平的优势。会就校验不会就跳过。注意计算哈希时要用流式读取不要一次性把整个文件读进内存。大文件比如几十MB的场景AssetBundle一次性读取容易触发GC峰值在低端机上直接卡顿甚至OOM。3.3 缓存写入的原子性操作缓存写入最怕的就是“写了一半”。玩家下载到90%的时候切后台、断网、杀进程下次启动时这个半截文件如果被当成完整文件加载轻则报错重则白屏。解决办法是先写临时文件写完再重命名。具体流程下载时写入xxx.ab.tmp下载完成后校验哈希校验通过再把.tmp重命名为xxx.ab。这样即使中途中断下次启动时看到的只有.tmp文件直接删掉重新下载即可不会污染正式缓存。重命名操作在同一个文件系统内是原子性的不用担心重命名到一半又断了。这个逻辑听起来简单但我见过至少三个项目没做结果线上频繁出现“资源加载失败”的客诉查了半天才发现是缓存文件不完整。加上这个机制之后这类问题基本归零。3.4 版本比对与差异下载的策略版本比对不是简单地比版本号大小而是要比每个资源的哈希。因为有时候版本号没变但某个资源被重新打包了比如修了个贴图这时候如果只比版本号客户端不会更新玩家看到的还是旧资源。我的做法是客户端本地维护一份“已缓存资源清单”记录每个资源的名字和哈希。启动时拉取远端清单逐个比对哈希不一致的就加入下载队列。这样即使版本号相同只要有资源变了也能正确更新。差异下载的并发数要控制。我试过同时开10个下载线程在低端机上直接把网络模块打满导致其他请求超时。后来改成最多3个并发配合一个下载队列稳定很多。下载失败的资源要记录重试次数超过3次就跳过并上报不要无限重试卡住启动流程。4. 实操过程与核心环节实现4.1 打包阶段的清单生成与签名打包脚本我一般用C#写一个Editor工具在BuildPipeline.BuildAssetBundles之后执行。核心步骤遍历所有生成的AssetBundle文件逐个计算SHA256和文件大小。读取每个AssetBundle的依赖关系Unity提供了AssetDatabase.GetAssetBundleDependencies但打包后要用AssetBundleManifest来获取。组装成JSON结构写入manifest.json。对manifest.json本身计算SHA256写入manifest.hash。如果启用签名用私钥对manifest.json的内容签名签名结果写入manifest.sig。签名这块我用的是RSA-2048私钥只存在于打包机上公钥硬编码在客户端。验签时用公钥解密签名比对内容哈希。虽然RSA验签比纯哈希慢一些但清单文件小实测在移动端也就10到20毫秒完全可以接受。提示私钥文件千万不要提交到版本控制系统。我一般放在打包机的独立目录通过环境变量读取路径CI脚本里也不打印私钥内容。4.2 客户端启动时的清单拉取与校验流程客户端启动时的流程我拆成六步每一步都有失败兜底检查网络无网络时直接用本地缓存启动跳过更新。拉取远端清单带超时我设的是5秒超时则用本地缓存。校验清单哈希比对manifest.hash不一致则拒绝使用走本地缓存。验签如果启用用公钥验签失败则拒绝使用。比对资源哈希生成本地缓存清单与远端清单逐个比对。执行差异下载按队列下载完成后更新本地缓存清单。这里有个细节第3步和第4步的失败处理要区分。哈希不一致可能是CDN同步延迟或者文件损坏可以重试一次验签失败则大概率是被篡改直接拒绝并上报不要重试。我在实际项目里就遇到过CDN节点同步不及时导致哈希对不上的情况重试一次就正常了。4.3 本地缓存的读写与完整性校验本地缓存的读写我封装了一个CacheManager类核心方法就三个Read、Write、Verify。Write方法负责原子写入前面讲过的临时文件加重命名。Read方法在读取前先调Verify校验哈希和CRC。Verify的实现要注意不要每次都重新算哈希那样太慢。我的做法是维护一个内存字典记录本次启动已经校验过的资源避免重复计算。对于特别大的资源比如超过50MB的场景包我建议跳过启动时的哈希校验改为加载时由Unity的CRC校验兜底。因为启动时算一个大文件的SHA256可能要几百毫秒玩家会感觉到明显的卡顿。Unity的AssetBundle.LoadFromFile自带CRC校验虽然算法不同但同样能发现文件损坏。4.4 断点续传与失败重试的实现断点续传对热更新体验影响很大尤其是大版本更新时。实现方式是下载时记录已下载的字节数下次从断点继续。但这里有个坑如果远端文件变了断点续传会拼出一个错误的文件。所以断点续传的前提是远端文件的哈希没变每次续传前要先比对哈希。失败重试我设的是最多3次每次间隔递增1秒、3秒、5秒。超过3次就标记该资源为“下载失败”跳过并继续下载其他资源。启动完成后如果有失败资源弹一个提示让玩家手动重试而不是卡在启动界面。这个体验上的小改动能减少很多客诉。5. 常见问题与排查技巧实录5.1 清单拉取成功但资源加载失败这是最常见的问题表现是清单能拉到版本也比对成功了但加载某个AssetBundle时报“文件不存在”或“CRC错误”。排查顺序检查缓存文件是否存在去缓存目录看对应的.ab文件在不在不在就是下载环节出了问题。检查文件大小跟清单里的size字段比对不一致说明下载不完整。检查哈希手动算一下文件的SHA256跟清单里的hash比对。检查依赖如果文件存在且哈希正确但加载还是失败大概率是依赖的AssetBundle没加载。去看清单里的deps字段确认依赖资源是否都已缓存。我遇到过一次排查了半天发现是打包时依赖关系没写对deps字段是空的导致加载时找不到依赖的shader。后来在打包脚本里加了一个校验确保每个AssetBundle的依赖都被正确记录。5.2 缓存文件被篡改的识别与处理识别篡改靠哈希校验但处理方式要分情况。如果是普通资源被改比如贴图可以静默重新下载覆盖如果是关键资源被改比如配置表、核心逻辑相关的AssetBundle我建议直接清空整个缓存目录强制全量更新。因为关键资源被改可能意味着玩家在尝试作弊全量更新能覆盖掉所有被改的文件。清空缓存的操作要谨慎不要直接Directory.Delete而是先重命名整个缓存目录再新建一个空目录最后异步删除旧目录。这样即使删除过程中出问题也不会影响游戏启动。5.3 版本回滚时的缓存清理策略版本回滚是热更新的高级操作比如新版本上线后发现严重bug需要紧急回退到旧版本。这时候缓存里既有新版本的资源又有旧版本的资源如果不清理干净可能出现“加载了旧版本清单但用了新版本资源”的混乱情况。我的策略是回滚时直接切换缓存目录。比如当前用的是/Cache/1.2.4/回滚到1.2.3时把/Cache/1.2.3/设为活动目录1.2.4的目录保留但不再使用。这样回滚是瞬时的不需要重新下载。等确认旧版本稳定后再异步清理1.2.4的目录。5.4 常见问题速查表问题现象可能原因排查方法解决方式启动白屏清单拉取失败且无本地缓存看日志有无网络超时加兜底资源或提示玩家检查网络资源加载报CRC错误缓存文件损坏比对文件哈希删除损坏文件重新下载贴图丢失依赖AssetBundle未加载检查deps字段补全依赖关系重新打包更新后仍是旧资源版本比对只比了版本号检查比对逻辑改为逐资源哈希比对下载卡在99%断点续传拼接错误检查远端文件哈希是否变化哈希变化时放弃续传重新下载低端机更新卡顿并发下载数过高看网络模块CPU占用降低并发数到3以下提示所有排查动作都要有日志支撑。我习惯在关键节点打日志包括清单拉取耗时、哈希校验结果、下载开始和结束、缓存写入结果。线上出问题时让玩家上传日志基本能定位到具体环节。6. 我踩过的坑与实操心得先说一个最坑的CDN缓存刷新不及时。我们有一次紧急更新清单和资源都传上去了但CDN节点还是返回旧清单导致部分玩家更新后资源错乱。后来学乖了每次更新后主动调CDN的刷新接口并且在清单URL后面加一个时间戳参数强制不走CDN缓存。这个时间戳参数不要用打包时间用客户端启动时的时间否则同一时间段内所有玩家拿到的还是同一个缓存。第二个坑是哈希校验的性能问题。早期我对所有缓存文件都在启动时校验结果低端机上启动时间从3秒变成了8秒。后来改成只校验关键资源并且把校验结果缓存到内存第二次启动时如果文件修改时间没变就跳过校验启动时间才降回来。第三个坑是Android上的文件权限问题。有次把缓存目录设在了外部存储结果在Android 11上因为分区存储的限制写入失败但没报错导致缓存一直是空的每次启动都重新下载。后来统一改用persistentDataPath问题消失。这个坑提醒我缓存路径的选择一定要考虑目标平台的文件系统特性不能想当然。最后一个心得热更新的安全排查不是一次性的工作而是要持续监控。我在项目里加了一个上报机制每次启动时把清单版本、缓存命中率、校验失败次数上报到后台。如果某个版本的校验失败率突然升高说明可能有人在搞事情或者CDN出了问题能第一时间发现。这个机制上线后我们提前发现过一次CDN节点被污染的情况避免了更大范围的影响。这套东西说起来复杂但真正落地之后热更新的线上事故率能降一个数量级。核心就一句话清单要验缓存要校写入要原子失败要兜底。把这四点做到位剩下的就是细节打磨了。
1. 热更新链路到底在解决什么问题做过Unity手游的兄弟都清楚包体大小和版本迭代速度是一对天生的冤家。玩家在应用商店下载一个几百兆甚至上G的安装包每次改个活动配置、修个UI贴图、调个数值表都要重新走一遍渠道审核短则一天长则一周运营节奏根本扛不住。热更新这套机制就是为了打破这个僵局把可以动态替换的资源从主包里剥离出来运行时按需从远端拉取本地缓存命中就直接用没命中就下载后落盘。整条链路串起来就是打包 → 上传CDN → 客户端请求清单 → 比对版本 → 下载差异资源 → 写入本地缓存 → 加载生效。听起来很顺但真正上线之后你会发现问题几乎全出在“安全排查”这四个字上。CDN上的清单被人篡改过怎么办本地缓存被玩家手动替换成魔改资源怎么办下载到一半断网导致缓存文件损坏下次启动直接白屏怎么办这些都不是危言耸听我在实际项目里全都遇到过。所以这篇内容不是教你从零搭一套热更新框架而是聚焦在链路已经跑通之后怎么把CDN清单和本地缓存这两个关键节点排查干净让线上事故率降下来。适合谁看如果你已经用Unity做过至少一个上线项目对AssetBundle的打包和加载有基本概念但热更新上线后总出一些“偶发”“复现不了”的诡异问题那这篇就是写给你的。我会把清单校验、缓存完整性、版本回滚、异常兜底这些环节拆开讲每个点都配上我踩过的坑和实际验证过的处理方式。全程不聊虚的只讲能直接抄作业的操作。2. 整体方案设计与安全边界拆解2.1 为什么安全排查要分“清单”和“缓存”两层很多人做热更新注意力全放在“怎么下载快”“怎么压缩小”上安全校验往往是最后才补的。但从攻击面和故障面来看CDN清单是入口本地缓存是落脚点这两层任何一层出问题整个热更新链路就废了。CDN清单本质上是一个描述文件通常包含资源名、哈希值、文件大小、版本号、依赖关系。客户端启动时第一件事就是拉这个清单然后拿它跟本地已缓存的版本做比对。如果清单本身被篡改——比如有人通过某些手段替换了CDN上的文件把某个AssetBundle的哈希改成恶意资源的哈希——客户端会毫无防备地下载并加载被替换的内容。这不是理论风险早期很多项目清单就是明文JSON直接扔在CDN上连个签名都没有。本地缓存则是另一个战场。玩家设备上的缓存目录在Android上如果放在外部存储root过的机器或者某些文件管理器就能直接改。我见过玩家把角色皮肤贴图换成自定义图片的也见过因为缓存写入中断导致文件半截、加载时报CRC错误的。所以缓存层要解决的是完整性和防篡改两个问题前者保稳定后者保安全。2.2 清单校验的三种方案与选型逻辑清单校验我实际用过三种方案各有适用场景直接上对比表方案实现方式安全性性能开销适用场景明文JSON直接读取无校验极低几乎为零内网测试、单机Demo哈希校验清单内附带自身哈希或单独存放哈希文件中低一次哈希计算中小型项目、对安全要求一般签名校验用非对称加密对清单签名客户端用公钥验签高中验签耗时约几毫秒到几十毫秒正式上线项目、有对抗需求选型逻辑很简单看你的项目有没有被针对性攻击的价值。休闲小游戏用哈希校验足够了大型MMO或者有交易系统的项目签名校验是底线。我现在的习惯是哪怕项目不大也至少上哈希校验因为实现成本真的很低但能挡掉绝大多数“缓存文件损坏”类的低级问题。哈希校验的具体做法是打包时对清单文件本身计算一次SHA256把这个哈希值写到一个单独的.hash文件里或者直接硬编码在客户端的一个常量里。客户端拉取清单后先算哈希再比对不一致就直接拒绝使用走兜底逻辑。这里有个细节哈希值不要跟清单放在同一个CDN目录下否则被一锅端的风险还是存在。我一般会把哈希值放在客户端代码里或者通过另一个独立接口下发。2.3 本地缓存的目录结构与命名策略缓存目录的设计直接影响排查效率。我见过有的项目把所有AssetBundle平铺在一个文件夹里几千个文件堆在一起出问题了根本不知道哪个是哪个。合理的做法是按版本号资源类型分目录比如/Cache/ /1.2.3/ /ui/ login.ab main.ab /character/ hero_001.ab manifest.hash /1.2.4/ ...这样设计的好处是版本回滚时直接切目录不用逐个文件删排查时也能快速定位到某个版本的某类资源。命名上我建议保留原始AssetBundle的名字不要做额外映射否则日志里报错的名字和实际文件名对不上查起来很痛苦。还有一个关键点缓存目录要放在应用私有空间。Android上用Application.persistentDataPathiOS上用Application.temporaryCachePath或沙盒内的Documents目录。不要图方便放外部存储否则被篡改的概率会大幅上升。如果确实需要放外部存储比如某些渠道要求那至少要对每个缓存文件做完整性校验加载前先验哈希。3. 核心细节解析与实操要点3.1 清单文件的结构设计与字段含义一个健壮的清单文件字段设计要能支撑校验、比对、回滚三个动作。我常用的结构是这样的以JSON为例{ version: 1.2.4, timestamp: 1699999999, hash: a1b2c3d4..., assets: [ { name: ui/login.ab, hash: e5f6g7h8..., size: 102400, deps: [ui/common.ab], crc: 123456789 } ] }逐字段说明version是整包版本号用于快速比对timestamp是打包时间排查时能确认清单是不是最新的hash是清单自身的哈希用于自校验assets数组里每个资源都有自己的hash、size、deps和crc。deps字段特别重要AssetBundle的依赖关系如果处理不好会出现“资源加载了但贴图丢失”的问题排查时优先看这个字段有没有漏。crc是Unity在打包时可以生成的校验值加载时Unity自己会校验但前提是你打包时开启了Append Hash to AssetBundle Name或者手动记录了CRC。我建议两个都做清单里记一份加载时用AssetBundle.LoadFromFile的CRC参数再校验一次双保险。3.2 哈希算法选择与计算时机哈希算法我统一用SHA256不用MD5。原因很简单MD5已经被证明存在碰撞攻击的可能虽然实际项目中遇到刻意碰撞的概率极低但既然SHA256的计算开销在现代设备上完全可以接受没必要省那一点性能。实测在骁龙660级别的机器上对一个1MB的文件算SHA256大约耗时3到5毫秒一个清单文件通常也就几十KB开销可以忽略。计算时机有两个打包时和加载前。打包时计算是为了写入清单加载前计算是为了校验缓存文件有没有损坏。加载前的校验我建议只对关键资源做比如配置表、核心UI、角色模型不要对所有资源都做否则加载时间会明显变长。判断标准是这个资源如果被篡改或损坏会不会导致游戏无法正常运行或者产生不公平的优势。会就校验不会就跳过。注意计算哈希时要用流式读取不要一次性把整个文件读进内存。大文件比如几十MB的场景AssetBundle一次性读取容易触发GC峰值在低端机上直接卡顿甚至OOM。3.3 缓存写入的原子性操作缓存写入最怕的就是“写了一半”。玩家下载到90%的时候切后台、断网、杀进程下次启动时这个半截文件如果被当成完整文件加载轻则报错重则白屏。解决办法是先写临时文件写完再重命名。具体流程下载时写入xxx.ab.tmp下载完成后校验哈希校验通过再把.tmp重命名为xxx.ab。这样即使中途中断下次启动时看到的只有.tmp文件直接删掉重新下载即可不会污染正式缓存。重命名操作在同一个文件系统内是原子性的不用担心重命名到一半又断了。这个逻辑听起来简单但我见过至少三个项目没做结果线上频繁出现“资源加载失败”的客诉查了半天才发现是缓存文件不完整。加上这个机制之后这类问题基本归零。3.4 版本比对与差异下载的策略版本比对不是简单地比版本号大小而是要比每个资源的哈希。因为有时候版本号没变但某个资源被重新打包了比如修了个贴图这时候如果只比版本号客户端不会更新玩家看到的还是旧资源。我的做法是客户端本地维护一份“已缓存资源清单”记录每个资源的名字和哈希。启动时拉取远端清单逐个比对哈希不一致的就加入下载队列。这样即使版本号相同只要有资源变了也能正确更新。差异下载的并发数要控制。我试过同时开10个下载线程在低端机上直接把网络模块打满导致其他请求超时。后来改成最多3个并发配合一个下载队列稳定很多。下载失败的资源要记录重试次数超过3次就跳过并上报不要无限重试卡住启动流程。4. 实操过程与核心环节实现4.1 打包阶段的清单生成与签名打包脚本我一般用C#写一个Editor工具在BuildPipeline.BuildAssetBundles之后执行。核心步骤遍历所有生成的AssetBundle文件逐个计算SHA256和文件大小。读取每个AssetBundle的依赖关系Unity提供了AssetDatabase.GetAssetBundleDependencies但打包后要用AssetBundleManifest来获取。组装成JSON结构写入manifest.json。对manifest.json本身计算SHA256写入manifest.hash。如果启用签名用私钥对manifest.json的内容签名签名结果写入manifest.sig。签名这块我用的是RSA-2048私钥只存在于打包机上公钥硬编码在客户端。验签时用公钥解密签名比对内容哈希。虽然RSA验签比纯哈希慢一些但清单文件小实测在移动端也就10到20毫秒完全可以接受。提示私钥文件千万不要提交到版本控制系统。我一般放在打包机的独立目录通过环境变量读取路径CI脚本里也不打印私钥内容。4.2 客户端启动时的清单拉取与校验流程客户端启动时的流程我拆成六步每一步都有失败兜底检查网络无网络时直接用本地缓存启动跳过更新。拉取远端清单带超时我设的是5秒超时则用本地缓存。校验清单哈希比对manifest.hash不一致则拒绝使用走本地缓存。验签如果启用用公钥验签失败则拒绝使用。比对资源哈希生成本地缓存清单与远端清单逐个比对。执行差异下载按队列下载完成后更新本地缓存清单。这里有个细节第3步和第4步的失败处理要区分。哈希不一致可能是CDN同步延迟或者文件损坏可以重试一次验签失败则大概率是被篡改直接拒绝并上报不要重试。我在实际项目里就遇到过CDN节点同步不及时导致哈希对不上的情况重试一次就正常了。4.3 本地缓存的读写与完整性校验本地缓存的读写我封装了一个CacheManager类核心方法就三个Read、Write、Verify。Write方法负责原子写入前面讲过的临时文件加重命名。Read方法在读取前先调Verify校验哈希和CRC。Verify的实现要注意不要每次都重新算哈希那样太慢。我的做法是维护一个内存字典记录本次启动已经校验过的资源避免重复计算。对于特别大的资源比如超过50MB的场景包我建议跳过启动时的哈希校验改为加载时由Unity的CRC校验兜底。因为启动时算一个大文件的SHA256可能要几百毫秒玩家会感觉到明显的卡顿。Unity的AssetBundle.LoadFromFile自带CRC校验虽然算法不同但同样能发现文件损坏。4.4 断点续传与失败重试的实现断点续传对热更新体验影响很大尤其是大版本更新时。实现方式是下载时记录已下载的字节数下次从断点继续。但这里有个坑如果远端文件变了断点续传会拼出一个错误的文件。所以断点续传的前提是远端文件的哈希没变每次续传前要先比对哈希。失败重试我设的是最多3次每次间隔递增1秒、3秒、5秒。超过3次就标记该资源为“下载失败”跳过并继续下载其他资源。启动完成后如果有失败资源弹一个提示让玩家手动重试而不是卡在启动界面。这个体验上的小改动能减少很多客诉。5. 常见问题与排查技巧实录5.1 清单拉取成功但资源加载失败这是最常见的问题表现是清单能拉到版本也比对成功了但加载某个AssetBundle时报“文件不存在”或“CRC错误”。排查顺序检查缓存文件是否存在去缓存目录看对应的.ab文件在不在不在就是下载环节出了问题。检查文件大小跟清单里的size字段比对不一致说明下载不完整。检查哈希手动算一下文件的SHA256跟清单里的hash比对。检查依赖如果文件存在且哈希正确但加载还是失败大概率是依赖的AssetBundle没加载。去看清单里的deps字段确认依赖资源是否都已缓存。我遇到过一次排查了半天发现是打包时依赖关系没写对deps字段是空的导致加载时找不到依赖的shader。后来在打包脚本里加了一个校验确保每个AssetBundle的依赖都被正确记录。5.2 缓存文件被篡改的识别与处理识别篡改靠哈希校验但处理方式要分情况。如果是普通资源被改比如贴图可以静默重新下载覆盖如果是关键资源被改比如配置表、核心逻辑相关的AssetBundle我建议直接清空整个缓存目录强制全量更新。因为关键资源被改可能意味着玩家在尝试作弊全量更新能覆盖掉所有被改的文件。清空缓存的操作要谨慎不要直接Directory.Delete而是先重命名整个缓存目录再新建一个空目录最后异步删除旧目录。这样即使删除过程中出问题也不会影响游戏启动。5.3 版本回滚时的缓存清理策略版本回滚是热更新的高级操作比如新版本上线后发现严重bug需要紧急回退到旧版本。这时候缓存里既有新版本的资源又有旧版本的资源如果不清理干净可能出现“加载了旧版本清单但用了新版本资源”的混乱情况。我的策略是回滚时直接切换缓存目录。比如当前用的是/Cache/1.2.4/回滚到1.2.3时把/Cache/1.2.3/设为活动目录1.2.4的目录保留但不再使用。这样回滚是瞬时的不需要重新下载。等确认旧版本稳定后再异步清理1.2.4的目录。5.4 常见问题速查表问题现象可能原因排查方法解决方式启动白屏清单拉取失败且无本地缓存看日志有无网络超时加兜底资源或提示玩家检查网络资源加载报CRC错误缓存文件损坏比对文件哈希删除损坏文件重新下载贴图丢失依赖AssetBundle未加载检查deps字段补全依赖关系重新打包更新后仍是旧资源版本比对只比了版本号检查比对逻辑改为逐资源哈希比对下载卡在99%断点续传拼接错误检查远端文件哈希是否变化哈希变化时放弃续传重新下载低端机更新卡顿并发下载数过高看网络模块CPU占用降低并发数到3以下提示所有排查动作都要有日志支撑。我习惯在关键节点打日志包括清单拉取耗时、哈希校验结果、下载开始和结束、缓存写入结果。线上出问题时让玩家上传日志基本能定位到具体环节。6. 我踩过的坑与实操心得先说一个最坑的CDN缓存刷新不及时。我们有一次紧急更新清单和资源都传上去了但CDN节点还是返回旧清单导致部分玩家更新后资源错乱。后来学乖了每次更新后主动调CDN的刷新接口并且在清单URL后面加一个时间戳参数强制不走CDN缓存。这个时间戳参数不要用打包时间用客户端启动时的时间否则同一时间段内所有玩家拿到的还是同一个缓存。第二个坑是哈希校验的性能问题。早期我对所有缓存文件都在启动时校验结果低端机上启动时间从3秒变成了8秒。后来改成只校验关键资源并且把校验结果缓存到内存第二次启动时如果文件修改时间没变就跳过校验启动时间才降回来。第三个坑是Android上的文件权限问题。有次把缓存目录设在了外部存储结果在Android 11上因为分区存储的限制写入失败但没报错导致缓存一直是空的每次启动都重新下载。后来统一改用persistentDataPath问题消失。这个坑提醒我缓存路径的选择一定要考虑目标平台的文件系统特性不能想当然。最后一个心得热更新的安全排查不是一次性的工作而是要持续监控。我在项目里加了一个上报机制每次启动时把清单版本、缓存命中率、校验失败次数上报到后台。如果某个版本的校验失败率突然升高说明可能有人在搞事情或者CDN出了问题能第一时间发现。这个机制上线后我们提前发现过一次CDN节点被污染的情况避免了更大范围的影响。这套东西说起来复杂但真正落地之后热更新的线上事故率能降一个数量级。核心就一句话清单要验缓存要校写入要原子失败要兜底。把这四点做到位剩下的就是细节打磨了。
