iOS包大小分析和减包大小

苹果规定大小超过100M的App在非wifi环境下下载时会弹出一个alertview对话框，提示用户用户是否继续下载。看到这么一个对话框，绝大多数的用户估计会选择取消（当然，土豪肯定随意）。目前主流App基本上都包含armv7和arm64两种架构，再加上资源文件（图片、音频、配置文件等），大中型的app基本上都会面临着减包的任务。本文主要从以下两个方面讨论如何进行包大小的裁剪：
1、图片资源
UE提供的图片资源往往都是直接从PhotoShop中剪切后的资源，大小非常大，可以使用以下两种方法进行图片的压缩：
（1）使用软件ImageOptim，优点是可以进行批量操作，缺点是压缩率不高
（2）使用网站tinypng.com，优点是压缩率高，但是不能批量操作，每次只能一张，而且有张数限制
笔者曾经试过UE给的一张图片资源4KB，用（1）中的方法可以压缩到3KB，但是用（2）的方法可以压缩到500字节，而且视觉上无感知，可以说这个网站对图片的压缩算法非常给力！
除了对原有图片进行压缩外，也可以把一些尽量能拉伸的图片用拉伸图片，而不是用一张大图，一些简单颜色值，能用代码实现尽量用代码，减少图片的数量。
2、代码上
（1）使用LinkMap文件对可执行文件安装包进行分析
在xcode的设置中找到如下设置项，把值设置为YES，然后运行Build该app。



在以下目录可以看到LinkMap文件，如下：
/Users/chenxintao/Library/Developer/Xcode/DerivedData/AppName-fnpgyspdoyxnotbpoliocmwypkff/Build/Intermediates/AppName.build/Debug-iphoneos/AppName.build/AppName-LinkMap-normal-arm64.txt
LinkMap文件主要分为以下三部分：
Object files
整个可执行文件里包含的所有.O文件，前面的数字是这个.o文件的序号
# Path:/Users/chenxintao/Library/Developer/Xcode/DerivedData/AppName-fnpgyspdoyxnotbpoliocmwypkff/Build/Products/Debug-iphoneos/AppName.app/AppName
# Arch: arm64
# Object files:
[ 0] linker synthesized
[ 1]/Users/chenxintao/Library/Developer/Xcode/DerivedData/AppName-fnpgyspdoyxnotbpoliocmwypkff/Build/Intermediates/AppName.build/Debug-iphoneos/AppName.build/Objects-normal/arm64/BMBDWalletOrderInfo.o
[ 2]/Users/chenxintao/Library/Developer/Xcode/DerivedData/AppName-fnpgyspdoyxnotbpoliocmwypkff/Build/Intermediates/AppName.build/Debug-iphoneos/AppName.build/Objects-normal/arm64/BMWindow.o
[ 3]/Users/chenxintao/Library/Developer/Xcode/DerivedData/AppName-fnpgyspdoyxnotbpoliocmwypkff/Build/Intermediates/AppName.build/Debug-iphoneos/AppName.build/Objects-normal/arm64/BMPayOrderInfo.o
Sections
整个可执行文件段大小，目前暂不知对减包大小的分析有什么帮助，欢迎读者补充
# Sections:
# Address Size Segment Section
0x100007918 0x046B86A8 __TEXT __text
0x1046BFFC0 0x000038B8 __TEXT __stubs
0x1046C3878 0x0000360C __TEXT __stub_helper
0x1046C6E84 0x001720DA __TEXT __objc_methname
0x104838F60 0x001ADC12 __TEXT __cstring
0x1049E6B72 0x0002E04B __TEXT __objc_classname
Symbols
可执行文件中各种symbol的大小，包括各个symbol的起始地址，占用大小，来自哪一个.o文件（使用之前提到的.o文件的序号）
# Symbols:
# Address Size File Name
0x100007918 0x000000FC [ 1] +[BMBDWalletOrderInfogetRequiredDateFormatStringFromDate:]
0x100007A14 0x000000BC [ 1] -[BMBDWalletOrderInfoinit]
0x100007AD0 0x00000308 [ 1] -[BMBDWalletOrderInfoparameterInit]
0x100007DD8 0x00000208 [ 1] -[BMBDWalletOrderInfoparameterValidation]
0x100007FE0 0x00000760 [ 1] -[BMBDWalletOrderInfomakeOrderString]
0x100008740 0x0000002C [ 1] -[BMBDWalletOrderInfospNo]
0x10000876C 0x0000004C [ 1] -[BMBDWalletOrderInfosetSpNo:]
0x1000087B8 0x0000002C [ 1] -[BMBDWalletOrderInfoorderCreateTime]
0x1000087E4 0x0000004C [ 1] -[BMBDWalletOrderInfosetOrderCreateTime:]

计算某个.o文件在最终安装包中占用的大小，主要是解析Object files和Symbols两个部分，从Object files读取出每个.o文件名和对应的序号，然后对Symbols中序号相同的文件的Size字段相加，即可得到每个.o文件在最终包的大小。

但是笔者遇到的任务其实不是分析整个可执行文件各个.o文件的大小，笔者的工作是负责整个app中的某一个库，这个库以.a的方式链接到最终的可执行文件中，假设改库名称为**.a。我的任务是需要分析出这个库在最终可执行文件占用的大小，同时对改库中各个.o文件在可执行文件中的大小进行排序，从而为减包大小提供数据参考和方向。

仔细观察Object files中文件名字部分，可以观察到如果是以静态库链接到可执行文件中的，会在路径中加入静态库的名字，如下：

/Users/chenxintao/Library/Developer/Xcode/DerivedData/AppName-ekgnvxcffasvgqcfmdqxlfhxvcod/Build/Products/Debug-iphonesimulator/libOHAttributedLabel.a(NSAttributedString+Attributes.o)

通过这点可以找到**.a中所有在可执行文件中有贡献的.o文件，然后按照上文提到的方法分别计算出每个.o文件的大小并进行排序即可。

（2）对**.a进行分析

对于笔者来说，包的大小最直观的是.a文件的大小，由于各种历史遗留原因，**.a中包含了一部分.o文件最终没有链接到最终可执行文件中，如何找到这部分的文件并进行排序也是当时笔者当时减包大小的一个方向。

本来是用的是mn命令，但是发现mn无法打印出符号的大小，只好放弃，用ar命令。

ar命令列出静态库包含的.o文件，会在当前路径下列出所有的.o文件，如下：

ar –x .a路径

对输出的.o所在目录使用如下命令，得到.o文件大小和文件名：

ls -l | tr -s ' ' | tr -s '\t' | tr '\t' '' | cut -d ' ' -f 9,5 | sort -nr -k 1 >objectfiles.txt

即可得到**.a中所有的.o文件

对**.a中的所有.o文件进行遍历，如果在可执行文件中没有命中该.o，则说明改.o文件为冗余文件。最后把所有的冗余文件按照大小进行排序即可。