我们探索了 BuildingClosure 的生成过程，发现在Building Closure阶段中，可能存在字符串的 Hash 碰撞 引发循环次数大幅增加，进而引发了启动耗时暴增，进而导致启动耗时的大幅增加。
一、神秘的 BuildingClosure
1. dyld && BuildingClosure
2. BuildingClosure 非常耗时
3. BuildingClosure 文件解析
二、离奇的启动耗时暴增事件
1. 启动耗时暴增 200ms
2. BuildingClosure 耗时异常变化定位
三、启动优化新秘境
1. Perfect Hash
2. 向前一步
四、总结
得物一直重视用户体验，尤其是启动时长这一重要指标。在近期的启动时长跟进中，我们发现了在BuildingClosure 阶段的一个优化方式，成功的帮助我们降低了 1/5 的 BuildingClosure 阶段的启动耗时。Building Closure 并非工程的编译阶段（虽然它有一个building），Building Closure 是应用初次启动时会经历的阶段，因此它会影响应用的启动时长。
单就BuildingClosure阶段而言，我们观察到该阶段其中一个函数从 480ms 暴增到 1200ms 左右（PC 电脑端运行 dyld 调试统计耗时数据），我们通过优化，将耗时从1200ms降低到110ms。即使相比最开始的情况，也相当于从480ms降低到了110ms，由此可见Building Closure 优化是应用进行启动优化必不可少的一个重要手段。因此在这里我们也和各位读者进行分享，期望能够对各自项目有所帮助。
一、神秘的 BuildingClosure
启动优化的技术、实现方案业界有不少的文章可以参考学习，这里不再额外赘述。我们来探索下启动过程中非常神秘的 BuildingClosure。
BuildingClosure 是在System Interface Initialization阶段 dyld 生成的，并且我们也无法做任何的干预，另外相关的剖析文章相对较少，所以说BuildingClosure 较为神秘，也是实至名归。
BuildingClosure 是由dyld在应用启动阶段执行的，所以想要了解 BuildingClosure 还是要从 dyld 开始了解。
dyld && BuildingClosure
Dyld 源码可以在 Apple GitHub 上查阅 https://github.com/apple-oss-distributions/dyld
相信大家都应该了解过，BuildingClosure 是在 iOS 13 引入进来的，对应的 dyld 为 dyld3，目的是为了减少启动环节符号查找、Rebase、Bind 的耗时。
核心技术逻辑是将重复的启动工作只做一次，在 App 首次启动、版本更新、手机重启之后的这次启动过程中，将相关信息缓存到 Library/Caches/com.app.dyld/xx.dyld 文件中，App 在下次启动时直接使用缓存好的信息，进而优化二次启动的速度。
在 iOS 15 Dyld4 中更是引入了 SwiftConformance，进一步解决了运行时 Swift 中的类型、协议检查的耗时。
图片
