iOS的App启动一般有两个过程，发生在main函数前的过程和main函数之后的过程。
main函数前
App开始启动后，系统首先加载可执行文件（即App所有.o文件），然后加载动态链接库dyld，dyld是一个专门负责加载动态链接库的库（the dynamic link editor工具），dyld会加载所有可执行文件（.o文件）的依赖动态库，包括App使用到的所有系统 framework，还有一些runtime和系统级别的lib，如libobjc、libSystem等
简单来说，上述所说的可执行文件（.o文件）和动态库都可以称为image。
所有动态链接库、App集成的静态库、所有类文件编译后的.o文件最终都是由dyld这个工具加载到内存中。每个image都是由一个叫做ImageLoader的类来负责加载。
ImageLoader
这里的image并不是代表图片的意思，表示一个二进制文件（可执行文件或 so 文件），里面是被编译过的符号、代码等，所以 ImageLoader 作用是将这些文件加载进内存，且每一个文件对应一个ImageLoader实例来负责加载。
大概流程
1、dyld 开始将程序二进制文件初始化
2、交由 ImageLoader 读取 image，其中包含了我们的类、方法等各种符号
3、由于 runtime 向 dyld 绑定了回调，当 image 加载到内存后，dyld 会通知 runtime 进行处理
4、runtime 接手后调用 mapimages 做解析和处理，接下来 loadimages 中调用 callloadmethods 方法，遍历所有加载进来的 Class，按继承层级依次调用 Class 的 +load 方法和其 Category 的+load 方法。
至此，可执行文件中和动态库所有的符号(Class，Protocol，Selector，IMP，…)都已经按格式成功加载到内存中，被 runtime 所管理，再这之后，runtime 的那些方法(动态添加 Class、swizzle 等等才能生效)。
简单来说就是
dyld加载各种库---->ImageLoader读取 image ---- >runtime初始化环境
优化
对于main()调用之前的耗时我们可以优化的点有：
1、减少动态库，官方建议6个，不要链接那些用不到的库（包括系统）。
2、检查+load()方法是否合理
3、合并或者删减一些OC类，关于清理项目中没用到的类。
4、二进制重排，减少page fault的次数
启动时间计算
pre-main的大概过程可以简述为
加载可执行文件、加载动态链接器dyld、按照依赖加载动态库
为了获得启动时间，可以在第一个动态库开始记录启动时间，但是在加载动态库之前还有一段时间我们记录不到。
所以这时候可以换一个方法。
使用OC的NSProcessInfo类，获取App创建进程的时间戳。
#import
#include
#include
#include
//// 根据进程ID,获取进程信息！
+ (BOOL)processInfoForPID:(int)pid procInfo:(struct kinfo_proc*)procInfo
{
int cmd[4] = {CTL_KERN, KERN_PROC, KERN_PROC_PID, pid};
size_t size = sizeof(*procInfo);
return sysctl(cmd, sizeof(cmd)/sizeof(*cmd), procInfo, &size, NULL, 0) == 0;
}
// 根据进程信息，获取具体的进程加载到内存中的时间戳
+ (NSTimeInterval)processStartTime {
struct kinfo_proc kProcInfo;
if ([[self class] processInfoForPID:[[NSProcessInfo processInfo] processIdentifier] procInfo:&kProcInfo]) {
return (kProcInfo.kp_proc.p_un.__p_starttime.tv_sec * 1000.0 + kProcInfo.kp_proc.p_un.__p_starttime.tv_usec / 1000.0);
} else {
NSAssert(NO, @"无法取得进程的信息");
return 0;
}
}
启动之后，进入main函数之后到applicationDidBecomeActive，才算启动结束。
所以统计创建进程的时间戳到BecomeActive时间戳时间的时间差即可。
启动函数耗时
Instrument中的 Time Profiler工具，可以查看App在某一段时间的方法耗时，大概原理如下。
1ms 采样一次，只采集在运行线程的调用栈，最后以统计学的方式汇总。注意，每1ms采样，Profiler看堆栈的方法，如果有，那么这个方法就叠加 1ms,事实上并不是代码实际执行的时间，不是很准确的，有可能会遗漏，而是栈在采样统计中出现的时间
除了使用 Time Profiler工具，我们还可以使用fishhook工具，hook objc_msgSend方法，用来统计每个方法（包含第三方SDK静态库内部的方法）的启动耗时。本质上是在方法的开始和末尾打两个点，就知道这个方法的耗时，然后转换成 Chrome 的标准的火焰图 json 格式，将该json文件传入分析工具chrome://tracing/生成火焰图，通过以下火焰图，我们可以非常方便的看到启动时执行了哪些方法和耗时的多少。
软件的性能分析，往往需要查看 CPU 耗时，了解瓶颈在哪里。
火焰图（flame graph）是性能分析的利器。
main函数后
在main()被调用之后，
执行
- (BOOL)Application:(UIApplication *)Application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
然后在这个方法必要的服务，配置第三方库、显示首页内容等。
可以优化的点：
1、尽量使用代码布局UI，避免使用XIB、storyboard。
2、一些在didFinishLaunchingWithOptions的配置或者创建可以使用懒加载，或者延后创建。
参考文章
https://techblog.toutiao.com/2017/01/17/iosspeed/