“如果不能衡量，就无法管理”。-- 管理大师彼得.德鲁克

先确定目标

“如果不能衡量，就无法管理”。对于性能优化来讲，不能衡量就无法知道优化结果的好坏。

我们的目标是什么？是给“下载包”瘦身，而不是“上传审核包”。区别在于审核包，会包含所有硬件架构的二进制内容。上传后苹果会自动帮我们拆分开，针对不同手机生成不同的下载包。下载包的大小可以到app 开发者后台自己看。

下载包的大小

最终安装到手机上占用的空间就是“安装大小”，它一定会大于“下载大小”。尽量减少小文件、或把小文件都合并在一起可以有效减小“安装大小”。

安装大小可以在手机上查看：设置-》通用-》iPhone存储空间，找到你要查看的app。

我们这里目标在于“安装大小”。

不要忘记app thinning

千万不要忘记苹果的app thinning，它从3个方面有效缩减了安装大小。

App Slicing

把你上传的包重新组合下，会给每个机型生成特定的安装包。它的原理是，

1，只包含当前设备的二进制文件：armv7s的机器不需要arm64的二进制文件。

2，只包含当前文件的图片：视网膜屏就不需要2x图了。

这里要说明一点，有的开发者会只生成arm64下运行代码，以为省去armv7s的大小。实际上这只影响了上传审核包的大小。因为最后苹果会自动重打包。

On Demand Resource

按需下载资源，不常用资源可以设置ODR资源，也可以有效减少安装包大小。只要在工程里打开，再配合ORD用法。本质还是从网络侧下载资源。现在谁都有个服务器，把资源放自己服务器上就可以了。我能想到的场景，就是单机App、没有自己服务器的App、耗带宽的音频类大文件。

BitCode

误传可以减小尺寸，我试过没有明显效果。在编译选项里打开就行。

资源瘦身

主要指图片、音频、视频等其他非源代码文件。思路就是

1，删除不用的、重名的、相似的。

2，再就是采用压缩技巧

3，非常用资源专为按需下载。类似App Thinning的ODR思路。

4，storyboard和xib也非常占资源，影秀城App目前已经全部改成代码布局了。

还有更精细的技术，比方把不影响显示效果的情况下把32bit图片转为8bit图片。

资源瘦身

这一步骤的重点在于有好的工具帮助发现无用资源、压缩资源。

这篇文章介绍的非常详细了：《质量监控-图片减包》

我也有个发现，影秀城App里图片资源大约在4.5M，用图片工具压缩后显示减少了1.8M。但打包后，发现App的安装大小并没有显著变化。原因是：

App打包过程本身也会采用压缩算法，之前图片资源压缩比很高；通过图片工具处理后的图片资源已经无法再压缩了，所有打包后大小并无显著变化。

代码瘦身

先把简单的几步做了，确认编译选项：

Optimization Level: Fastest,

Smallest Deployment Postprocessing: Yes

Strip linked Product: Yes

Symbols Hidden by default: Yes

Make Strings Read-only: Yes

没毛病的好，这些都是Release版本的默认选项。

再就是不要使用动态库

主要留意pod中把“use_frameworks!”这样注释掉，否则产生动态库，而不是静态库。

重点是发现和移除无用代码

还是文章开头那句话，没有度量就没法进行优化。

利用工具可以查看每个静态文件和每个.o文件大小；工具在这里 从重点着手：

查看静态库和.o文件大小

这个工具可以查看OC中未使用的方法。

稍微改一下后，这个作者还提供了工具。查找是否在代码里调用了被废弃的系统函数。

删除无用代码带来另一个福利就是，App的启动速度变快了。

项目实践

1，在影秀城App里，最大收益还是来自于删除了无用资源和无用代码。

2，无用资源和无用代码还是反应了UI设计师和iOS工程师在项目管理上的无序。

3，今后在项目中的改进：

-- 开发完成后开发人员通过工具进行自查，然后再提交个测试。

-- 测试人员通过检查包大小，对于异常包增值要提出异议。

思考&总结

1，性能类的优化必须要有量化的结果可以查看，明确目标。

-- 有的文章里错误的以上传审核的包大小作为了优化目标。

-- 核实优化结果，比方图片压缩后，其实并没减少“下载大小”。

2，性能类优化，必须要有合适的工具进行辅助。

3，了解下App Thinning的概念。

4，对于小厂来讲，最重要的就是及时删除无用资源、无用代码，不至于以后无法收拾。

5，对iOS开发到一定程度不能满足于写写代码。要做全方面了解、了解些背后的故事。比方，这个编译过程。

人只有碰到一堵墙弹回来，才会了解真正的自己。所以我要去找堵墙...