iOS App启动过程

1、启动过程

iOS开发中，main函数是咱们熟知的程序启动入口，但实际上并不是真正意义上的入口，由于在咱们运行程序，再到main方法被调用之间，程序已经作了许许多多的事情，好比咱们熟知的runtime的初始化就发生在main函数调用前，还有程序动态库的加载连接也发生在这阶段。

整个过程为：

1. 系统先读取App的可执行文件（Mach-O文件），从里面得到dyld的路径
2. 加载dyld（the dynamic link editor，Apple 的动态连接器，系统 kernel 作好启动程序的初始准备后，交给 dyld 负责），dyld去初始化运行环境，开启缓存策略，
3. dyld加载程序相关动态库，并对这些库进行连接,调用每一个依赖库的初始化方法
4. runtime被初始化
5. ImageLoader:dyld把Image（包含咱们的类、方法等）load进来
6. runtime对加载进来的Image全部类进行类结构初始化，调用全部的load方法，Category方法也在此时被调用
7. dyld返回main函数地址，main函数被调用
8. main函数调用
9. 执行AppDelegate的代理方法，主要是didFinishLaunchingWithOptions
10. 初始化Window，初始化基础的ViewController结构
11. 获取数据(Local DB／Network)，展现给用户

2、main函数启动以前

Mach-O可执行文件

Mach-O文件格式是 OS X 与 iOS 系统上的可执行文件格式，像咱们编译过程产生的.O文件，以及程序的可执行文件，动态库等都是Mach-O文件。有如下几种Mach-O

• Executable 可执行文件
• Dylib 动态库
• Bundle 库：没法被链接的动态库，只能经过dlopen()加载
• Image ：指的是Executable，Dylib或者Bundle的一种，文中会屡次使用Image这个名词。
• Framework 库：动态库和对应的头文件和资源文件的集合

Mach-O的结构以下：

• Header 头部，包含能够执行的CPU架构，好比x86,arm64
• Load commands 加载命令，包含文件的组织架构和在虚拟内存中的布局方式
• Data，数据，包含load commands中须要的各个段(segment)的数据，每个Segment都得大小是Page的整数倍。

更多Mach-O可查看《Mac OS X ABI Mach-O File Format Reference》

有两种方式能够查看一个APP动态调用的系统可执行文件

一、经过machoview,选择APP的可执行文件，能够看到

二、经过otool -L命令行查看

dyld

全程the dynamic loade，Apple 的动态连接器，系统 kernel 作好启动程序的初始准备后，交给 dyld 负责。

2017年，苹果引入了Dyld 3.0，可是只有系统APP采用这个，第三方APP都是采用Dyld 2.0。

Dyld 2.0的加载过程是：

1. 解析 mach-o 文件，找到其依赖的库，而且递归的找到全部依赖的库，造成一张动态库的依赖图。iOS 上的大部分 app 都依赖 300 到 600 个动态连接库，因此这个步骤包含了较大的工做量。
2. 匹配 mach-o 文件到自身的地址空间；
3. 进行符号查找：好比 app 中调用了 printf 方法，就须要去系统库中查找到 printf 的地址，而后将地址拷贝到 app 中的函数指针中；
4. 绑定和变基：因为 app 须要让地址空间配置随机加载，因此全部的指针都须要加上一个基地址；
5. 运行初始化程序（Runtime、+load、+initialize），以后运行 main() 函数。

3、优化启动时间

main函数以后

Appdelegate

能延迟初始化的尽可能延迟初始化，不能延迟初始化的尽可能放到后台初始化。

• 三方SDK初始化，好比Crash统计; 像分享之类的，能够等到第一次调用再出初始化。
• 初始化某些基础服务，好比WatchDog，远程参数。
• 启动相关日志，日志每每涉及到DB操做，必定要放到后台去作
• 业务方初始化，这个交由每一个业务本身去控制初始化时间。

启动业务的优化

建一个类来管理初始化，全部须要初始化的代码都在这里进行，分类初始化：

ViewController

延迟初始化那些没必要要的UIViewController。

用Time Profiler找到元凶

Main以前

dylibs

启动的第一步是加载动态库，加载系统的动态库使很快的，由于能够缓存，而加载内嵌的动态库速度较慢。因此，提升这一步的效率的关键是：减小动态库的数量。

• 合并动态库，好比公司内部由私有Pod创建了以下动态库：XXTableView, XXHUD, XXLabel，强烈建议合并成一个XXUIKit来提升加载速度。

Rebase & Bind & Objective C Runtime

Rebase和Bind都是为了解决指针引用的问题。对于Objective C开发来讲，主要的时间消耗在Class/Method的符号加载上，因此常见的优化方案是：

• 减小__DATA段中的指针数量。
• 合并Category和功能相似的类。好比：UIView+Frame,UIView+AutoLayout…合并为一个
• 删除无用的方法和类。
• 多用Swift Structs，由于Swfit Structs是静态分发的。感兴趣的同窗能够看看我以前这篇文章：《Swift进阶以内存模型和方法调度》

Initializers

一般，咱们会在+load方法中进行method-swizzling，这也是Nshipster推荐的方式。

• 用initialize替代load。很多同窗喜欢用method-swizzling来实现AOP去作日志统计等内容，强烈建议改成在initialize进行初始化。
• 减小__atribute__((constructor))的使用，而是在第一次访问的时候才用dispatch_once等方式初始化。
• 不要建立线程
• 使用Swfit重写代码。

4、Category

category其实是个结构体，与Class结构体相似

struct _category_t {
	const char *name; // 类的名字，用于寻找类
	struct _class_t *cls; // 编译期为空，在runtime经过name找到类后得到
	const struct _method_list_t *instance_methods; // 实例方法
	const struct _method_list_t *class_methods; // 类方法
	const struct _protocol_list_t *protocols; // 协议
	const struct _prop_list_t *properties; // 关联属性
};
复制代码

1. runtime的入口_objc_init方法里调用_getObjc2CategoryList获取category_t 的列表，而后再一一将category添加进去
2. category是在runtime在把类的结构已经初始化以后，加载进去的，由于内存布局已经肯定，因此不能添加实例变量，只能经过添加关联属性的方式来添加“变量”。
3. runtime添加方法的时候会放在方法列表的前面，也就是说若是以前有相同名字的方法，根据运行时的特性，调用方法时将会调用category的方法，从而达到了“覆盖”的效果

5、iOS 静态库，动态库与 Framework

静态库与动态库的区别

首先来看什么是库，库(Library)说白了就是一段编译好的二进制代码，加上头文件就能够供别人使用 何时咱们会用到库呢？一种状况是某些代码须要给别人使用，可是咱们不但愿别人看到源码，就须要以库的形式进行封装，只暴露出头文件。另一种状况是，对于某些不会进行大的改动的代码，咱们想减小编译的时间，就能够把它打包成库，由于库是已经编译好的二进制了，编译的时候只须要 Link 一下，不会浪费编译时间。 上面提到库在使用的时候须要 Link，Link 的方式有两种，静态和动态，因而便产生了静态库和动态库。

静态库

静态库即静态连接库（Windows 下的 .lib，Linux 和 Mac 下的 .a）。之因此叫作静态，是由于静态库在编译的时候会被直接拷贝一份，复制到目标程序里，这段代码在目标程序里就不会再改变了。 静态库的好处很明显，编译完成以后，库文件实际上就没有做用了。目标程序没有外部依赖，直接就能够运行。固然其缺点也很明显，就是会使用目标程序的体积增大。

动态库

动态库即动态连接库（Windows 下的 .dll，Linux 下的 .so，Mac 下的 .dylib/.tbd）。与静态库相反，动态库在编译时并不会被拷贝到目标程序中，目标程序中只会存储指向动态库的引用。等到程序运行时，动态库才会被真正加载进来。 动态库的优势是，不须要拷贝到目标程序中，不会影响目标程序的体积，并且同一份库能够被多个程序使用（由于这个缘由，动态库也被称做共享库）。同时，编译时才载入的特性，也可让咱们随时对库进行替换，而不须要从新编译代码。动态库带来的问题主要是，动态载入会带来一部分性能损失，使用动态库也会使得程序依赖于外部环境。若是环境缺乏动态库或者库的版本不正确，就会致使程序没法运行（Linux 下喜闻乐见的 lib not found 错误）。

iOS Framework

除了上面提到的 .a 和 .dylib/.tbd 以外，Mac OS/iOS 平台还可使用 Framework。Framework 其实是一种打包方式，将库的二进制文件，头文件和有关的资源文件打包到一块儿，方便管理和分发。

在 iOS 8 以前，iOS 平台不支持使用动态 Framework，开发者可使用的 Framework 只有苹果自家的 UIKit.Framework，Foundation.Framework 等。这种限制多是出于安全的考虑（见这里的讨论)。换一个角度讲，由于 iOS 应用都是运行在沙盒当中，不一样的程序之间不能共享代码，同时动态下载代码又是被苹果明令禁止的，没办法发挥出动态库的优点，实际上动态库也就没有存在的必要了。

因为上面提到的限制，开发者想要在 iOS 平台共享代码，惟一的选择就是打包成静态库 .a 文件，同时附上头文件（例如微信的SDK）。可是这样的打包方式不够方便，使用时也比较麻烦，你们仍是但愿共享代码都能能像 Framework 同样，直接扔到工程里就能够用。因而人们想出了各类奇技淫巧去让 Xcode Build 出 iOS 可使用的 Framework，具体作法参考这里和这里，这种方法产生的 Framework 还有 “伪”(Fake) Framework 和 “真”(Real) Framework 的区别。

iOS 8/Xcode 6 推出以后，iOS 平台添加了动态库的支持，同时 Xcode 6 也原生自带了 Framework 支持（动态和静态均可以），上面提到的的奇技淫巧也就没有必要了（新的作法参考这里）。为何 iOS 8 要添加动态库的支持？惟一的理由大概就是 Extension 的出现。Extension 和 App 是两个分开的可执行文件，同时须要共享代码，这种状况下动态库的支持就是必不可少的了。可是这种动态 Framework 和系统的 UIKit.Framework 仍是有很大区别。系统的 Framework 不须要拷贝到目标程序中，咱们本身作出来的 Framework 哪怕是动态的，最后也仍是要拷贝到 App 中（App 和 Extension 的 Bundle 是共享的），所以苹果又把这种 Framework 称为 Embedded Framework。