1. 项目概述为什么Unity AssetBundle需要加密在Unity项目开发尤其是移动端和WebGL平台的项目中AssetBundleAB包是资源热更新和分包加载的核心载体。我们辛辛苦苦制作的美术模型、UI贴图、音频和配置表最终都会被打进一个个AB包里。然而一个长期被许多开发者忽视或心存侥幸的问题是这些AB包文件一旦发布出去几乎是“裸奔”的。你可以用任何一款十六进制编辑器甚至记事本打开一个未加密的AssetBundle虽然看到的可能是乱码但通过Unity引擎或一些第三方工具如AssetStudio其内部资源可以被轻易地提取、查看、甚至修改。这意味着你的核心美术资产、付费内容、乃至游戏逻辑配置如果以ScriptableObject形式打包都暴露在风险之下。资源泄露不仅仅是知识产权损失更可能导致外挂、私服、内容被恶意替换等一系列运营事故。因此为AssetBundle实现加密从一个“可选项”变成了面向商业化项目的“必选项”。但正如网络热词中提到的“AES加密”它仅仅是众多加密算法中的一种。选择AES是因为它在安全性、性能和通用性上取得了很好的平衡是当前工业界的标准选择之一。而“内存加载”则是加密后的必然选择加密文件无法被Unity的AssetBundle.LoadFromFileAPI直接识别我们必须先将加密文件读入内存解密后再从内存数据流中加载AB包。这个过程听起来简单实则涉及到IO操作、解密时机、内存管理等多个技术细节处理不当就会引发性能问题或新的资源泄露内存泄露。我经历过不止一个项目因为加密加载方案设计有缺陷导致WebGL平台初始化卡顿对应热词“unity webgl初始化很久”或者移动端内存峰值过高而崩溃。所以今天我就结合自己踩过的坑手把手带你实现一套既安全又高效的Unity AssetBundle AES加密与内存加载方案让你能真正告别资源泄露的烦恼。2. 核心方案设计AES加密与内存加载的架构解析在动手写代码之前我们必须先理清整个流程的架构。一个完整的加密AB包生命周期包括打包时加密、发布后分发、运行时解密加载。我们的方案需要覆盖全链路。2.1 整体流程与模块划分整个系统可以划分为两个相对独立的部分编辑/打包工具链和运行时加载器。编辑/打包工具链Editor工具职责在项目构建BuildAssetBundle之后对生成的.assetbundle文件进行加密处理。输入原始的AssetBundle文件。处理使用预设的AES密钥和初始化向量IV对文件进行加密生成新的加密文件。通常我们会选择追加或修改文件头以区别于未加密文件。输出加密后的AssetBundle文件例如将.assetbundle重命名为.ab或保持原名但内部内容已加密。运行时加载器Runtime Script职责在游戏运行时根据资源加载请求获取加密的AB包文件解密后加载到Unity引擎中。核心API放弃AssetBundle.LoadFromFile转而使用AssetBundle.LoadFromMemory或AssetBundle.LoadFromStream。前者需要将完整解密数据置于一个byte[]中后者则可以通过Stream边解密边加载内存效率更高。流程请求资源-根据路径找到加密文件-读取文件字节流-使用AES解密字节流-将解密后的流传递给AssetBundle.LoadFromStream-加载资源-卸载AB包。2.2 为什么选择AES而不是异或或自定义算法网络热词和资料里提到了“AES加密”和“异或加密”。这里必须强调对于商业项目请永远选择AES等标准加密算法绝对不要使用简单的异或XOR或自创的“魔改”算法。异或加密本质上是一种混淆而非加密。它的密钥空间小模式固定对于稍有经验的破解者来说通过频率分析或已知明文攻击可以瞬间破解。它唯一的优点是速度极快开销几乎可以忽略。但这就像用纸糊的门来防贼只能防君子不能防小人。它适用于对安全性要求极低但又需要一点简单混淆的场景比如防止资源被文本编辑器直接打开绝不能用于保护核心资产。AES加密是美国联邦标准经过全球密码学家多年检验在正确使用如选择合适的模式、管理好密钥的前提下目前被认为是计算上安全的。它的性能开销在现代CPU尤其是支持AES-NI指令集的CPU上已经非常小完全在游戏可接受的范围内。性能对比资料也提到加密不是免费的午餐但AES这份“午餐”的价格性能损耗对于其带来的安全保障来说是超值的。关于AES的使用要点模式选择通常使用CBC模式。它需要一个初始化向量IV来增加随机性防止相同的明文块加密后产生相同的密文块。IV不需要保密但必须不可预测通常可以随机生成并保存在加密文件头部。密钥管理这是安全的核心。密钥绝不能硬编码在客户端代码里。常见的策略是将密钥拆分成多个部分分别存放在不同的位置如一部分在代码中一部分从服务器首次启动时下发一部分由设备信息生成并在内存中使用后尽快清除。更高级的做法是结合白盒加密或使用硬件安全区域如iOS的Keychain、Android的Keystore。填充AES是块加密算法需要数据长度是16字节的倍数。我们使用PKCS7填充标准。2.3 内存加载方案选型LoadFromMemory vs LoadFromStream这是影响运行时性能和内存占用的关键选择。AssetBundle.LoadFromMemory(byte[] binary)工作原理需要先将整个加密文件读取到byte[]然后解密到另一个byte[]最后将这个完整的解密数据数组交给API。优点接口简单逻辑清晰。缺点内存峰值高。假设一个加密AB包是100MB解密后可能变为100MB那么在解密瞬间内存中会同时存在加密数据100MB和解密数据100MB的两个完整副本峰值内存增加超过200MB对于移动设备是巨大的压力。解密完成后加密数据的数组才能被GC回收。AssetBundle.LoadFromStream(Stream stream)工作原理我们实现一个自定义的Stream类例如AesDecryptStream。Unity引擎会从这个Stream中按需读取数据。我们可以在Read方法内部实现解密逻辑引擎读多少我们就解密多少。优点内存效率极高。只需要一个较小的缓冲区例如AES的一个块大小16KB用于解密操作内存占用是常数级别的。非常适合加载大型AB包。缺点实现稍复杂需要正确处理Stream的Position,Length,Seek等属性以兼容Unity的加载器。并且不能与AssetBundle.LoadFromFile或LoadFromMemoryAsync混合使用因为Stream的生命周期需要手动管理。结论对于追求性能和内存优化的项目LoadFromStream是更优的选择。这也是本次教程我们将重点实现的方式。它能有效避免因加密解密过程引发的内存暴涨从而规避“由于设备驱动程序的前一个实例仍在内存中”这类内存问题引发的连锁反应虽然该热词原意不同但内存管理不当的本质是相通的。3. 实战第一步创建AES加密工具Editor工具我们首先在Unity Editor下创建一个工具用于在打包后自动加密AB包。3.1 创建编辑器脚本与菜单在项目的Editor文件夹下如果没有就创建一个新建一个C#脚本命名为AssetBundleEncryptor.cs。using UnityEngine; using UnityEditor; using System.IO; using System.Security.Cryptography; using System; public static class AssetBundleEncryptor { // 这是一个示例密钥和IV。真实项目中必须通过安全的方式生成和管理 // AES-256 需要32字节的密钥 AES-128 需要16字节。 private static readonly byte[] s_AesKey { 0x01, 0x23, 0x45, 0x67, 0x89, 0xAB, 0xCD, 0xEF, 0xFE, 0xDC, 0xBA, 0x98, 0x76, 0x54, 0x32, 0x10, 0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF }; private static readonly byte[] s_AesIV { 0x0F, 0x1E, 0x2D, 0x3C, 0x4B, 0x5A, 0x69, 0x78, 0x87, 0x96, 0xA5, 0xB4, 0xC3, 0xD2, 0xE1, 0xF0 }; [MenuItem(Tools/AssetBundle/Encrypt All Bundles)] public static void EncryptAllBundles() { // 1. 定位AssetBundle的输出目录 string outputPath Path.Combine(Application.streamingAssetsPath, AssetBundles); // 或者使用你的自定义输出路径 // string outputPath “你的AB包输出路径”; if (!Directory.Exists(outputPath)) { Debug.LogError($AssetBundle目录不存在: {outputPath}); return; } // 2. 遍历目录下所有文件 string[] allFiles Directory.GetFiles(outputPath, *, SearchOption.AllDirectories); int processedCount 0; foreach (string filePath in allFiles) { // 跳过.meta等非AB包文件 if (filePath.EndsWith(.meta) || filePath.EndsWith(.manifest)) { continue; } EncryptSingleBundle(filePath); processedCount; } Debug.Log($加密完成共处理 {processedCount} 个文件。); AssetDatabase.Refresh(); // 刷新编辑器让新文件可见 } private static void EncryptSingleBundle(string originalFilePath) { try { // 3. 读取原始文件 byte[] originalBytes File.ReadAllBytes(originalFilePath); // 4. 使用AES加密 byte[] encryptedBytes EncryptBytesWithAes(originalBytes); // 5. 写入加密文件这里选择覆盖原文件也可生成新文件 // 重要在实际项目中建议先写入临时文件成功后再替换防止加密过程出错导致原文件损坏。 string tempFilePath originalFilePath .encrypted.tmp; File.WriteAllBytes(tempFilePath, encryptedBytes); // 替换原文件 File.Delete(originalFilePath); File.Move(tempFilePath, originalFilePath); Debug.Log($已加密: {Path.GetFileName(originalFilePath)}); } catch (Exception e) { Debug.LogError($加密文件 {originalFilePath} 时发生错误: {e.Message}); } } public static byte[] EncryptBytesWithAes(byte[] plainBytes) { using (Aes aesAlg Aes.Create()) { aesAlg.Key s_AesKey; aesAlg.IV s_AesIV; aesAlg.Mode CipherMode.CBC; aesAlg.Padding PaddingMode.PKCS7; using (ICryptoTransform encryptor aesAlg.CreateEncryptor()) using (MemoryStream msEncrypt new MemoryStream()) { using (CryptoStream csEncrypt new CryptoStream(msEncrypt, encryptor, CryptoStreamMode.Write)) { csEncrypt.Write(plainBytes, 0, plainBytes.Length); csEncrypt.FlushFinalBlock(); // 确保所有数据写入并应用填充 return msEncrypt.ToArray(); } } } } }注意上述代码中的s_AesKey和s_AesIV是硬编码的示例绝对不可用于生产环境生产环境中密钥应由构建服务器生成或通过安全的配置系统注入并且每个项目、甚至每个版本都应使用不同的密钥。3.2 工具使用流程与注意事项构建AssetBundle首先通过Unity的AssetBundle构建管道如BuildPipeline.BuildAssetBundles构建出原始的AB包。执行加密在Unity Editor菜单栏点击Tools - AssetBundle - Encrypt All Bundles。工具会遍历指定目录示例中是StreamingAssets/AssetBundles加密所有非.meta和.manifest文件。验证你可以尝试用文本编辑器打开加密后的AB包看到的将是乱码。而用未加密的加载方式去加载它Unity会报错提示文件格式错误。实操心得备份原文件在实际的自动化构建流程中建议先复制原始AB包到另一个目录进行加密保留一份原始文件用于调试和比对。文件头标识更专业的做法是在加密文件的开头写入一个特定的魔数Magic Number或版本号。这样在运行时加载器可以快速判断一个文件是否已被加密、是哪种加密方式。例如在加密后的数据前追加4字节的标识0xABCD1234。与构建流程集成可以通过继承IPostprocessBuildWithReport接口在构建完成后自动调用加密逻辑实现一键打包并加密。4. 实战第二步实现运行时AES解密流与加载器接下来是更核心的部分在运行时加载加密的AB包。我们将实现一个AesDecryptStream并封装一个易用的资源加载管理器。4.1 创建AesDecryptStream类这个类继承自Stream并重写关键方法使其能透明地进行解密。using System; using System.IO; using System.Security.Cryptography; public class AesDecryptStream : Stream { private readonly Stream _baseStream; // 底层加密文件的流 private readonly ICryptoTransform _decryptor; private readonly CryptoStream _cryptoStream; // 内部缓冲区用于缓存解密后的数据块 private byte[] _decryptedBuffer; private int _decryptedBufferOffset 0; private int _decryptedBufferCount 0; public AesDecryptStream(Stream baseStream, byte[] key, byte[] iv) { _baseStream baseStream ?? throw new ArgumentNullException(nameof(baseStream)); using (Aes aes Aes.Create()) { aes.Key key; aes.IV iv; aes.Mode CipherMode.CBC; aes.Padding PaddingMode.PKCS7; _decryptor aes.CreateDecryptor(); } // CryptoStream本身也是一个Stream我们将其置于“读模式”从它里面读取解密后的数据。 // 注意CryptoStream在Dispose时会自动关闭_baseStream这里我们传入leaveOpen: true来避免。 _cryptoStream new CryptoStream(_baseStream, _decryptor, CryptoStreamMode.Read, leaveOpen: true); // 设置一个合理的缓冲区大小例如AES块大小的倍数16KB _decryptedBuffer new byte[16 * 1024]; } public override int Read(byte[] buffer, int offset, int count) { int totalBytesRead 0; while (count 0) { // 如果内部缓冲区没有数据了就从CryptoStream中读取下一块 if (_decryptedBufferOffset _decryptedBufferCount) { _decryptedBufferCount _cryptoStream.Read(_decryptedBuffer, 0, _decryptedBuffer.Length); _decryptedBufferOffset 0; // 如果CryptoStream也读完了返回0说明已到文件尾 if (_decryptedBufferCount 0) { break; } } // 从内部缓冲区拷贝数据到用户提供的buffer int bytesToCopy Math.Min(_decryptedBufferCount - _decryptedBufferOffset, count); Array.Copy(_decryptedBuffer, _decryptedBufferOffset, buffer, offset, bytesToCopy); _decryptedBufferOffset bytesToCopy; offset bytesToCopy; count - bytesToCopy; totalBytesRead bytesToCopy; } return totalBytesRead; } // 必须重写的基础属性对于只读的AssetBundle加载流我们只需要支持读取。 public override bool CanRead true; public override bool CanSeek false; // 注意CryptoStream在CBC模式下通常不支持随机访问Seek除非使用特殊的模式。 public override bool CanWrite false; public override long Length throw new NotSupportedException(加密流的长度在解密前未知); public override long Position { get throw new NotSupportedException(); set throw new NotSupportedException(); } public override long Seek(long offset, SeekOrigin origin) throw new NotSupportedException(); public override void SetLength(long value) throw new NotSupportedException(); public override void Write(byte[] buffer, int offset, int count) throw new NotSupportedException(); public override void Flush() { } protected override void Dispose(bool disposing) { if (disposing) { _decryptor?.Dispose(); _cryptoStream?.Dispose(); // _baseStream 会被 _cryptoStream 关闭因为我们传入了leaveOpen: true所以这里需要手动关闭 _baseStream?.Dispose(); } base.Dispose(disposing); } }关键点解析CanSeek返回false这是最重要的限制。AES CBC模式是链式的解密第N个块需要依赖第N-1个块的密文。因此无法直接跳到文件中间开始解密。Unity的AssetBundle.LoadFromStream在加载标准AB包时本身也不要求Stream必须支持Seek。但如果你使用了某些需要随机访问资源的特性如AssetBundle的依赖加载可能会遇到问题。这是选择此方案时需要接受的权衡。缓冲区设计我们使用了一个中间缓冲区_decryptedBuffer。CryptoStream.Read每次解密出一块数据我们将其暂存然后提供给Unity引擎的Read调用。这比每次只解密Unity请求的几个字节要高效。流生命周期我们严格管理Dispose确保CryptoTransform、CryptoStream和底层的FileStream都被正确释放避免资源泄露。4.2 封装资源加载管理器现在我们创建一个管理类统一处理加密AB包的加载、缓存和卸载。using UnityEngine; using System.Collections.Generic; using System.IO; using System; public class EncryptedAssetBundleManager : MonoBehaviour { private static EncryptedAssetBundleManager s_instance; public static EncryptedAssetBundleManager Instance { get { if (s_instance null) { GameObject go new GameObject(EncryptedAssetBundleManager); s_instance go.AddComponentEncryptedAssetBundleManager(); DontDestroyOnLoad(go); } return s_instance; } } // 缓存已加载的AssetBundle private Dictionarystring, AssetBundle _loadedBundles new Dictionarystring, AssetBundle(); // 缓存正在进行的异步操作防止重复加载 private Dictionarystring, AssetBundleCreateRequest _loadingRequests new Dictionarystring, AssetBundleCreateRequest(); // 示例密钥和IV必须与加密工具保持一致生产环境应从安全位置获取。 private byte[] _aesKey new byte[32] { /* 你的32字节密钥 */ }; private byte[] _aesIV new byte[16] { /* 你的16字节IV */ }; public AssetBundle LoadBundle(string bundleName) { string bundlePath GetBundlePath(bundleName); if (_loadedBundles.TryGetValue(bundleName, out AssetBundle cachedBundle)) { Debug.Log($Bundle [{bundleName}] 已缓存直接返回。); return cachedBundle; } // 1. 创建文件流 FileStream fileStream new FileStream(bundlePath, FileMode.Open, FileAccess.Read); // 2. 创建解密流 AesDecryptStream decryptStream new AesDecryptStream(fileStream, _aesKey, _aesIV); // 3. 从解密流加载AssetBundle AssetBundle bundle AssetBundle.LoadFromStream(decryptStream); // 4. 关闭流 (LoadFromStream会持有流的引用但根据文档我们应在加载后关闭流) decryptStream.Close(); fileStream.Close(); if (bundle ! null) { _loadedBundles[bundleName] bundle; Debug.Log($成功同步加载加密Bundle: {bundleName}); } else { Debug.LogError($加载加密Bundle失败: {bundleName}); } return bundle; } public void LoadBundleAsync(string bundleName, ActionAssetBundle onComplete) { if (_loadedBundles.TryGetValue(bundleName, out AssetBundle cachedBundle)) { onComplete?.Invoke(cachedBundle); return; } if (_loadingRequests.ContainsKey(bundleName)) { Debug.LogWarning($Bundle [{bundleName}] 正在异步加载中请勿重复请求。); // 可以在这里添加回调到现有请求的逻辑这里简化处理。 return; } StartCoroutine(CoLoadBundleAsync(bundleName, onComplete)); } private System.Collections.IEnumerator CoLoadBundleAsync(string bundleName, ActionAssetBundle onComplete) { string bundlePath GetBundlePath(bundleName); // 异步读取文件字节UnityWebRequest或File.ReadAllBytesAsync在某些平台更好这里用WWW举例新项目建议用UnityWebRequest // 注意为了使用LoadFromStream我们需要先获得文件流。这里演示一个变通方案先异步读取到内存再创建MemoryStream。 // 对于大文件这有内存峰值问题。理想方案是使用支持异步读的文件流但Unity的LoadFromStream是同步接口。 // 因此更常见的异步加载加密AB包做法是先异步将加密文件读入内存byte[]然后在主线程解密并调用LoadFromMemoryAsync。 // 这里展示LoadFromMemoryAsync的方案因为它更通用。 byte[] encryptedBytes null; using (UnityEngine.Networking.UnityWebRequest www UnityEngine.Networking.UnityWebRequest.Get(bundlePath)) { www.downloadHandler new UnityEngine.Networking.DownloadHandlerBuffer(); yield return www.SendWebRequest(); if (www.result UnityEngine.Networking.UnityWebRequest.Result.Success) { encryptedBytes www.downloadHandler.data; } else { Debug.LogError($下载Bundle失败 [{bundleName}]: {www.error}); onComplete?.Invoke(null); yield break; } } // 在主线程解密解密是CPU密集型操作可以考虑分帧进行 byte[] decryptedBytes null; yield return StartCoroutine(DecryptBytesOnMainThread(encryptedBytes, (result) decryptedBytes result)); if (decryptedBytes null) { Debug.LogError($解密Bundle失败 [{bundleName}]); onComplete?.Invoke(null); yield break; } // 异步从内存加载AssetBundle AssetBundleCreateRequest createRequest AssetBundle.LoadFromMemoryAsync(decryptedBytes); _loadingRequests[bundleName] createRequest; yield return createRequest; _loadingRequests.Remove(bundleName); if (createRequest.assetBundle ! null) { _loadedBundles[bundleName] createRequest.assetBundle; Debug.Log($成功异步加载加密Bundle: {bundleName}); onComplete?.Invoke(createRequest.assetBundle); } else { Debug.LogError($异步加载AssetBundle失败: {bundleName}); onComplete?.Invoke(null); } } private System.Collections.IEnumerator DecryptBytesOnMainThread(byte[] encryptedBytes, Actionbyte[] callback) { byte[] decryptedBytes null; // 在实际项目中对于大文件这里应该分帧解密避免卡顿。 // 示例使用简单同步解密在协程中执行。 System.Threading.Tasks.Task.Run(() { try { using (Aes aes Aes.Create()) { aes.Key _aesKey; aes.IV _aesIV; aes.Mode CipherMode.CBC; aes.Padding PaddingMode.PKCS7; using (ICryptoTransform decryptor aes.CreateDecryptor()) using (MemoryStream msEncrypt new MemoryStream(encryptedBytes)) using (CryptoStream csDecrypt new CryptoStream(msEncrypt, decryptor, CryptoStreamMode.Read)) using (MemoryStream msDecrypt new MemoryStream()) { csDecrypt.CopyTo(msDecrypt); decryptedBytes msDecrypt.ToArray(); } } } catch (Exception e) { Debug.LogError($解密过程出错: {e.Message}); } }).Wait(); // 注意这里Wait会阻塞仅作示例。生产环境应用更复杂的异步解密。 callback?.Invoke(decryptedBytes); yield return null; } public void UnloadBundle(string bundleName, bool unloadAllLoadedObjects false) { if (_loadedBundles.TryGetValue(bundleName, out AssetBundle bundle)) { bundle.Unload(unloadAllLoadedObjects); _loadedBundles.Remove(bundleName); Debug.Log($已卸载Bundle: {bundleName}); } } private string GetBundlePath(string bundleName) { // 根据平台组合路径示例为StreamingAssets路径 string platformFolder GetPlatformFolder(); return Path.Combine(Application.streamingAssetsPath, platformFolder, bundleName); } private string GetPlatformFolder() { switch (Application.platform) { case RuntimePlatform.Android: return Android; case RuntimePlatform.IPhonePlayer: return iOS; case RuntimePlatform.WebGLPlayer: return WebGL; case RuntimePlatform.WindowsPlayer: case RuntimePlatform.WindowsEditor: return Windows; case RuntimePlatform.OSXPlayer: case RuntimePlatform.OSXEditor: return macOS; // ... 其他平台 default: return Application.platform.ToString(); } } void OnDestroy() { foreach (var bundle in _loadedBundles.Values) { if (bundle ! null) bundle.Unload(true); } _loadedBundles.Clear(); _loadingRequests.Clear(); } }代码要点与避坑指南异步加载的复杂性AssetBundle.LoadFromStream本身是同步接口且要求Stream不支持异步读取。因此实现真正的“异步流解密加载”非常复杂。上述代码的异步方案退回到了LoadFromMemoryAsync即先异步下载整个加密文件到内存再解密到另一个内存块最后异步加载。这会带来内存峰值但对于中小型AB包是可接受的。如果必须使用LoadFromStream且要异步可能需要自己实现一个支持BeginRead/EndRead的异步Stream包装器并确保Unity的加载器能兼容这属于高级话题。密钥管理_aesKey和_aesIV在示例中仍是硬编码。真实项目中它们应该在游戏启动时从服务器动态获取经过HTTPS或通过代码混淆、分段存储等方式保护。核心原则不要给破解者一个完整的、静态的密钥。内存流与文件流同步加载使用了FileStreamAesDecryptStream内存效率高。异步加载使用了UnityWebRequest下载到byte[]再解密内存效率低但实现简单。你需要根据项目需求包体大小、目标平台选择或混合使用。卸载UnloadBundle方法提供了卸载接口。注意bundle.Unload(false)只卸载AB包容器已加载的资产如Texture, GameObject如果还在被引用则不会卸载。bundle.Unload(true)会强制卸载所有从中加载的资产可能导致场景中的引用丢失变成Missing。管理好AB包的生命周期是避免内存泄露的另一关键。5. 性能优化与平台适配要点实现基础功能后我们需要关注性能和不同平台的兼容性。5.1 性能考量与实测数据加密解密必然带来CPU开销。你需要在实际的目标设备上进行性能分析。WebGL平台需要特别小心。热词中提到了“unity webgl初始化很久”。WebGL是单线程的所有解密操作都会阻塞主线程导致卡顿。对于WebGL项目建议将AB包尺寸做小减少单次解密的数据量。建议在显示加载界面时进行解密让玩家感知为加载时间。避免在游戏运行时同步解密大文件。可以尝试使用WebAssembly或Web Workers进行异步解密如果Unity版本和构建设置支持但这需要更复杂的前端集成。移动平台iOS/AndroidAES硬件加速现代ARM CPU大多支持AES指令集System.Security.Cryptography.Aes类在IL2CPP后端下通常会调用这些指令性能损失相对可控。但仍需测试。内存与发热持续的解密操作会增加CPU使用率可能导致设备发热。应避免在每帧都进行解密操作。性能测试方法在目标设备上分别测试加载未加密AB包、使用内存解密加载、使用流式解密加载三种方式的耗时和内存分配。使用Unity Profiler关注LoadFromMemory/LoadFromStream调用前后的GC Alloc和Total Memory变化。5.2 多平台路径与读取方式不同平台读取文件的方式不同我们的GetBundlePath和加载逻辑需要适配。AndroidApplication.streamingAssetsPath指向APK内的压缩目录不能直接用File.ReadAllBytes。必须使用UnityWebRequest或WWW来读取。上述异步加载示例已经使用了UnityWebRequest这在Android上是正确的。iOS对Application.streamingAssetsPath可以直接使用File.ReadAllBytes。Windows/Mac/Linux (Standalone)可以直接使用File.ReadAllBytes或FileStream。WebGLApplication.streamingAssetsPath指向服务器URL必须使用UnityWebRequest。一个健壮的路径获取与加载方法需要根据平台分支处理。更佳实践是使用UnityWebRequest统一处理所有平台的远程或StreamingAssets文件读取因为它具有最广泛的平台兼容性。5.3 与Addressables系统的结合如果你的项目使用了Unity的Addressable Asset System加密方案需要集成进去。Addressables提供了IResourceProvider接口允许你自定义资源的加载逻辑。你可以创建一个自定义的Provider在它的LoadInternal方法中插入你的解密流程。这样你仍然可以使用Addressables的加载、依赖、释放等强大功能同时底层资源是加密的。这是更现代化、也更复杂的集成方案。6. 常见问题排查与安全加固实录即使代码写完了在实际集成和运行中你一定会遇到各种问题。下面是我总结的常见“坑点”和解决方法。6.1 加载失败魔数错误或数据损坏问题现象调用LoadFromStream或LoadFromMemory后返回null或Unity报错“不是有效的AssetBundle文件”。排查步骤检查加密/解密密钥是否一致这是最常见的原因。确保打包服务器和客户端使用的密钥和IV完全一致字节对字节。建议将密钥信息输出到日志仅调试版本进行比对。检查文件是否真的被加密用二进制编辑器对比加密前后文件的大小和头部数据。加密后的文件应该面目全非。如果只是大小变了但头部还能看到UnityFS等字样说明加密可能没生效。检查填充Padding确保加密和解密都使用相同的填充模式如PKCS7。如果填充不一致解密出的最后几个字节会是错误的导致整个AB包数据损坏。检查CryptoStream的关闭时机在同步加载示例中我们在LoadFromStream之后立即关闭了流。但根据Unity文档的某些版本和情况LoadFromStream可能会延迟读取数据。保险的做法是不要立即关闭流而是将流的生命周期与AssetBundle绑定。可以创建一个包装类在AssetBundle卸载时再关闭流。不过我们的AesDecryptStream在Read方法中已经缓冲了数据提前关闭底层FileStream可能没问题但这依赖于实现细节。最安全的方法是让流一直打开直到AB包卸载。6.2 内存泄露与性能问题问题现象游戏运行一段时间后内存持续增长或加载大型AB包时瞬间卡顿。排查与解决Profiler是你的朋友使用Unity Memory Profiler查看AssetBundle和Texture等资源的引用情况。确认每次调用UnloadBundle后相关的内存是否被释放。流式加载的内存优势如果使用LoadFromStream在Profiler中你应该看到加载AB包时GC Alloc和Total Memory不会有大幅飙升。如果仍有飙升检查是否在解密过程中创建了不必要的完整字节数组副本。异步加载的卡顿如果在协程中同步解密大块数据如DecryptBytesOnMainThread中的Task.Run(...).Wait()会导致主线程卡住。解决方案是分帧解密。可以将解密任务分解成多个小块每帧解密一部分通过yield return null来避免卡顿。虽然总时间可能变长但帧率更平滑。WebGL的特别优化对于WebGL由于单线程限制分帧解密尤为重要。可以考虑将AB包在服务器端进行分块加密客户端按需加载和解密小块。6.3 安全加固建议加密只是安全的第一道防线。一个坚定的破解者仍然可以动态调试你的游戏在内存中抓取解密后的AB包数据或者直接Hook你的解密函数。代码混淆使用像Obfuscator这样的工具对DLL进行混淆增加静态分析和动态调试的难度。密钥动态组合不要使用一个完整的静态密钥。可以将密钥拆散一部分来自代码中的常量一部分从服务器响应中获得一部分由设备ID或用户信息哈希生成。在运行时动态组合。内存擦除解密完成后尽快将保存密钥和原始解密数据的字节数组用随机数据覆盖Array.Clear减少内存中敏感信息驻留的时间。检测调试器在发布版本中加入反调试代码虽然不能完全阻止但可以提高门槛。完整性校验对加密后的AB包计算一个哈希值如SHA256存储在manifest或服务器上。加载时先校验文件哈希防止资源被篡改。记住没有绝对的安全。我们的目标是提高破解成本使得破解所需的技术、时间和精力远超其获取的收益从而保护大多数资源的安全。7. 总结与个人体会实现一套完整的AssetBundle加密加载方案远不止是调用Aes.Encrypt和LoadFromStream那么简单。它涉及构建管道的改造、运行时架构的设计、平台细节的适配以及性能与安全的权衡。我个人在多个项目中实践下来的体会是首先明确需求。如果你的资源价值不高或者项目是内部工具或许简单的混淆甚至不加密都可以。但如果涉及商业资产加密是必须的。其次流式加载LoadFromStream是处理大型加密AB包的优选。它能有效控制内存峰值避免因解密大文件导致的瞬间内存暴涨和GC压力。虽然牺牲了随机访问能力但对于大多数按需加载的场景是足够的。再次密钥管理是灵魂。再坚固的加密算法如果密钥放在客户端明文中就等于把钥匙挂在门上。花在密钥安全管理上的心思应该和花在加密算法本身一样多。最后一定要做全平台、全流程的测试。在Editor下能跑通不代表在真机尤其是WebGL和移动端没问题。务必在目标平台上测试从打包、加密、分发到加载、卸载的完整流程用Profiler监控性能和内存确保没有泄露和卡顿。这套方案为你提供了一个坚实可靠的起点。你可以根据自己项目的具体需求在此基础上进行扩展例如集成到Addressables、实现更复杂的密钥分发系统、或者增加资源压缩与加密的混合处理。希望这篇长文能帮你彻底告别AssetBundle资源泄露的隐患让你的项目更加安全稳健。
Unity AssetBundle AES加密与内存加载实战：告别资源泄露
1. 项目概述为什么Unity AssetBundle需要加密在Unity项目开发尤其是移动端和WebGL平台的项目中AssetBundleAB包是资源热更新和分包加载的核心载体。我们辛辛苦苦制作的美术模型、UI贴图、音频和配置表最终都会被打进一个个AB包里。然而一个长期被许多开发者忽视或心存侥幸的问题是这些AB包文件一旦发布出去几乎是“裸奔”的。你可以用任何一款十六进制编辑器甚至记事本打开一个未加密的AssetBundle虽然看到的可能是乱码但通过Unity引擎或一些第三方工具如AssetStudio其内部资源可以被轻易地提取、查看、甚至修改。这意味着你的核心美术资产、付费内容、乃至游戏逻辑配置如果以ScriptableObject形式打包都暴露在风险之下。资源泄露不仅仅是知识产权损失更可能导致外挂、私服、内容被恶意替换等一系列运营事故。因此为AssetBundle实现加密从一个“可选项”变成了面向商业化项目的“必选项”。但正如网络热词中提到的“AES加密”它仅仅是众多加密算法中的一种。选择AES是因为它在安全性、性能和通用性上取得了很好的平衡是当前工业界的标准选择之一。而“内存加载”则是加密后的必然选择加密文件无法被Unity的AssetBundle.LoadFromFileAPI直接识别我们必须先将加密文件读入内存解密后再从内存数据流中加载AB包。这个过程听起来简单实则涉及到IO操作、解密时机、内存管理等多个技术细节处理不当就会引发性能问题或新的资源泄露内存泄露。我经历过不止一个项目因为加密加载方案设计有缺陷导致WebGL平台初始化卡顿对应热词“unity webgl初始化很久”或者移动端内存峰值过高而崩溃。所以今天我就结合自己踩过的坑手把手带你实现一套既安全又高效的Unity AssetBundle AES加密与内存加载方案让你能真正告别资源泄露的烦恼。2. 核心方案设计AES加密与内存加载的架构解析在动手写代码之前我们必须先理清整个流程的架构。一个完整的加密AB包生命周期包括打包时加密、发布后分发、运行时解密加载。我们的方案需要覆盖全链路。2.1 整体流程与模块划分整个系统可以划分为两个相对独立的部分编辑/打包工具链和运行时加载器。编辑/打包工具链Editor工具职责在项目构建BuildAssetBundle之后对生成的.assetbundle文件进行加密处理。输入原始的AssetBundle文件。处理使用预设的AES密钥和初始化向量IV对文件进行加密生成新的加密文件。通常我们会选择追加或修改文件头以区别于未加密文件。输出加密后的AssetBundle文件例如将.assetbundle重命名为.ab或保持原名但内部内容已加密。运行时加载器Runtime Script职责在游戏运行时根据资源加载请求获取加密的AB包文件解密后加载到Unity引擎中。核心API放弃AssetBundle.LoadFromFile转而使用AssetBundle.LoadFromMemory或AssetBundle.LoadFromStream。前者需要将完整解密数据置于一个byte[]中后者则可以通过Stream边解密边加载内存效率更高。流程请求资源-根据路径找到加密文件-读取文件字节流-使用AES解密字节流-将解密后的流传递给AssetBundle.LoadFromStream-加载资源-卸载AB包。2.2 为什么选择AES而不是异或或自定义算法网络热词和资料里提到了“AES加密”和“异或加密”。这里必须强调对于商业项目请永远选择AES等标准加密算法绝对不要使用简单的异或XOR或自创的“魔改”算法。异或加密本质上是一种混淆而非加密。它的密钥空间小模式固定对于稍有经验的破解者来说通过频率分析或已知明文攻击可以瞬间破解。它唯一的优点是速度极快开销几乎可以忽略。但这就像用纸糊的门来防贼只能防君子不能防小人。它适用于对安全性要求极低但又需要一点简单混淆的场景比如防止资源被文本编辑器直接打开绝不能用于保护核心资产。AES加密是美国联邦标准经过全球密码学家多年检验在正确使用如选择合适的模式、管理好密钥的前提下目前被认为是计算上安全的。它的性能开销在现代CPU尤其是支持AES-NI指令集的CPU上已经非常小完全在游戏可接受的范围内。性能对比资料也提到加密不是免费的午餐但AES这份“午餐”的价格性能损耗对于其带来的安全保障来说是超值的。关于AES的使用要点模式选择通常使用CBC模式。它需要一个初始化向量IV来增加随机性防止相同的明文块加密后产生相同的密文块。IV不需要保密但必须不可预测通常可以随机生成并保存在加密文件头部。密钥管理这是安全的核心。密钥绝不能硬编码在客户端代码里。常见的策略是将密钥拆分成多个部分分别存放在不同的位置如一部分在代码中一部分从服务器首次启动时下发一部分由设备信息生成并在内存中使用后尽快清除。更高级的做法是结合白盒加密或使用硬件安全区域如iOS的Keychain、Android的Keystore。填充AES是块加密算法需要数据长度是16字节的倍数。我们使用PKCS7填充标准。2.3 内存加载方案选型LoadFromMemory vs LoadFromStream这是影响运行时性能和内存占用的关键选择。AssetBundle.LoadFromMemory(byte[] binary)工作原理需要先将整个加密文件读取到byte[]然后解密到另一个byte[]最后将这个完整的解密数据数组交给API。优点接口简单逻辑清晰。缺点内存峰值高。假设一个加密AB包是100MB解密后可能变为100MB那么在解密瞬间内存中会同时存在加密数据100MB和解密数据100MB的两个完整副本峰值内存增加超过200MB对于移动设备是巨大的压力。解密完成后加密数据的数组才能被GC回收。AssetBundle.LoadFromStream(Stream stream)工作原理我们实现一个自定义的Stream类例如AesDecryptStream。Unity引擎会从这个Stream中按需读取数据。我们可以在Read方法内部实现解密逻辑引擎读多少我们就解密多少。优点内存效率极高。只需要一个较小的缓冲区例如AES的一个块大小16KB用于解密操作内存占用是常数级别的。非常适合加载大型AB包。缺点实现稍复杂需要正确处理Stream的Position,Length,Seek等属性以兼容Unity的加载器。并且不能与AssetBundle.LoadFromFile或LoadFromMemoryAsync混合使用因为Stream的生命周期需要手动管理。结论对于追求性能和内存优化的项目LoadFromStream是更优的选择。这也是本次教程我们将重点实现的方式。它能有效避免因加密解密过程引发的内存暴涨从而规避“由于设备驱动程序的前一个实例仍在内存中”这类内存问题引发的连锁反应虽然该热词原意不同但内存管理不当的本质是相通的。3. 实战第一步创建AES加密工具Editor工具我们首先在Unity Editor下创建一个工具用于在打包后自动加密AB包。3.1 创建编辑器脚本与菜单在项目的Editor文件夹下如果没有就创建一个新建一个C#脚本命名为AssetBundleEncryptor.cs。using UnityEngine; using UnityEditor; using System.IO; using System.Security.Cryptography; using System; public static class AssetBundleEncryptor { // 这是一个示例密钥和IV。真实项目中必须通过安全的方式生成和管理 // AES-256 需要32字节的密钥 AES-128 需要16字节。 private static readonly byte[] s_AesKey { 0x01, 0x23, 0x45, 0x67, 0x89, 0xAB, 0xCD, 0xEF, 0xFE, 0xDC, 0xBA, 0x98, 0x76, 0x54, 0x32, 0x10, 0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF }; private static readonly byte[] s_AesIV { 0x0F, 0x1E, 0x2D, 0x3C, 0x4B, 0x5A, 0x69, 0x78, 0x87, 0x96, 0xA5, 0xB4, 0xC3, 0xD2, 0xE1, 0xF0 }; [MenuItem(Tools/AssetBundle/Encrypt All Bundles)] public static void EncryptAllBundles() { // 1. 定位AssetBundle的输出目录 string outputPath Path.Combine(Application.streamingAssetsPath, AssetBundles); // 或者使用你的自定义输出路径 // string outputPath “你的AB包输出路径”; if (!Directory.Exists(outputPath)) { Debug.LogError($AssetBundle目录不存在: {outputPath}); return; } // 2. 遍历目录下所有文件 string[] allFiles Directory.GetFiles(outputPath, *, SearchOption.AllDirectories); int processedCount 0; foreach (string filePath in allFiles) { // 跳过.meta等非AB包文件 if (filePath.EndsWith(.meta) || filePath.EndsWith(.manifest)) { continue; } EncryptSingleBundle(filePath); processedCount; } Debug.Log($加密完成共处理 {processedCount} 个文件。); AssetDatabase.Refresh(); // 刷新编辑器让新文件可见 } private static void EncryptSingleBundle(string originalFilePath) { try { // 3. 读取原始文件 byte[] originalBytes File.ReadAllBytes(originalFilePath); // 4. 使用AES加密 byte[] encryptedBytes EncryptBytesWithAes(originalBytes); // 5. 写入加密文件这里选择覆盖原文件也可生成新文件 // 重要在实际项目中建议先写入临时文件成功后再替换防止加密过程出错导致原文件损坏。 string tempFilePath originalFilePath .encrypted.tmp; File.WriteAllBytes(tempFilePath, encryptedBytes); // 替换原文件 File.Delete(originalFilePath); File.Move(tempFilePath, originalFilePath); Debug.Log($已加密: {Path.GetFileName(originalFilePath)}); } catch (Exception e) { Debug.LogError($加密文件 {originalFilePath} 时发生错误: {e.Message}); } } public static byte[] EncryptBytesWithAes(byte[] plainBytes) { using (Aes aesAlg Aes.Create()) { aesAlg.Key s_AesKey; aesAlg.IV s_AesIV; aesAlg.Mode CipherMode.CBC; aesAlg.Padding PaddingMode.PKCS7; using (ICryptoTransform encryptor aesAlg.CreateEncryptor()) using (MemoryStream msEncrypt new MemoryStream()) { using (CryptoStream csEncrypt new CryptoStream(msEncrypt, encryptor, CryptoStreamMode.Write)) { csEncrypt.Write(plainBytes, 0, plainBytes.Length); csEncrypt.FlushFinalBlock(); // 确保所有数据写入并应用填充 return msEncrypt.ToArray(); } } } } }注意上述代码中的s_AesKey和s_AesIV是硬编码的示例绝对不可用于生产环境生产环境中密钥应由构建服务器生成或通过安全的配置系统注入并且每个项目、甚至每个版本都应使用不同的密钥。3.2 工具使用流程与注意事项构建AssetBundle首先通过Unity的AssetBundle构建管道如BuildPipeline.BuildAssetBundles构建出原始的AB包。执行加密在Unity Editor菜单栏点击Tools - AssetBundle - Encrypt All Bundles。工具会遍历指定目录示例中是StreamingAssets/AssetBundles加密所有非.meta和.manifest文件。验证你可以尝试用文本编辑器打开加密后的AB包看到的将是乱码。而用未加密的加载方式去加载它Unity会报错提示文件格式错误。实操心得备份原文件在实际的自动化构建流程中建议先复制原始AB包到另一个目录进行加密保留一份原始文件用于调试和比对。文件头标识更专业的做法是在加密文件的开头写入一个特定的魔数Magic Number或版本号。这样在运行时加载器可以快速判断一个文件是否已被加密、是哪种加密方式。例如在加密后的数据前追加4字节的标识0xABCD1234。与构建流程集成可以通过继承IPostprocessBuildWithReport接口在构建完成后自动调用加密逻辑实现一键打包并加密。4. 实战第二步实现运行时AES解密流与加载器接下来是更核心的部分在运行时加载加密的AB包。我们将实现一个AesDecryptStream并封装一个易用的资源加载管理器。4.1 创建AesDecryptStream类这个类继承自Stream并重写关键方法使其能透明地进行解密。using System; using System.IO; using System.Security.Cryptography; public class AesDecryptStream : Stream { private readonly Stream _baseStream; // 底层加密文件的流 private readonly ICryptoTransform _decryptor; private readonly CryptoStream _cryptoStream; // 内部缓冲区用于缓存解密后的数据块 private byte[] _decryptedBuffer; private int _decryptedBufferOffset 0; private int _decryptedBufferCount 0; public AesDecryptStream(Stream baseStream, byte[] key, byte[] iv) { _baseStream baseStream ?? throw new ArgumentNullException(nameof(baseStream)); using (Aes aes Aes.Create()) { aes.Key key; aes.IV iv; aes.Mode CipherMode.CBC; aes.Padding PaddingMode.PKCS7; _decryptor aes.CreateDecryptor(); } // CryptoStream本身也是一个Stream我们将其置于“读模式”从它里面读取解密后的数据。 // 注意CryptoStream在Dispose时会自动关闭_baseStream这里我们传入leaveOpen: true来避免。 _cryptoStream new CryptoStream(_baseStream, _decryptor, CryptoStreamMode.Read, leaveOpen: true); // 设置一个合理的缓冲区大小例如AES块大小的倍数16KB _decryptedBuffer new byte[16 * 1024]; } public override int Read(byte[] buffer, int offset, int count) { int totalBytesRead 0; while (count 0) { // 如果内部缓冲区没有数据了就从CryptoStream中读取下一块 if (_decryptedBufferOffset _decryptedBufferCount) { _decryptedBufferCount _cryptoStream.Read(_decryptedBuffer, 0, _decryptedBuffer.Length); _decryptedBufferOffset 0; // 如果CryptoStream也读完了返回0说明已到文件尾 if (_decryptedBufferCount 0) { break; } } // 从内部缓冲区拷贝数据到用户提供的buffer int bytesToCopy Math.Min(_decryptedBufferCount - _decryptedBufferOffset, count); Array.Copy(_decryptedBuffer, _decryptedBufferOffset, buffer, offset, bytesToCopy); _decryptedBufferOffset bytesToCopy; offset bytesToCopy; count - bytesToCopy; totalBytesRead bytesToCopy; } return totalBytesRead; } // 必须重写的基础属性对于只读的AssetBundle加载流我们只需要支持读取。 public override bool CanRead true; public override bool CanSeek false; // 注意CryptoStream在CBC模式下通常不支持随机访问Seek除非使用特殊的模式。 public override bool CanWrite false; public override long Length throw new NotSupportedException(加密流的长度在解密前未知); public override long Position { get throw new NotSupportedException(); set throw new NotSupportedException(); } public override long Seek(long offset, SeekOrigin origin) throw new NotSupportedException(); public override void SetLength(long value) throw new NotSupportedException(); public override void Write(byte[] buffer, int offset, int count) throw new NotSupportedException(); public override void Flush() { } protected override void Dispose(bool disposing) { if (disposing) { _decryptor?.Dispose(); _cryptoStream?.Dispose(); // _baseStream 会被 _cryptoStream 关闭因为我们传入了leaveOpen: true所以这里需要手动关闭 _baseStream?.Dispose(); } base.Dispose(disposing); } }关键点解析CanSeek返回false这是最重要的限制。AES CBC模式是链式的解密第N个块需要依赖第N-1个块的密文。因此无法直接跳到文件中间开始解密。Unity的AssetBundle.LoadFromStream在加载标准AB包时本身也不要求Stream必须支持Seek。但如果你使用了某些需要随机访问资源的特性如AssetBundle的依赖加载可能会遇到问题。这是选择此方案时需要接受的权衡。缓冲区设计我们使用了一个中间缓冲区_decryptedBuffer。CryptoStream.Read每次解密出一块数据我们将其暂存然后提供给Unity引擎的Read调用。这比每次只解密Unity请求的几个字节要高效。流生命周期我们严格管理Dispose确保CryptoTransform、CryptoStream和底层的FileStream都被正确释放避免资源泄露。4.2 封装资源加载管理器现在我们创建一个管理类统一处理加密AB包的加载、缓存和卸载。using UnityEngine; using System.Collections.Generic; using System.IO; using System; public class EncryptedAssetBundleManager : MonoBehaviour { private static EncryptedAssetBundleManager s_instance; public static EncryptedAssetBundleManager Instance { get { if (s_instance null) { GameObject go new GameObject(EncryptedAssetBundleManager); s_instance go.AddComponentEncryptedAssetBundleManager(); DontDestroyOnLoad(go); } return s_instance; } } // 缓存已加载的AssetBundle private Dictionarystring, AssetBundle _loadedBundles new Dictionarystring, AssetBundle(); // 缓存正在进行的异步操作防止重复加载 private Dictionarystring, AssetBundleCreateRequest _loadingRequests new Dictionarystring, AssetBundleCreateRequest(); // 示例密钥和IV必须与加密工具保持一致生产环境应从安全位置获取。 private byte[] _aesKey new byte[32] { /* 你的32字节密钥 */ }; private byte[] _aesIV new byte[16] { /* 你的16字节IV */ }; public AssetBundle LoadBundle(string bundleName) { string bundlePath GetBundlePath(bundleName); if (_loadedBundles.TryGetValue(bundleName, out AssetBundle cachedBundle)) { Debug.Log($Bundle [{bundleName}] 已缓存直接返回。); return cachedBundle; } // 1. 创建文件流 FileStream fileStream new FileStream(bundlePath, FileMode.Open, FileAccess.Read); // 2. 创建解密流 AesDecryptStream decryptStream new AesDecryptStream(fileStream, _aesKey, _aesIV); // 3. 从解密流加载AssetBundle AssetBundle bundle AssetBundle.LoadFromStream(decryptStream); // 4. 关闭流 (LoadFromStream会持有流的引用但根据文档我们应在加载后关闭流) decryptStream.Close(); fileStream.Close(); if (bundle ! null) { _loadedBundles[bundleName] bundle; Debug.Log($成功同步加载加密Bundle: {bundleName}); } else { Debug.LogError($加载加密Bundle失败: {bundleName}); } return bundle; } public void LoadBundleAsync(string bundleName, ActionAssetBundle onComplete) { if (_loadedBundles.TryGetValue(bundleName, out AssetBundle cachedBundle)) { onComplete?.Invoke(cachedBundle); return; } if (_loadingRequests.ContainsKey(bundleName)) { Debug.LogWarning($Bundle [{bundleName}] 正在异步加载中请勿重复请求。); // 可以在这里添加回调到现有请求的逻辑这里简化处理。 return; } StartCoroutine(CoLoadBundleAsync(bundleName, onComplete)); } private System.Collections.IEnumerator CoLoadBundleAsync(string bundleName, ActionAssetBundle onComplete) { string bundlePath GetBundlePath(bundleName); // 异步读取文件字节UnityWebRequest或File.ReadAllBytesAsync在某些平台更好这里用WWW举例新项目建议用UnityWebRequest // 注意为了使用LoadFromStream我们需要先获得文件流。这里演示一个变通方案先异步读取到内存再创建MemoryStream。 // 对于大文件这有内存峰值问题。理想方案是使用支持异步读的文件流但Unity的LoadFromStream是同步接口。 // 因此更常见的异步加载加密AB包做法是先异步将加密文件读入内存byte[]然后在主线程解密并调用LoadFromMemoryAsync。 // 这里展示LoadFromMemoryAsync的方案因为它更通用。 byte[] encryptedBytes null; using (UnityEngine.Networking.UnityWebRequest www UnityEngine.Networking.UnityWebRequest.Get(bundlePath)) { www.downloadHandler new UnityEngine.Networking.DownloadHandlerBuffer(); yield return www.SendWebRequest(); if (www.result UnityEngine.Networking.UnityWebRequest.Result.Success) { encryptedBytes www.downloadHandler.data; } else { Debug.LogError($下载Bundle失败 [{bundleName}]: {www.error}); onComplete?.Invoke(null); yield break; } } // 在主线程解密解密是CPU密集型操作可以考虑分帧进行 byte[] decryptedBytes null; yield return StartCoroutine(DecryptBytesOnMainThread(encryptedBytes, (result) decryptedBytes result)); if (decryptedBytes null) { Debug.LogError($解密Bundle失败 [{bundleName}]); onComplete?.Invoke(null); yield break; } // 异步从内存加载AssetBundle AssetBundleCreateRequest createRequest AssetBundle.LoadFromMemoryAsync(decryptedBytes); _loadingRequests[bundleName] createRequest; yield return createRequest; _loadingRequests.Remove(bundleName); if (createRequest.assetBundle ! null) { _loadedBundles[bundleName] createRequest.assetBundle; Debug.Log($成功异步加载加密Bundle: {bundleName}); onComplete?.Invoke(createRequest.assetBundle); } else { Debug.LogError($异步加载AssetBundle失败: {bundleName}); onComplete?.Invoke(null); } } private System.Collections.IEnumerator DecryptBytesOnMainThread(byte[] encryptedBytes, Actionbyte[] callback) { byte[] decryptedBytes null; // 在实际项目中对于大文件这里应该分帧解密避免卡顿。 // 示例使用简单同步解密在协程中执行。 System.Threading.Tasks.Task.Run(() { try { using (Aes aes Aes.Create()) { aes.Key _aesKey; aes.IV _aesIV; aes.Mode CipherMode.CBC; aes.Padding PaddingMode.PKCS7; using (ICryptoTransform decryptor aes.CreateDecryptor()) using (MemoryStream msEncrypt new MemoryStream(encryptedBytes)) using (CryptoStream csDecrypt new CryptoStream(msEncrypt, decryptor, CryptoStreamMode.Read)) using (MemoryStream msDecrypt new MemoryStream()) { csDecrypt.CopyTo(msDecrypt); decryptedBytes msDecrypt.ToArray(); } } } catch (Exception e) { Debug.LogError($解密过程出错: {e.Message}); } }).Wait(); // 注意这里Wait会阻塞仅作示例。生产环境应用更复杂的异步解密。 callback?.Invoke(decryptedBytes); yield return null; } public void UnloadBundle(string bundleName, bool unloadAllLoadedObjects false) { if (_loadedBundles.TryGetValue(bundleName, out AssetBundle bundle)) { bundle.Unload(unloadAllLoadedObjects); _loadedBundles.Remove(bundleName); Debug.Log($已卸载Bundle: {bundleName}); } } private string GetBundlePath(string bundleName) { // 根据平台组合路径示例为StreamingAssets路径 string platformFolder GetPlatformFolder(); return Path.Combine(Application.streamingAssetsPath, platformFolder, bundleName); } private string GetPlatformFolder() { switch (Application.platform) { case RuntimePlatform.Android: return Android; case RuntimePlatform.IPhonePlayer: return iOS; case RuntimePlatform.WebGLPlayer: return WebGL; case RuntimePlatform.WindowsPlayer: case RuntimePlatform.WindowsEditor: return Windows; case RuntimePlatform.OSXPlayer: case RuntimePlatform.OSXEditor: return macOS; // ... 其他平台 default: return Application.platform.ToString(); } } void OnDestroy() { foreach (var bundle in _loadedBundles.Values) { if (bundle ! null) bundle.Unload(true); } _loadedBundles.Clear(); _loadingRequests.Clear(); } }代码要点与避坑指南异步加载的复杂性AssetBundle.LoadFromStream本身是同步接口且要求Stream不支持异步读取。因此实现真正的“异步流解密加载”非常复杂。上述代码的异步方案退回到了LoadFromMemoryAsync即先异步下载整个加密文件到内存再解密到另一个内存块最后异步加载。这会带来内存峰值但对于中小型AB包是可接受的。如果必须使用LoadFromStream且要异步可能需要自己实现一个支持BeginRead/EndRead的异步Stream包装器并确保Unity的加载器能兼容这属于高级话题。密钥管理_aesKey和_aesIV在示例中仍是硬编码。真实项目中它们应该在游戏启动时从服务器动态获取经过HTTPS或通过代码混淆、分段存储等方式保护。核心原则不要给破解者一个完整的、静态的密钥。内存流与文件流同步加载使用了FileStreamAesDecryptStream内存效率高。异步加载使用了UnityWebRequest下载到byte[]再解密内存效率低但实现简单。你需要根据项目需求包体大小、目标平台选择或混合使用。卸载UnloadBundle方法提供了卸载接口。注意bundle.Unload(false)只卸载AB包容器已加载的资产如Texture, GameObject如果还在被引用则不会卸载。bundle.Unload(true)会强制卸载所有从中加载的资产可能导致场景中的引用丢失变成Missing。管理好AB包的生命周期是避免内存泄露的另一关键。5. 性能优化与平台适配要点实现基础功能后我们需要关注性能和不同平台的兼容性。5.1 性能考量与实测数据加密解密必然带来CPU开销。你需要在实际的目标设备上进行性能分析。WebGL平台需要特别小心。热词中提到了“unity webgl初始化很久”。WebGL是单线程的所有解密操作都会阻塞主线程导致卡顿。对于WebGL项目建议将AB包尺寸做小减少单次解密的数据量。建议在显示加载界面时进行解密让玩家感知为加载时间。避免在游戏运行时同步解密大文件。可以尝试使用WebAssembly或Web Workers进行异步解密如果Unity版本和构建设置支持但这需要更复杂的前端集成。移动平台iOS/AndroidAES硬件加速现代ARM CPU大多支持AES指令集System.Security.Cryptography.Aes类在IL2CPP后端下通常会调用这些指令性能损失相对可控。但仍需测试。内存与发热持续的解密操作会增加CPU使用率可能导致设备发热。应避免在每帧都进行解密操作。性能测试方法在目标设备上分别测试加载未加密AB包、使用内存解密加载、使用流式解密加载三种方式的耗时和内存分配。使用Unity Profiler关注LoadFromMemory/LoadFromStream调用前后的GC Alloc和Total Memory变化。5.2 多平台路径与读取方式不同平台读取文件的方式不同我们的GetBundlePath和加载逻辑需要适配。AndroidApplication.streamingAssetsPath指向APK内的压缩目录不能直接用File.ReadAllBytes。必须使用UnityWebRequest或WWW来读取。上述异步加载示例已经使用了UnityWebRequest这在Android上是正确的。iOS对Application.streamingAssetsPath可以直接使用File.ReadAllBytes。Windows/Mac/Linux (Standalone)可以直接使用File.ReadAllBytes或FileStream。WebGLApplication.streamingAssetsPath指向服务器URL必须使用UnityWebRequest。一个健壮的路径获取与加载方法需要根据平台分支处理。更佳实践是使用UnityWebRequest统一处理所有平台的远程或StreamingAssets文件读取因为它具有最广泛的平台兼容性。5.3 与Addressables系统的结合如果你的项目使用了Unity的Addressable Asset System加密方案需要集成进去。Addressables提供了IResourceProvider接口允许你自定义资源的加载逻辑。你可以创建一个自定义的Provider在它的LoadInternal方法中插入你的解密流程。这样你仍然可以使用Addressables的加载、依赖、释放等强大功能同时底层资源是加密的。这是更现代化、也更复杂的集成方案。6. 常见问题排查与安全加固实录即使代码写完了在实际集成和运行中你一定会遇到各种问题。下面是我总结的常见“坑点”和解决方法。6.1 加载失败魔数错误或数据损坏问题现象调用LoadFromStream或LoadFromMemory后返回null或Unity报错“不是有效的AssetBundle文件”。排查步骤检查加密/解密密钥是否一致这是最常见的原因。确保打包服务器和客户端使用的密钥和IV完全一致字节对字节。建议将密钥信息输出到日志仅调试版本进行比对。检查文件是否真的被加密用二进制编辑器对比加密前后文件的大小和头部数据。加密后的文件应该面目全非。如果只是大小变了但头部还能看到UnityFS等字样说明加密可能没生效。检查填充Padding确保加密和解密都使用相同的填充模式如PKCS7。如果填充不一致解密出的最后几个字节会是错误的导致整个AB包数据损坏。检查CryptoStream的关闭时机在同步加载示例中我们在LoadFromStream之后立即关闭了流。但根据Unity文档的某些版本和情况LoadFromStream可能会延迟读取数据。保险的做法是不要立即关闭流而是将流的生命周期与AssetBundle绑定。可以创建一个包装类在AssetBundle卸载时再关闭流。不过我们的AesDecryptStream在Read方法中已经缓冲了数据提前关闭底层FileStream可能没问题但这依赖于实现细节。最安全的方法是让流一直打开直到AB包卸载。6.2 内存泄露与性能问题问题现象游戏运行一段时间后内存持续增长或加载大型AB包时瞬间卡顿。排查与解决Profiler是你的朋友使用Unity Memory Profiler查看AssetBundle和Texture等资源的引用情况。确认每次调用UnloadBundle后相关的内存是否被释放。流式加载的内存优势如果使用LoadFromStream在Profiler中你应该看到加载AB包时GC Alloc和Total Memory不会有大幅飙升。如果仍有飙升检查是否在解密过程中创建了不必要的完整字节数组副本。异步加载的卡顿如果在协程中同步解密大块数据如DecryptBytesOnMainThread中的Task.Run(...).Wait()会导致主线程卡住。解决方案是分帧解密。可以将解密任务分解成多个小块每帧解密一部分通过yield return null来避免卡顿。虽然总时间可能变长但帧率更平滑。WebGL的特别优化对于WebGL由于单线程限制分帧解密尤为重要。可以考虑将AB包在服务器端进行分块加密客户端按需加载和解密小块。6.3 安全加固建议加密只是安全的第一道防线。一个坚定的破解者仍然可以动态调试你的游戏在内存中抓取解密后的AB包数据或者直接Hook你的解密函数。代码混淆使用像Obfuscator这样的工具对DLL进行混淆增加静态分析和动态调试的难度。密钥动态组合不要使用一个完整的静态密钥。可以将密钥拆散一部分来自代码中的常量一部分从服务器响应中获得一部分由设备ID或用户信息哈希生成。在运行时动态组合。内存擦除解密完成后尽快将保存密钥和原始解密数据的字节数组用随机数据覆盖Array.Clear减少内存中敏感信息驻留的时间。检测调试器在发布版本中加入反调试代码虽然不能完全阻止但可以提高门槛。完整性校验对加密后的AB包计算一个哈希值如SHA256存储在manifest或服务器上。加载时先校验文件哈希防止资源被篡改。记住没有绝对的安全。我们的目标是提高破解成本使得破解所需的技术、时间和精力远超其获取的收益从而保护大多数资源的安全。7. 总结与个人体会实现一套完整的AssetBundle加密加载方案远不止是调用Aes.Encrypt和LoadFromStream那么简单。它涉及构建管道的改造、运行时架构的设计、平台细节的适配以及性能与安全的权衡。我个人在多个项目中实践下来的体会是首先明确需求。如果你的资源价值不高或者项目是内部工具或许简单的混淆甚至不加密都可以。但如果涉及商业资产加密是必须的。其次流式加载LoadFromStream是处理大型加密AB包的优选。它能有效控制内存峰值避免因解密大文件导致的瞬间内存暴涨和GC压力。虽然牺牲了随机访问能力但对于大多数按需加载的场景是足够的。再次密钥管理是灵魂。再坚固的加密算法如果密钥放在客户端明文中就等于把钥匙挂在门上。花在密钥安全管理上的心思应该和花在加密算法本身一样多。最后一定要做全平台、全流程的测试。在Editor下能跑通不代表在真机尤其是WebGL和移动端没问题。务必在目标平台上测试从打包、加密、分发到加载、卸载的完整流程用Profiler监控性能和内存确保没有泄露和卡顿。这套方案为你提供了一个坚实可靠的起点。你可以根据自己项目的具体需求在此基础上进行扩展例如集成到Addressables、实现更复杂的密钥分发系统、或者增加资源压缩与加密的混合处理。希望这篇长文能帮你彻底告别AssetBundle资源泄露的隐患让你的项目更加安全稳健。
