性能优化：App启动优化

一、App启动流程

二、App启动优化

三、定量监测App启动耗时

四、定位耗时代码

五、果速送App启动优化

一、App启动流程

---

App启动分两种：冷启动和热启动。冷启动是指启动一个杀死的App，系统需要为App开辟一个新进程，热启动是指启动一个在后台运行的App，App的进程还存活着，系统不需要开辟新进程。而我们通常所说的App启动优化，主要是指冷启动优化——尽可能地缩短启动时间，所以接下来本文中谈到的启动都是指冷启动。

App启动流程主要分为两大阶段：main函数调用前的阶段和main函数调用至didFinishLaunchingWithOptions方法执行完毕的阶段。

1、main函数调用前的阶段

• App启动后，系统会首先加载项目的可执行文件和依赖的动态库到内存中。
• 然后系统会调用Runtime的函数对项目的可执行文件进行解析和处理，把项目中所有的类和分类加载到内存中，此时会调用项目中所有类和分类的+load方法。

2、main函数调用至didFinishLaunchingWithOptions方法执行完毕的阶段

• 系统会调用main函数、UIApplicationMain函数、AppDelegate的didFinishLaunchingWithOptions方法，我们通常会在这个方法里给window设置rootViewController，不过我们要知道只有rootViewController或者rootViewController首屏的viewDidLoad方法和viewWillAppear方法走完了，才算rootViewController设置完毕。
• rootViewController设置完毕，我们通常还会在这个方法里为App添加一些必要的启动项，didFinishLaunchingWithOptions方法走完了就代表App启动起来了，此时系统才会去调用rootViewController或者rootViewController首屏的viewDidAppear方法，这是后话了。

二、App启动优化

---

1、main函数调用前的阶段

• 尽量减少动态库的使用，定期清理掉不必要的动态库；
• 尽量减少类和分类的数量，定期清理掉不必要的类和分类；尽量减少类和分类+load方法的调用，不要在里面做复杂的操作，可以用+initialize方法和dispatch_once替代，因为+initialize方法是初始化类和分类时才调用的。

2、main函数调用至didFinishLaunchingWithOptions方法执行完毕的阶段

• 在rootViewController或者rootViewController首屏的viewDidLoad方法和viewWillAppear方法里尽量只做一些关键数据的初始化和绘制UI操作，不要做别的耗时操作，如果非做不可，就放到子线程里去做。
• 启动项最好按需配置，不需要在App一启动就配置的启动项可以推迟到使用时再配置，必须配置的启动项如果很耗时，就放到子线程里去做。

三、定量监测App启动耗时

---

1、main函数调用前的阶段

Xcode --> Target --> Edit Scheme --> Run --> Arguments --> Environment Variables，添加DYLD_PRINT_STATISTICS = YES。

运行项目，控制台就会打印pre-main阶段的启动耗时了。

我们添加一个ARKit动态库。

我们再添加很多类和分类。

我们再调用一下某个类的+load方法，里面休眠2s模拟耗时操作。

2、main函数调用至didFinishLaunchingWithOptions方法执行完毕的阶段

Xcode --> Project --> Target --> Build Settings --> dsym --> Debug Information Format --> 都设置为DWARF with dSYM File，否则Time Profiler显示出来的都是函数的内存地址而不是函数名。

Instruments的Time Profiler：

• Xcode打开项目，连接真机（一定要用真机调试，因为模拟器用的是电脑的CPU，检测不出手机的启动耗时来）。
• 打开Instruments的Time Profiler。

• 选择真机、选择项目、运行、定量地监测App启动耗时，并定位耗时代码。

// AppDelegate.m
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {

    self.window = [[UIWindow alloc] initWithFrame:[UIScreen mainScreen].bounds];
    [self.window setBackgroundColor:[UIColor whiteColor]];
    [self.window makeKeyAndVisible];
    
    [self.window setRootViewController:[[ViewController alloc] init]];
    
    return YES;
}


// ViewController.m
- (void)viewDidLoad {
    [super viewDidLoad];

}

- (void)viewWillAppear:(BOOL)animated {
    [super viewWillAppear:animated];
    
}

我们在rootViewController的viewDidLoad方法和viewWillAppear方法里添加一些耗时操作。

// ViewController.m
- (void)viewDidLoad {
    [super viewDidLoad];
    
    [self doSomething];
}

- (void)viewWillAppear:(BOOL)animated {
    [super viewWillAppear:animated];
    
    [self doSomething];
}


#pragma mark - 模拟耗时操作

- (void)doSomething {
    
    for (int i = 0; i < 200000; i++) {
        
        NSLog(@"%d", i);
    }
}

可见Test项目的总启动耗时为2.92s，其中“main函数调用至didFinishLaunchingWithOptions方法执行完毕阶段”耗时2.66s，而导致耗时这么长的原因就是rootViewController的viewDidLoad方法和viewWillAppear方法里的doSomething方法，我们可以对它进行优化

我们再在rootViewController设置完毕、didFinishLaunchingWithOptions方法执行完毕之前添加一些耗时操作。

// AppDelegate.m
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {

    self.window = [[UIWindow alloc] initWithFrame:[UIScreen mainScreen].bounds];
    [self.window setBackgroundColor:[UIColor whiteColor]];
    [self.window makeKeyAndVisible];
    
    [self.window setRootViewController:[[ViewController alloc] init]];
    
    [self doSomething];
    
    return YES;
}


#pragma mark - 模拟耗时操作

- (void)doSomething {
    
    for (int i = 0; i < 200000; i++) {
        
        NSLog(@"%d", i);
    }
}

五、果速送App启动优化

---

当然App启动优化的方案有很多，比如尽量减少动态库的使用；尽量减少类和分类的数量，尽量减少类和分类+load方法的调用；在rootViewController首屏的viewDidLoad方法和viewWillAppear方法里尽量只做一些关键数据的初始化和绘制UI操作，不要做别的耗时操作，如果非做不可，就放到子线程里去做；启动项最好按需配置，不需要在App一启动就配置的启动项可以推迟到使用时再配置，必须配置的启动项如果很耗时，就放到子线程里去做。

但是经过定量检测，我们发现影响我们App启动速度的主要原因有两个：一是有一些不用的动态库没有及时清理掉，二是有一个访问数据库的同步I/O操作的启动项比较耗时。

所以我们就定了主要的优化方案就是针对这两点，优化之前App的启动时间大概在700ms左右，而当我们清理掉一些不用的动态库，并且把那个同步I/O操作的启动项放在子线程中去做后，App的启动时间大概就在500ms左右了。

一个额外的优化

此外我们发现首页里有一个“发起定位 --> 定位成功后，拿定位数据发起网络请求 --> 网络请求成功后，拿网络数据刷新页面”这么个串行流程，这个串行过程是很耗时的，这也是导致用户迟迟不能开始使用App的原因所在。

所以我们对这个串行流程也做了优化：在发起定位的同时，拿缓存的定位数据发起网络请求。定位成功后，判断最新的定位数据是否命中缓存的定位数据，如果命中则什么都不做，让之前的请求生效就行了；如果未命中，则取消之前的请求，并拿最新的定位数据发起网络请求。

注意：取消网络请求这个操作

• 如果请求未发出，取消后则不会发出请求；
• 如果请求已发出、未完成，取消后则会立即触发请求的failure回调，我们要在这里判断一下是否是取消了请求再做错误弹框处理；
• 如果请求已完成，取消后则不会有任何效果。

启动项整理

杂乱无章的启动项 整理后的启动项