在我们提交安装包到App Store的时候，如果安装包过大，有可能会收到类似如下内容的一封邮件：
收到这封邮件的时候，意味着安装包在App Store上下载的时候，有的设备下载的安装包大小会超过100M。对于超过100M的安装包，只能在WIFI环境下下载，不能直接通过4G网络进行下载。
在这里，我们提交App Store的安装包大小为虚拟机实
- polly: 支持高级别的循环和数据本地化优化支持的LLVM框架。
- klee: 基于LLVM编译基础设施的符号化虚拟机
【说明】：从功能的角度来说，微观的LLVM可以认为是一个编译器的后端，而Clang是一个编译器的前端。关于Clang和LLVM的关系，可以看一下。
从一个简单的例子开始：
在编译一个源文件时，编译器的处理过程分为几个阶段。要想查看编译 main.m 源文件需要几个不同的阶段，我们可以让通过 clang 命令观察：
从结果可以看到，从源文件到可执行文件，经过了这么几个过程：预处理、编译、汇编、链接，最终生成可执行文件。
当程序执行时，操作系统将可执行文件拷贝到内存中。那么我们的程序最终是怎么执行的呢？程序的执行是在进程中进行的，程序转化为进程大致分为这么几个步骤：
- 1.内核将程序读入内存，为程序镜像分配内存空间。程序镜像的内存布局分为如下部分(可通过size指令查看代码段、数据段、BSS段的大小以及这3个段大小之和的十进制和十六进制表示)：
- 代码段：即机器码，只读，可共享（多个进程共享代码段）；
- 数据段：储存已被初始化了的静态数据；
- BSS段(未初始化的数据段)：储存未始化的静态数据；
- 堆：储存动态分配的内存；
- 栈：储存函数调用的上下文，动态数据。
- 2.内核为该进程分配进程标志符（PID）。
- 3.内核为该进程保存PID及相应的进程状态信息。
经过上面几个步骤，操作系统向内核数据结构中添加了适当的信息，并为运行程序代码分配了必要的资源之后，程序就变成了进程。下面我们来分析编译的几个阶段。
执行指令，我们看一下预处理阶段都做了哪些事情：
【说明】:目前预处理中引入了功能，这使预处理变得更加的高级。
通过上面的指令，我们看一下输出的结果：
从结果可以看到，预处理阶段，会进行宏的替换，头文件的导入，以及类似#if的处理。
在预处理完成之后，会进行词法分析，这里会把代码切成一个个 Token，比如大小括号，等于号还有字符串等。我们可以通过指令看一下词法分析：
然后进行语法分析，验证语法是否正确，然后将所有节点组成抽象语法树 AST：
我们可以用下面的命令让 clang 输出汇编代码：
//.section 指令指定接下来会执行哪一个段
//.globl 指令说明 _main 是一个外部符号。这就是我们的 main() 函数。这个函数对于二进制文件外部来说是可见的，因为系统要调用它来运行可执行文件。
//.align 指令指出了后面代码的对齐方式。在我们的代码中，后面的代码会按照 16(2^4) 字节对齐，如果需要的话，用 0x90 补齐。
//_main 函数真正开始的地址。这个符号会被 export。二进制文件会有这个位置的一个引用。
//.cfi_startproc 指令通常用于函数的开始处。CFI 是调用帧信息 (Call Frame Information) 的缩写。这个调用 帧 以松散的方式对应着一个函数。当开发者使用 debugger 和 step in 或 step out 时，实际上是 stepping in/out 一个调用帧。在 C 代码中，函数有自己的调用帧，当然，别的一些东西也会有类似的调用帧。.cfi_startproc 指令给了函数一个 .eh_frame 入口，这个入口包含了一些调用栈的信息（抛出异常时也是用其来展开调用帧堆栈的）。这个指令也会发送一些和具体平台相关的指令给 CFI。它与后面的 .cfi_endproc 相匹配，以此标记出 main() 函数结束的地方。
//和.cfi_offset %rbp, -16一起，会输出一些关于生成调用堆栈展开和调试的信息。我们改变了堆栈和基础指针，而这两个指令可以告诉编译器它们都在哪儿，或者更确切的，它们可以确保之后调试器要使用这些信息时，能找到对应的东西。
//把局部变量放置到栈上
//将栈指针移动 16 个字节，也就是函数会调用的位置
//把使用来存储参数的寄存器数量存储在寄存器 al 中
//下面的代码将 ecx 寄存器设置为 0，并把 eax 寄存器的值保存至栈中，然后将 ect 中的 0 拷贝至 eax 中。ABI 规定 eax 将用来保存一个函数的返回值
//把之前存储至 rbp 中的值从栈中弹出来
//返回调用者， ret 会读取出栈的返回地址
//.section 指令指出下面将要进入的段
//L_.str 标记运行在实际的代码中获取到字符串的一个指针
//.asciz 指令告诉编译器输出一个以 ‘\0’ (null) 结尾的字符串。
关于汇编指令的资料，可以在 苹果的 中进行查看和学习。
汇编器将可读的汇编代码转换为机器代码。它会创建一个目标对象文件，一般简称为 对象文件。这些文件以 .o 结尾。如果用 Xcode 构建应用程序，可以在工程的 derived
我们也可以通过如下指令来生成：
链接器解决了目标文件和库之间的链接。 如上面的汇编代码：
printf() 是 libc 库中的一个函数。无论怎样，最后的可执行文件需要能需要知道 printf() 在内存中的具体位置：例如，_printf 的地址符号是什么。链接器会读取所有的目标文件 (此处只有一个) 和库
(此处是 libc)，并解决所有未知符号 (此处是 _printf) 的问题。然后将它们编码进最后的可执行文件中 （可以在 libc 中找到符号 _printf），接着链接器会输出可以运行的执行文件。
这里我们讲一个复杂点的可执行文件。
通过如下指令来分别生成各个类的目标文件，并最终生成可执行文件：
可执行文件和目标文件都有一个符号表，这个符号表规定了它们的符号。如果我们用 nm(1) 工具观察一下 main.o 目标文件，可以看到如下内容：
接下来我们看一下可执行文件：
可以看到所有的 Foundation 和 Objective-C 运行时符号依旧是 undefined，不过现在的符号表中已经多了如何解析它们的信息，例如在哪个动态库中可以找到对应的符号。
当构建一个程序时，将会链接各种各样的库。它们又会依赖其他一些 framework 和 动态库。需要加载的动态库会非常多。而对于相互依赖的符号就更多了。可能将会有上千个符号需要解析处理，这将花费很长的时间：一般是好几秒钟。
为了缩短这个处理过程所花费时间，在 OS X 和 iOS 上的动态链接器使用了共享缓存，共享缓存存于 /var/db/dyld/。对于每一种架构，操作系统都有一个单独的文件，文件中包含了绝大多数的动态库，这些库都已经链接为一个文件，并且已经处理好了它们之间的符号关系。当加载一个 Mach-O
文件 (一个可执行文件或者一个库) 时，动态链接器首先会检查 共享缓存 看看是否存在其中，如果存在，那么就直接从共享缓存中拿出来使用。每一个进程都把这个共享缓存映射到了自己的地址空间中。这个方法大大优化了 OS X 和 iOS 上程序的启动时间。
2.4可执行文件的瘦身
上面介绍了可执行文件的结构以及整个编译过程，介绍这些内容是为了对可执行文件以及它的来历有一个了解，下面我们分析一下对可执行文件的瘦身都有哪些方法。
我们知道，可执行文件是由我们编写的代码产生的。通过脚本分析前面说的LinkMap文件，我们可以更加清晰的知道具体的某个类在可执行文件中的大小。
#使用参数-g会统计每个模块.o的统计大小 #查找 files 列表，找到所有.o文件 #symbol可能来自app本身的目标文件或者系统的动态库
执行脚本之后，输出结果示例如下：
从结果看到，不仅是我们编写的类的大小可以统计出来，第三方的也可以。在实际工程中，我们可以对一些可执行文件中过大的第三方库，思考其存在的必要性，对于不需要存在或者有替换方案的，可以考虑替换或删除。
AppCode是一种智能的Objective-C集成开发环境，由专业的开发收费IDE的公司开发，具有这些特点：
- 最好的代码助手：IDE深入的了解代码结构，编辑器能提供准确的代码实现选择。通过代码生成节省了不必要的输入，减少了日常任务。
- 可靠的代码重构：安全、准确和可靠的代码重构允许我们随时修改和提升代码质量。
- 快速项目导航：通过类继承可以从方法导航到它的声明或使用处，或者直接从一个文件链接到另一个文件。支持即时跳转到项目中的任何文件、类、标号处，或者查看标号的实际使用者，并不仅仅是文本匹配那么简单。
- 强大的代码调试器：使用便携调试器中灵活的断点、窗口、框架视图和求值表达式调整您的应用或单元测试。
- 无缝集成：AppCode完美地集成大部分流行的版本控制系统，如Git, Mercurial、Perforce等，还集成了Kiwi测试框架、Dash和成分文档工具以及很多问题追踪器，提供与Xcode100%的互操作性。
在这里，我们可以用它的inspect code来扫描无用代码，包括无用的类、函数、宏定义、value、属性等，而safe delete功能使得删除一些由于runtime被调用到的代码时更加安全智能。扫描结果示例：
【说明】：如果工程很大，这个扫描的时间可能会比较长。我们现在的工程中，大概有2700个类，扫描时间在一个半小时。
实际上，在2.4.1的扫描结果中，包含无用类，但2.4.1的扫描时间会比较长，另外扫描出来的内容也较多。如果只是需要清理无用类的话，可以用如下脚本：
'未引用到工程的文件列表为：'
同样的工程，这个脚本执行速度大概是三分钟，结果如下：
2.4.3清理无用方法
以往C++在链接时，没有被用到的类和方法是不会编进可执行文件里。但Objctive-C不同，由于它的动态性，它可以通过类名和方法名获取这个类和方法进行调用，所以编译器会把项目里所有OC源文件编进可执行文件里，哪怕该类和方法没有被使用到。
- ：从LinkMap可以发现每个类和方法名都在__cstring段里都存了相应的字符串值，所以类和方法名的长短也是对可执行文件大小是有影响的，原因还是Objective-C的动态特性，因为需要通过类/方法名反射找到这个类/方法进行调用，Objective-C对象模型会把类名，方法名列表都保存下来。实际上这部分占用的长度比较小，中型项目也就几百K，可以忽略。
-
ARC->MRC：ARC代码会在某些情况多出一些retain和release的指令，例如调用一个方法，它返回的对象会被retain，退出作用域后会被release，MRC就不需要，汇编指令变多，机器码变多，可执行文件就变大了。ARC对可执行文件大小的影响几乎都是在代码段，通过实验，结论是ARC大概会使代码段增加10%的size，考虑代码段占可执行文件大约有80%，估计对整个可执行文件的影响会是8%。但考虑到它的可实施性，可以忽略。
点击联系发帖人
