Soul-iOS包大小防劣化实践

原创 Soul-iOS Soul技术团队

1 引言：为什么要关注包大小

包体治理是每一个App都需要关注的优化项目，针对iOS而言，200MB的App包体下载大小更是一个关键的临界指标。因为超过200MB的App，进行下载时苹果会提示是否使用Wifi下载，会对新客的转化率造成较为严重的影响。包体的治理势在必行。

图1：包大小分为下载大小（Download）和安装大小（Install）两个概念，苹果的200MB限制是基于下载大小的，我们一般关注的也是下载大小。在不同的设备上，iOS包体的表现不尽相同，我们以设备中下载大小最大的数值作为参照指标（我们一般看iPhoneX）

图2：超过200MB的App在运营商网络下载时提示的「Wifi下载提示弹框

图3：苹果手机的流量下载弹框的配置位置：Settings→App Store→App Downloads。默认配置是「Ask If Over 200MB」

2 包体治理的思路

包体的治理可以简单分为「优化」和「防劣化」

2.1 优化 - 造减量

常见的优化方案如：

工程配置层面：编译等级配置/StripCode配置/TEXT段转移等（针对TEXT段转移，小伙伴们可能比较陌生，可以参考下这篇文章：http://www.kffy.cn/meiwen/359417.html，本篇不详情展开）
未使用文件清理：未使用资源清理/未使用源文件清理等
大资源优化：压缩/远程化等

2.2 防劣化 - 防增量

随着业务的持续迭代，我们的的包体的自然行为几乎必然是持续变大的，他们主要包含：

新增的业务代码增量
新增的三方库增量
新增的直接放置到包体的大资源
废弃的未移除的旧代码/旧资源

我们当前基本防劣化思路是：

约定软性的增量准入规则
进行版本包体变化监控，跟进处理逾越准入规则的增量项目
不定期进行包体优化

Soul包体防劣化思路说明图

基于我们的防劣化思路，我们可以发现一些基本的需求问题点：

如何确定产生包体增量的模块与相对准确的增量值？
如何发现版本新引入的大资源？
如何快速定位相关资源/代码引入的关键人？
如何发现废弃的资源/源文件？

纯靠人力处理上述问题显然不是有效持久的方案，我们需要工具的支持。

2.3 工具辅助

从高ROI的角度出发，我们优先考虑第三方工具。

我们发现了LSUnusedResources(https://github.com/tinymind/LSUnusedResources)，它无疑是一款协助发现无用资源的优秀的工具，但针对我们的需求，它存在明显的不足：

只能整体发现无用资源（无法区分模块，无法分析有效资源，无法分析源文件，无法对比版本等）
它是一个桌面工具，难以基于脚本直接调用
使用的文件发现方式较慢（使用 /urs/bin/find 命令）

同时，考虑到需要：

结合我们App本身的工程结构特性分析
应对紧急的特例分析需求变化

等因素，我们决定自研一套App包体的分支支持工具。

3 Soul的包体分析

讲到包体分析，我们第一想到的未使用资源(图片)的清理，它需要基于工程源码进行分析。但在我们基于源码分析进行工具开发的过程中发现，它很难准确分析模块迭代的二进制增量，因此我们进一步引入了LinkMap分析，形成了「LinkMap分析二进制 & 源码分析资源」的基本模式，每种模式都包含「增量监控」和「存量分析」。

Soul包体分析的功能支持

上图即为Soul包体分析的功能支持示意，下面我们详细看看LinkMap分析和源码分析的一些关键技术点。

3.1 LinkMap - 分析二进制

什么是LinkMap？

编译一般包括「预处理-->编译-->汇编-->链接」几个阶段。Link Map File 即链接映射文件，是 Xcode 生成可执行文件时一起生成的文件，用于记录链接相关信息。

iOS工程在Xcode中配置了Target-Build Setting-Linking-Write Link Map File 为 YES，即可让工程编译后自动生成LinkMap文件

生成的LinkMap一般在DrivedData目录下面。

LinkMap一般包括Path,Arch,Object files,Section,Symbols,Dead Stripped Symbols几个部分。

3.1.1 为什么要基于LinkMap分析

基于源文件的大小变化来判断包体二进制增量，我们发现它的局限性很大：

源文件的增量&包体的二进制增量很难建立起有效的映射关系；
随着二进制组件的增多，源文件对包体增量归因愈发不准确；
因为归因准确性不强，问题的反馈&跟进阻碍重重

我们亟需一种方式，能更真实准确地反应包体二进制的真实变化分布。经过调研发现，基于LinkMap的分析可以获取到每个模块的二进制大小，进而比对增量，符合我们需求。

包体各模块二进制增量呈现

如图，基于新旧2个工程LinkMap的对比分析，可获取各模块的二进制增量变化排序。

3.1.2 LinkMap的关键分析流程说明

1）获取.o文件编号

LinkMap文件 Object files段示意

.o 文件可以简单理解为一个源文件（比如aaa.m）的二进制形式（即aaa.o）。如图，在LinkMap文件的「Object files」部分，我们可以获取到所有链接的 .o 文件的两项关键信息：

编号：左边的[0][1][2][3]...
.o文件路径：编号右边的内容

我们先关注下「文件编号」

2）聚合.o文件符号，获取.o文件大小

LinkMap文件 - Symbols段示意

接下来我们关注下LinkMap文件的Symbols部分，我们可以看到两个关键的讯息：

Size：特定符号的大小
File: 特定符号所在的文件编号

将相同文件编号的符号聚合起来，我们就可以获取到对应.o文件的大小。

3）聚合.o文件，获取模块大小

LinkMap - Object files段包含模块信息

在LinkMap文件的「Object files」部分，.o文件的路径信息其实已经包含了模块相关信息，参考它，我们可以区分以pod为基础的模块。将相同模块的.o文件进行聚合，就可以获取模块的大小。

4）基于模块比较两份LinkMap文件的分析结果

两份工程LinkMap的对比结果

将新旧2份工程的LinkMap文件基于模块的二进制大小聚合结果进行对比后，输出成csv表格形式（方便利用表格的筛选/排序功能），可快速关注到App版本迭代的二进制增量变化。

3.1.3 LinkMap分析的工具架构

了解了LinkMap分析的关键技术流程，再关注一下我们LinkMap分析工具的架构。

Soul LinkMap分析工程架构

1）main

提供命令行参数支持
触发LinkMap解析&比较流程

2）Compare

2.1）CYLinkMapComparer

支持两个完成分析的CYLinkMap对象的比较
记录比较结果
进行必要比较结果抽取

2.2）CYLinkMapCompareItem

描述两个项目的大小比较结果
属性含：比较备注，大小改变，状态（修改/新增/删除/无变化）
比较结果承载模型

3）LinkMap Digger

3.1）CYLinkMap

支持LinkMap文件的解析
记录LinkMap解析原始数据
记录LinkMap即系聚合数据
支持LinkMap分析结果写文件
提供整体从解析，到写文件的流程支持

3.2）CYModule

用以LinkMap中object对象的模块聚合。
直接的object对象过于零碎，我们更多关注的是模块的变化，比如一个pod的变化

3.3）CYObjectFile

描述LinkMap文件中 Object files 部分的单项的数据结构
负责 Object 单行信息的解析
记录其关联的符号信息

3.4）CYSymbolItem

描述LinkMap文件中 Symbols / Dead Stripped Symbols 两个部分的单项的数据结构
负责 Symbol 单行信息的解析
主要关注其 size 和 fileId，前者用于计算大小，后者用户关联object对象

3.5）CYSectionItem

描述LinkMap文件中 Sections 部分的单项的数据结构
负责 Section 单行信息的解析

4）Utils

4.1）CYFileWritter

提供文件输出的相关操作，封装定制输出csv文件接口

4.2）LineIterator

支持文件的流式逐行读取

3.2 工程源码 - 分析资源

LinkMap分析可以有效的分析二进制的变化，但对于随应用打包的资源（图片/音频/视频）等却无能为力。实践过程中我们发现，造成包体异常增量的关键因素往往正是大资源的随意引入。我们需要基于资源的增量/存量信息来指导治理，获取这些信息的方式可以通过分析工程源码实现。3.2 工程源码 - 分析资源

3.2.1 技术点 - 正则提取

在「未使用资源查找」的技术需求中，最基础的一个操作即为判断某个资源是否被某个文件所「使用」,它往往需要在一个文件中提取到符合某个特定范式的字符串，这就需要用到正则（关于正则的规则约定，在此不再赘述，网上可以找到很多完备的资料）。

从源文件中提取目标图片名

如图的defaultPic文本，可以通过正则「@\"(.*?)\"」快速提取。

3.2.2 技术点 - 基于TagString的效率优化

基于「未使用资源查找」来简单介绍下TagString的查找算法思路与优势。

场景举例：一份工程中有 5000个png图片和 20000份.m源文件

1）多重循环的思路

即针对每个图片，依次判断它是否在20000个源文件中被匹配，若均没有，则认为该图片为未使用的图片。伪码如下：

noUsedImageArray = []   // 未使用图片数组
for (image in allImages) {  // 共5000张图片
        imageUsed = false   // 标记某个资源是否被使用
        for (file in allFiles) {  // 共20000份源文件
                if (file中包含image的名称) {
                        imageUsed = true
                        break
                }
        }
        if (imageUsed = false) {
            noUsedImageArray.append(image)
        }
}
return noUsedImageArray

2）TagString的思路

先提取20000个源文件中的所有可能为图片名的关键字符串（TagString）并存入一个随机查找的数据结构中（如Set），然后再看5000个图片名是否在这个TagString的Set中存在。

文件中的tagString提取示意

伪码如下：

tagStringSet = Set()
for (file in allFiles) {  // 共20000份源文件
    tagStrings = extractTagStringFromFile(file)
    tagStringSet.addObjects(tagStrings)
}
 
noUsedImageArray = []   // 未使用图片数组
for (image in allImages) {  // 共5000张图片
    if (image not in tagStringSet) {
        noUsedImageArray.append(image)
    }
}
return noUsedImageArray

两种无用资源提取思路的比较：

常规双循环-运算量：1亿次 (5000 * 20000)
tagString-运算量：2.5万次 (5000 + 20000)

可以看出来，使用TagString的方式，运算速度的提升有接近4个数量级

TagString的提取正则

下面是一些常见文件中提取图片资源TagString的正则参考，对于不同类型的文件，其使用图片的范式是有差异的。

self.conf_regexDic = @{
            @"h": @[@"([a-zA-Z0-9_-]*)\\.(png|jpg|imageset|svg|json|mp3|gif|caf)"],
            @"m": @[@"@\"(.*?)\""],
            @"mm": @[@"@\"(.*?)\""],
            @"swift": @[@"\"(.*?)\""],
            @"xib": @[@"image name=\"(.+?)\""],
            @"storyboard": @[@"image name=\"(.+?)\""],
            @"strings": @[@"=\\s*\"(.*)\"\\s*;"],
            @"c": @[@"([a-zA-Z0-9_-]*)\\.(png|jpg|imageset|svg|json|mp3|gif|caf)"],
            @"cpp": @[@"([a-zA-Z0-9_-]*)\\.(png|jpg|imageset|svg|json|mp3|gif|caf)"],
            @"html": @[@"img\\s+src=[\"'](.*?)[\"']"],
            @"js": @[@"[\"']src[\"'],\\s+[\"'](.*?)[\"']"],
            @"json": @[@":\\s*\"(.*?)\""],
            @"plist": @[@">(.*?)<"],
            @"css": @[@"([a-zA-Z0-9_-]*)\\.(png|jpg|imageset|svg|json|mp3|gif|caf)"],
    };

3.2.3 技术类比 - 无用源文件的发现思路

tagString仅仅可以用于无用资源检索么？不，这套模式还可以用于其他的分析，比如：基于头文件判定的无用源码文件发现（提取头文件引用内容作为tagString进而判断未使用的文件，当然，对swift无效……）。下面是一些常见文件中提取import文件名TagString的正则参考：

// 无用源码文件发现-提取头信息
self.conf_regexDic = @{
        @"h": @[
                    @"#import[ ]*<([a-zA-Z0-9_\\-\\+]*)\\.h",
                    @"#import[ ]*\"([a-zA-Z0-9_\\-\\+]*)\\.h",
                    @"#import.*/([a-zA-Z0-9_\\-\\+]*)\\.h",
                    @"#include[ ]*<([a-zA-Z0-9_\\-\\+]*)\\.h",
                    @"#include[ ]*\"([a-zA-Z0-9_\\-\\+]*)\\.h",
                    @"#include.*/([a-zA-Z0-9_\\-\\+]*)\\.h",
                    @"@import[ ]*([a-zA-Z0-9_\\-\\+]*)",
        ],
        @"m": @[
                    @"#import[ ]*<([a-zA-Z0-9_\\-\\+]*)\\.h",
                    @"#import[ ]*\"([a-zA-Z0-9_\\-\\+]*)\\.h",
                    @"#import.*/([a-zA-Z0-9_\\-\\+]*)\\.h",
                    @"#include[ ]*<([a-zA-Z0-9_\\-\\+]*)\\.h",
                    @"#include[ ]*\"([a-zA-Z0-9_\\-\\+]*)\\.h",
                    @"#include.*/([a-zA-Z0-9_\\-\\+]*)\\.h",
                    @"@import[ ]*([a-zA-Z0-9_\\-\\+]*)",
        ],
        @"mm": @[
                    @"#import[ ]*<([a-zA-Z0-9_\\-\\+]*)\\.h",
                    @"#import[ ]*\"([a-zA-Z0-9_\\-\\+]*)\\.h",
                    @"#import.*/([a-zA-Z0-9_\\-\\+]*)\\.h",
                    @"#include[ ]*<([a-zA-Z0-9_\\-\\+]*)\\.h",
                    @"#include[ ]*\"([a-zA-Z0-9_\\-\\+]*)\\.h",
                    @"#include.*/([a-zA-Z0-9_\\-\\+]*)\\.h",
                    @"@import[ ]*([a-zA-Z0-9_\\-\\+]*)",
        ],
        @"c": @[
                    @"#import[ ]*<([a-zA-Z0-9_\\-\\+]*)\\.h",
                    @"#import[ ]*\"([a-zA-Z0-9_\\-\\+]*)\\.h",
                    @"#import.*/([a-zA-Z0-9_\\-\\+]*)\\.h",
                    @"#include[ ]*<([a-zA-Z0-9_\\-\\+]*)\\.h",
                    @"#include[ ]*\"([a-zA-Z0-9_\\-\\+]*)\\.h",
                    @"#include.*/([a-zA-Z0-9_\\-\\+]*)\\.h",
                    @"@import[ ]*([a-zA-Z0-9_\\-\\+]*)",
        ],
        @"cpp": @[
                    @"#import[ ]*<([a-zA-Z0-9_\\-\\+]*)\\.h",
                    @"#import[ ]*\"([a-zA-Z0-9_\\-\\+]*)\\.h",
                    @"#import.*/([a-zA-Z0-9_\\-\\+]*)\\.h",
                    @"#include[ ]*<([a-zA-Z0-9_\\-\\+]*)\\.h",
                    @"#include[ ]*\"([a-zA-Z0-9_\\-\\+]*)\\.h",
                    @"#include.*/([a-zA-Z0-9_\\-\\+]*)\\.h",
                    @"@import[ ]*([a-zA-Z0-9_\\-\\+]*)",
        ],
        @"swift": @[
                    @"import[ ]*([a-zA-Z0-9_\\-\\+]*)",
        ]
};

3.2.4 增量监控

通常，针对迭代产生的增量数据（某个模块的二进制新增了300KB，新增了某个80KB的资源等）关注度是更高的，分析控制增量是控制准入的不二法门。

1）定义文件数据结构

程序=数据结构+算法，良好的数据结构是简单有效的程序的基础，增量监控工具一样需要一些关键数据结构的支持，比如一个文件包含很多的基础信息：文件目录，文件名，文件大小等。针对分析中，我们常见用的数据信息，提前在model中进行抽取，以对后续分析的便捷性帮助。

如下是我们简单定义的一个FileItem数据结构的部分属性。

/* 基础文件信息 */
@interface CYFileItem : NSObject
 
@property (nonatomic, strong) NSString *filePath;               /* 文件路径 */
@property (nonatomic, strong) NSString *fileReletivePath;       /* 文件相对路径 */
@property (nonatomic, assign) uint64_t fileSize;                /* 文件大小 */
 
@property (nonatomic, strong) NSString *fileName;               /* 文件名称（含后缀） */
@property (nonatomic, strong) NSString *pureFileName;           /* 文件名称（不含后缀）*/
@property (nonatomic, strong) NSString *fileSuffix;             /* 文件后缀 */
@property (nonatomic, strong) NSString *fileTag;                /* 文件标签，用以匹配 */
 
@property (nonatomic, assign) CGSize imageSize;                 /* 当文件是图片类型文件时，的size大小信息 */
 
@end