我们把 pre-main阶段称为 t1,
main() 阶段一直到首个页面加载完成称为 t2。
===============================================================================
其中 t1苹果提供了内建的测量方法, Xcode 中 Edit scheme -> Run -> Auguments 将环境变量 DYLD_PRINT_STATISTICS 设为 1
//结果为
Total pre-main time: 1.4 seconds (100.0%)
dylib loading time: 1.3 seconds (89.4%)
rebase/binding time: 36.75 milliseconds (2.5%)
ObjC setup time: 35.65 milliseconds (2.4%)
initializer time: 80.97 milliseconds (5.5%)
slowest intializers :
libSystem.B.dylib : 12.63 milliseconds (0.8%)
//解读
1、main()函数之前总共使用了1.4s
2、在94.33ms中，加载动态库用了1.3s，指针重定位使用了36.75ms，ObjC类初始化使用了35.65ms，各种初始化使用了80.97ms。
3、在初始化耗费的80.97ms中，用时最多的初始化是libSystem.B.dylib。
可以看到,我的 dylib loading time 花费了 1.3s时间，
其中各部分的作用是
1、【加载dylib】
分析每个dylib（大部分是iOS系统的），找到其Mach-O文件，
打开并读取验证有效性，找到代码签名注册到内核，
最后对dylib的每个segment调用mmap()。
2、【Rebase/Bind】
dylib加载完成之后，它们处于相互独立的状态，需要绑定起来。
在dylib的加载过程中，系统为了安全考虑，引入了ASLR（Address Space Layout Randomization）技术和代码签名。
由于ASLR的存在，镜像（Image，包括可执行文件、dylib和bundle）会在随机的地址上加载，和之前指针指向的地址（preferred_address）会有一个偏差（slide），dyld需要修正这个偏差，来指向正确的地址。
Rebase在前，Bind在后。
Rebase做的是将镜像读入内存，修正镜像内部的指针，性能消耗主要在IO。
Bind做的是查询符号表，设置指向镜像外部的指针，性能消耗主要在CPU计算。
3、【OC setup】
OC的runtime需要维护一张类名与类的方法列表的全局表。
dyld做了如下操作：
1、对所有声明过的OC类，将其注册到这个全局表中（class registration）
2、将category的方法插入到类的方法列表中（category registration）。这里是往前插入，在读取的时候，是从前往后读取，所以先读取到的是category类中的方法，而本类无效。
3、检查每个selector的唯一性（selector uniquing）
4、pre-main阶段加载方法
如果在各个 OC 类别的 ‘load’方法里做了不少事情(如在里面使用 Method swizzle),那么这是pre-main阶段最耗时的部分。
dyld运行APP的初始化函数，调用每个OC类的+load方法，调用C++的构造器函数（attribute((constructor))修饰），创建非基本类型的C++静态全局变量，然后执行main函数。
结合上面 pre-main 打印的结果，我们可以大致了解整个启动过程如下图所示：
exec() -> Load Executable -> Load Dyld -> Load Dylibs -> Rebase -> Binding ->ObjCSetUp -> Initializers
优化思路是
1. 移除不需要用到的动态库
2. 移除不需要用到的类
3. 合并功能类似的类和扩展
4. 尽量避免在+load方法里执行的操作，可以推迟到+initialize方法中。
===============================================================================
t2使用了来自NewPan大大 的打点计时器BLStopwatch
可以看到，我的 APP 加载时间并没有很慢，但是也想看一看有没有优化的空间。
在 didFinishLaunchingWithOptions 方法里我们一般都有以下的逻辑：
1、初始化第三方 SDK
2、配置 APP 运行需要的环境
3、自己的一些工具类的初始化
...
这里主要参考[iOS]一次立竿见影的启动时间优化
从优化图可以看到，我的应用的跳转逻辑是 打开 -> 广告页 -> 首页，首页的UI 架构是:
但是如果 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 这些方法的执行顺序是怎么样的呢？
1、didFinishLaunchingWithOptions 开始执行
2、开始加载 TestTabBarController 的 viewDidLoad
3、didFinishLaunchingWithOptions 跑完了
4、开始加载 TestViewController 的 viewDidLoad, 然后执行一堆初始化的操作
在TestTabBarController 中操作了 TestViewController 的 view 的话，那么调用顺序将会是这样：
1、didFinishLaunchingWithOptions 开始执行
2、开始加载 TestTabBarController 的 viewDidLoad
3、开始加载 TestViewController 的 viewDidLoad, 然后执行一堆初始化的操作
4、didFinishLaunchingWithOptions 跑完了
这样的问题就是当我们把界面的初始化、网络请求、数据解析、视图渲染等操作放在了viewDidLoad 方法里，这样一来每次启动 APP 的时候，在用户看到第一个页面之前，我们要把这些事件全部都处理完，才会进入到视图渲染阶段。
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V获取：vip204888 （备注Android）
最后，如果大伙有什么好的学习方法或建议欢迎大家在评论中积极留言哈，希望大家能够共同学习、共同努力、共同进步。
小编在这里祝小伙伴们在未来的日子里都可以 升职加薪，当上总经理，出任CEO，迎娶白富美，走上人生巅峰！！
不论遇到什么困难，都不应该成为我们放弃的理由！
很多人在刚接触这个行业的时候或者是在遇到瓶颈期的时候，总会遇到一些问题，比如学了一段时间感觉没有方向感，不知道该从那里入手去学习
如果你看到了这里，觉得文章写得不错就给个赞呗？如果你觉得那里值得改进的，请给我留言，一定会认真查询，修正不足，谢谢。
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
困难，都不应该成为我们放弃的理由！
很多人在刚接触这个行业的时候或者是在遇到瓶颈期的时候，总会遇到一些问题，比如学了一段时间感觉没有方向感，不知道该从那里入手去学习
如果你看到了这里，觉得文章写得不错就给个赞呗？如果你觉得那里值得改进的，请给我留言，一定会认真查询，修正不足，谢谢。
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
[外链图片转存中…(img-2Qs9wAXj-1712789114015)]
931
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
