App 启动速度怎么做优化与监控？

目录

APP启动过程

冷启动优化

app启动三个阶段过程着手优化

功能级别的启动优化

方法级别的启动优化

        检查首屏渲染完成前主线程上有哪些耗时方法，将没必要的耗时方法滞后或者异步执行。

        启动速度监控，找出耗时方法

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

待更新

---

APP启动过程

• 冷启动：App 点击启动前，它的进程不在系统里，需要系统新创建一个进程分配给它启动的情况。这是一次完整的启动过程；我的理解：冷却后的启动，也就是app已经被后台杀掉后的启动。如第一次启动app、杀掉app重新进入、app崩溃后重新进入。
• 热启动：App 在冷启动后用户将 App 退后台，在 App 的进程还在系统里的情况下，用户重新启动进入 App 的过程，这个过程做的事情非常少。我的理解：app启动后还活着的时候，再次进入app的过程。

冷启动优化

app启动三个阶段过程着手优化

1. main() 函数执行前；

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

• 加载可执行文件（App 的.o 文件的集合）；
• 加载动态链接库，进行 rebase 指针调整和 bind 符号绑定；
• Objc 运行时的初始处理，包括 Objc 相关类的注册、category 注册、selector 唯一性检查等；
• 初始化，包括了执行 +load() 方法、attribute((constructor)) 修饰的函数的调用、创建 C++ 静态全局变量。
  • attribute((constructor)) 修饰的函数
    • 参考：__attribute__作用_xiaowhy的博客-CSDN博客_attribute 的作用
  • C++ 静态全局变量
    • 全局变量和和由static修饰的静态变量都被储存在全局数据区
    • 全局数据区的内存在程序运行时会被全部置'0'.这不同于局部变量，局部变量在栈上分配内存，但此块内存一般不为零，且编译器不会在局部变量被声明的地方为其置'0',除非申明时对其初始化值为0
    • 全局的声明在任何函数以外，任何文件都可以引用，使用externel关键字引用即可。
    • 静态变量如果声明在本文件所有函数以外，所有函数都可以访问；如果声明在方法类作为局部变量，则只有本方法可以访问，也就是静态的局部变量，和局部变量的区别是，只初始化一次，假如初始值是10，改成了20，第2此进入，初始值则是20。也就是第二次进入，自动忽略了初始化这一步了。
    • ​​​​​​​​​​​​​​​​​​​​​参考c++全局变量与静态变量_wusimpl的博客-CSDN博客_c++ 全局静态变量

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

• 减少动态库加载。每个库本身都有依赖关系，苹果公司建议使用更少的动态库，并且建议在使用动态库的数量较多时，尽量将多个动态库进行合并。数量上，苹果公司建议最多使用 6 个非系统动态库。
  • 动态库怎么合并？
    • 参考自动合并真机和模拟器frameworkiOS 自动生成framework并自动进行模拟器和真机framework合并_jeffasd的博客-CSDN博客​​​​​​​
    • 参考解决三方framework只提供arm64,没有x86_64,模拟器不能运行的问题 - 简书
• 减少加载启动后不会去使用的类或者方法。我的理解是无效代码？
• +load() 方法里的内容可以放到首屏渲染完成后再执行，或使用 +initialize() 方法替换掉。因为，在一个 +load() 方法里，进行运行时方法替换操作会带来 4 毫秒的消耗。不要小看这 4 毫秒，积少成多，执行 +load() 方法对启动速度的影响会越来越大。
  • 问题：+load()方法什么时候调用？
    • 参考iOS +load()详解 - 简书，再多看看，更深入了解+load()方法的执行原理
  • 问题： +initialize()什么时候调用
    • + initialize 方法类似一个懒加载，如果没有使用这个类，那么系统默认不会去调用这个方法，且默认只加载一次
    • + initialize 的调用发生在 -init 方法之前
    • 如果你实现了 + load 方法，那么当类被加载时它会自动被调用。这个调用非常早。如果你实现了一个应用或框架的 + load，并且你的应用链接到这个框架上了，那么 ＋ load 会在 main() 函数之前被调用。如果你在一个可加载的 bundle 中实现了 + load，那么它会在 bundle 加载的过程中被调用。
    • + initialize 方法的调用看起来会更合理，通常在它里面写代码比在 + load 里写更好。+ initialize 很有趣，因为它是懒调用的，也有可能完全不被调用。
    • +initialize和+load的区别在于，+load只能执行一次，而+initialize会执行多次，为什么呢，因为我们知道+initialize是消息机制触发的，当一个子类中没有+initialize方法时，它自然会执行父类的+initialize方法，而+load方法逻辑是，当该类没有实现+load时，则会跳过！
    • 类第一次被加载时，+ initialize 不会被调用。类接收消息时，运行时会先检查 + initialize 有没有被调用过。如果没有，会在消息被处理前调用；
    • swift没有load？
      • 参考Sina Visitor System
    • 参考iOS - + initialize 与 +load_马拉萨的春天的博客-CSDN博客iOS开发-关于+load和+initialize_CaicaiNo.1的博客-CSDN博客
• 控制 C++ 全局变量的数量。问题：写在类以外的变量？

2.main() 函数执行后；

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

问题：首屏渲染相关方法执行完成具体指哪个方法？

• 从main函数执行，到设置self.window.rootViewController执行完成
• 参考iOS App启动优化（一）—— 了解App的启动流程 - 程序员大本营

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

         

3.首屏渲染完成后。

        从函数上来看，这个阶段指的就是截止到 didFinishLaunchingWithOptions 方法作用域内执行首屏渲染之后的所有方法执行完成。

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

功能级别的启动优化

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

        我的思考：在didFinishLaunchingWithOptions方法里少些代码，将不同功能类型的代码抽取到对应模块，在这里只负责调用，这样就方便检查出来那些代码放在了不合适的位置。

方法级别的启动优化

        检查首屏渲染完成前主线程上有哪些耗时方法，将没必要的耗时方法滞后或者异步执行。

        1. 对资源的操作（读取、编辑、存储文件等）的方法耗时较长，滞后或者异步执行

        2.不太容易看出的耗时方法

        就像 +load() 方法，一个耗时 4 毫秒，100 个就是 400 毫秒，这种耗时用户也是能明显感知到的。比如，我以前使用的 ReactiveCocoa 框架（这是一个 iOS 上的响应式编程框架），每创建一个信号都有 6 毫秒的耗时。这样，稍不注意各种信号的创建就都被放在了首屏渲染完成前，进而导致 App 的启动速度大幅变慢。

        启动速度监控，找出耗时方法

• 定时抓取主线程上的方法调用堆栈，计算一段时间里各个方法的耗时。
• 对 objc_msgSend 方法进行 hook 来掌握所有方法的执行耗时

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

待更新