App的启动速度不单单是用户体验的事情,往往还决定着它能否获取更多的用户!启动速度的优化是App开发过程中不可或缺的一个环节.启动速度优化的学习在这里要感谢滴滴技术专家戴明老师,给我很大的启发!
一般情况下,App的启动分为冷启动和热启动.
1.冷启动是指,App点击启动前,它的进程不在系统里,需要系统创建一个进程分配给它启动的情况.这是一次完整的启动过程
2.热启动是指,App在冷启动后,用户将App退到后台,在App的进程还在系统里的情况下,用户重新启动进入App的过程,这个过程做的事情非常少.
所以我们主要针对冷启动来分析.
一般而言,App的启动时间,是指从用户点击App开始到用户看到的第一个界面的时间.总结来说,App的启动主要经过三个阶段:
1.main()函数执行前 2.main()函数执行后 3.首屏渲染完成后
整个过程的示意图,如下所示
main()函数执行前
1.加载可执行文件(App的.o文件集合)
2.加载动态链接库,进行rebase(基变)指针调整和bind符号绑定
3.Objc运行时的初始处理,包括Objc相关类的注册,category注册,selector唯一性的检查等.
4.初始化,包括了执行+load()方法,attribute(constructor)修饰的函数的调用,创建c++静态全局变量
显而易见,在这个阶段我们可以从这几个方面着手优化,可以做的事情包括:
1.减少动态库加载.每个库本身都有依赖关系,apple建议使用更少的动态库,并且建议使用动态库的数量较多时,尽量讲多个动态库进行合并.在数量上,apple可以最多支持6个非系统动态库合并成一个.
2.减少加载启动后不会实用的类或者方法.
3.+load()方法里的内容可以放到首屏渲染完成后再执行,或使用+initialize()方法替换掉.因为在一个+load()方法里,惊醒运行时方法替换操作会带来4毫秒的消耗.积少成多,执行+load()方法对启动速度的影响会越来越大
4.控制c++全局变量的数量
main()函数执行后
main()函数执行后的阶段,指的是从main()函数执行开始,到appDelegate 的didFinishLaunchingWithOptions方法里首屏渲染相关方法执行完成
首页的业务代码都是要在这个阶段,也就是首屏渲染执行前的,主要包括了:
1.首屏初始化所需要的配置文件的读写操作
2.首屏列表大数据读取
3.首屏渲染的大量计算等
在这个阶段我们可以做的优化包括:
梳理出哪些是App启动必要的初始化功能,哪些是只需要在对应功能开始使用时才需要的功能.梳理完成后将这些初始化功能分别放到合适的阶段进行.
首屏渲染完成后
首屏渲染后的这个阶段,主要完成的是,非首屏渲染其它业务服务模块的初始化,监听注册,配置文件的读取等,从函数上来看,这个极端就是截至到didFinishLaunchingWithOptions方法作用域内执行首屏渲染之后的所有方法执行完成.简单的说,这个阶段就是从渲染完成开始,到didFinishLaunchingWithOptions方法作用域结束时结束.
这个阶段用户已经能够看到App的首页信息了,所以优化的优先级排在最后,但是那些会卡住主线程的方法还是需要最优先处理的,不然还是会影响到用户后面的交互操作.
明白了App启动阶段需要完成的工作后,我们就可以有针对性的对启动速度进行又花了,这些优化包括功能级别和方法级别的启动优化,接下来我们就从这两个角度展开看看.
功能级别的启动优化
功能级别的启动优化,就是要从main()函数执行后这个阶段下手.
优化的思路是:main()函数开始执行后到首屏渲染前只处理首屏相关的业务,其它飞首屏业务的初始化,监听注册,配置文件读取都放到首屏渲染完成后去做,如下图所示:
方法级别的启动优化
检查首屏渲染后前主线程有哪些耗时操作,或者异步操作.通常情况下,具体的表现就是加载,编辑,储存图片和文件等.
那么,你觉的是不是只需要优化对资源的操作就可以了呢?
当然不是!就像+load()方法一个耗时4-5毫秒 100个呢?这种耗时用户是明显可以感觉到的.
累死这种单个方法耗时不多,但由于堆积导致App启动速度大幅度变慢的方法数不胜数.所以我们需要一个能够针对启动方法耗时进行全面,精确的检查手段!
xcode工具里自带的Time Profiler
定时抓取主线程上的方法调用堆栈,计算一段时间里各个方法的耗时.具体请参考Time Profiler使用
