这篇文章来简单分析一下关于启动时长的问题，只是方便大家了解哪些事情可能跟启动性能有关。文章内容相对入门，同时，也了解友盟+u-apm这一性能检测工具，能帮助开发者做哪些工作!
一、APP启动方式
启动方式分为“冷启动”与“热启动”，
冷启动：App点击启动前，此时App的进程还不在系统里。
需要系统新创建一个进程分配给App。(这是一次完整的App启动过程)
热启动：App在冷启动后用户将App退回后台，此时App的进程还在系统里。
用户重新返回App的过程。(热启动做的事较少)
二、 App启动过程
解析Info.plist
加载相关信息，例如如闪屏
沙箱建立、权限检查
Mach-O加载
如果是胖二进制文件，寻找合适当前CPU类别的部分
加载所有依赖的Mach-O文件(递归调用Mach-O加载的方法)
定位内部、外部指针引用，例如字符串、函数等
执行声明为__attribute__((constructor))的C函数
加载类扩展(Category)中的方法
C++静态对象加载、调用ObjC的 +load 函数
程序执行
调用main()调用UIApplicationMain()调用applicationWillFinishLaunching
三、如何测量启动过程耗时
当用户按下home键的时候，iOS的App并不会马上被kill掉，还会继续存活若干时间。理想情况下，用户点击App的图标再次回来的时候，App几乎不需要做什么，就可以还原到退出前的状态，继续为用户服务。这种持续存活的情况下启动App，我们称为热启动，相对而言冷启动就是App被kill掉以后一切从头开始启动的过程。那么在这里推荐友盟+U-APM来测量启动过程耗时。
友盟+U-APM启动耗时分析：提供详细的启动趋势分析、慢启动情况、启动崩溃数据。启动趋势分析，能够展示当前筛选维度和时间状态下的启动次数、平均耗时、以及分位数;慢启动分析直观表现出，慢启动分布的设备、系统、运营商、版本、渠道、地域这一系列详细强大的信息统计数据;启动崩溃分析，能够归纳出启动阶段中出现的崩溃信息，支持筛选首次启动、冷启动、热启动状态下的崩溃率，实时反馈崩溃信息的发生，帮助开发者减少修复时间。
其中友盟+云真机搭载在U-APM应用性能监控平台上，为开发者提供了灵活地测试操作界面，支持ADB调试、WEB远程调试、扫码、抓包、虚拟定位等测试功能，并提供了测试报告供开发者后续查看。帮助开发者更好平衡成本和需求。
四、影响启动性能的因素
App启动过程中每一个步骤都会影响启动性能，但是有些部分所消耗的时间少之又少，另外有些部分根本无法避免，考虑到投入产出比，我们只列出我们可以优化的部分：
1、main()函数之前耗时的影响因素
2、动态库加载越多，启动越慢。
3、ObjC类越多，启动越慢
4、C的constructor函数越多，启动越慢
5、C++静态对象越多，启动越慢
6、ObjC的+load越多，启动越慢
五、一些优化方向
1、利用DYLD_PRINT_STATISTICS分析main()函数之前的耗时
2、重新梳理架构，减少动态库、ObjC类的数目，减少Category的数目
3、定期扫描不再使用的动态库、类、函数，例如每两个迭代一次
4、用dispatch_once()代替所有的 attribute((constructor)) 函数、C++静态对象初始化、ObjC的+load
5、在设计师可接受的范围内压缩图片的大小，会有意外收获
6、利用锚点分析applicationWillFinishLaunching的耗时
7、将不需要马上在applicationWillFinishLaunching执行的代码延后执行
8、rootViewController的加载，适当将某一级的childViewController或subviews延后加载
9、如果你的App可能会被后台拉起并冷启动，可考虑不加载rootViewController
10、异步操作并不影响指标，但有可能影响交互体验，例如大量网络请求导致数据拥堵
总的来说，导致启动速度变慢的原因多种多样，要想精准定位问题所在，还是借用友盟+u-apm较为方便快捷，性能问题如果盲目解决，反而可能影响到其他进程，这样就得不偿失了!