相关文章
整体启动过程分为 pre-main 和 main
打印pre-main信息
在pre-mian中 系统执行的耗时以及比例 可以通过添加run的变量查看
打印pre-main信息
- 控制台打印如下
Total pre-main time: 2.2 seconds (100.0%)
dylib loading time: 1.0 seconds (45.2%) 加载 dyld(动态库加载器) 和 dylib(动态库)
rebase/binding time: 100.05 milliseconds (4.3%) 重定向内部指针(IO操作) 和 查询符号表设置镜像外部指针(CUP计算)
ObjC setup time: 207.21 milliseconds (9.0%) 启动runtime 注册类和方法, 注册category, 检测selector唯一
initializer time: 946.39 milliseconds (41.3%) 加载+load方法, 加载C++构造器
slowest intializers : 上面步骤中最耗时的模块
libSystem.B.dylib : 8.54 milliseconds (0.3%)
libBacktraceRecording.dylib : 46.30 milliseconds (2.0%)
libglInterpose.dylib : 187.42 milliseconds (8.1%)
beiliao : 896.56 milliseconds (39.1%)
pre-main的优化
- 优化
- 减少不必要的framework,因为动态链接比较耗时
- check framework应当设为optional和required,如果该framework在当前App支持的所有iOS系统版本都存在,那么就设为required,否则就设为optional,因为optional会有些额外的检查
- 合并或者删减一些OC类,关于清理项目中没用到的类,使用工具AppCode代码检查功能
- 删减一些无用的静态变量
- 删减没有被调用到或者已经废弃的方法
- 将不必须在+load方法中做的事情延迟到+initialize中
- 尽量不要用C++虚函数(创建虚函数表有开销)
launching后的优化
- launching后的优化: 详情
- 比如日志 / 统计等需要第一时间启动的, 仍然放在 didFinishLaunchingWithOptions 中.
- 比如用户数据需要在广告显示完成以后使用, 所以需要伴随广告页启动
- 比如直播和分享等业务, 肯定是用户能看到真正的主界面以后才需要启动, 所以推迟到主界面加载完成以后启动(viewDidAppear:)
网友评论