iOS App的启动流程可以分成两个阶段 pre-main阶段和main阶段。

pre-main阶段

系统将App的可执行文件（Mach-O文件）和dyld加载到内存，由dyld进行动态链接。

• 设置相关环境变量

  根据环境变量设置相应的值以及获取当前运行架构。例如配置环境变量打印启动流程耗时： DYLD_PRINT_STATISTICS和DYLD_PRINT_STATISTICS_DETAILS。

• 加载共享缓存库

  加载动态共享缓存库到动态库共享缓存区，例如UIKit、CoreFoundation等官方库。

• 加载动态库

  把所有的可执行文件所依赖的动态库递归加载到内存中。

• rebase和binding

  iOS采用ASLR技术（地址空间布局随机化），加载App的内存地址是随机的，rebase会根据随机的偏移量对原来的地址做重定向。
  binding进行符号绑定。指向image外部动态库的指针被符号（symbol）绑定。dyld需要去符号表里查找，找到对应的实现。

• Objc setup

  1. 注册ObjC类
  2. 把category的定义插入方法列表
  3. selector唯一性检查

• initializer

  1. 调用所有类、分类的+load方法
  2. 调用__attribute__((constructor))修饰的函数
  3. 非基本类型的C++静态全局变量的创建（通常是类或结构体）

map_images与load_images
map_images : dyld 将 image 加载进内存时 , 会触发该函数.
load_images : dyld 初始化 image 会触发该方法. ( 我们所熟知的 load 方法也是在此处调用 ) .
dyld在初始化其他动态库之前，会最先初始化系统库libsystem，运行Runtime。系统库libsystem初始化完成后，就会初始化其他动态库，然后由Runtime调用map_images来读取类、方法、协议以及分类并存储到对应的表中(注意：分类并不是直接存，而是通过attachLists方法把分类的数据添加到类里面)，然后Runtime会继续调用load_images调用所有类的load方法以及分类的load方法，这些都做完之后，通过dyld提供的回调_dyld_objc_notify_register，告诉dyld加载完毕，然后dyld就开始找主程序的入口main函数，最后进入程序的main函数。

load方法的调用顺序
+load方法是在load_images中调用的。
load方法调用顺序为：先处理类，后处理分类；处理类的顺序是先父类，后子类
在调用类的load方法时，做了递归处理，会先调用父类的load，然后再调用子类的load，所有类的load方法调用完成后，才会开始处理所有类的分类，分类的处理顺序取决于Mach-O头文件，和类的顺序没有直接关系。先后顺序即：父类->子类->所有类的分类。

pre-main时间统计

iOS10至iOS14，可通过Edit Scheme->Arguments->Environment Variables添加环境变量 DYLD_PRINT_STATISTICS和DYLD_PRINT_STATISTICS_DETAILS，value都为YES。
iOS15以上可通过instrument->app launch进行分析。

ab8ac863d.png

• 统计线上用户App启动时间

添加环境变量或者通过app launch，可以在开发阶段进行分析，那么如何在App发布后，统计线上用户App的启动时间？
实际上，在App冷启动时系统会为App开启一个进程，而这个进程的信息可以通过代码获得，因此可以通过以下代码获取pre-main耗时。同理，只需在application:didFinishLaunchingWithOptions:执行完毕后调用statisticsLaunchTime方法即可获得整个app的启动时间。之后通过日志服务上传，即可统计线上数据。

BOOL getProcessInfo(int pid , struct kinfo_proc*procInfo)
{
    int cmd[4] = {CTL_KERN, KERN_PROC, KERN_PROC_PID, pid};
    size_t size = sizeof(*procInfo);
    return sysctl(cmd, sizeof(cmd)/sizeof(*cmd), procInfo, &size, NULL, 0) == 0;
}

NSTimeInterval statisticsLaunchTime(void)
{
    struct kinfo_proc kProcInfo;
    if (getProcessInfo([[NSProcessInfo processInfo] processIdentifier],&kProcInfo)) {
        NSTimeInterval startTime = kProcInfo.kp_proc.p_un.__p_starttime.tv_sec * 1000 + kProcInfo.kp_proc.p_un.__p_starttime.tv_usec / 1000.0; //转为毫秒
        NSTimeInterval curTime = [[NSDate date] timeIntervalSince1970] * 1000;
        return (curTime - startTime) / 1000.0;
    }
    return -1;
}

int main(int argc, char * argv[]) {
    NSLog(@"Pre Main Launch Time : %.4f", statisticsLaunchTime());
    
    NSString * appDelegateClassName;
    @autoreleasepool {
        // Setup code that might create autoreleased objects goes here.
        appDelegateClassName = NSStringFromClass([AppDelegate class]);
    }
    return UIApplicationMain(argc, argv, nil, appDelegateClassName);
}

main阶段

在pre-main阶段完成之后，dyld 会调用 main() 函数，main() 会调用 UIApplicationMain()，直至application:didFinishLaunchingWithOptions:执行完毕，整个启动流程就完成了。当然从用户体验的角度来说，首屏渲染完成后才算是启动完成。

Mach-O文件格式

mach-o format.png

Load Commands.png

可以用MachOView查看Mach-O文件，其中__TEXT segment 包含可执行代码块和只读数据，__DATA segment是可读可写的。

启动优化思路

• pre-main流程优化

  1. 第三方动态库不宜过多，加载越多的第三方动态库，启动越慢。且由于iOS的沙盒机制，第三方动态库需要采用嵌入的方式置入app内，并不能减少app的体积。
  2. 代码瘦身，删除无用的代码和资源，减少ObjC类以提高ObjC setup的速度。
  3. 减少+load方法。尽量用+initialize或者其他替代实现。
  4. 减少__attribute__((constructor))函数和非基本类型的C++静态全局变量的创建。

• main流程优化

main阶段从main函数开始直到application:didFinishLaunchingWithOptions:执行完才结束。在这个阶段主要做的工作有：初始化配置、启动项注册、rootViewController创建等。优化思路如下：

1. 减少耗时操作，如果必须在启动时执行，那么在情况允许的情况下应将其放在并发队列中异步执行，避免阻塞主线程。
2. 减少IO操作，如大图的读取等，从磁盘读取数据会耗费大量时间。
3. 对启动项进行分类，部分启动项注册可以延后执行。
4. 缓存首页数据

等。

• 利用App Launch定位耗时代码

Instrument—App Launch，选择需要分析的app，点击左上角按钮就能进行分析。Call Tree建议将 Separate by Thread 和 Hide System Libraries勾选上，分析之后的调用栈会忽略掉系统调用和按线程划分，便于我们分析自己的代码。

AppLaunch_01.png

AppLaunch_02.png

    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        [self p_checkServiceFinderDependences];
    });

getDeviceUserAgent则是获取User-Agent字符串的过程，这里本身AppConfig就需要初始化一个单例，而getDeviceUserAgent方法内部还有dispatch_once代码，需要花费一定的时间。而且内部需要临时构造一个WKWebView，这就限制了其必须在主线程中执行。但该方法不会影响到后续步骤，故放在主队列中异步执行就可。

    dispatch_async(dispatch_get_main_queue(), ^{
        [[AppConfig sharedInstance] getDeviceUserAgent];
    });

优化之后Main Thread的时间降到1.88s。

fc7a108e58.png

启动项注册

随着业务的发展，启动项难免越来越多。如果把启动项的注册都写在一个方法内的话，那将造成代码臃肿。另外不同的启动项的注册时机并不相同，部分启动项需要尽早注册（例如crash统计，日志上报，热修复等），部分启动项则可以延后注册（在首屏渲染完成后注册或者使用时才注册）。再有，当把某个启动项对应的功能模块化做成独立的framework之后，每个App使用它都必须写一遍注册方法。
目前我们App的处理方案是：利用plist记录启动项，并使用FBModuleManager对启动项进行管理。FBModuleManager会根据启动项的配置将其分成立即启动和LazyLoad两种。这里就不赘述。

• 启动项注册

下面将介绍另一种启动项管理的思路。

__attribute__((used, section("__DATA,__launch")))

实现在编译期间往Mach-O文件写入字段，used防止在release环境下函数被链接器优化掉，section指定写入的位置，此处我们将数据写入__DATA segment下的__launch section。
为了编码方便，我们定义如下宏：

#define LAUNCH_MODULE_EXPORT(module, stage, priority) \
static id _LAUNCH_START_##module(void); \
__attribute__((used, section("__DATA,__launch"))) \
static const struct LAUNCH_MODULE _LAUNCH_MODULE_##module = (struct LAUNCH_MODULE){(char *)&#module, stage, priority, (void *)(&_LAUNCH_START_##module)}; \
static id _LAUNCH_START_##module(void) \

struct LAUNCH_MODULE {
    char *module;             //模块名
    int stage;                //注册时机
    int priority;             //优先级
    id (*startFunc)(void);    //启动方法，返回初始化后的模块实例，Nullable
};

之后我们便可以在模块内部简单地通过如下代码实现自注册，在这里我们注册了一个在preMain阶段的启动项。

LAUNCH_MODULE_EXPORT(TestPreMainModule, FBLaunchStagePreMain, FBLaunchPriorityLow) {
    return [TestPreMainModule start];
}

对于启动阶段和执行优先级的枚举如下，同一个启动阶段下，越高的优先级越先执行代码。

typedef NS_ENUM(NSInteger, FBLaunchStage) {
    FBLaunchStagePreMain = 0,
    FBLaunchStageWillFinishLaunch = 1,
    FBLaunchStageDidFinishLaunch = 2,
    FBLaunchStageWillShowFirstScreen = 3,
    FBLaunchStageDidShowFirstScreen = 4,
    FBLaunchStageLazyLoad = 5,
};

typedef NS_ENUM(NSInteger, FBLaunchPriority) {
    FBLaunchPriorityLow = 0,
    FBLaunchPriorityMid = 1,
    FBLaunchPriorityHigh = 2,
};

写入的效果如下：

截屏2023-01-10 11.44.13.png

• 启动项读取

在App启动时，我们需要读取所有的Mach-O文件注册的启动项，关键代码如下：

@interface FBLaunchModule : NSObject

@property (nonatomic, strong) NSString *module;
@property (nonatomic, assign) FBLaunchStage stage;
@property (nonatomic, assign) FBLaunchPriority priority;
@property (nonatomic, assign) id(*startMethod)(void);
@property (nonatomic, assign) BOOL alreadStart;
@property (nonatomic, strong) id moduleInstance;

@end

- (void)getAllModules {
    NSString *appName = [[[NSBundle mainBundle] infoDictionary] objectForKey:(NSString *)kCFBundleExecutableKey];
    NSString *fullAppName = [NSString stringWithFormat:@"/%@.app/", appName];
    char *fullAppNameC = (char *)[fullAppName UTF8String];
    
    NSMutableArray<FBLaunchModule *> *result = [[NSMutableArray alloc] init];

    int num = _dyld_image_count();
    for (int i = 0; i < num; i++) {
        const char *name = _dyld_get_image_name(i);
        if (strstr(name, fullAppNameC) == NULL) {
            continue;
        }
        
        const struct mach_header *header = _dyld_get_image_header(i);
        
        Dl_info info;
        dladdr(header, &info);
        
        const FBMachOExportValue dliFbase = (FBMachOExportValue)info.dli_fbase;
        const FBMachOExportSection *section = FBGetSectByNameFromHeader(header, "__DATA", "__launch");
        if (section == NULL) continue;
        int addrOffset = sizeof(struct LAUNCH_MODULE);
        for (FBMachOExportValue addr = section->offset;
             addr < section->offset + section->size;
             addr += addrOffset) {
            
            struct LAUNCH_MODULE entry = *(struct LAUNCH_MODULE *)(dliFbase + addr);
            FBLaunchModule *module = [[FBLaunchModule alloc] init];
            module.module = [NSString stringWithCString:entry.module encoding:NSUTF8StringEncoding];
            module.stage = entry.stage;
            module.priority = entry.priority;
            module.checkFunc = entry.checkFunc;
            module.startFunc = entry.startFunc;
            [result addObject:module];
        }
    }
    
    _modules = [NSArray arrayWithArray:result];
}

• 启动项执行

我们实现了一个管理类FBLaunchManager，用于统一读取、保存、执行启动项。

@interface FBLaunchManager : NSObject

+ (id)sharedInstance;
- (void)executeLaunchersForStage:(FBLaunchStage)stage;
- (id)getModuleByName:(NSString *)moduleName;

@end

执行不同阶段启动项的代码如下：

- (void)executeLaunchersForStage:(FBLaunchStage)stage {
    if (_modules.count == 0) {
        return;
    }
    NSMutableArray *moduleAry = [NSMutableArray new];
    
    //阶段
    for (FBLaunchModule *m in _modules) {
        if (m.stage == stage) {
            [moduleAry addObject:m];
        }
    }
    
    //优先级
    [moduleAry sortUsingComparator:^NSComparisonResult(FBLaunchModule * _Nonnull obj1, FBLaunchModule * _Nonnull obj2) {
        return obj1.priority < obj2.priority;
    }];
    
    for (NSInteger i = 0; i < [moduleAry count]; i++) {
        FBLaunchModule *module = moduleAry[i];
        module.moduleInstance = module.startFunc();
        module.alreadStart = YES;
    }
}

如果一个启动项被声明为FBLaunchStageLazyLoad，那么只有在使用它的时候才初始化，在getModuleByName:中实现了懒加载的逻辑。

- (id)getModuleByName:(NSString *)moduleName {
    for (FBLaunchModule *m in _modules) {
        if ([m.module isEqualToString:moduleName]) {
            if (m.alreadStart) {
                return m.moduleInstance;
            }
            m.moduleInstance = m.startFunc();
            m.alreadStart = YES;
            return m.moduleInstance;
        }
    }
    return nil;
}

PreMain阶段启动：

__attribute__((constructor)) static void executePreMainLaunchers() {
    [[FBLaunchManager sharedInstance] executeLaunchersForStage:FBLaunchStagePreMain];
}

此处之所以使用__attribute__((constructor)) 函数，是因为其会在所有类和分类的+load方法执行完毕后才调用，可以避免因代码执行时序而引起的问题。

类似地，其他阶段启动的代码也是在相应时机调用executeLaunchersForStage:方法。

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    // Override point for customization after application launch.   
    [[FBLaunchManager sharedInstance] executeLaunchersForStage:FBLaunchStageDidFinishLaunch];    
    return YES;
}

• 总结

通过这种思路，我们就可以实现组件自注册与分阶段启动，一定程度上做到模块解耦。需要注意的是，这种注入方式主工程几乎是无知觉的，所以需要自注册的组件必须明确自己的启动阶段与启动的必要性。对于非必要的启动项，无需注册或者注册时声明为LazyLoad。
为了安全性考虑，可以再getAllModules方法内做一些校验工作，例如模块名合法性检测、同名模块去重等。模块start方法本身也需要做一些检测，比如模块依赖检测、路由检测等。

Demo代码：https://github.com/linjunyi/LaunchManagerDemo