美文网首页iOS 实用技术学无止境DevSupport
阿里数据iOS端启动速度优化的一些经验

阿里数据iOS端启动速度优化的一些经验

作者: 半尺尘 | 来源:发表于2017-07-27 17:38 被阅读5031次

背景

7月26号我们阿里数据iOS端发布了4.4.0版本,这次版本主要是优化了性能,其中main()阶段的启动耗时优化成果比较明显,从之前的0.5-0.7秒,降低为目前的0.1-0.2秒(main()第一行代码到didFinishLaunchingWithOptions最后一行代码的耗时),用户体验提升明显。在这里梳理一下优化的一些经验,欢迎大家一起交流。

应用启动流程

iOS应用的启动可分为pre-main阶段和main()阶段,其中系统做的事情依次是:

1. pre-main阶段

1.1. 加载应用的可执行文件
1.2. 加载动态链接库加载器dyld(dynamic loader)
1.3. dyld递归加载应用所有依赖的dylib(dynamic library 动态链接库)

2. main()阶段

2.1. dyld调用main()
2.2. 调用UIApplicationMain()
2.3. 调用applicationWillFinishLaunching
2.4. 调用didFinishLaunchingWithOptions

启动耗时的测量

在进行优化之前,我们首先应该能测量各阶段的耗时。

1. pre-main阶段

对于pre-main阶段,Apple提供了一种测量方法,在 Xcode 中 Edit scheme -> Run -> Auguments 将环境变量DYLD_PRINT_STATISTICS 设为1 :

pre-main阶段启动耗时测量.png

设置好后把程序跑起来,控制台会有如下输出,pre-main阶段各过程的耗时一览无余(Apple这个Demo有点过于夸张...)

pre-main阶段启动耗时测量.png
2. main()阶段

对于main()阶段,主要是测量main()函数开始执行到didFinishLaunchingWithOptions执行结束的耗时,就需要自己插入代码到工程中了。先在main()函数里用变量StartTime记录当前时间:


CFAbsoluteTime StartTime;
int main(int argc, char * argv[]) {
      StartTime = CFAbsoluteTimeGetCurrent();

再在AppDelegate.m文件中用extern声明全局变量StartTime


extern CFAbsoluteTime StartTime;

最后在didFinishLaunchingWithOptions里,再获取一下当前时间,与StartTime的差值即是main()阶段运行耗时。


double launchTime = (CFAbsoluteTimeGetCurrent() - StartTime);

pre-main阶段的优化

要对pre-main阶段的耗时做优化,需要再学习下dyld加载的过程,根据Apple在WWDC上的介绍,dyld的加载主要分为4步:

1. Load dylibs

这一阶段dyld会分析应用依赖的dylib,找到其mach-o文件,打开和读取这些文件并验证其有效性,接着会找到代码签名注册到内核,最后对dylib的每一个segment调用mmap()
一般情况下,iOS应用会加载100-400个dylibs,其中大部分是系统库,这部分dylib的加载系统已经做了优化。

所以,依赖的dylib越少越好。在这一步,我们可以做的优化有:

  1. 尽量不使用内嵌(embedded)的dylib,加载内嵌dylib性能开销较大
  2. 合并已有的dylib和使用静态库(static archives),减少dylib的使用个数
  3. 懒加载dylib,但是要注意dlopen()可能造成一些问题,且实际上懒加载做的工作会更多
2. Rebase/Bind

在dylib的加载过程中,系统为了安全考虑,引入了ASLR(Address Space Layout Randomization)技术和代码签名。由于ASLR的存在,镜像(Image,包括可执行文件、dylib和bundle)会在随机的地址上加载,和之前指针指向的地址(preferred_address)会有一个偏差(slide),dyld需要修正这个偏差,来指向正确的地址。
Rebase在前,Bind在后,Rebase做的是将镜像读入内存,修正镜像内部的指针,性能消耗主要在IO。Bind做的是查询符号表,设置指向镜像外部的指针,性能消耗主要在CPU计算。

所以,指针数量越少越好。在这一步,我们可以做的优化有:

  1. 减少ObjC类(class)、方法(selector)、分类(category)的数量
  2. 减少C++虚函数的的数量(创建虚函数表有开销)
  3. 使用Swift structs(内部做了优化,符号数量更少)
3. Objc setup

大部分ObjC初始化工作已经在Rebase/Bind阶段做完了,这一步dyld会注册所有声明过的ObjC类,将分类插入到类的方法列表里,再检查每个selector的唯一性。

在这一步倒没什么优化可做的,Rebase/Bind阶段优化好了,这一步的耗时也会减少。

4. Initializers

到了这一阶段,dyld开始运行程序的初始化函数,调用每个Objc类和分类的+load方法,调用C/C++ 中的构造器函数(用attribute((constructor))修饰的函数),和创建非基本类型的C++静态全局变量。Initializers阶段执行完后,dyld开始调用main()函数。

在这一步,我们可以做的优化有:

  1. 少在类的+load方法里做事情,尽量把这些事情推迟到+initiailize
  2. 减少构造器函数个数,在构造器函数里少做些事情
  3. 减少C++静态全局变量的个数

main()阶段的优化

这一阶段的优化主要是减少didFinishLaunchingWithOptions方法里的工作,在didFinishLaunchingWithOptions方法里,我们会创建应用的window,指定其rootViewController,调用window的makeKeyAndVisible方法让其可见。由于业务需要,我们会初始化各个二方/三方库,设置系统UI风格,检查是否需要显示引导页、是否需要登录、是否有新版本等,由于历史原因,这里的代码容易变得比较庞大,启动耗时难以控制。

所以,满足业务需要的前提下,didFinishLaunchingWithOptions在主线程里做的事情越少越好。在这一步,我们可以做的优化有:

  1. 梳理各个二方/三方库,找到可以延迟加载的库,做延迟加载处理,比如放到首页控制器的viewDidAppear方法里。
  2. 梳理业务逻辑,把可以延迟执行的逻辑,做延迟执行处理。比如检查新版本、注册推送通知等逻辑。
  3. 避免复杂/多余的计算。
  4. 避免在首页控制器的viewDidLoadviewWillAppear做太多事情,这2个方法执行完,首页控制器才能显示,部分可以延迟创建的视图应做延迟创建/懒加载处理。
  5. 采用性能更好的API。
  6. 首页控制器用纯代码方式来构建。

阿里数据iOS端优化实践

在以上的认知指导下,阿里数据iOS端开始着手优化,在pre-main阶段和main()阶段分别做了一系列优化,取得了一定的成果。

1. pre-main阶段的优化

1.1. 排查无用的dylib,移除不再使用的libicucore.tbd
1.2. 删除无用文件&库,合并重复文件(多个重复的分类)。移除不再使用的库UMSocial、PSTCollectionView、MCSwipeTableViewCell,移除功能重复的库Mantle。
1.3. 梳理各个类的+load方法,将多个类中+load方法做的事延迟到+initiailize里去做。

优化前pre-main阶段耗时:

优化前pre-main阶段耗时.png

优化后pre-main阶段耗时:

优化后pre-main阶段耗时.png

测试环境:Xcode8.3.3 iOS10.2的模拟器,热启动。
备注:测试发现,pre-main阶段耗时有一定波动,冷启动时波动更大,这里截图贴的是一个中位数水平。
可以看到热启动下,pre-main阶段耗时有一定下降。

2. main()阶段的优化

2.1. 去掉其中100ms的dispatch_after...检查代码发现之前会故意让启动图多显示100ms,不知道是什么逻辑...
2.2. 将多个二方/三方库延迟加载。包括TBCrashReporter、TBAccsSDK、UT、TRemoteDebugger、ATSDK等。
2.3. 将若干系统UI配置、业务逻辑延迟执行。包括注册推送、检查新版本、更新Orange配置等。
2.4. 避免多余的计算。之前会前后两次获取是否要显示广告图,每次获取都需要反序列化Orange中的配置信息,再比较配置中的开始/结束时间,大约耗时20ms。目前的解决方案是第一次计算后,用一个BOOL属性缓存起来,下次直接取用。
2.5. 延迟加载&懒加载部分视图。快捷密码验证页是启动图消失后用户看到的第一个页面,这个页面由于涉及到图片的解码、多个视图的创建&布局,viewDidLoad阶段会耗时100ms左右。目前的解决方案是把其中密码输入框视图延迟到viewDidAppear里加载,对密码错误提示视图做成懒加载,耗时降低到30m左右。

通过instruments的Time Profiler分析,优化后启动速度有明显提升,didFinishLaunchingWithOptions耗时在75ms左右(iPhone6s iOS10.3.3)

启动耗时..png

其中目前耗时最多的是快捷密码验证页(PAPasscodeViewController)的创建&布局,其次是DTLaunchViewControlle里对是否要显示广告页的判断代码。可以看到PAPasscodeViewControllerviewDidAppear耗时了78ms,但已经没有太大关系,此时用户已经看到了页面,准备去验证指纹/密码了。

总结&后续规划

1. 总结

总结起来,好像启动速度优化就一句话:让系统在启动期间少做一些事。当然我们得先清楚工程里做的哪些事是在启动期间做的、对启动速度的影响有多大,然后case by case地分析工程代码,通过放到子线程、延迟加载、懒加载等方式让系统在启动期间更轻松些。

2. 后续规划

2.1. 替代部分庞大的库,采用更轻量级的解决方案。
2.2. 整理代码,去除重复的实现,避免出现功能重复的类&分类&方法。
2.3. 梳理和移除已经下线的业务涉及的类&分类&方法。
2.4. 监控好灰度版本启动速度的变化趋势,尽早发现&解决拖慢启动速度的问题。

参考资料

WWDC Optimizing App Startup Time
attribute 总结
dyld 加载 Mach-O
优化 App 的启动时间
今日头条iOS客户端启动速度优化

相关文章

网友评论

  • 悠闲自在的蜗牛:启动时间提高0.5秒,用户体验大增?广告好几秒。
  • eagleTang:emmmm. 看完之后感受到了差距
  • 淼是三个水的淼:我想说,对于常见的APP,启动页上加载5秒广告的做法,还需要做启动优化吗?😂
    半尺尘:@风裳水佩 需要,让广告更快显示出来:yum:
  • MoussyL:大神你好,有个问题
    文中所说:“尽量不使用内嵌(embedded)的dylib,加载内嵌dylib性能开销较大”
    内嵌的 dylib 具体指的是哪些?能举个实际例子么 ?谢谢~ :pray:
  • KeepMoveingOn:请问博主是如何排查无用的dylib:flushed:
    半尺尘:@KeepMoveingOn 会报错找不到符号,Undefined symbols for architecture XXX这样...你去试试~
    KeepMoveingOn:@半尺尘 移除依赖的动态库不一定会编译报错吧
    :fearful:
    半尺尘:凭借对项目的了解,先排除掉在用的。剩下不确定在不在用的,一个个试着移除后再编译一下...
  • 悠闲自在的蜗牛:楼主这里测量main阶段的启动时间,不应该使用CFAbsoluteTimeGetCurrent(),而应该使用CACurrentMediaTime()。且,你这种定义变量测试,是不正确的哦。
  • 月咏蝴蝶:Rebase/Bind 这里面的优化方法,能具体举个例子么?谢谢
    东健FO_OF:@月咏蝴蝶 storyboard和xib加载速度的确要比代码慢
    月咏蝴蝶:@半尺尘 谢谢回答,Rebase/Bind在我这边消耗了700ms,而且随着版本的迭代,类和方法也会越来越多,我想问一下您这边是怎么能优化到39.84ms这样,还有什么其他操作么?我这边模型基本都是struct,不过我有用较多storyboard和xib,会是这个原因么?:pray:
    半尺尘:你好,对于这一步的优化,目标是减少指针数量。在这一步,我们可以做的优化有:
    1. 减少ObjC类(class)、方法(selector)、分类(category)的数量
    2. 减少C++虚函数的的数量(创建虚函数表有开销)
    3. 使用Swift structs(内部做了优化,符号数量更少)

    比如针对第一点,可以梳理下代码,把无用的类和方法等干掉...
  • fanglaoda:楼主好,想咨询个问题
    如何是自己写的load方法改起来还是相对比较方便的,但有些load方法是第三方的楼主如何处理的,直接修改三方代码吗?
    东健FO_OF:减少不必要的第三方使用,有的小伙伴写项目的时候,工程刚创建,不管用不用得到,先拉一大堆“工具类”和第三方进去,这样就会导致这些文件中有的重写了load方法,你即使根本没必要用它的,但是它还是参与了运行,甚至拖慢了速度
  • 君赏:人眨眼速度是一秒 0.5秒只是眨眼半个过程 从0.5到0.1给用户多大体验 有必要优化吗?
    半尺尘:@君赏 言重了哈,我们团队对启动速度倒是很重视的...
    君赏:@半尺尘 这个涉及到一些其他理论了 能优化是很好的 但是也要看一些现实栗子 比如你就对10个item的数组进行比较那个算法遍历最快没什么意义 你说的文章是从0.5到0.1秒 是APP启动的时间 并不是页面的 不过你也可以尝试viewWillAppear睡眠0.5 另外睡眠0.1 看看效果怎么样。从文章的技术我是认可的,但是优化方案确实不认同。比如你说你从启动三四秒 优化到不到一秒 这种客观就可以看出来的从慢到快效果是客观的。 比如我之前老师说过 单面MTK系统席卷全国的时候, 对于这些手机只有一百多K 想在上面做游戏而不卡 只能实现手动计算出位置 用人工计算代替计算机计算 提高运行速度。 这些在现今的开发依然可以提升运行速度 但是对于现在现今的CPU计算来说 只能算是体现不出来了 人眼所能接受一秒的频率是有限的 你就算电影一秒放200帧 对于人来说只能接受60帧。 不过还是佩服你的技术, 是我我是优化不出来。 大神,我对事不对人,见谅!
    半尺尘:当然有必要,或者你给每个控制器的viewDidAppear里让线程睡个0.5秒?看看感觉怎么样...

    启动等待时间越短,体验越好。

    比如爱奇艺视频和乐视视频就是两个很好的例子,爱奇艺视频启动很快,乐视视频很慢,体验差了一个档次...
  • Tsui_YuenHong:建议对 Time Profiler 的具体函数名打码
    半尺尘:谢谢提醒~
  • LannisZheng:“将多个二方/三方库延迟加载,将若干系统UI配置、业务逻辑延迟执行” 像注册推送、检查新版本等这些功能延迟到什么时候加载好一些?
    邦Ben:@半尺尘 保证执行一次的话,直接dispatch_once不是会好点吗?
    LannisZheng:@半尺尘 明白了 感谢讲解~
    半尺尘:我们是放在首页完全显示后做,在tabBar控制器的viewDidAppear方法里,同时用某个单例对象的Bool值记录是否执行过这些逻辑,保证只执行一次。
  • ForKid:嗯 对 我现在就是这么干的
  • ForKid:O__O "… 我想说我们老板觉得启动太快了~ 让我放慢点~ 这个怎么破~
    4b4d42e9a1bb:@ForKid 你们老板的需求真是太奇葩了
    半尺尘:可以在didFinishLaunchingWithOptions里让线程睡个觉:[NSThread sleepForTimeInterval:1.0]
    ...

本文标题:阿里数据iOS端启动速度优化的一些经验

本文链接:https://www.haomeiwen.com/subject/rtftlxtx.html