以前的老文章了，搬到cnblog
更小的安装包意味着更快的下载安装速度，也往往意味着更快的加载运行速度，是优化ios应用的一个重要方面，本文主要参考《减小iOS应用程序的大小》，在实际测试的基础上，给出了优化ios安装包大小的更全面、更具体的建议。
开发者在Xcode里，可以做一个archive（Product->Archive，注意要build realse版），然后在Organizer界面，可以通过Estimate Size来估计大小，本人尝试了一下，这个大小比实际appstore的ipa要稍大；可以创建一个Ad hoc的ipa看看，而这个安装包比实际appstore的ipa稍小，这是因为appstore的ipa做了加密处理，导致压缩率降低。
检查安装包，剔除不需要的资源文件
随着版本的迭代，总会出现一些老版本需要，新版本不再需要的资源，要及时剔除这些文件。当引入第三方库时，可能会同时引入一些资源文件，要确定一下，是否有不需要使用的资源文件，如果有，要删除。建议在发布之前，做一个archive（Product->Archive)，看看到底有哪些资源文件被打包了，鉴别不需要的。
可执行文件大小
- 目标CPU架构
如果应用需要在多种cpu架构下运行，那么xcode生成的二进制文件会包含对应架构的多个副本，这样可执行文件的大小就会成倍增加。
arm cpu架构可以标识为armvX (64)，X代表一个数字，如果不指定是64位，就是指32位。 一般来说arm架构都是向后兼容的，armv6的代码可以在armv7上运行，32位的代码可以在64位cpu上运行；但是新版本的xocde不支持生成老arm架构的代码。自iphone3GS开始cpu都是armv7的，所谓的armv7s(iphone5s用得是这个）是苹果搞出来的，加了个协处理器，多了一些浮点向量指令。平时在新闻媒体上看到所谓A6，A7处理器其实都是基于armv7架构Context-A家族的具体实现版本。 从新闻来看，iPhone6用的是A8的cpu，还是armv7的。关于arm架构知识可以参考：http://zh.wikipedia.org/wiki/ARM架構
因此，现在将目标cpu架构（buidsettings->Architectures)设置为armv7即可。对于一个现有的ios可执行文件，可以通过otool -h [file path]来查看支持哪些cpu架构；当然还有很多其他的命令来查看二进制文件。 - 编译选项
将build setting中的Optimization Level设置为Fastest, Smallest [-Os]; 将build setting 中的Strip Debug Symbols During Copy设置为YES(COPY_PHASE_STRIP = YES)，这样可以减小编译出二进制文件的尺寸。这里提到的这些设置在Xcode工程中对于Release的配置是默认的，所以只要自己不去瞎折腾就好。
### 图片资源 - 从PhotoShop保存的文件默认包含一些“语法数据”，因此存在一定的优化空间： imageOptim工具可以很方便地批量优化图片，效果很显著。两个工具用
-
尽量使用resizable的图片：对于可拉伸的图片，比如圆角按钮的背景，尽量减少原始图片的像素尺寸，和android里面9patch概念一样。 而且经过测试，这种图片的运行时内存效率也更高。
背景图：尽量与UI设计沟通，使用纯色、瓦片(可无限重复平铺)的形式； -
大图片： 对于大图片，如果不是启动图，也没有透明部分，可以试试jpg格式；或者与UI设计沟通一下，是否可以分拆成简单背景加前景小图片来减少总尺寸
-
不使用图片可以考虑替代方案：纯色； 对于简单的渐变（轴式、放射式)，可以考虑用2D绘图代码实现，像引导页这种只显示一次的图，如果可能的话，用这种方式是比较合适的。
注意：对一个很大的(比如可滚动的）且并长期存在的view，不要用2D绘图，因为这导致系统为这个view创建一个同样尺寸的bitmap，内存消耗是很惊人的：retina的iphone上一张全屏图需要11369604 ~= 4M内存 -
image assets：xcode5引入image asset的概念，方便了对图片的管理，一个好处是添加/删除图片不再修改project文件。如果你的build target是ios7以下的话，没有什么其他的区别；如果是ios7的话，images.xasset会被编译器打包处理成一个二进制文件Asset.car，减少总体图片文件尺寸；从测试的情况看，确实能稍稍减小总体的尺寸，而且还能识别内容重复、名字不同的图片。
由于这个措施是有益无害的，建议有时间改动的话，将图片加到image asserts里面，而且image asset还能保存resizable信息，减少了在代码里面指定的麻烦。 -
Xcode的pngcrush:Xcode自带一个png处理工具，可以对png进行处理，但是这种处理有可能会减小、也有可能会稍微增大png图片；在我测试的例子里面，一张优化至80k左右的图片打包后变成了100k。苹果的说法是这个处理工具将png转换成ios设备易于加载的形式，可以在xcode的
buildsettings->compress png files来设置这个选项。
从本人测试的情况看，关闭这个选项对加载速度的影响并不明显，同时对最终安装包大小的影响(在完成了其他优化措施的前提下)也不是很大，所以建议还是保持默认的打开就好。
stack overflow上有个讲这个问题的帖子http://stackoverflow.com/questions/12667066/why-are-png-images-larger-in-the-ios-app-bundle-than-in-my-project/12673061#12673061
### 字符串数据 字符串如果直接嵌在代码里面，就被编译成为可执行文件的数据段的一个部分；这种情况下那么相当于内存的映像，没有什么可压缩的空间。字符串如果做成localizable.string的形式，就会形成一个单独的文本文件，可以被编译器很大地压缩，而且通过运行测试，这种形式占用的内存也稍微小一点。 从优化的实际效果来看，这一点对安装包的大小影响倒不是很大；但相对于把数据资源嵌在可执行文件里面，这种方式总归是比较好的做法，以后维护起来也比较方便。
### 动态下载资源 如果资源不是运行必须的，可以考虑不放在安装包里面，改为动态下载， 比如字体、图片、配置数据等。
### 减少升级包的大小 当从App Store升级应用时，不会下载所有的文件，只会下载需要更新的文件，这个过程对用户和开发者都是透明的；因此，如果尽量少修改文件，避免修改大文件，将修改隔离成一个小文件能够显著减少升级所需要下载的安装包尺寸。要不是安装文件特别大的话，还没有必要在这上面下功夫。
参考资料：
https://developer.apple.com/library/ios/qa/qa1795/_index.html#//apple_ref/doc/uid/DTS40014195-CH1-MEASURE
http://beyondvincent.com/blog/2014/03/24/reducing-the-size-of-my-app/
http://stackoverflow.com/questions/12667066/why-are-png-images-larger-in-the-ios-app-bundle-than-in-my-project/12673061#12673061
http://jishu.zol.com.cn/140415.html
http://zh.wikipedia.org/wiki/ARM架構