1:资源瘦身
a:资源瘦身主要是去掉无用资源和压缩资源，资源包括图片、音视频文件、配置文件以及多语言wording。无用资源是指资源在工程文件里，但没有被代码引用。检查方法是，用资源关键字（通常是文件名，图片资源需要去掉@2x @3x），搜索代码，搜不到就是没有被引用。当然，有些资源在使用过程中是拼接而成的（如loading_xxx.png），需要手工过滤。
b:资源压缩主要对png进行无损压缩。不建议对资源做有损压缩，有损压缩需要设计一个个检查，通常压缩后效果不尽人意。
2:可执行文件瘦身
a:以往C++在链接时，没有被用到的类和方法是不会编进可执行文件里。但Objctive-C不同，由于它的动态性，它可以通过类名和方法名获取这个类和方法进行调用，所以编译器会把项目里所有OC源文件编进可执行文件里，哪怕该类和方法没有被使用到。
b:删除无用的oc类
3.文档资源的优化
a:是否有不必要的文档资源，如果过期的旧版本所需要的文档资源 清理即可。
b:优化文档资源大小，主要是优化精简文档内容。
4:有人提出用ARC写的代码编译出来的可执行文件是会比用MRC大的，原因大致是ARC代码会在某些情况多出一些retain和release的指令，例如调用一个方法，它返回的对象会被retain，退出作用域后会被release，MRC就不需要，汇编指令变多，机器码变多，可执行文件就变大了。
结果是ARC大概会使代码段增加10%的size，考虑代码段占可执行文件大约有80%，估计对整个可执行文件的影响会是8%。
可以评估一下8%的体积下降是不是值得把项目里某些模块改成MRC，这样程序的维护成本上升了，一般不到特殊情况不建议这么做。
5:类/方法名长度
观察linkmap可以发现每个类和方法名都在__cstring段里都存了相应的字符串值，所以类和方法名的长短也是对可执行文件大小是有影响的，原因还是object-c的动态特性，因为需要通过类/方法名反射找到这个类/方法进行调用，object-c对象模型会把类/方法名字符串都保存下来。
对此我们可以考虑在编译前把所有类和方法名进行混淆，跟压缩js一样，把长名字替换成短名字，这样做的好处除了缩小体积外，还对安全性有很大提升，别人拿到可执行文件对它class-dump出来的结果都是混淆后的类和方法名，就无法从类和方法名中猜出某个方法是做什么的，就难以挂钩子进行hack。不过这样做有个缺点，就是crash堆栈反解出来的堆栈方法名会是混淆后的，需要再加一层混淆->原名的转换，实现和使用成本有点高。
实际上这部分占用的长度比较小，中型项目也就几百K，对安全性要求高的情况可以试试。
6:编译选项优化
Strip Link Product设成YES，WeChatWatch可执行文件减少0.3M
Make Strings Read-Only设为YES，也许是因为微信工程从低版本Xcode升级过来，这个编译选项之前一直为NO，设为YES后可执行文件减少了3M
去掉异常支持，Enable C++ Exceptions和Enable Objective-C Exceptions设为NO，并且Other C Flags添加-fno-exceptions，可执行文件减少了27M，其中__gcc_except_tab段减少了17.3M，__text减少了9.7M，效果特别明显。可以对某些文件单独支持异常，编译选项加上-fexceptions即可。
参考文章:https://techblog.toutiao.com/2016/12/27/iphone/
网友评论