App启动速度优化与监控

最近在作一款陌生人社交的软件，市场上这类软件都是大同小异。为了能让产品比竞品更具竞争力，作为开发者，除了完成来自产品经理需求外，咱们能作的还有这些：

• 崩溃率优化
• 交互的优化
• 动画的优化

我把App启动速度的优化归结在交互优化中

通常状况下，App的启动分为冷启动和热启动

• 冷启动 app启动前，它的进程不在系统里，须要系统新建立一个进程分配给他启动的状况，即App从被杀死的状况下启动
• 热启动

app在冷启动后将程序退到后台，在app进程还在系统里的状况下，用户重 新启动进入app的过程，即app从被挂起的状况下启动，这个过程作的事情很是少

这篇文章主要探讨app冷启动的优化 用户能感知到的启动慢，其实都发生在主线程上，而主线程慢的缘由有不少，好比在主线程上执行了大文件读写操做、在渲染周期执行了大量计算等。可是，有时候你会发现即便你把首屏显示以前的这些主线程的耗时问题都解决了，仍是比竞品启动得慢。

通常而言，App的启动时间，指的是从用户点击App开始，到用户看到第一个界面之间的时间，总结来讲，App的启动主要包括三个阶段：

1. main()函数执行前
2. main()函数执行后
3. 首屏渲染完成后

main()函数执行前

在 main()函数执行前，系统主要会作下面几件事：

• 加载可执行文件（App的.o文件的集合）
• 加载动态连接库，进行rebase指针调整和bind符号绑定
• objc 运行时的初始处理，包括objc相关类的注册、category注册、selector惟一性检查等
• 初始化，包括了执行+load()方法、attribute((constructor))修饰的函数的调用、建立C++静态全局变量

响应的，在这个阶段对于启动速度优化来讲，能够作的事情包括:

• 减小动态库加载,每一个库自己都有依赖关系，苹果官方建议使用更少的动态库，而且建议在使用动态库的数量较多时，尽可能将多个动态库进行合并。数量上，苹果公司最多能够支持6个非系统动态库合并为1个
• 减小加载启动后不会去使用的类或者方法
• +load()方法里的内容能够放到首屏渲染完成后再执行，或使用+initialize方法替换掉。由于，在一个+load()方法里，运行运行时方法替换操做会带来4毫秒的消耗，不要小看这4毫秒，聚沙成塔，执行+load()方法对启动速度的影响会愈来愈大
• 控制C++全局变量的数量

main()函数执行后

main()函数执行后的阶段，指的是从main() 函数执行开始，到 appDelegate的(BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {}方法里首屏渲染相关方法执行完成 首页的业务代码都是要在这个阶段，也就是首屏渲染前执行的，主要包括了：

• 首屏初始化所需配置文件的读写操做
• 首屏列表大数据的读取
• 首屏渲染的大量计算等

不少时候，咱们会把各类初始化工做都放到这个阶段执行（如各种sdk初始化），致使渲染完成置后。更加优化的开发方式，应该是从功能上梳理出哪些是首屏渲染必要的初始化功能，哪些是App启动必要的初始化功能，而哪些是只须要在对应功能开始使用时才须要初始化的。梳理完以后，将这些初始化功能分别放到合适的阶段进行。

首屏显示完成后

首屏渲染完成后的这个阶段，主要完成的是，非首屏其它业务服务模块的初始化、监听的注册、配置文件的读取等。从函数上来看，这个阶段指的就是截止到(BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {}方法做用域内执行首屏渲染以后的全部执行方法。简单说的话，这个阶段就是从渲染完成时，到(BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {}方法做用域结束时结束。

这个阶段用户已经可以看到App的首页信息了，因此优化的优先级排在最后。可是，那些会卡住主线程的方法仍是须要最优先处理的，否则仍是会影响到用户后面的交互操做。

明白了App启动阶段须要完成的工做后，咱们就能够有的放矢的进行启动速度的优化了。这些优化，包括了功能级别和方法级别的优化

功能级别的启动优化

功能级别的启动优化，就是要从main()函数执行后这个阶段入手

优化的思路是：main()函数开始执行后到首屏渲染完成前只处理首屏相关的业务，其余非首屏业务的初始化、监听注册、配置文件读取等都放到首屏渲染完成后去作

方法级别的启动优化

通过功能级别的启动优化，也就是将首屏业务所需的功能滞后之后，当用户点击App到看到首屏的时间将会很大程度的缩减，也就达到了优化App启动速度的目的。

在这以后，咱们须要进一步作的，是坚持首屏渲染完成前主线程上有哪些耗时方法，将不必的耗时方法滞后或者异步执行。一般状况下，耗时较长的方法主要发生在计算大量数据的状况下，具体的表现就是加载、编辑、储存图片和文件等资源

App启动速度的监控

• 定时抓取主线程上的方法调用堆栈，计算一段时间里各个方法的耗时。Xcode工具里的Time Profile 采用的就是这种方式
• 对objc_msgSend 方法进行hook来掌握全部方法的执行耗时

hook方法的意思是，在原方法开始执行时换成其余你指定的方法，或者再原有方法执行先后执行你指定的方法，来达到掌握和改变指定方法的目的。

hook objc_msgSend这种方式的优势是很是精确，而缺点是只能针对Objective-C方法。对于c方法和block，可使用libffi 的ffi_call来达成hook。缺点就是编写维护相关工具门槛高

综上，若是对于检查结果精准度要求高的话，推荐使用hool objc_msgSend方式来检查启动方法的执行耗时