极致优化 Android 平台 APK 的大小

UE包体与内存优化实战：从数百M到百M内的Android瘦身指南

在游戏项目开发中，打包环节总是绕不开一个核心诉求：如何让每个平台的安装包尽可能小巧，以便于分发和下载？特别是对于Android平台，应用商店常有明确的体积限制。Unreal Engine本身功能强大，但也因此包含了海量代码和插件，编译后生成的libUE4.so体积庞大，动辄数百兆，再加上引擎资源和项目资产，一个空APK轻松突破数百M大关。这不仅是上架的门槛，更是对用户设备存储和运行时内存的直接压力。因此，对UE包体进行系统性裁剪，势在必行。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

一、包大小分布

要精准优化，首先得摸清“家底”。一个典型的UE Android APK中，空间占用的大头主要来自以下三部分：

• 可执行代码（.so文件）：位于 lib/arm64-v8a 目录下，通常是 libUE4.so 或 libUnreal.so，这是编译后所有引擎和游戏逻辑代码的集合体。
• 游戏内资源（main.obb）：包含打包进PAK的游戏资产，以及通过 DirectoriesToAlwaysStageAsNonUFS 配置直接放入的文件。
• 第三方组件文件：一些集成的SDK或插件会将其必要的库、模型、配置文件等拷贝到APK的特定目录。

我们的优化策略，就需要针对这三座“大山”分别制定攻坚方案。

二、压缩NativeLibs

你知道吗？APK安装时，系统对原生库（NativeLibs）的处理方式其实有两种选择：

1. 安装时就将.so文件解压到应用内部存储目录（/data/app//lib/）。
2. 直接从APK文件中加载.so，跳过解压步骤，从而加快安装速度。

这就引出了一个关键点：如果允许安装时解压，那么在打包APK时，这些.so文件是可以被压缩的。压缩与否，对最终APK大小的影响可谓天壤之别。

在原生Android开发中，这个行为由 AndroidManifest.xml 中的 `android:extractNativeLibs` 属性控制。幸运的是，新版UE引擎已经在 AndroidRuntimeSettings 配置中直接提供了 `bExtractNativeLibs` 选项，方便我们开关。

不过需要特别注意一个版本兼容性问题：在旧版本引擎（如4.27及之前）中，如果Gradle工具升级到4.2以上，其属性名会从 `extractNativeLibs` 变为 `useLegacyPackaging`，且默认值可能导致APK体积意外增大。如果遇到此情况，可以通过修改UPL脚本强制修正该属性值。

但请记住，这个设置仅仅控制.so文件在APK内是否被压缩，并不会减少.so文件本身的体积。要想真正“瘦身”，还得深入到代码优化层面。

三、代码体积优化

对于Android平台，代码优化的核心目标非常明确：全力缩减单个.so文件的大小，同时尽可能避免对运行时性能造成负面影响。

通用的NativeLibs优化思路包括：减少动态库数量、剔除内部无用符号、缩减代码段大小以及去除调试信息。然而，对于UE项目，我们能直接控制的主要是引擎和项目自身的代码。因此，接下来的策略将聚焦于如何对 libUE4.so/libUnreal.so 动刀。

1. 减小libUE4.so

UE默认采用Monolithic（单体）模式编译，所有代码最终都汇聚到一个巨大的可执行文件中。好在，UE基于UBT的编译框架和 target.cs/build.cs 中的丰富配置，为我们提供了精细控制编译过程的可能性。

优化.so体积，可以从以下几个方向入手：

• 禁用不必要的引擎模块
• 精细控制代码优化选项（如内联、优化级别）
• 关闭不必要的异常处理
• 启用链接时优化（LTO）
• 剔除无用的导出符号

(1) 禁用模块
最直接的方法，就是在项目的 target.cs 中关闭那些确认用不到的引擎内置模块。例如，如果你的项目不需要物理破坏系统Chaos或NVIDIA的APEX物理，可以直接关闭。同时，务必梳理项目引入的第三方运行时插件，减少参与编译的模块总数，从源头上削减代码量。

(2) 关闭内联（Inline）
内联是编译器为了提升运行效率而做的优化，它会将函数调用展开为函数体本身。这虽然减少了函数调用的开销，却会显著增大 .text 代码段的大小。在 target.cs 中，可以通过 `bUseInlining` 参数来控制（注意，此参数默认对Android平台可能不生效，可能需要修改UBT脚本以添加 `-fno-inline-functions` 编译参数）。

这里有个权衡：关闭内联后，对于那些被高频调用的函数，可能会带来轻微的性能损失。但根据实际测试，在多数非极端情况下，其对整体帧率的影响微乎其微，换来的体积收益却非常可观。

(3) 关闭异常处理
检查你的代码，如果确认某些模块启用了C++异常处理（`bEnableExceptions = true`），但实际上并未使用 try/catch 块，那么关闭它可以有效减少 .eh_frame 段的大小，为.so“减负”。

(4) 使用O3/Oz编译优化
在 target.cs 中，`bOptimizeForSize` 这个开关决定了编译器的优化倾向。当其关闭时，编译器采用 `-O3` 优化，以性能为优先，会积极进行内联和循环展开；当其开启时，则采用 `-Oz` 优化，以体积为优先，会尽量避免内联并保持循环结构。项目可以根据自身对性能和包体大小的敏感度来抉择。

(5) 启用链接时优化（LTO）
LTO（Link Time Optimization）允许编译器在链接阶段进行全局优化，例如跨模块的死代码消除、函数内联等。在UE中，通过 `bAllowLTCG`（Link Time Code Generation）参数控制。对于Android平台，同样需要在UBT中为其添加 `-flto=thin` 编译参数（thin是兼顾优化效果和链接时间的版本）。

(6) 剔除导出符号
默认情况下，编译出的.so文件会导出所有函数和变量符号，以便其他库调用。但对于libUE4.so而言，真正需要被外部（主要是JNI）访问的接口屈指可数。大量无用的导出符号不仅增大文件体积，也增加了内存占用。

现代链接器支持通过 `version-script` 机制精确控制符号的可见性。我们可以创建一个链接脚本，只保留必要的JNI接口符号（如 `Ja va_*`、`ANativeActivity_onCreate`、`JNI_OnLoad`），将其余所有符号设置为局部可见。在 target.cs 中，将此脚本传递给链接器，即可大幅裁剪.so的体积。

2. 优化数据

实践是检验真理的唯一标准。应用上述一系列优化策略后，效果究竟如何？

(1) so压缩后大小对比
前面提到，NativeLibs在APK内可被压缩。因此，减小.so的原始大小，能直接带来压缩后体积的下降。

经过综合优化，在Shipping构建模式下，libUE4.so的原始大小从惊人的258M降至146M。反映在APK内，压缩后的.so体积也从74.3M减少到44.67M，足足减少了29.63M。通过 readelf 工具查看优化前后的段信息对比，也能直观看到.text等核心代码段的显著缩减。

(2) 内存收益
对.so的“瘦身”不仅利好包体，对运行时内存同样有增益。系统加载.so文件时，其代码段会映射到内存中。体积变小，占用的内存自然减少。

通过Android的 `dumpsys meminfo` 命令可以查看进程的.so内存占用。对比优化前后数据，可以清晰看到“.so mmap”部分的PSS（实际使用内存）和RSS（驻留内存）均有明显下降，获得了额外的内存空间。

3. 优化策略补充

(1) 重定位表压缩
这是一个效果极为显著的“黑科技”。

① 针对SDK >= 28 (Android 9+)
当项目的 `MinSDKVersion` 大于等于28时，可以开启RELR（Relative Relocations）重定位表压缩。它利用相对地址重定位的特性，对重定位信息进行高效编码，从而大幅减少存储空间。

开启方法是在编译和链接时传递特定参数。优化后，使用 `readelf -d` 查看.so文件，会发现多出了 `RELR` 段。效果立竿见影：重定位表大小从优化前的25.82M骤降至280K，直接让.so文件缩小约25M，APK也随之减小约4M。

内存优化效果同样惊人。在Development构建下，.so内存占用从190.49M降至161.06M，减少了近30M。更重要的是，这是一种正面性能优化，通过减少运行时重定位操作，反而提升了代码加载速度。

② 针对SDK >= 23
如果项目无法升级到SDK 28，也有退而求其次的方案。使用 `-Wl,--pack-dyn-relocs=android` 链接参数，同样能压缩重定位表（虽然压缩率不如RELR），并将Development构建下的.so内存占用从190.49M降低到163.19M，节省了27.3M。

③ 最终效果
在启用重定位表压缩后，Shipping包的.so运行时内存可以进一步降低到134.74M左右，优化成果非常扎实。

四、资源裁剪

1. APK内文件

除了代码，APK内由第三方插件引入的文件也是优化重点。需要逐一分析，区别对待：

• 剔除完全不需要的第三方组件。
• 对于必需的组件，剔除其中非必要的文件（如未启用功能的模型、配置文件）。

(1) 组件裁剪实战：以GVoice为例
如果项目集成了GCloud语音组件，其模型文件在APK的assets目录下可能占据超过10M空间。仔细分析其文件构成：

• `wa ve_dafx_data.bin`, `wa ve_3d_data.bin`：3D语音功能相关，如未使用可移除。
• `cldnn_spkvector.mnn`：声纹提取模型，默认未使用可移除。
• `libwxvoiceembed.bin`：文明语音模型，如未使用可移除。
• `decoder_v4_small.nn`, `encoder_v4_small.nn`：AICodec模型，如未使用可移除。
• `dse_v1.nn` 等：Wwise下的新算法资源，如对包体有极致要求，可评估移除。
• `libgvoicensmodel.bin`：噪声抑制模型，通常为核心功能，不能删除。

建议不要直接删除文件，而是通过修改该插件的UPL脚本（如GVoice_APL.xml）中的拷贝逻辑，实现按需拷贝。

(2) 游戏内资源优化
游戏内资源主要指打包进PAK或通过 `DirectoriesToAlwaysStageAsNonUFS` 配置放入main.obb的文件。

PAK内资源：引擎核心资源位于pakchunk0中。优化关键在于确保其中只保留引擎启动和运行所必需的最小资源集合（如关键引擎资产、ini配置文件、GlobalShader、项目ShaderLibrary、启动地图等）。对于非启动必须的资源（如部分本地化文件、非启动期字体），可以考虑延迟加载或移至安装包外。

引擎默认的资源拆分机制有其局限性，例如整个项目生成的单一ShaderLibrary在项目庞大后会成为包体瓶颈。更灵活的方案可能需要自定义资源管理和打包策略。

StageAsNonUFS资源：默认情况下，`Content/Movies` 目录下的视频文件会直接拷贝到main.obb。可以利用引擎配置文件的平台特异性，为Android平台制定独立的策略。例如，仅将启动时必须立即播放的视频放入安装包，其他所有游戏内视频都打包进PAK并转为动态下载。这样既能大幅减小APK初始体积，又使得视频资源可以热更新。

五、优化效果

综合运用上述所有优化手段后，成果是显著的。成功将一款游戏的APK大小从1.23G压缩至130M，而最核心的libUE4.so原始大小也从258M优化到了132M。

与此同时，运行时内存也降低了数十兆。最终，安装包本体变成了一个极简的“下载器”，包含了完整的第三方组件和核心游戏功能，绝大部分资源可通过动态下载获取，极大地便利了传播与分发。

当然，具体采用哪些策略，需要根据项目的实际需求、对包体大小的容忍度以及对性能的平衡来谨慎选择。例如，是否关闭内联、选择何种编译优化级别、是否对本地化等资源进行极致裁剪，都需要结合项目具体情况和性能测试数据来最终定夺。