Android 下 StreamingAssets 的特殊姿势
ABSTRACT
个人博客笔记（Loading & Learning）。揭示 Android APK 中 StreamingAssets 段默认以 Store（不压缩）方式打包的机制：apktool 重打包时该信息对无后缀名文件丢失，导致 AssetBundle 全变 Deflate、加载显著变慢；解法是给 AB 加后缀名，或在 Gradle 里用 aaptOptions.noCompress 显式声明。
核心要点
- APK 本质是 zip 容器，内部各块可用不同压缩方式；Unity 打包时 StreamingAssets 以 AAPT 的
-0标志写入，即 Store 不压缩（AB 本身已是压缩/二进制格式，再压缩只拖慢读取）。 - 可用 Bandizip、APK Analyzer 等工具查看包内每个文件是 Store 还是 Deflate。
- 坑：apktool 解包时会记录每个文件的压缩方式并在回打包时恢复，但该功能对无后缀名文件失效——无后缀的 AB 回打包后全部变 Deflate，加载明显变慢。
- 解法一：给 AssetBundle 文件加后缀（如 .bundle），apktool 即可正确恢复 Store 标记；作者无意中因此避坑。
- 解法二：自定义 Gradle 构建时显式声明
aaptOptions { noCompress 'bundle' }，保证该后缀资源不被压缩——这也是「导出 Gradle 工程后 AB 加载变慢」的官方推荐修法。 - 同类问题表象：「出包后加密/资源处理流程导致 APK 大小无规律变化」，根因往往也是压缩方式被改变。
关键实体与概念
StreamingAssets、APK、AAPT、Store/Deflate、apktool、noCompress、aaptOptions、AssetBundle 后缀名、APK Analyzer
关联概念
来源回溯
- 原始文件：
raw/gamedev/android下streaming-assets特殊姿势-loading-learning.md（evernote/FW-游戏3研发技术 导入）
时效性评估
- 仍有效：AAPT noCompress 机制至今存在，自定义出包流水线（加密、渠道重打包）踩「压缩方式被改」的坑仍常见。
- 已过时：apktool 无后缀失效是特定旧版本 bug；现代分发形态（Addressables 远程包、Play Asset Delivery）减少了直接改 APK 内 AB 的场景，但渠道加固/重打包环节仍需核对压缩标记。