ANDROID 冷启动耗时 ios冷启动过程

转载

mob64ca13fd163c 2023-11-18 16:17:43

文章标签 ANDROID 冷启动耗时 ios 加载初始化启动时间 文章分类 Android 移动开发

前言

当用户按下Home键的时候，iOS的APP并不会马上被kill掉，还会继续存活若干时间。理想情况下，用户点击APP的图标再次回来的时候，APP几乎不需要做什么，就可以还原带退出前的状态，继续为用户服务。这种持续存活的情况下启动APP，我们称为热启动，相对而言冷启动就是APP被kill掉以后一切从头开始启动的过程。我们这里只讨论APP冷启动的情况。

对于冷启动来说，启动时间是指从用户点击APP那一刻开始到用户看到第一个界面这中间的时间。我们进行优化的时候，我们将启动时间分为 pre-main 时间和 main 函数到第一个界面渲染完成时间这两部分。

因为APP的入口在 main 函数，在 main 函数之后我们的代码才会执行。

这里有两个阶段

1、pre-main阶段

    1.1、加载应用的可执行文件
    1.2、加载动态链接库加载器dyld (dynamic loader)
    1.3、dyld 递归加载 应用所有依赖的 dylib (dynamic library 动态链接库)

2、main() 阶段

    2.1、dyld 调用 main()
    2.2、调用 UIApplicationMain()
    2.3、调用applicationWillFinishLaunching
    2.4、调用didFinishLaunchingWithOptions

我们把 pre-main 阶段称为 t1, main() 阶段一直到首个页面加载完成称为 t2。

t1时间的优化分析

t1部分主要参考自APP启动优化的一次实践

其中t1苹果提供了内建的测量方法，Xcode中 Edit scheme -> Run -> Auguments 将环境变量 DYLD_PRINT_STATISTICS 设置为 1

//结果为：
Total pre-main time: 1.7 seconds (100.0%)
        dylib loading time: 799.29 milliseconds (46.9%)
       rebase/binding time: 141.75 milliseconds (8.3%)
           ObjC setup time: 260.70 milliseconds (15.3%)
          initializer time: 499.85 milliseconds (29.3%)
           slowest intializers :
             libSystem.B.dylib : 8.00 milliseconds (0.4%)
    libMainThreadChecker/dylib : 59.75 milliseconds (3.5%)
                   CloudOffice :  323.43 milliseconds (30.7%)

//解读
1、main() 函数之前总共使用了 1.7 秒
2、加载动态库用了799.29毫秒，指针重定位使用了141.75毫秒，ObjC类初始化使用了260.7毫秒各种初始化使用了499.85毫秒
3、在初始化耗费的499.85毫秒中，用时最多的初始化是CloudOffice

可以看到，我的 dylib loading time

加载 dylib
分析每个 dylib（大部分是iOS系统库），找到其 Mach-O 文件，
打开并读取验证有效性，找到代码签名注册到内核，
最后对 dylib 的每个 segment 调用 mmap()。
rebase/bind
dylib 加载完成之后，它们处于相互独立的状态，需要绑定起来。
在 dylib 的加载过程中，系统为了安全考虑，引入了 ASLR（Address Space Layout Randomization）技术和代码签名。
由于ASLR的存在，镜像（Image，包括可执行文件、dylib和bundle）会在随机的地址上加载，和之前指针指向的地址（preferred_address）会有一个偏差（slide）,dyld 需要修正这个偏差，来指向正确的地址。
Rebase在前，Bind在后，Rebase做的是将镜像读入内存，修正镜像内部的指针，性能消耗主要在IO。
Bind做的是查询符号表，设置指向镜像外部的指针，性能消耗主要在CPU计算。
OC setup
OC的runtime需要维护一张类名与类的方法列表的全局表。
dyld 做了如下操作：
对所有声明过的OC类，将其注册到这个全局表中（class registration）
将 category 的方法插入到类的方法列表中（category registration）
检查每个Selector 的唯一性（Selector uniquing）
如果在各个 OC 类别的 ‘load’ 方法里做了不少事情（如在里面使用 Method swizzle）,那么这是 pre-main 阶段最耗时的部分。dyld 运行APP的初始化函数，调用每个 OC 类的 +load

优化思路是：

1、移除不需要用到的动态库；
2、移除不需要用到的类；
3、合并功能类似的类和扩展；
4、尽量避免在 +load 方法里执行的操作，可以推迟到 +initialize

t2时间的优化分析

t2可以使用 NewPan 大佬的打点计时器BLStopwatch，或者Instrument 的 Time Profile，亦或者自己写一个时间戳统计工具。

在 didFinishLaunchingWithOptions

初始化第三方 SDK
配置 APP 运行所需要的环境
自己的一些工具类的初始化
......

这里主要参考[iOS]一次立竿见影的启动时间优化

我的应用的跳转逻辑是打开 -> 广告页 -> 首页，首页的UI架构是：

ANDROID 冷启动耗时 ios冷启动过程_ANDROID 冷启动耗时

但是如果UI架构如上，并且在 didFinishLaunchingWithOptions

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    NSLog(@"didFinishLaunchingWithOptions 开始执行");

    self.window = [[UIWindow alloc] initWithFrame:[UIScreen mainScreen].bounds];
    TestTabBarController *tabBarVc = [TestTabBarController new];
    self.window.rootViewController = tabBarVc;
    [self.window makeKeyAndVisible];

    NSLog(@"didFinishLaunchingWithOptions 跑完了");

    return YES;
}

然后我们来到 TestTabBarController 里的 viewDidLoad 方法里进行它的 viewControllers 的设置，然后再进入到每个 viewController 的viewDidLoad 方法里进行更多的初始化操作。那么你觉得从 didFinishLaunchingWithOptions 到最后显示展示的 viewController 的 viewDidLoad 这些方法的执行顺序是怎么样了呢？

didFinishLaunchingWithOptions  开始执行
开始加载 TestTabBarController 的viewDidLoad
didFinishLaunchingWithOptions  跑完了
开始加载 TestViewController 的 viewDidLoad，然后执行一堆初始化的操作

在 TestTabBarController 中操作了 TestViewController 的 view

didFinishLaunchingWithOptions  开始执行
开始加载 TestTabBarController 的 viewDidLoad
开始加载 TestViewController 的 viewDidLoad，然后执行一堆初始化的操作
didFinishLaunchingWithOptions  跑完了

这样的问题就是当我们把界面的初始化、网络请求、数据解析、视图渲染等操作放在了 viewDidLoad

一般来说，我们放到 didFinishLaunchingWithOptions 执行的代码，有很多初始化操作，如日志，统计，SDK配置等。尽量做到只放必须的，其他的可以延迟到 MainViewController 展示完成 viewDidAppear

日志、统计等必须在 APP 一启动就最先配置的事件
项目配置、环境配置、用户信息的初始化、推送、IM等事件
其他SDK和配置事件

第一类，必须第一时间启动，仍然把它留在 didFinishLaunchingWithOptions 里启动。
第二类，这些功能在用户进入 APP 主体之前是必须要加载完的，我把它放到广告页面的 viewDidAppear 启动。
第三类，由于启动时间不是必须的，所以我们可以放在第一个界面的 viewDidAppear

优化思路

梳理各个三方库，找到可以延迟加载的库，做延迟加载处理，比如放到首页控制器的 viewDidAppear
梳理业务逻辑，把可以延迟执行的逻辑，做延迟执行处理。比如检查新版本、推送注册通知等逻辑。
避免复杂/多余的计算。
避免在首页控制器的 viewDidLoad 和 viewWillAppear
采用性能更好的API。
首页控制器用纯代码方式来构建。