启动时间
应用启动流程IOS应用的启动可分为pre-main阶段和main()阶段,其中系统做的事情依次是:
前主阶段1.1.加载应用的可执行文件1.2.加载动态链接库加载器DYLD(动态加载器)1.3。DYLD递归加载应用所有依赖的dylib(动态库动态链接库)
Main()阶段2.1。DYLD调用Main()2.2。调用UIApplicationMain()2.3。调用应用程序将最终运行2.4。调用完成了LaunchingWithOptions
启动耗时的测量
在进行优化之前,我们首先应该能测量各阶段的耗时.
1.前主阶段
对于预主阶段,Apple提供了一种测量方法,在Xcode中编辑方案->Run->Auguments将环境变量DYLD_print_STATISTICS设为1.之后控制台会输出类似内容:
Total pre-main time: 228.41 milliseconds (100.0%)
dylib loading time: 82.35 milliseconds (36.0%)
rebase/binding time: 6.12 milliseconds (2.6%)
ObjC setup time: 7.82 milliseconds (3.4%)
initializer time: 132.02 milliseconds (57.8%)
slowest intializers :
libSystem.B.dylib : 122.07 milliseconds (53.4%)
CoreFoundation : 5.59 milliseconds (2.4%)
这样我们可以清晰的看到每个耗时了.
2.main()阶段
米恩()阶段主要是测量ian()函数开始执行到最后做完,LaunchingWithOptions执行结束的时间,我们直接插入代码就可以了.
CFAbsoluteTime StartTime;
int main(int argc, char * argv[]) {
StartTime = CFAbsoluteTimeGetCurrent();
再在AppDelegate.m文件中用extern声明全局变量StartTime
extern CFAbsoluteTime StartTime;
最后在最后做完,LaunchingWithOptions里,再获取一下当前时间,与StartTime的差值即是Main()阶段运行耗时。
double launchTime = (CFAbsoluteTimeGetCurrent() - StartTime);
改善启动时间
预主阶段
在这一阶段,我们能做的主要是优化动态库
加载Dylib
之前提到过加载系统的dylib很快,因为有优化.但加载内嵌(嵌入式)的dylib文件很占时间,所以尽可能把多个内嵌dylib合并成一个来加载,或者使用静态存档。使用dlopen()来在运行时懒加载是不建议的,这么做可能会带来一些问题,并且总的开销更大.
重基/绑定
之前提过Rebaing消耗了大量时间在I/O上,而在之后的Binding就不怎么需要I/O了,而是将时间耗费在计算上。所以这两个步骤的耗时是混在一起的.
之前说过可以从查看__DATA段中需要修正(修补)的指针,所以减少指针数量才会减少这部分工作的耗时.对于objc来说就是减少Class,selector 和 category这些元数据的数量.从编码原则和设计模式之类的理论都会鼓励大家多写精致短小的类和方法,并将每部分方法独立出一个类别,其实这会增加启动时间.对于C++来说需要减少虚方法,因为虚方法会创建vtable,这也会在__DATA段中创建结构.虽然C++虚方法对启动耗时的增加要比objc元数据要少,但依然不可忽视.
Objc设置
大部分objc初始化工作已经在rebase/BIND阶段做完了,这一步DYLD会注册所有声明过的objc类,将分类插入到类的方法列表里,再检查每个选择器的唯一性。在这一步倒没什么优化可做的,重基/绑定阶段优化好了,这一步的耗时也会减少。
初始化器
到了这一阶段,DYLD开始运行程序的初始化函数,调用每个objc类和分类的+Load方法,调用C/C++中的构造器函数(用属性(构造函数))修饰的函数),和创建非基本类型的C++静态全局变量。初始化器阶段执行完后,DYLD开始调用Main()函数。在这一步,我们可以做的优化有:
1.少在类的+加载方法里做事情,尽量把这些事情推迟到+初始化2。减少构造器函数个数,在构造器函数里少做些事情3.减少C++静态全局变量的个数
Main()阶段的优化
这一阶段的优化主要是减少didFinishLaunchingWithOptions方法里的工作,在didFinishLaunchingWithOptions方法里,我们会创建应用的窗口,指定其rootViewController,调用窗口的makeKeyAndVisible方法让其可见.由于业务需要,我们会初始化各个二方/三方库,设置系统UI风格,检查是否需要显示引导页、是否需要登录、是否有新版本等,由于历史原因,这里的代码容易变得比较庞大,启动耗时难以控制.
所以,满足业务需要的前提下,didFinishLaunchingWithOptions在主线程里做的事情越少越好.在这一步,我们可以做的优化有:
1.梳理各个二方/三方库,找到可以延迟加载的库,做延迟加载处理,比如放到首页控制器的viewDidacuar方法里.2.梳理业务逻辑,把可以延迟执行的逻辑,做延迟执行处理.比如检查新版本、注册推送通知等逻辑.3.避免复杂/多余的计算.4.避免在首页控制器的viewDidLoad和viewWillacuar做太多事情,这2个方法执行完,首页控制器才能显示,部分可以延迟创建的视图应做延迟创建/懒加载处理.5.首页控制器用纯代码方式来构建.
点击可获取iOS技术资料大全
总结
总结起来,好像启动速度优化就一句话:让系统在启动期间少做一些事.当然我们得先清楚工程里做的哪些事是在启动期间做的、对启动速度的影响有多大,然后逐个案例地分析工程代码,通过放到子线程、延迟加载、懒加载等方式让系统在启动期间更轻松些。