淘宝客 网站选择WORDPRESS,中国建设监理企业协会网站,学硬件好还是学软件好,石狮服装城商家微网站建设简介#xff1a; 作为程序猿来说#xff0c;“性能优化”是我们都很熟悉的词#xff0c;也是我们需要不断努⼒以及持续进⾏的事情#xff1b;其实优化是⼀个很⼤的课题#xff0c;因为细分来说的话有⼤⼤⼩⼩⼗⼏种优化⽅向 #xff0c;但是切忌在实际开发过程中不能盲⽬…简介 作为程序猿来说“性能优化”是我们都很熟悉的词也是我们需要不断努⼒以及持续进⾏的事情其实优化是⼀个很⼤的课题因为细分来说的话有⼤⼤⼩⼩⼗⼏种优化⽅向 但是切忌在实际开发过程中不能盲⽬的 为了优化⽽优化这样有时可能会造成适得其反的负效果需要我们根据实际场景以及业务需求进⾏合理优 化。接下来进⼊正题本⽂将会以iOS App的启动优化为展开点进⾏探讨。
前言
作为程序猿来说“性能优化”是我们都很熟悉的词也是我们需要不断努⼒以及持续进⾏的事情其实优化是⼀个很⼤的课题因为细分来说的话有⼤⼤⼩⼩⼗⼏种优化⽅向 但是切忌在实际开发过程中不能盲⽬的 为了优化⽽优化这样有时可能会造成适得其反的负效果需要我们根据实际场景以及业务需求进⾏合理优 化。接下来进⼊正题本⽂将会以iOS App的启动优化为展开点进⾏探讨。
启动流程
iOS App 的启动我们都知道分为 为pre-main 和 main() 两个阶段并且在这两个阶段中系统会进 ⾏⼀系列的加载操作过程如下
1、pre-main阶段
1. 加载应⽤的可执⾏⽂件
2. 加载dyld动态连接器
3. dyld递归加载应⽤所有依赖的动态链接库dylib
2、main()阶段
1. dyld调⽤ main()
2. 调⽤UIApplicationMain()
3. 调⽤applicationWillFinishLaunching
4. 调⽤didFinishLaunchingWithOptions
阶段优化项
1、pre-main阶段
针对 pre-main 阶段做优化时我们需要先详细了解其加载过程这个可以在2016年WWDC 的 Optimizing App Startup Time 中详细了解到 相关材料
1.1 Load dylibs 这⼀阶段dyld会分析应⽤依赖的 dylib xcode7以后.dylib已改为名.tbd找到其 mach-o ⽂件打开和读取这些⽂件并验证其有效性接着会找到代码签名注册到内核最后对 dylib 的每⼀个 segment 调⽤ mmap()。不过这⾥的 dylib ⼤部分都是系统库不需要我们去做额外的优化。
优化结论 1、尽量不使⽤内嵌的dylib从⽽避免增加 Load dylibs开销 2、合并已有的dylib和使⽤静态库static archives减少dylib的使⽤个数 3、懒加载dylib但是要注意dlopen()可能造成⼀些问题且实际上懒加载做的⼯作会更多
1.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 struct 内部做了优化符号数量更少
1.3 Objc setup ⼤部分ObjC初始化⼯作已经在Rebase/Bind阶段做完了这⼀步dyld会注册所有声明过的ObjC类将分类插 ⼊到类的⽅法列表⾥再检查每个selector的唯⼀性。
在这⼀步倒没什么优化可做的 Rebase/Bind阶段优化好了这⼀步的耗时也会减少。
1.4 Initializers 在这⼀阶段 dyld开始运⾏程序的初始化函数调⽤每个Objc类和分类的load⽅法调⽤C/C 中的构造器 函数⽤attribute((constructor))修饰的函数和创建⾮基本类型的C静态全局变量。 Initializers阶段执⾏ 完后 dyld开始调⽤main()函数。
优化结论 1. 少在类的load⽅法⾥做事情尽量把这些事情推迟到initiailize 2. 减少构造器函数个数在构造器函数⾥少做些事情 3. 减少构造器函数个数在构造器函数⾥少做些事情
2、main()阶段
在这⼀阶段⾥主要优化重点放在 SDK初始化、业务⼯具注册、整体
didFinishLaunchingWithOptions ⽅法中因为我们的⼀些第三⽅ app ⻛格配置、启动引导⻚显示状态逻辑、版本更新逻辑等等基本⽅都会在这⾥进⾏如果这部分逻辑没有做好优化梳理随着业务不断拓展臃肿的业务逻辑会直接导致启动时 间加⻓。 在满⾜业务需求的前提下尽量减少 didFinishLaunchingWithOptions ⽅法在主线程中的事件处理逻辑 ⽐如 1. 根据实际业务状况梳理各个⼆⽅/三⽅库找到可以延迟加载的库做延迟加载处理⽐如放到⾸⻚控制器 的viewDidAppear⽅法⾥。 2. 梳理业务逻辑把可以延迟执⾏的逻辑做延迟执⾏处理。⽐如检查新版本、注册推送通知等逻辑 3. 避免进⾏⼀些复杂/多余的计算逻辑这类逻辑尽量进⾏异步延迟处理 4. 避免在⾸⻚控制器的viewDidLoad和viewWillAppear做太多容易阻塞主线程的事情这2个⽅法执⾏完 ⾸⻚控制器才能显示
场景补充
另外在我们实际开发过程中很多项⽬的⾸⻚控制器都会有⼀些后台可配、较为丰富的结构或者推荐数据 进⾏展示⽽且我们的⾸⻚展示速度通常也会被纳⼊启动优化的⼀部分其实对于这种类型的优化如果我 们还只是⽤传统的 api - data - UI ⽅式进⾏的话就很难有明显的改善空间因为⽤户的⽹络状态 并不是可控项如果不做其他处理的话那在很多场景下对⽤户来说即使我们放上⼀些占位图展示的样式也是很不友好的毕竟⾸⻚控制器对⽤户的第⼀视觉冲击影响还是⽐较⼤的。
对于这种场景下的优化来说⼀般我们可以采取 Local Network Update 的⽅式在⼀定程度上优化 ⾸⻚加载速度 即 1、 app更新过程中⾸先进⾏本地内嵌处理逻辑内嵌⾸⻚数据结构 localDataBase、内嵌⾸⻚样式所需 资源 localStorage 2、在安装启动之后对本地与线上数据更新记录进⾏对⽐检测是否需要更新本地内嵌数据结构 3、检测到有需要更新的数据时才会对指定结构进⾏静默更新并且同步更新本地数据结构
这样做的好处是 1、⾸⻚数据直接从本地加载减少⽹络数据等待时间 2、仅检测数据key值变化⼩数据量对⽐定向更新结构减少api数据交互频次及数据包体积 3、能够保证⾸⻚对于⽤户来说会⼀直处于⼀个友好的展示状态
当然这种也并不是唯⼀的应对⽅式⽽且也并⾮对所有场景都适⽤只是提供⼀种思路⽽已还是需要根据 项⽬的实际场景选择适合的优化⽅案。
统计时⻓
另外如果在开发过程中我们想直观的查看 app 启动期间各阶段的耗时情况也可以在Xcode的 edit scheme 设置添加 DYLD_PRINT_STATISTICS 为1 打印启动时⻓例如 优化前启动时⻓ 优化后启动时⻓ 当然这些log我们仅仅只能在开发调试阶段查看打印那么在实际项⽬中我们需要对线上项⽬的启动数据 进⾏监控以便及时的定位和优化那些影响 app 启动时⻓的环节这时我们应该怎样更好的处理呢
当然我们可以通过服务器埋点上报的⽅式⾃⾏统计分析不过这样⼀来会发现我们的统计成本就会⼤⼤增 加⽽且结果分析也会变得不那么灵活。所以这⾥推荐⼀种简单的监控⽅式那就是友盟的 U-APM 应能性 能监控SDK 只需要我们进⾏简单的pod集成之后便可根据我们的实际需要进⾏⼿动或者⾃动监控启动数 据详情可以参考 U-APM 并且为了⽅便我们对数据进⾏分析友盟后台已经根据这些数据帮我们绘制出 了对应的分布图我们可以⼀⽬了然的得出启动耗时分布、启动类型占⽐等等如图 除此之外我们还可以通过SDK进⾏崩溃分析、 ANR分析、监控告警、卡顿分析、内存分析等等诸多功能 有了 U-APM 这个监控平台其实在实际开发过程中很⼤程度的提升了我们对线上 app 的优化分析效率。
当然本⽂的介绍也只是⽐较浅显的优化项仅供参考以及思路引导优化之路任重⽽道远还需要我们不断 的去探索、发现、提⾼。不过最后还是要提醒⼀句在实际项⽬开发过程中不要为了优化⽽优化要根据 项⽬情况有针对性的进⾏优化。
参考
探秘 Mach-O ⽂件
iOS底层 - 从头梳理 dyld 加载流程
iOSapp启动 - dyld加载App流程
wwdc2016optimizingappstartuptime.pdf
作者武玉宝
原文链接 本文为阿里云原创内容未经允许不得转载。
