iOS性能优化 - APP启动时间优化

2018-08-03  本文已影响295人  Simba_LX

废话不说,直接上干货!


一、APP启动过程

1.解析Info.plist

2.Mach-O加载

3.程序执行


二、监测启动时间

1.开启时间分析功能

在Xcode的菜单中选择Project→Scheme→Edit Scheme...,然后找到Run → Environment Variables → +,添加name为DYLD_PRINT_STATISTICSvalue1的环境变量。

image

运行后会在控制台看到如下内容:

Total pre-main time:  94.33 milliseconds (100.0%)
dylib loading time:  61.87 milliseconds (65.5%)
rebase/binding time:   3.09 milliseconds (3.2%)
ObjC setup time:  10.78 milliseconds (11.4%)
initializer time:  18.50 milliseconds (19.6%)
slowest intializers :
libSystem.B.dylib :   3.59 milliseconds (3.8%)
libBacktraceRecording.dylib :   3.65 milliseconds (3.8%)
MyTest :   7.09 milliseconds (7.5%)

得出结论:


三、影响APP启动性能的因素

1.main()函数之前耗时的影响因素

实验证明,在ObjC类的数目一样多的情况下,需要加载的动态库越多,App启动就越慢。同样的,在动态库一样多的情况下,ObjC的类越多,App的启动也越慢。需要加载的动态库从1个上升到10个的时候,用户几乎感知不到任何分别,但从10个上升到100个的时候就会变得十分明显。同理,100个类和1000个类,可能也很难查察觉得出,但1000个类和10000个类的分别就开始明显起来。

同样的,尽量不要写__attribute__((constructor))的C函数,也尽量不要用到C++的静态对象;至于ObjC的+load方法,似乎大家已经习惯不用它了。任何情况下,能用dispatch_once()来完成的,就尽量不要用到以上的方法。

2.main()函数之后耗时的影响因素

main()函数开始至didFinishLaunchingWithOptions结束,我们统一称为main()函数之后的部分。

3.didFinishLaunchingWithOptions的耗时

其实 didFinishLaunchingWithOptions 方法里我们一般都有以下的逻辑:


四、制定优化目标

分为四个部分:

  1. main()函数之前
  2. main()函数之后至didFinishLaunchingWithOptions完成
  3. App完成所有本地数据的加载并将相应的信息展示给用户
  4. App完成所有联网数据的加载并将相应的信息展示给用户

五、优化方案

1.main()函数之前的优化

  1. 移除不需要用到的动态库。
  2. 移除不需要用到的类。
  3. 合并功能类似的类和扩展(Category)。
  4. 压缩资源图片。
  5. 减少load 方法中执行的代码。

2.main()函数之后至didFinishLaunchingWithOptions完成的优化

这一步主要优化didFinishLaunchingWithOptions方法中的代码和rootViewController加载的优化。

  1. didFinishLaunchingWithOptions优化
    对于 didFinishLaunchingWithOptions,这里面的初始化是必须执行的,但是我们可以适当的根据功能的不同对应的适当延迟启动的时机。对于我们项目,我将初始化分为三个类型:

对于第一类,由于这类事件的特殊性,所以必须第一时间启动,仍然把它留在 didFinishLaunchingWithOptions 里启动。第二类事件,这些功能在用户进入 APP 主体的之前是必须要加载完的,所以我们可以把它放在第二批,也就是用户已经看到广告页面,再进行广告倒计时的时候再启动。第三类事件,由于不是必须的,所以我们可以放在第一个界面渲染完成以后的 viewDidAppear 方法里,这里完全不会影响到启动时间。

  1. rootViewController加载优化
    这个只能看具体的逻辑和业务了,尽量把不必要的业务和网络请求等延后加载。
上一篇 下一篇

猜你喜欢

热点阅读