App启动速度优化与监控

iOS Objective-C 评论

App启动

App启动类型

  • 冷启动

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

  • 热启动

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

App启动三个阶段

  • main() 函数执行前；

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

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

    在该阶段可以做一些事情来优化App的启动速度：

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

  • main() 函数执行后；

    main() 函数执行后的阶段，指的是从 main() 函数执行开始，到 appDelegate 的 didFinishLaunchingWithOptions方法里首屏渲染相关方法执行完成。

    首页的业务代码都是要在这个阶段，也就是首屏渲染前执行的，主要包括：

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

  • 首屏渲染完成后。

    首屏渲染后的这个阶段，主要完成的是，非首屏其他业务服务模块的初始化、监听的注册、配置文件的读取等。从函数上来看，这个阶段指的就是截止到 didFinishLaunchingWithOptions 方法作用域内执行首屏渲染之后的所有方法执行完成。简单说的话，这个阶段就是从渲染完成时开始，到 didFinishLaunchingWithOptions 方法作用域结束时结束。

    这个阶段用户已经能够看到 App 的首页信息了，所以优化的优先级排在最后。但是，那些会卡住主线程的方法还是需要最优先处理的，不然还是会影响到用户后面的交互操作。

查看App启动耗时

查看main()调用前花费的总时间

在Product->Scheme->Edit Scheme->Run->Arguments->Environment Variables->DYLD_PRINT_STATISTICS设置为YES，就可以在控制台中查看main函数执行前总共花费的多长时间。

查看加载了多少动态库

在Product->Scheme->Edit Scheme->Run->Diagnostics->Logging->勾选Dynamic Library Loads，就可以在控制台中查看本项目中加载的所有动态库（包括系统的和自己的）。

查看Main函数启动后的耗时

main函数调用后的耗时，可以使用一些工具来监控，有一种非常笨但是很实用的方法，就是通过打点，在didFinishLaunchingWithOptions开始前打一个点，在App显示完成第一个界面再打一个点，计算两个点之间的耗时，就可以知道main函数调用后到界面显示出来的耗时了，但是这样只能笼统的知道总的耗时，并不能准确的知道时间花在了哪里。

如果想用这个打点法的话，推荐一个打点工具BLStopwatch

App启动速度优化

功能级别的启动优化

功能级别的启动优化要从main()函数执行后这个阶段下手。思路：

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

方法级别的启动优化

优化对资源的操作

将主线程上线耗时方法滞后或者异步执行。通常情况下，耗时较长的方法主要发生在计算大量数据的情况下，具体的表现就是加载、编辑、存储图片和文件等资源。

对App启动方法耗时进行监控

  1. 定时抓取主线程上的方法调用栈，计算一段时间里各个方法耗时

    • 定时间隔设置得长了，会漏掉一些方法，从而导致检查出来的耗时不精确

    • 而定时间隔设置得短了，抓取堆栈这个方法本身调用过多也会影响整体耗时，导致结果不准确

    这个定时时间小于所有方法的执行时间(如：0.002秒)，那么基本就能监控到所有方法，但是这样计算出来的整体耗时不够准确。一般将这个时间间隔设置成0.01秒，这样虽然很多方法耗时不准确，但是整体耗时比较准确。所以这种方式虽然单个方法耗时不是非常准确，但是相对来说，整体耗时精度够用。如，Xcode自带TimeProfiler就是采用这种方式计算的。

  2. 对 objc_msgSend 方法进行 hook 来掌握所有方法的执行耗时。

    • hook 方法的意思是，在原方法开始执行时换成执行其他你指定的方法，或者在原有方法执行前后执行你指定的方法，来达到掌握和改变指定方法的目的
    • hook objc_msgSend 这种方式的优点是非常精确，而缺点是只能针对 Objective-C 的方法。当然，对于 c 方法和 block 也不是没有办法，你可以使用 libffi 的 ffi_call 来达成 hook，但缺点就是编写维护相关工具门槛高

    综上，如果对于检查结果精准度要求高的话，我比较推荐你使用 hook objc_msgSend 方式来检查启动方法的执行耗时。

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

根据TimeProfiler原理，实现了一个计算主线程上所有方法耗时的工具(点我)，大致思路如下：

  1. 通过定时器，每隔0.01s，获取一次主线程的函数堆栈，将函数名称、函数地址、函数耗时模型化为TimeModel，保存在callStackDict中，其中key为函数地址，value为TimeModel
  2. 定时执行的回调中，每次都判断函数地址是否存在，如果已经存在此函数地址，就讲对应的TimeModel中的耗时增加0.01s；如果不存在此函数地址，就初始化一个TimeModel，并将时间设置为0.01s。
  3. 当主界面显示完成之后，输出此callStackDict，即可查看主线程中每个方法的耗时

欢迎各位大佬指教