夕阳最美时，也总是将近黄昏。
世上有很多事都是这样子的，尤其是一些特别辉煌美好的事。
所以你不必伤感，也不用惋惜，纵然到江湖去赶上了春，也不必留住它。
因为这就是人生，有些事你留也留不住。
你一定要先学会忍受它的无情，才会懂得享受它的温柔。
所以该静心撸码的时候，就不要想其他。好了，废话少说，直接切入主题。
1. App启动过程
解析Info.plist
- 加载相关信息，例如如闪屏
- 沙箱建立、权限检查
Mach-O加载
- 如果是胖二进制文件，寻找合适当前CPU类别的部分
- 加载所有依赖的Mach-O文件（递归调用Mach-O加载的方法）
- 定位内部、外部指针引用，例如字符串、函数等
- 执行声明为attribute((constructor))的C函数
- 加载类扩展（Category）中的方法
- C++静态对象加载、调用ObjC的 +load 函数
程序执行
- 调用main()
- 调用UIApplicationMain()
- 调用applicationWillFinishLaunching
什么是冷启动、热启动
从电路角度来看：
热启动是在系统仍通电的情况下重新启动系统，热启动也是一次软件复位。热启动清除易失性系统内存，并重新装载操作系统。
冷启动是用关闭电源来启动系统，冷启动还对硬件进行复位，它检查硬件，并重新装载操作系统。
最重要的是冷启动对硬件进行一次检查。现在的电脑这个过程好像不是很明显，但是在40年前，这个硬件检查一次可是很耗时间的。
冷启动，电路会从断开变成通路，期间，主机受到的影响类似我们开电灯的时候电灯受的影响（我说的是类似），大家都知道，电动设备启动的时候会有一大电流冲击。
从移动app角度来看：
当用户按下home键的时候，iOS的App并不会马上被kill掉，还会继续存活若干时间。理想情况下，用户点击App的图标再次回来的时候，App几乎不需要做什么，就可以还原到退出前的状态，继续为用户服务。这种持续存活的情况下启动App，我们称为热启动，相对而言冷启动就是App被kill掉以后一切从头开始启动的过程。我们这里只讨论App冷启动的情况。
测量Pre-main Time
在Xcode的菜单中选择Project→Scheme→Edit Scheme...，然后找到 Run → Environment Variables
配置的 key 为：DYLD_PRINT_STATISTICS 设置1或者YES都可。
勾选如图：
运行的时候会进行打印：
what`s the fuck？
main()函数之前总共使用了1.6ms
加载动态库用了1.1ms，
指针重定位使用了392.11ms，
ObjC类初始化使用了46.43ms，
各种初始化使用了56.29ms。
在初始化耗费的56.29ms中，用时最多的初始化是libSystem.dylib、libMainThreadChecker.dylib
那么如何尽可能的减少pre-main花费的时间呢,主要就从输出日志给出的四个阶段下手:
对动态库加载的时间优化
每个App都进行动态库加载,其中系统级别的动态库占据了绝大数,而针对系统级别的动态库都是经过系统高度优化的,不用担心时间的花费.开发者应该关注于自己集成到App的那些动态库,这也是最能消耗加载时间的地方.对此Apple建议减少在App里开发者的动态库集成或者有可能地将其多个动态库最终集成一个动态库后进行导入,尽量保证将App现有的非系统级的动态库个数保证在6个以内.减少Appp的
Objective-C类,分类和的唯一Selector的个数
这样做主要是为了加快程序的整个动态链接, 在进行动态库的重定位和绑定(Rebase/binding)过程中减少指针修正的使用,加快程序机器码的生成.减少Objc运行初始化的时间花费.
主要是类的注册,分类的注册,唯一选择器的存在,以及涉及子父类内存布局的Non Fragile ivars偏移的更新,都会影响Objective-C运行时初始化的时间消耗.使用
initialize方法进行必要的初始化工作.用+initialize方法替换调用原先在OC的+load方法中执行初始代码工作,从而加快所有类文件的加载速度.
使用load不要在这里面执行耗时的操作。其他的不是短时间能改变的。
测量main Time
一般项目的组织架构：
didFinishLaunchingWithOptions
在didFinishLaunchingWithOptions这里面有的是必须执行的，但是我们可以适当的根据功能的不同对应的适当延迟启动的时机。对于我们项目，我将初始化分为三个类型：
- 日志、统计等必须在 APP 一起动就最先配置的事件
- 项目配置、环境配置、用户信息的初始化 、推送、IM等事件
- 其他 SDK 和配置事件
第一类，由于这类事件的特殊性，所以必须第一时间启动，仍然把它留在 didFinishLaunchingWithOptions 里启动。
第二类事件，这些功能在用户进入 APP 主体的之前是必须要加载完的，所以我们可以把它放在第二批，也就是用户已经看到广告页面，再进行广告倒计时的时候再启动。
第三类事件，由于不是必须的，所以我们可以放在第一个界面渲染完成以后的 viewDidAppear 方法里，这里完全不会影响到启动时间。
参考文章，我们不妨提取出一个工具类，为了以后防止以后继续优化
下面是这个类的头文件：
/**
* 注意: 这个类负责所有的 didFinishLaunchingWithOptions 延迟事件的加载.
* 以后引入第三方需要在 didFinishLaunchingWithOptions 里初始化或者我们自己的类需要在 didFinishLaunchingWithOptions 初始化的时候,
* 要考虑尽量少的启动时间带来好的用户体验, 所以应该根据需要减少 didFinishLaunchingWithOptions 里耗时的操作.
* 第一类: 比如日志 / 统计等需要第一时间启动的, 仍然放在 didFinishLaunchingWithOptions 中.
* 第二类: 比如用户数据需要在广告显示完成以后使用, 所以需要伴随广告页启动, 只需要将启动代码放到 startupEventsOnADTimeWithAppDelegate 方法里.
* 第三类: 比如直播和分享等业务, 肯定是用户能看到真正的主界面以后才需要启动, 所以推迟到主界面加载完成以后启动, 只需要将代码放到 startupEventsOnDidAppearAppContent 方法里.
*/
#import <Foundation/Foundation.h>
NS_ASSUME_NONNULL_BEGIN
@interface BLDelayStartupTool : NSObject
/**
* 启动伴随 didFinishLaunchingWithOptions 启动的事件.
* 启动类型为:日志 / 统计等需要第一时间启动的.
*/
+ (void)startupEventsOnAppDidFinishLaunchingWithOptions;
/**
* 启动可以在展示广告的时候初始化的事件.
* 启动类型为: 用户数据需要在广告显示完成以后使用, 所以需要伴随广告页启动.
*/
+ (void)startupEventsOnADTime;
/**
* 启动在第一个界面显示完(用户已经进入主界面)以后可以加载的事件.
* 启动类型为: 比如直播和分享等业务, 肯定是用户能看到真正的主界面以后才需要启动, 所以推迟到主界面加载完成以后启动.
*/
+ (void)startupEventsOnDidAppearAppContent;
@end
NS_ASSUME_NONNULL_END
下面是 .m 文件，这里做了一层自动校验，如果 30 秒 以后，这些启动项有没有被启动的，就会在 DEBUG 环境下弹出警告信息。同时也会将那些没有启动的启动项进行启动。
#import "BLDelayStartupTool.h"
static BOOL _isCalledStartupEventsOnAppDidFinishLaunchingWithOptions = NO;
static BOOL _isCalledStartupEventsOnADTimeWithAppDelegate = NO;
static BOOL _isCalledStartupEventsOnDidAppearAppContent = NO;
const NSTimeInterval kBLDelayStartupEventsToolCheckCallTimeInterval = 30;
@implementation BLDelayStartupTool
+ (void)load {
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(kBLDelayStartupEventsToolCheckCallTimeInterval * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
[self checkStartupEventsDidLaunched];
});
}
+ (void)checkStartupEventsDidLaunched {
NSString *alertString = @"";
if (!_isCalledStartupEventsOnAppDidFinishLaunchingWithOptions) {
alertString = [alertString stringByAppendingString:@"AppDidFinishLaunching, "];
[self startupEventsOnAppDidFinishLaunchingWithOptions];
}
if (!_isCalledStartupEventsOnADTimeWithAppDelegate) {
alertString = [alertString stringByAppendingString:@"ADTime, "];
[self startupEventsOnADTime];
}
if (!_isCalledStartupEventsOnDidAppearAppContent) {
alertString = [alertString stringByAppendingString:@"DidAppearAppContent"];
[self startupEventsOnDidAppearAppContent];
}
if (alertString.length > 0) {
#if DEBUG
alertString = [alertString stringByAppendingString:@" 等延迟启动项没有启动, 这会造成应用奔溃"];
UIAlertView *alertView = [[UIAlertView alloc] initWithTitle:@"注意" message:alertString delegate:nil cancelButtonTitle:@"好的" otherButtonTitles:nil];
[alertView show];
#endif
}
}
+ (void)startupEventsOnAppDidFinishLaunchingWithOptions {
_isCalledStartupEventsOnAppDidFinishLaunchingWithOptions = YES;
}
+ (void)startupEventsOnADTime {
_isCalledStartupEventsOnADTimeWithAppDelegate = YES;
}
+ (void)startupEventsOnDidAppearAppContent {
_isCalledStartupEventsOnDidAppearAppContent = YES;
}
@end
参考文章：
一次立竿见影的启动时间优化
WWDC 之优化 App 启动速度
App Startup Time: Past, Present, and Future
iOS App 启动性能优化
优化 App 的启动时间
iOS 启动优化 + 监控实践
