实测iOS Dynamic Framework 对 App 启动时间的影响效果
最近看到的Slow App Startup Times里提到：
The dynamic loader finds and reads the dependent dynamic libraries (dylibs) used by the App. Each library can itself have dependencies. The loading of Apple system frameworks is highly optimized but loading your embedded frameworks can be expensive. To speed up dylib loading Apple suggests you use fewer dylibs or consider merging them A suggested target is for six extra (non-system) frameworks.
至于什么是static lib什么是dynamic lib这里就不展开提了，大家可以通过在文章底部的相关链接去详细了解。
引用一下官方的解释就是：
A better approach is for an app to load code into its address space when it’s actually needed, either at launch time or at runtime. The type of library that provides this flexibility is called dynamic library.
When an app is launched, the app’s code—which includes the code of the static libraries it was linked with—is loaded into the app’s address space.Applications with large executables suffer from slow launch times and large memory footprints
如果给你一个简单的概念就是如果你的framework使用了swift就是dynamic lib。这也是本文要对比的主题：动态的framework对app启动时间影响到底多大。
测试的方法就采用 iOS 10 提供的新的环境变量 DYLD_PRINT_STATISTICS 输出的app启动时间。Xcode的版本是8.1，测试设备是iphone 6。cocoapod版本1.1。
注意，测试过程发现每次获得的时间统计都不一致，所以我这里的数据可能和你自己测试得到的不同，但是我认为这种偏差不影响定性。
基准线：空的OC项目 VS 空的Swift项目
创建两个没有任何业务逻辑的空的项目。
纯OC项目的启动时间
纯swift空项目的启动时间
大概有10毫秒的差异。这个差距考虑到测量的偏差可以认为两者几乎是一致的。
但是有时会出现swift加载忽然提高到400ms的情况。这是因为系统的动态framework只会加载一份。假设10个app启动都用到了UIKit，系统内部也只加载了一份UIKit。所以有时swift项目启动的时候刚好用到了系统framework没有缓存，就会显得的长一点。
6个framework
现在我们对比有代码的情况。两个项目分别加入5个依赖。
这是OC项目的6个依赖：
pod 'AFNetworking', '~> 3.0'
pod 'Masonry'
pod 'MJRefresh'
pod 'SDWebImage'
pod 'MBProgressHUD'
pod 'IQKeyboardManager'
这是swift项目的6个依赖，为了模拟真实生产中依然使用一些OC库的情况，将3个库换成了swift编码的，保留了3个OC库：
pod 'Alamofire'
pod 'SnapKit'
pod 'MJRefresh'
pod 'Kingfisher'
pod 'MBProgressHUD'
pod 'IQKeyboardManager'
OC的启动时间在70-100ms左右。这里取快的情况的数据：
OC6个依赖的启动时间
swift项目在第一次安装时的启动时间在dylib会多100ms，不知为何。swift项目在已经安装后运行打开的成绩：
swift6个依赖
列一个横向对比图：
结论
swift项目的dylib时间相比OC多了一百多毫秒，远远大于OC。
Swift 不使用framework VS 使用framework
我们猜测是不是加载framework导致时间增大很多呢。所以我们把这些依赖的代码全部放在主app里，不使用framework分离。这次我们把几个依赖的库全部换成swift：
pod 'Alamofire'
pod 'SnapKit'
pod 'Kingfisher'
pod 'SwiftDate'
pod 'ObjectMapper'
5个依赖的项目在app已经安装，运行打开结果：
5个依赖
考虑到误差可以认为framework里的代码是OC还是swift对于加载时间的影响并不大。
把依赖的代码全都合并到App里，就是采取手工拷贝的方式：
安装后打开的启动时间统计：
对比图：
结论
如果把代码收到拷贝进app里，可以显著降低dylib加载时间。
15个framework OC VS Swift
OC的podfile：
pod 'AFNetworking', '~> 3.0'
pod 'Masonry'
pod 'MJRefresh'
pod 'SDWebImage'
pod 'MBProgressHUD'
pod 'IQKeyboardManager'
pod 'FMDB'
pod 'GPUImage'
pod 'OpenUDID'
pod 'DateTools'
pod 'TMCache'
pod 'WebViewJavascriptBridge'
pod 'ZBarSDK'
pod 'JSQMessagesViewController'
pod 'YYKit'
pod 'DZNEmptyDataSet
swift项目的podfile：
pod 'AFNetworking', '~> 3.0'
pod 'Alamofire'
pod 'SnapKit'
pod 'MJRefresh'
pod 'Kingfisher'
pod 'MBProgressHUD'
pod 'IQKeyboardManager'
pod 'FMDB'
pod 'GPUImage'
pod 'OpenUDID'
pod 'SwiftDate'
pod 'CryptoSwift'
pod 'ObjectMapper'
pod 'ZBarSDK'
pod 'CocoaLumberjack/Swift'
pod 'YYKit'
pod 'DZNEmptyDataSet'
OC的结果：
swift的结果：
对比图：
时间对比
纵向对比：
结论
OC的项目随着依赖增多，初始化时间增大，但是dylib时间增加不明显。swift则dylib时间大幅增加，初始化时间变化不大。总的启动时间比OC多了200多毫秒，随着framework的增多，启动时间差距拉大。
25个dynamic framework
如果把dylib提高到25个时间又会增长多少呢。
在15个基础上再添加10个依赖：
pod 'EZSwiftExtensions'
pod 'ReactiveCocoa', '5.0.0-alpha.3'
pod 'RxSwift', '~> 3.0'
pod 'RxCocoa', '~> 3.0'
pod 'MonkeyKing'
pod 'Reusable'
pod 'SwiftyJSON'
pod 'XCGLogger'
pod 'Gifu', '~> 2.0.0-rc'
pod 'Spring', :git => 'https://github.com/MengTo/Spring.git', :branch => 'swift3'
运行时间：
和15个dylib的时候的对比：
dylib加载时间从400增加到600，增加了30%左右。dylib数量从15到25个增加40%。接近线性。
总结
毫无疑问，使用了dynamic framework后会增加app启动时间。如果你的数量在25个左右，相比OC的静态framework启动时间会增加0.5s左右。我个人对于iOS提高加载framework的时间不太抱有希望，苹果让自定义的framework常驻内存似乎也无望，这个时间短期内可能无法抹平。
如果人为的把一些外部依赖手动管理在一个framework也是可行，但是如果复杂一点包的互相依赖的情况会比较费心。
如果公司对性能有着苛刻要求可能500ms是难以忍受的。但是我觉得对于大多数产品而言，牺牲这500ms的性能相比于使用OC，我觉得还是用OC比较难受。
