使用友盟U-APM进行启动时长分析

这篇文章来简单分析一下关于启动时长的问题，只是方便大家了解哪些事情可能跟启动性能有关。文章内容相对入门，同时，也了解友盟+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较为方便快捷，性能问题如果盲目解决，反而可能影响到其他进程，这样就得不偿失了!