作为一名开发者一定经常听到一个词，那就是“性能优化”。性能优化是一个很大的课题，优化的方向细分为很多，是需要我们开发者不断去探索的事情，但是切记在优化中，不能盲目的为优化而优化，否则出现的效果会适得其反。本篇文章将根据iOS性能优化展开探讨!
一、启动流程
这篇文章主要来说一下iOS性能优化中的启动优化，在谈及优化方案时，首先来了解一下iOS的启动流程!
iOSApp的启动我们都知道分为pre-main和main()两个阶段，并且在这两个阶段中，系统会进系列的加载操作，过程如下：
1、pre-main阶段
1）.加载应的可执件
2）.加载dyld动态连接器
3）.dyld递归加载应所有依赖的动态链接库dylib
2、main()阶段
1).dyld调main()
2).调UIApplicationMain()
3).调applicationWillFinishLaunching
4).调
二、阶段优化项
1、pre-main阶段
针对pre-main阶段做优化时，我们需要先详细了解其加载过程。(由于篇幅原因这里就不细说了，感兴趣的小伙伴可以自行查阅一下)
1.1Loaddylibs
这阶段dyld会分析应依赖的dylib(xcode7以后.dylib已改为名.tbd)，找到其mach-o件，打开和读取这些件并验证其有效性，接着会找到代码签名注册到内核，最后对dylib的每个segment调mmap()。不过这的dylib部分都是系统库，不需要我们去做额外的优化。
优化结论：
1)、尽量不使内嵌的dylib，从避免增加`Loaddylibs`开销
2)、合并已有的dylib和使静态库(staticarchives)，减少dylib的使个数
3)、懒加载dylib，但是要注意dlopen()可能造成些问题，且实际上懒加载做的作会更多
1.2Rebase/Bind
在dylib的加载过程中，系统为了安全考虑，引了ASLR(AddressSpaceLayoutRandomization)技术和代码签名。由于ASLR的存在，镜像(Image，包括可执件、dylib和bundle)会在随机的地址上加载，和之前指针指向的地址(preferred_address)会有个偏差(slide)，dyld需要修正这个偏差，来指向正确的地址。Rebase在前，Bind在后，Rebase做的是将镜像读内存，修正镜像内部的指针，性能消耗主要在IO。Bind做的是查询符号表，设置指向镜像外部的指针，性能消耗主要在CPU计算。
优化结论：
在此过程中，我们需要注意的是尽量减少指针数量，如：
1).减少ObjC类(class)、法(selector)、分类(category)的数量
2).减少C++虚函数的的数量(创建虚函数表有开销)
3).使Swiftstruct(内部做了优化，符号数量更少)
1.3Objcsetup
部分ObjC初始化作已经在Rebase/Bind阶段做完了，这步dyld会注册所有声明过的ObjC类，将分类插到类的法列表，再检查每个selector的唯性。
在这步倒没什么优化可做的，Rebase/Bind阶段优化好了，这步的耗时也会减少。
1.4Initializers
在这阶段，dyld开始运程序的初始化函数，调每个Objc类和分类的+load法，调C/C++中的构造器函数(attribute((constructor))修饰的函数)，和创建基本类型的C++静态全局变量。Initializers阶段执完后，dyld开始调main()函数。
优化结论：
1).少在类的+load法做事情，尽量把这些事情推迟到+initiailize
2).减少构造器函数个数，在构造器函数少做些事情
3).减少构造器函数个数，在构造器函数少做些事情
2、main()阶段
在这阶段，主要优化重点放在SDK初始化、业务具注册、整体
didFinishLaunchingWithOptions法中，因为我们的些第三app格配置、启动引导显示状态逻辑、版本更新逻辑等等基本都会在这进，如果这部分逻辑没有做好优化梳理，随着业务不断拓展，臃肿的业务逻辑会直接导致启动时间加。
优化结论：
Xcode
在满业务需求的前提下，尽量减少didFinishLaunchingWithOptions法在主线程中的事件处理逻辑，如：
1).根据实际业务状况，梳理各个/三库，找到可以延迟加载的库，做延迟加载处理，如放到控制器的viewDidAppear法。
2).梳理业务逻辑，把可以延迟执的逻辑，做延迟执处理。如检查新版本、注册推送通知等逻辑。
3).避免进些复杂/多余的计算逻辑，这类逻辑尽量进异步延迟处理。
4).避免在控制器的viewDidLoad和viewWillAppear做太多容易阻塞主线程的事情，这2个法执完，控制器才能显示。
三、性能检测工具友盟+u-apm
在实际项目开发中，我们需要对线上项的启动数据进多维度监控，那么，这时我们可以使用友盟U-APM应用性能监控，来精准定位问题。
例如如何统计启动时长。传统方法可以通过服务器埋点上报的式自行统计分析，不过这样来统计成本就会增加，且结果分析也不那么灵活。因此使用友盟U-APM应用性能监控，便可根据我们的实际需要对数据进行分析，而友盟后台已经根据这些数据帮我们绘制出了对应的分布图，我们可以了然的得出启动耗时分布、启动类型占等等，如图：
除此之外，我们还可以通过SDK进崩溃分析、ANR分析、监控告警、卡顿分析、内存分析等等诸多功能，有了U-APM这个监控平台，其实在实际开发过程中很程度的提升了我们对线上app的优化分析效率。
四、总结
本文只是浅显的介绍了iOS性能优化思路，以供大家参考。性能优化问题任重而道远，需要大家不断去发掘探索，在这条道路上如果有友盟相伴，那么我们在实际开发过程中，也能更加针对性的进行工作。