Unity包体积优化实践

简述

在移动端App混合Unity开发的项目中，Unity的包体增量一直是一个被严格把控的关卡，包体积增量太大估计老板都直接不给上Unity了，因此Unity移动端的包体积优化尤为重要。由于混合开发中Unity部分的优化和Unity独立App的优化手段差不多，这里就以Android独立App项目为例，实践一波包体积优化。

优化前

我未做任何优化在Unity里直接打一个Apk出来，可以借用工具例如Android Studio查看Apk的大小和具体构成，供我们分析，可以看到，这个Apk大小为107.9MB，我们看看它的组成

可以看到，assets目录是占最大的，其次是lib目录，而dex相关文件只占很小部分。我们先看看这三个部分代表的什么：

• assets目录：我们先看看assets目录包含什么东西
  
  其中TestData和AssetsBundles目录都是我工程里放在StreamingAssets目录下的子目录，里面包含了资源，看来是被原封不动地放到了这里。而这个bin目录是什么呢？点进去看
  
  可以看到包含了一大堆dll文件，原封不动地放到了这里，除此之外还包含了一些Resources和其他引用到的资源，图中没显示全，assest目录就大概包含了以上这些内容

• lib目录：我们再看看lib目录下，可以看到右armeabi-v7a的文件夹，但是没有arm64的文件夹
  
  可以看到，里面包含了各种用到的so库

• classes.dex文件：这个主要是java的代码，占比很小，可以忽略不计

优化中

assets目录

我们首先从assets目录的大小开始优化，从上面的分析得知，我们StreamingAssets目录下的资源和Resources目录的资源和其他引用的资源都放在了这个目录下，因此我们先对这个资源进行优化

资源ab包动态下发

我们把相关的资源改为动态加载的方式，全部打成ab包，放到cdn上动态下发，在运行时再去加载，我们用Android Studio自带的Apk大小比较工具看看效果：

可以看到Apk只剩60.4MB了，减小了47.6M，几乎所有的集中在assets目录，还有极小部分减小在META-INF目录。其实大部分项目进行包体积优化的最大优化部分都是资源优化，所以几乎所有的移动端项目都会使用ab包动态下发的方式进行资源的包体积优化。

扫描二维码关注公众号，回复： 15616359 查看本文章

资源大小优化

如果还有部分资源是需要直接嵌入在Apk里的，也可以进行资源的压缩，资源大小主要是模型和贴图，模型可以通过减面和更换低模进行优化，贴图也可以通过各种手段进行优化，最简单的方式是在Unity里进行各个贴图分辨率控制和贴图压缩，还有贴图的合并图集等。虽然我们大部分资源都使用了ab包动态下发的方式，但是ab包里的资源也可以先优化之后再打ab包，减小ab包的大小和增强运行时性能。在当前这个测试项目中，资源都通过ab包下载，因此这部分没有减小包体积，但对于那些不使用ab包动态下载的项目中就会变得非常有用

dll大小优化

目前生成了一大堆的dll，在assets占用了大量包体，我们继续去优化一下。这里其实是因为旧的mono编译方式会把C#代码编译为中间语言，使用默认的中等优化级别，生成的二进制代码相对较大，同时还包含一些跨平台的兼容性代码，导致生成的dll较大。这里我们采用最新的IL2CPP编译方式替代mono编译，IL2CPP编译器会进行更高级别的优化，将C#生成更紧凑的、高效的本机机器码，因此不需要额外的跨平台适配逻辑，可以减小包体积大小，以下是我们换成IL2CPP的大小（对比优化前）：

可以看到在assets目录下有大幅度的减小，但是lib却大幅度增长，最终反而增长了12.6MB，达到了72.9M，明显不符合预期，这是为什么呢？其实是因为我们IL2CPP打包的时候，选择打了ARMv7和ARM64两个cpu架构的包，但在现在的手机市场中，一般情况我们选一种就可以了，我们只选择ARM64，再进行一次打包：

可以看到，大小从72.9MB降到了45.1MB。我们看看和mono方式的对比：

assets目录大幅度减小，lib目录增长，总包体积减小了-15.2MB（需要注意的是，APK大小是压缩后的数据，而里面目录的大小是没压缩前的数据）

场景模型动态下载和加载

前面我们做了一些基本的ab包加载，但当时做的只是和一些本来就需要动态下载的资源相关的事情，没把场景里放置的场景资源也放进去，现在我们采用所有场景资源都ab包动态下载和加载的方式，再次验证大小：

可以看到，assets目录再次减小，总包体积从45.1MB降到了36.3MB，这里没有细查项目中的所有资源，如果全部找出来处理掉，这里还能再小，但是由于剩下的这些资源在压缩到apk里后大小占比太小，这里就不做处理了

优化assets目录后大小

我们再看看以上这些步骤优化后，在压缩的apk包里，各部分的大小：

可以看到，assets目录已经只剩下5.9MB了。而lib目录依然占比较大。

lib目录

优化目标架构

其实前面已经对这里进行过优化了，我们去掉了ARMv7，只保留ARM64，就已经是优化了一半大小。

裁剪代码

在Unity的Player Settings中，选择"Player Settings"，然后在"Other Settings"下的"Optimization"部分，勾选"Strip Engine Code"。这将删除未使用的引擎代码，减小.so文件的大小。请注意，这可能会导致某些功能的不可用性，因此在使用此选项之前，请确保测试应用程序的功能完整性。在我的测试项目中，开到了最大的裁剪幅度，然后出现了一些问题，解决后，apk大小再次降低：

这次减小到29MB了，lib目录甚至assets目录都在减小。

优化代码和引用

有时候我们代码里会引用很多第三方dll，我们需要了解这些dll我们是否必须引用，引用过多的dll肯定是会增加大小的，想查看引用的dll，我们在Unity Editor编译好Apk后，点击Unity Editor Console控制台的右上角三个点，然后选择Open Editor Log，找到类似以下的内容：

这样就可以查看我们引用的所有dll了，然后根据实际情况去处理，这里测试项目就不处理，因为这部分会花费不少时间，还需要注意会不会引入新的问题，如果引用不多，优化力度也不是很大。除此之外，我们还要优化我们自己编写的代码，尽量不要写无效代码。

其他优化项

Shader优化

我们刚刚已经打开了Editor Log，其实下面还有显示各部分占比大小，虽然不是很全面，但是我们也可以从中得知一些信息：

可以看到，我们的资源部分基本上没有任何占用了，但能看到Shaders还有一些占用，我们继续处理，这些shader实际上都是在工程里设置了always include shaders才引入的，有时候设置了但是又忘了去掉，又用不到，也会占用内存。我们根据实际情况做一下删减，我这里做一下删减，未压缩前的assets目录减少了2MB左右，但是压缩后几乎可以忽略不计，这里就补贴出图片了，项目里Shader很复杂的需要注意这里的优化就行了

Release模式

我们前面其实一直用的debug模式，我们开启一下release模式，然后选择Use R8再次再次编译，看看效果：

可以看到，优化的力度是非常大的，但是会增加编译时间，并且无法进行调试，所以平时开发时还是用debug模式，发布时记得改Release模式。

编译选项

我们在打包的时候，可以选择一些压缩配置，例如在Build窗口，我们可以改为以下两个配置：

我们再次进行打包验证，最终会变成以下大小：

优化后

我们最后总结一下以上各个步骤的优化情况：

初始大小	部分资源ab包动态下发	IL2CPP（只保留ARM64）	全部资源打ab包	裁剪代码	Release模式	编译压缩选项
107.9MB	60.4MB	45.1MB	36.3MB	29MB	19.1MB	17.4MB

到这里，我们基本上从107.9MB优化到了17.4MB，减小了80%多的包体大小。如果追求极限，还有进一步的优化空间，但也和这个差不了多少了，工作量却会大幅度增加，一般按照上面这些配置，已经能满足现在大部分工程的需要。并且如果是和移动端混合开发，还会配合使用移动端的一些优化方案，会进一步减小大小。