前言

在上一篇中《Soul 包体优化之 so 篇》专门讲述了在so大小治理相关的经验。本次继续分享下包大小治理关于资源方面的一些经验。主要从减存量，控增量两个方面展开介绍对资源的优化；其中减存量主要介绍大资源检测、assets无用资源检测这两个沉淀下来的工具；控增量措施较多，主要介绍下新增资源检测卡口、三方SDK引入增加包大小规范这两个效果较好的措施。

大资源优化

在多部门协作开发，项目组件化的情况下，大资源优化痛点在于怎么快速找出所有需要优化的大资源，以及资源在哪个库和由谁维护，有了这些信息，才能快速的找到相关方进行优化；基于此痛点我们做了一个工具，能快速找出项目中所有符合条件的大资源以及相关信息，然后定期集中优化。因为资源优化方案较简单，就不展开；这里主要介绍下沉淀下来的大资源检测工具。

大资源检测工具
目的是找出所有业务库里文件超过预期大小的资源，包括图片、视频、音频、其它资源文件等等；有了目标文件，推动各个业务方优化自己领域的资源文件大小。

1. 遍历指定目录下的所有文件；

2. 校验文件类型是否在我们要检测的名单中（.png, .jpg, .jpeg, .webp, .gif, .JPG, .mp4, .mp3, .wav, .zip）；

3. 校验文件是否属于大资源；

4. 如果是，则获取文件基本信息以及文件git信息；

5. 将结果放入到缓存中，并按文件大小排序；

6. 将缓存结果输出到csv文件中，方便开发快速提取关键信息。

   
   

结果输出
最后的结果如下，对于需要处理的资源一目了然；推动对应领域的研发进行优化。

assets无用资源扫描

在无用资源检测方面，res下的无用资源检测已有较多可靠方案；但是对于assets无用资源的检测，尝试过较多已有方案，发现准确度都非常不合预期，很多无用资源检测不出来；所以根据assets资源的使用方式，整理了一个适合assets资源检查的工具。

1. 先反编译apk包，获取所有的代码和资源；

2. 收集所有的assets资源文件名和文件夹名称；

3. 在反编译出来的代码和资源文件的文件内容里搜索assets资源和文件夹名称关键字，没搜索到则表示assets资源没有使用；

4. 遍历查找所有aar包，查找未使用的assets资源所在的aar。

   
   

结果输出
只需要根据结果，推动各个模块负责人删除对应资源即可；资源删除尽量由业务方确认后自行删除，避免出现业务问题。

新增资源大小卡口

在Soul App发布过程中，每个版本都需要人工去校验包体的增长情况，至少耗费0.5d的时间去分析包体的增长来源，并给出包体的增长报告，不合规范的集成资源，相对成本较高；其次，发现不合规规范的资源，需要重新集成，影响大家的时间，延长了开发流程，影响开发体验感。

定规范

工具实现
当前方案主要分成两步，一是hooksPath的自动设置过程，二是代码提交时资源校验过程。

hooksPath自动设置
1、本地代码开发，开发工具中执行build任务；
2、判断本地开关是否开启；
3、如果开启了，判断之前是否过hooksPath，如果设置过，比较pre-commit是否相同，如果一致，则不处理，如果不同，则需要清理掉之前老的文件，重新拷贝一份pre-commit到指定目录，如果没有设置过，则拷贝pre-commit到指定目录，并设置hooksPath；
4、如果是关闭状态，判断之前是否过hooksPath，如果设置过，则需要清理掉指定路径pre-commit，并清理hooksPath的配置，如果没有设置过，则忽略掉。

流程图

提交资源校验

技术方案概述
1、代码开发阶段性结束，开始提交代码；
2、因设置过hooksPath，在提交代码之前会自动触发pre-commit脚本；
3、执行git diff-index --cached HEAD命令，获取本次提交的资源集合；
4、遍历本地提交的资源集合中的文件大小是否符合规范；
5、如果发现不符合规范的资源，打印出具体的文件路径和真实大小，提示开发，然后继续commit;
6、如果没有发现不符合规范的资源，则继续commit。

流程图

执行结果

代码集成

技术方案概述
1、jenkins执行模块构建；
2、获取当前构建模块的git&分支信息；
3、执行git diff ”current_branch“ master --stat；
4、获取得到差异资源集合；
5、编译差异资源集合，校验资源是否有超过大小限制的资源；
6、如果有，则终止构建，集成失败，代码不合入master分支；
7、如果无，则继续构建，最终集成成功，代码合入master分支；
8、将集成的结果告知用户。

流程图

执行结果

流程控制

在长期的迭代过程中，我们发现导致应用包体积骤增的主要原因之一是引入第三方SDK。由于开发部门众多，各自根据业务需求引入不同的第三方SDK，如果不对全局进行控制，包体积难以有效管理。因此，我们制定了一套专门的第三方SDK引入流程。这个流程的最大作用并非是为了阻止大包体积的SDK集成，而是为了确保各开发部门都能充分重视SDK包的大小。

结语
通过对资源系统化的治理，不仅减少了包大小，同时在过程中也不断的沉淀防裂化工具，做到长期包大小可控。在包大小治理道路上Soul App依然会持续演进，后续也将继续分享不同的系列，敬请期待。