iOS应用启动慢并不一定是main函数之后的初始化代码导致的。通过Xcode自带的启动耗时统计可以发现，很多应用的空白等待时间发生在main之前，也就是常说的Pre-main阶段。这一阶段由dyld负责，包含动态库加载、rebase与binding以及Objective-C运行时初始化等工作，其中+load方法的执行经常是隐藏的耗时大户。理解这一阶段的时间分布并逐步优化，是缩短启动时间最直接的手段之一。
Pre-main阶段的时间构成
在iOS工程中，main函数并不是程序的真正入口。用户点击图标后，内核加载Mach-O文件，接着由动态链接器dyld接管后续工作。dyld需要先解析主二进制以及所有依赖的动态库，把它们映射到进程地址空间，然后处理指针重定位和符号绑定。对Objective-C工程来说，dyld还会把镜像中的类、分类、协议信息注册到运行时，最终调用所有类与分类的+load方法。整个过程全部完成后，才会进入我们熟悉的main函数。
要测量这个阶段的耗时，最简便的方式是在Xcode的Run scheme中添加环境变量DYLD_PRINT_STATISTICS并设置为1。重新运行应用后，控制台会输出类似下面的统计信息：
Total pre-main time: 820.43 milliseconds (100.0%) dylib loading time: 310.21 milliseconds (37.8%) rebase/binding time: 126.73 milliseconds (15.4%) ObjC setup time: 168.54 milliseconds (20.5%) initializer time: 214.95 milliseconds (26.1%) slowest intializers : libSystem.dylib : 18.53 milliseconds libBacktraceRecording.dylib : 12.21 milliseconds YourApp : 151.09 milliseconds
这份输出清楚地展示了不同环节的占比。动态库加载时间高，通常意味着工程里引入了太多动态framework，或者存在大量未合并的pod子库；rebase与binding时间高，则与二进制大小、符号数量有关；initializer time高，往往说明+load方法或者C++静态初始化做了太多事情。尤其当YourApp出现在慢初始化列表里时，需要重点检查主工程和各静态库中的+load实现。
需要注意的是，动态库并不总是越少越好，但每一个动态库都会带来额外的解析、映射和加载成本。很多团队在组件化过程中拆出了十几个甚至几十个动态framework，这在开发期带来了模块隔离的好处，却也直接推高了启动耗时。对于启动敏感的App，可以把一些纯逻辑库改为静态库链接，或者合并核心库，减少dyld的工作量。
+load方法的执行机制与代价
Objective-C运行时在加载一个类或分类时，会检查它是否实现了+load方法。如果实现了，就会在类注册完成后调用它。这个过程发生在main之前，并且是自动完成的，不需要开发者手动触发。父类的+load一定先于子类执行，但不同类之间的顺序并不稳定，分类的+load通常晚于其所属类的+load。这种自动执行机制让+load看起来是执行初始化的方便位置，但也因此容易被滥用。
+load的代价主要体现在三个方面。第一，所有+load集中在一个连续的时间段内执行，完全阻塞主线程，类越多、分类越多，启动等待就越久。第二，+load里如果调用了其他类的方法，可能触发额外的类加载和初始化，形成连锁反应。第三，+load不适合做懒加载，即使某个类暂时用不到，它的+load也会在启动时被执行。下面是一个常见但不太合理的写法：
@implementation AppInitializer
+ (void)load {
// 启动时解析大体积JSON配置
NSString *path = [[NSBundle mainBundle] pathForResource:@"config" ofType:@"json"];
NSData *data = [NSData dataWithContentsOfFile:path];
NSDictionary *config = [NSJSONSerialization JSONObjectWithData:data options:0 error:nil];
// 初始化第三方SDK
[ThirdPartySDK startWithConfig:config];
// 注册通知和埋点
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(handleNotification:)
name:UIApplicationDidFinishLaunchingNotification
object:nil];
}
@end
这段代码把文件IO、JSON解析、第三方SDK初始化全部放进了+load。文件IO和JSON解析本身就耗时，SDK启动可能还会创建线程、读写数据库或发起网络请求。即便这些操作本身不会阻塞很久，它们叠加在启动关键路径上，会显著拖慢从点击图标到首屏出现的时间。更合理的做法是把这些工作放到首次使用对应功能时再执行，或者放到didFinishLaunching之后的异步队列中处理。
还有一种常见场景是用+load做Method Swizzling。例如为了统一处理页面事件，在+load里交换viewDidAppear:方法。这确实能保证在所有类使用前完成交换，但代价是启动阶段多了一轮运行时方法解析和替换操作。如果工程里类似的AOP逻辑很多，累积的启动开销就很可观。对这类需求，可以考虑将Swizzling逻辑收敛到单一启动任务中，或者改为在首次进入对应页面时执行，避免全部集中在启动阶段。
延迟初始化与+initialize的替代方案
对于绝大多数初始化任务，最直接的优化思路就是延后执行。Objective-C提供了+initialize方法，它在类第一次收到消息时由运行时调用，属于懒加载，并且调用时机在main之后。虽然+initialize仍然会阻塞调用线程，但至少它不会拖慢启动。把原本放在+load里的逻辑迁移到+initialize，可以立即减少Pre-main阶段耗时。迁移后需要注意，+initialize可能会被子类继承触发，所以实现时最好加上类型判断，避免重复执行。
@implementation AppInitializer
+ (void)initialize {
if (self == [AppInitializer class]) {
// 首次使用AppInitializer时才执行
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
[self setupSDK];
});
}
}
+ (void)setupSDK {
// 原来+load里的初始化逻辑
}
@end
如果某些逻辑不依赖类首次接收消息，而是希望App启动后尽早但不阻塞主线程地执行，可以使用dispatch_async把任务派发到后台队列。例如，第三方SDK的注册、埋点系统的启动、大型配置文件的读取，都可以放到UIApplicationDidFinishLaunchingNotification之后异步处理。这样首屏渲染不会被这些辅助功能拖累，用户感知到的启动速度会明显改善。
还有一种折中方案是使用__attribute__((constructor))。它同样会在main之前执行，所以并不适合重量级任务，但它的调用时机通常早于+load或介于类加载和main之间，并且执行顺序更可控。如果项目确实需要在极早期完成某些轻量级准备工作，例如设置环境变量、初始化一个全局标志位，可以用它替代+load，让职责更清晰。对启动耗时而言，constructor仍然会增加Pre-main时间，使用时必须保持逻辑非常轻量。
减少动态库依赖与合并初始化任务
动态库数量是Pre-main阶段耗时的重要变量。每增加一个动态framework，dyld都需要解析它的Mach-O头、处理依赖关系、映射段以及绑定符号。如果组件化架构允许，应尽量把不涉及资源独立打包的模块从动态framework改为静态库。静态库在编译期直接链接进主二进制，虽然会增大包体和链接时间，但启动时不再需要额外的动态加载过程。对于启动耗时敏感的App，这种取舍通常是值得的。
实际优化时，可以先从podfile或工程配置中列出所有动态库，然后筛选出只被主App使用的模块。把这些模块改为静态链接后，重新运行DYLD_PRINT_STATISTICS，观察dylib loading time是否下降。需要注意的是，有些SDK本身以动态库形式提供，修改成本较高，此时可以把多个小SDK合并为一个动态库，减少动态库数量。也可以检查是否链接了一些启动阶段并不会使用的framework，例如只在特定页面用到的图像处理库，改为运行时按需加载。
对于分散在各个类中的+load方法，如果确实不能完全移除，可以考虑统一登记到一个启动初始化器中。例如只保留一个+load入口，其他模块通过注册表方式把初始化任务交出来，再由启动初始化器根据优先级依次执行。这样既减少了+load方法的数量，也能让初始化顺序变得可预期。更进一步，可以把初始化任务拆成同步关键路径和异步非关键路径，只保留首屏必需的部分在主线程执行，其余延后到首屏展示之后。
测量与验证启动优化效果
优化不能只凭感觉判断，必须有可量化的指标。除了前面提到的DYLD_PRINT_STATISTICS，还可以在main函数入口处记录一个时间戳，再与进程启动时间比较，得到Pre-main耗时。虽然这个方式比较粗糙，但适合快速验证。更专业的方式是使用Xcode自带的Instruments，选择App Launch模板，它会记录应用启动各阶段的时间，并给出可以点击展开的详细报告。通过对比优化前后的App Launch报告，可以明确看到Pre-main阶段减少的毫秒数。
如果希望线上持续监控启动耗时，可以使用MetricKit中的MXAppLaunchMetric，它在iOS 13及以上版本可用。这个框架会记录冷启动、热启动等不同场景下的耗时数据，并定期回调给App，方便上报到分析平台。线下与线上数据结合，能够更全面地评估优化效果，也能帮助发现特定设备或系统版本下的启动回退问题。
验证时还要关注优化是否引入了新的问题。例如把同步初始化改成异步后，某些依赖执行顺序的功能可能出现偶发失败；把+load迁移到+initialize后，如果类在首屏之前被提前使用，执行时机仍然会靠前，但不会像+load那样集中在启动最早期。每次改动后都应进行回归测试，尤其是涉及通知注册、方法交换、单例初始化的部分。
典型案例与风险控制
以一个典型App为例，它拥有约25个动态framework和30多个+load方法，启动时间中Pre-main阶段达到1.1秒左右。通过合并动态库、将12个+load迁移到+initialize或懒加载、把第三方SDK初始化移出关键路径，最终Pre-main耗时降到420毫秒左右。启动进入首页的时间从1.5秒缩短到0.7秒，用户感知提升非常明显。这个过程中，最关键的动作不是单纯减少代码量，而是弄清楚每一段启动时间花在了哪里，再针对性地调整。
风险控制方面，要特别注意那些看起来无关紧要的+load方法。有些SDK要求必须在+load中注册通知或交换方法，否则会丢失部分事件。对于这类情况，可以保留+load，但把方法体控制在只做最简单的注册和标志位赋值，不要在+load里访问磁盘、发起网络或者创建复杂对象。Method Swizzling如果必须在+load中完成，可以限制交换的目标方法数量，并确保实现代码精简。
最后，启动优化是一个持续过程。随着业务增长，新的动态库和+load方法仍会不断出现。建议在工程中建立启动耗时检查机制，例如在CI流程里运行DYLD_PRINT_STATISTICS并设置阈值，当Pre-main时间超过预设值就发出提醒。也可以定期审查新加入的+load方法，要求开发者说明无法延迟执行的原因。通过这些手段，让启动耗时始终处于可控范围。
iOS启动优化Pre-main阶段耗时+load方法修改时间：2026-10-02 21:11:06