APP启动速度

250 阅读10分钟

冷启动

  • 冷启动是指,App点击启动前,它的进程不在系统里,需要系统新创建一个进程分配给它 启动的情况。这是一次完整的启动过程。

热启动

  • 热启动是指,App在冷启动后用户将App退后台,在App的进程还在系统里的情况 下,用户重新启动进入App的过程,这个过程做的事情非常少。

APP启动3个阶段

main()函数执行前

在main()函数执行前,系统主要会做下面几件事情:

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

相应地,这个阶段对于启动速度优化来说,可以做的事情包括

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

main()函数执行后

  • main()函数执行后的阶段,指的是从main()函数执行开始,到appDelegate的didFinishLaunchingWithOptions 方法里首屏渲染相关方法执行完成。
  • 首页的业务代码都是要在这个阶段,也就是首屏渲染前执行的,主要包括了:
  • 首屏初始化所需配置文件的读写操作;

  • 首屏列表大数据的读取;

  • 首屏渲染的大量计算等。

  • 很多时候,开发者会把各种初始化工作都放到这个阶段执行,导致渲染完成滞后。更加优化 的开发方式,应该是从功能上梳理岀哪些是首屏渲染必要的初始化功能,哪些是App启动必 要的初始化功能,而哪些是只需要在对应功能开始使用时才需要初始化的。梳理完之后,将 这些初始化功能分别放到合适的阶段进行。

首屏渲染完成后

  • 首屏渲染后的这个阶段,主要完成的是,非首屏其他业务服务模块的初始化、监听的注册 配置文件的读取等。从函数上来看,这个阶段指的就是截止到did FinishLaunchingWithOptions方法作用域内执行首屏渲染之后的所有方法执行完成。简 单说的话,这个阶段就是从渲染完成时开始,到 didFinishLaunchingWithOptions方法作 用域结束时结束
  • 这个阶段用户已经能够看到App的首页信息了,所以优化的优先级排在最后。但是,那些会 卡住主线程的方法还是需要最优先处理的,不然还是会影响到用户后面的交互操作
  • 明白了App启动阶段需要完成的工作后,我们就可以有的放矢地进行启动速度的优化了。这 些优化,包括了功能级别和方法级别的启动优化。接下来,我们就从这两个角度展开看看。

功能级别的启动优化

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

  • 我想,你所在的团队一定面临过启动阶段的代码功能堆积、无规范、难维护的问题吧。在App项目开发初期,开发人员不多、代码量也没那么大时,这种情况比较少见。但到了后期,App业务规模扩大,团队人员水平参差不齐,各种代码问题就会爆发出来,终归需要来次全面治理。
  • 而全面治理过程中的手段、方法和碰到的问题,对于后面的规范制定以及启动速度监控都有着重要的意义。那么,我们要怎样从功能级别来进行全面的启动优化治理呢?
  • 优化的思路是:main()函数开始执行后到首屏渲染完成前只处理首屏相关的业务,其他非首屏业务的初始化、监听注册、配置文件读取等都放到首屏渲染完成后去做。如下图所示:

方法级别的启动优化

  • 经过功能级别的启动优化,也就是将非首屏业务所需的功能滞后以后,从用户点击App到看 到首屏的时间将会有很大程度的缩短,也就达到了优化App启动速度的目的
  • 在这之后,我们需要进一步做的,是检查首屏渲染完成前主线程上有哪些耗时方法,将没必 要的耗时方法滞后或者异步执行。通常情况下,耗时较长的方法主要发生在计算大量数据的 情况下,具体的表现就是加载、编辑、存储图片和文件等资源。
  • 那么,你觉得是不是只需要优化对资源的操作就可以了呢?
  • 当然不是。就像+load()方法,一个耗时4毫秒,100个就是400毫秒,这种耗时用户也 是能明显感知到的
  • 比如,我以前使用的 Reactive Cocoa框架(这是一个ios上的响应式编程框架),每创建 一个信号都有6毫秒的耗时。这样,稍不注意各种信号的创建就都被放在了首屏渲染完成 前,进而导致App的启动速度大幅变慢。
  • 类似这样单个方法耗时不多,但是由于堆积导致App启动速度大幅变慢的方法数不胜数。所 以,你需要一个能够对启动方法耗时进行全面、精确检查的手段。
  • 那么问题来了,有哪些监控手段?这些监控手段各有什么优缺点?你又该如何选择呢?

目前来看,对App启动速度的监控,主要有两种手段。

第一种方法是,定时抓取主线程上的方法调用堆栈,计算一段时间里各个方法的耗时。

  • Xcode 工具套件里自带的Time Profler,采用的就是这种方式。
  • 这种方式的优点是,开发类似工具成本不高,能够快速开发后集成到你的App中,以便在真实环境中进行检查。
  • 说到定时抓取,就会涉及到定时间隔的长短问题。
    • 定时间隔设置得长了,会漏掉一些方法,从而导致检查出来的耗时不精确;
    • 而定时间隔设置得短了,抓取堆栈这个方法本身调用过多也会影响整体耗时,导致结果不准确。
  • 这个定时间隔如果小于所有方法执行的时间(比如0.002秒),那么基本就能监控到所有方 法。但这样做的话,整体的耗时时间就不够准确。一般将这个定时间隔设置为0.01秒。这 样设置,对整体耗时的影响小,不过很多方法耗时就不精确了。但因为整体耗时的数据更加 重要些,单个方法耗时精度不高也是可以接受的,所以这个设置也是没问题的。
  • 总结来说,定时抓取主线程调用栈的方式虽然精准度不够高,但也是够用的。

第二种方法是,对objc_ msg Send方法进行hook来掌握所有方法的执行耗时。

  • hook方法的意思是,在原方法开始执行时换成执行其他你指定的方法,或者在原有方法执 行前后执行你指定的方法,来达到掌握和改变指定方法的目的
  • hook objc_ msgSend这种方式的优点是非常精确,而缺点是只能针对 Objective-C的方 法。当然,对于c方法和bock也不是没有办法,你可以使用lib的币ca来达成 hook,但缺点就是编写维护相关工具门槛高。
  • 关于,[i相关的内容,我会在后面的第35篇文章"ibfh:动态调用和定义C函数”里和 你详细说明。
  • 综上,如果对于检查结果精准度要求高的话,我比较推荐你使用 hook objc_msgSend方式 来检查启动方法的执行耗时。

如何做一个方法级别启动耗时检查工具来辅助分析和监控

  • 使用 hook objc_msgSend方式来检查启动方法的执行耗时时,我们需要实现一个称手的启动时间检查工具。那么,我们应该如何实现这个工具呢?
  • 现在,我就一步一步地和你说说具体怎么做。
  • 首先,你要了解为什么hook了objc_msgSend方法,就可以hook 全部 Objective-C的方法?
  • Objective-C里每个对象都会指向一个类,每个类都会有一个方法列表,方法列表里的每个方法都是由selector、函数指针和 metadata组成的。
  • objc_msgSend方法干的活儿,就是在运行时根据对象和方法的selector去找到对应的函数指针,然后执行。也就是说,objc_msgSend是Objective-C里方法执行的必经之路,能够控制所有的Objective-C的方法。
  • objc_msgSend 本身是用汇编语言写的,这样做的原因主要有两个:
    • 一个原因是,objc_msgSend的调用频次最高,在它上面进行的性能优化能够提升整个App 生命周期的性能。而汇编语言在性能优化上属于原子级优化,能够把优化做到极致。所以,这种投入产出比无疑是最大的。
    • 另一个原因是,其他语言难以实现未知参数跳转到任意函数指针的功能。
  • 现在,苹果公司已经开源了Objective-C的运行时代码。你可以在苹果公司的开源网站,找到objc_msgSend的源码。
  • 上图列出的是所有架构的实现,包括x86_64等。objc_ msgSend是ios方式执行最核心 的部分,编程领域的宝藏,值得你深入探究和细细品味。
  • objc_ msgSend方法执行的逻辑是:先获取对象对应类的信息,再获取方法的缓存,根据方 法的 selector查找函数指针,经过异常错误处理后,最后跳到对应函数的实现。
  • 按照这个逻辑去看源码会更加清晰,更容易注意到实现细节。阅读 objc_msgSend源码是编 写方法级耗时工具的一个必要的环节,后面还需要编写一些对应的汇编代码。