APP启动耗时分析及优化

转载自腾讯云

App启动过程

  • 解析Info.plist
    加载相关信息,例如如闪屏
    沙箱建立、权限检查
  • Mach-O加载
    如果是胖二进制文件,寻找合适当前CPU类别的部分
    加载所有依赖的Mach-O文件(递归调用Mach-O加载的方法)
    定位内部、外部指针引用,例如字符串、函数等
    执行声明为attribute((constructor))的C函数
    加载类扩展(Category)中的方法
    C++静态对象加载、调用ObjC的 +load 函数
  • 程序执行
    调用main()
    调用UIApplicationMain()
    调用applicationWillFinishLaunching

一、main()函数之前耗时

main函数启动之前耗时,对于一般的小型APP来说,影响微乎其微,但对于大型APP(动态库超过50或二进制文件超过30MB)来说,就会变得很明显,官方也提供了支持。
一般来说main()函数之前耗时 不宜超过400毫秒,之前与之后整体时间不宜超过20秒,如果超过20秒,系统会关闭进程,无法启动APP。
1、设置耗时日志输出,添加如下图所示变量环境
name:DYLD_PRINT_STATISTICS
value:1


2、运行Xcode,得到耗时报告

输出日志:
Total pre-main time: 460.69 milliseconds (100.0%)
dylib loading time: 85.29 milliseconds (18.5%)
rebase/binding time: 290.96 milliseconds (63.1%)
ObjC setup time: 57.51 milliseconds (12.4%)
initializer time: 26.80 milliseconds (5.8%)
slowest intializers :
libSystem.B.dylib : 2.63 milliseconds (0.5%)
libMainThreadChecker.dylib : 15.46 milliseconds (3.3%)

日志解释
main函数之前 共耗时460.69毫秒
动态库(dylib)加载 耗时85.29毫秒 占耗时18.5%
指针定位 耗时290.96 占耗时63.1%
类初始化 耗时57.51 占耗时12.4%
其它初始化 耗时 26.80 占耗时5.8%
比较耗时(或者说初始化慢的)有:
libSystem.B.dylib 耗时 2.63 占耗时0.5%
libMainThreadChecker.dylib 15.46 占耗时3.3%

main函数之前影响启动性能的因素

动态库加载越多,启动越慢。

  • ObjC类越多,启动越慢
  • C的构造函数越多,启动越慢
  • C++静态对象越多,启动越慢
  • ObjC的+load越多,启动越慢

二、main()函数之后耗时

从main函数开始至applicationWillFinishLaunching结束,称为main函数之后的部分。

main函数之后影响启动性能的因素
  • 执行main()函数的耗时
  • 执行applicationWillFinishLaunching的耗时
  • 根控制器(rootViewController)及其子控制器(childViewController)的加载、视图(view)及其子视图(subviews)的加载耗时

三、优化的目标

启动过程分为四个部分:
1、 main()函数之前
2、main()函数之后至applicationWillFinishLaunching完成
3、App完成所有本地数据的加载并将相应的信息展示给用户
4、App完成所有联网数据的加载并将相应的信息展示给用户
1+2一起决定了我们需要用户等待多久才能出现一个主视图,同时也是技术上可以精确测量的时长。
1+2+3决定了用户视觉上的等待出现有用信息所需要的时长。1+2+3+4决定了我们需要多少时间才能让我们需要展示给用户的所有信息全部出现。

四、优化策略

  • 移除不需要用到的动态库(利用 DYLD_PRINT_STATISTICS 变量来定位)
  • 移除不需要用到的类(可以使用fui进行辅助移除)
  • 合并功能类似的class和category
  • 压缩资源图片(Xcode在编译App的时候,已经自动把需要打包到App里的资源图片压缩过一遍了。然而Xcode的压缩会相对比较保守)
  • 优化applicationWillFinishLaunching(将不需要马上在此方法中执行的代码延后执行)
  • 优化rootViewController加载(适当将某一级的childViewController或subviews延后加载)
  • 异步操作不影响耗时,但影响交互体验(视觉上的优化有时比技术手段效果更好)
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 159,117评论 4 362
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,328评论 1 293
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,839评论 0 243
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 44,007评论 0 206
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,384评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,629评论 1 219
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,880评论 2 313
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,593评论 0 198
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,313评论 1 243
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,575评论 2 246
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,066评论 1 260
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,392评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,052评论 3 236
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,082评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,844评论 0 195
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,662评论 2 274
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,575评论 2 270