企业官网建设流程全解析

做Unity境外发行项目，Google分包处理几乎是必经之路。商店上传要求使用Android App Bundle，为了控制安装包体积，开发阶段都需要开启Play Asset Delivery（也就是我们常说的分包/Asset Pack）。我这边跟进的一个项目就是在这个节骨眼上出的问题：包确实从近200MB压到了80MB左右，但随之而来的是QA和用户反馈——所有通过CRI音效中间件播放的按钮音、技能音全部消声，过场视频直接黑屏，而普通音乐和UI却一切正常。最诡异的点是，你把同样的资源包换成旧式APK直装，一切都好；一旦从商店下载或者通过AAB格式安装，问题就复现。这个现象当时排查了整整两天，最后发现根子不在CRI，也不在Unity版本，而在分包模式下资源的存放位置变了，CRI那套基于文件路径的加载逻辑找不到文件了。

1. 问题现场：包变小了，声音和视频也消失了

先列一个我当时收集到的问题表现清单，方便大家对照排查：

• 正常：主界面BGM、操作手感反馈（如果用的是Unity原生AudioSource）、UI动画、场景逻辑。
• 异常：所有CriAtomSource触发的音效丢失，连初始化日志里都能看到大量Cue解析失败。
• 异常：CriManaPlayer播放的过场视频黑屏或卡在首帧，但进度计时器在走。
• 异常：部分机型上运行一段时间后，整个项目卡顿，疑似底层不断重试加载失败资源。

最迷惑的地方在于“旧APK没问题”。这说明代码逻辑、资源本身都没有损坏，纯粹是分发形态变化后，某个环节断了。

1.1 快速下个结论：分包让CRI找不到文件

CRIWARE里的ADX音频和Sofdec视频，在Unity上的加载方式和Unity原生AudioClip有本质区别。原生AudioClip搞成AssetBundle或Addressables后，运行时Unity会替你维护资源生命周期，你几乎感知不到文件路径的存在。CRI虽然也有内存加载API，但绝大多数项目沿用最传统的“文件路径加载”方式：ACF配置、ACB库、CPK容器、USM视频，都是默认从StreamingAssets目录或手动注册的外部目录读取。

分包机制一启用，这些文件可能被拆到不同的Asset Pack里，尤其是fast-follow和on-demand模式的包，安装完成后并不会立刻出现在设备上。CRI在初始化时去StreamingAssets下找文件，自然一无所获。这一步理解了，后面所有排查和修复思路都顺了。

2. Google分包机制到底动了什么：三种投放模式与Unity构建产物

要彻底搞清楚这个问题，得先看Google Play Asset Delivery是怎么组织资源的。很多刚转AAB的同学容易把“分包”理解成简单的分片压缩，其实它是一个独立于APK的资源投递系统，有自己的一套生命周期和目录约定。

2.1 install-time / fast-follow / on-demand三种模式

Play Asset Delivery把资源组织成一个个Asset Pack，然后允许你为每个资源包选择投放模式。这三种模式差别非常大，决定了文件“什么时候出现在设备上”。

问题恰恰出在后面两种。install-time的包，安装完成后文件就在应用数据目录里，等价于旧APK的老路径，CRI大概率还能按老办法找到文件。而fast-follow和on-demand的文件，在用户首次打开App时根本不在本地，或者被放在一个CRI默认不知道的目录里。如果你在分包配置里把包含CPK/USM的目录设成了fast-follow或on-demand，那CRI必然找不到。

2.2 Unity构建时，StreamingAssets和AssetBundle去了哪里

Unity构建AAB时，资源去向大体分三类：

• 直接打进base模块（基础APK）的：脚本、场景、普通AssetBundle、部分StreamingAssets。
• 放进install-time Asset Pack的：由Android插件配置指定的资源，通常包括拆分的“Split Application Binary”部分。
• 放进fast-follow/on-demand Asset Pack的：通过Play Asset Delivery的API或Unity的Addressables配置的包。

这里的坑在于，Unity对StreamingAssets的处理比较特殊：当你开启Split Application Binary后，StreamingAssets可能被单独拿到一个install-time的AssetPack里，仍然在设备的数据目录内。但如果你的CRI文件是放在StreamingAssets/CRI/这个目录下，而这个目录整体配给了一个install-time pack，那理论上旧路径还能用；如果某个版本Unity把它归为按需包，或者你用了PAD API去指定子目录，情况就完全不同了。因此最稳妥的做法不是赌路径，而是直接把CRI资源处理成AssetBundle字节资产。

2.3 手工检查AAB产物的方法

开发阶段不要只在Unity里看Build Report，务必解包确认文件去向。常用方法有两个：

• 使用Android SDK自带的bundletool系列指令查看包内结构，确认CPK/USM到底在哪个module或asset_pack下。
• 把AAB转成APKS后，逐个检查拆分出来的APK是否包含目标资源。

构建后执行一条bundletool build-apks命令，再用压缩工具看APKS内部的资源分布，只要能看到资源体积和目录结构，心里就有底。如果发现某个CRI资源出现在“asset pack”目录下，而它的投放模式是fast-follow，那基本就是这个环节出了问题。

3. 从日志到落地：一次完整的排错定位链路

分包问题最气人的地方在于，很多错误不是直接报“找不到文件”，而是表现得像资源损坏或插件初始化失败。这里分享我当时完整的定位链路，按顺序走不会走弯路。

3.1 第一层：看Unity日志里的CRI关键信息

在Android设备上跑，用adb连着logcat过滤CRI相关标签。常见可靠关键字包括CriFsPlugin、CriAtomEx、CriMana、CriFsUtility等。我当时的日志里反复出现类似：

E CriAtomEx : snb file not found E CriFsPlugin: dump file open error

这就是CRI在尝试按路径打开ACB/CPK文件但失败了。如果你能把日志里对应的文件名字和代码里传入的路径对上，立即就能定位到是哪个CRI资源在缺。

3.2 第二层：解包，找文件到底在不在

拿到构建机器上的.aab文件，用工具打开，切到asset_pack目录。我的项目里资源路径是StreamingAssets/CRI/ATOM/xxx.cpk，正常情况下它应该出现在base模块或install-time AssetPack里。结果我在aab里看到了一个asset pack叫asset_pack_xxx，里面确实有CPK，但该pack声明的交付模式是fast-follow，这下问题就清楚了——它不是不存在，而是还没下载。很多同学在这个环节会漏掉一点：aab里的文件名和路径只是“打包预期”，真正落地还要看设备上的AssetPackManager状态。

3.3 第三层：在真机上验证AssetPack下载状态

这一步是整条链路里最容易被跳过的，却很关键。用Google Play提供的Core API，或者直接在测试轨道安装后进行代码打点，输出当前AssetPack状态。我当时的打印显示，资源包的下载状态一直停留在“PENDING”，因为测试账号没把fast-follow的下载触发出来。这意味着，即便CRI代码写得再正确，启动瞬间也拿不到文件。确认这层之后，修复目标就很明确了：保证CRI初始化时需要的文件一定在本地，或者等文件到位后再初始化CRI。

3.4 第四层：排除解码和权限干扰

有时候日志里没有明确的not found，反而会往解码方向误引。建议顺手确认两件事：一是CRI的播放组件初始化是否调用成功，二是AndroidManifest里是否有必需的存储权限。如果旧APK能播、AAB不能播，那权限和硬件解码基本可以排除，不用在那边耗时间。

4. 修复方案的底层逻辑：三条路，按需选

定位清楚后，修复没有统一答案，取决于你项目的包体积目标、CRI资源规模和启动时序。下面三个方向都可以，我建议新项目直接走方案三，老项目稳妥走方案一。

4.1 方案一：把CPK/USM全部变成AssetBundle字节资产，再包进AssetPack

原理：CRI虽然不认Unity资产里的TextAsset，但我们可以在构建阶段把.cpk/.usm/.acf等文件作为.bytes导入，打成AssetBundle。运行时先从这个AssetBundle里把byte[]取出来，写入Application.persistentDataPath下的临时目录，然后让CRI像访问旧文件一样访问新写入的路径。

这个方案的优点是实现路径最通用，不依赖CRI的额外API，也不需要改动太多运行时逻辑。缺点是要多一次磁盘写入，且persistentDataPath空间有限，视频多的时候要控制生命周期。

关于持久化目录写临时文件，我补充一个细节：每次App版本更新前，最好清理掉旧版本遗留的CRI临时文件，否则新包版本号变了而旧文件还在，可能让CRI读到上一个版本的Cue表，出现诡异错位。

4.2 方案二：让CRI直接认识AssetPack目录，走搜索路径或mount

如果你不想做额外磁盘拷贝，希望CRI直接读取AssetPack落地后的文件，那就需要把AssetPack的真实目录告诉CRI。Unity侧可以通过Google Play Core的API拿到asset pack的路径，然后把它添加到CRI的文件系统搜索路径中。这个方案适合大视频包、不介意让CRI去二次挂载的场景，但要注意AssetPack的下载完成时机和路径在不同设备上的差异性，兼容性风险比方案一高。

4.3 方案三：使用CRI官方提供的Addressables扩展

CRI在近几年的SDK里提供了和Unity Addressables堆栈对接的扩展组件，核心思路是把CRI的ACF/ACB/CPK资源声明为Addressable资产，通过Addressables的远程/本地分组加载。这样分包时可以直接利用Addressables的Build Script生成AssetBundle，再由Play Asset Delivery处理。

这条路线最省心，但它会把项目资源组织方式往Addressables方向带，如果你现有的整个资源链路还是传统AssetBundle+自定义热更，强行迁移成本会比较高。

4.4 选型决策表

我当时选的是方案一，因为项目已经有成熟的AssetBundle热更框架，只新增了一小段“导出CRI字节到持久化目录”的逻辑，其余CRI调用完全不用动，风险最小。

5. 实操记录：把CRI资源安安稳稳放进AssetBundle再分包

下面按方案一记录一遍完整操作，大家可以直接照抄。不同CRI版本API名字可能有细微差别，但步骤是通用的。

5.1 准备资源：把CPK/USM变成.bytes资产

在Unity工程里，把CPK、ACF、USM这些CRI文件放到一个专门的目录，比如Assets/Build/CRIRaw/，然后把文件扩展名改成.bytes，或者直接用脚本在构建前自动生成副本。为什么要改成.bytes？因为Unity不会把未知扩展名当作原生导入资源，而.bytes会被当成TextAsset，可以参加AssetBundle打包。

我个人非常不建议直接改源文件扩展名，因为Editor里CRI的PostProcessor会失去识别能力，影响你在编辑器里的预览。正确做法是保留原始CPK供Editor调试，另建一个“Build Only”目录用于打包。

5.2 构建AssetBundle，并保留原始目录ID

用一段自定义Build脚本，遍历Build/CRIRaw/下的.bytes文件，为每个目录或文件生成一个AssetBundle名，例如cri_core、cri_video_chapter1。构建参数推荐BuildAssetBundleOptions.ChunkBasedCompression，虽然体积压缩率不是最低的，但对后续读取效率更友好。构建完成后，你的AssetBundle会出现在指定输出目录，把它当成普通AssetBundle纳入你的热更或分包流程。

using UnityEngine; using UnityEditor; using System.IO; public class CriBundleBuilder { [MenuItem("Tools/Build CRITest Bundles")] public static void Build() { string srcDir = "Assets/Build/CRIRaw"; string outDir = "Build/CRIBundles"; Directory.CreateDirectory(outDir); string[] allFiles = Directory.GetFiles(srcDir, "*.bytes", SearchOption.AllDirectories); foreach (string file in allFiles) { string bundleName = Path.GetFileNameWithoutExtension(file) + ".bundle"; AssetImporter importer = AssetImporter.GetAtPath(file); importer.assetBundleName = bundleName; importer.assetBundleVariant = ""; } BuildPipeline.BuildAssetBundles(outDir, BuildAssetBundleOptions.ChunkBasedCompression, BuildTarget.Android); AssetDatabase.RemoveUnusedAssetBundleNames(); } }

5.3 配置AssetPack交付模式

如果你希望这些AssetBundle跟着App一起安装，就把它们放到install-time AssetPack里，通过Unity的播放构建设置或Gradle插件配置路径。如果你接受首包小一点、运行后快速下载，就选择fast-follow，但必须在CRI初始化之前保证下载完成。

这里要特别小心一个顺序问题：CRI的初始化通常发生在场景启动最早期，而fast-follow下载是异步的。如果在CRI初始化时文件还没到位，就会出现开头说的黑屏静音。我的建议是，要么把所有CRI运行依赖都放install-time，要么做一个“等待AssetPack下载完成且持久化导出结束，再初始化CRI”的门闩。

5.4 运行时：从AssetBundle取字节，写盘，再走CRI老接口

核心代码示意如下，具体API名称以你使用的CRI版本为准：

using System.IO; using UnityEngine; using UnityEngine.Networking; public class CriBundleLoader : MonoBehaviour { private IEnumerator LoadCriFilesFromBundle(string bundleName) { string bundlePath = Path.Combine(Application.streamingAssetsPath, "CRIBundles", bundleName); var bundleReq = AssetBundle.LoadFromFileAsync(bundlePath); yield return bundleReq; AssetBundle bundle = bundleReq.assetBundle; TextAsset cpkAsset = bundle.LoadAsset<TextAsset>("audio_cue_cpk"); string targetPath = Path.Combine(Application.persistentDataPath, "CRITmp", "audio_cue.cpk"); Directory.CreateDirectory(Path.GetDirectoryName(targetPath)); File.WriteAllBytes(targetPath, cpkAsset.bytes); // 原CRI挂载/注册逻辑，这里只是示例 CriFsUtility.MountCpk(targetPath); } }

有几个细节必须注意：

• 写入目录要固定，且每次版本切换时清理一次。
• 如果视频文件很大，建议放后台线程的磁盘缓存，不要卡主线程。
• 确认Application.persistentDataPath在部分Android机型上有大小限制，太肥的按需包不要全量写入。

5.5 验证清单：按包构建后逐项检查

最后验收时，建议按这个列表过一遍：

• 在Editor模式下构建AAB，确认AssetBundle进入了预期的AssetPack。
• 改成AAB签名安装到测试机，而不是直接跑Editor。
• 打开App看CRI初始化日志，确认CPK挂载成功，无not found。
• 重新安装并强制断网一次，确认已有文件可正常播放，避免把“等待网络下载”混成“CRI加载失败”。
• 用商店测试轨道安装fast-follow模式包，在弱网环境验证“下载-就绪-初始化”的顺序。

6. 几个容易反复踩的坑：版本、时序、生命周期

方案一虽然稳，但也不是零成本。这里把我在后续迭代中反复踩的坑整理出来，算是给这方案查漏补缺。

6.1 不要在CRI初始化回调里同步做AssetPack下载

很多开发者喜欢把所有初始化都塞在一个Start里，一旦碰到fast-follow包，就会在下载未完成时就触发CRI注册。结果是第一次失败，第二次启动才正常。正确的写法是把CRI初始化放到资源就绪之后，而不是把下载放到初始化之后。

6.2 注意临时文件的跨版本残留

我遇到过一件事：上一个版本遗留的tmp/audio_cue.cpk还在，新版本直接把ACB结构改了，结果老Cue表和新Cue表错位，播放出来的声音音高不对。解决方式是记录App版本号，版本更新时清理整个persistentDataPath/CRITmp目录。这个很容易被忽略，一上线就能炸出玄学Bug。

6.3 大视频包建议做引用计数与缓存管理

如果你的项目有大量USM过场视频，每个都解到持久化路径会越积越大。建议给每个文件维护一个引用计数，场景不再需要时就删除，或者用LRU缓存控制整体体积。否则运营版本更新两三次，用户存储就满了，很难看。

6.4 别把分包测试放在Editor或直连APK环境

分包行为只有在AAB被商店服务处理后才会完全复现，直接安装一个拆出来的APKS可能部分复现，但fast-follow和on-demand的投递时机在APKS里测不准。至少在正式发版前，请用Google Play的测试通道或本地验证工具完整走一遍“从商店安装”的流程。

这一套做下来，Google分包处理和CRI就能和平共处。我在这个项目上最大的体会是：CRI系统本身很稳定，出问题多半是它和Unity的资源流、分发流没对齐。先把资源文件在构建产物里的位置查清楚，再从加载时机上做收敛，绝大多数失声黑屏问题都能在半天内解决。

如果你们项目已经在面向Google Play做改造，我真的建议在动代码之前先建立一套“构建产物体检”流程，把每个资源包的去向和下载状态都可视化，而不是等QA拿着复现步骤来找你。多花半天在工程化检查上，能省下一周半的神秘Bug定位时间。