【iOS APP启动分析】启动优化解读

在移动端有时会发生启动的性能问题，例如启动闪退、启动卡顿、启动延时等等，这些问题并不好检测，究竟是因为什么原因引起的，还要一一排查，甚是浪费时间。那么，有没有什么能够帮助开发者进行检测分析的工具呢？启动性能的可优化项有哪些?

【第一】App启动过程

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

1. pre-main阶段

加载应用的可执行文件(自身App的所有.o文件的集合);

加载动态链接器dyld(dynamic loader，是一个专门用来加载动态链接库的库);

dyld递归加载应用所有依赖的动态链接库dylib。

2. main()阶段

dyld调用main();

调用UIApplicationMain();

调用applicationWillFinishLaunching;

调用didFinishLaunchingWithOptions。

【第二】启动耗时的测量

在进行优化之前，我们首先应该对启动功能进行性能分析。使用u-apm工具进性能检测，接入友盟U-APM后即可拥有实时、可靠、全面的应用崩溃、ANR、自定义异常等捕获能力， 以及卡顿检测、启动分析、内存分析、网络分析等性能监测能力，支持多方面智能告警监测。

u-apm启动分析通过提供详尽的启动耗时、慢启动情况、启动崩溃数据。帮助开发者把控启动状态。图表方式详细的展示了数据情况，不同趋势之间支持交叉查询，帮助开发者数据分析。

【第三】总结我们app需要做的启动性能优化

1. pre-main阶段的优化

顺便先说一下， pre-main阶段优化到什么范围内比较好呢，苹果给出的建议最好是400ms之内，但这个肯定要按照项目的实际情况有所取舍。

1.1、排查无用的dylib(不确定的可以先删除，在编译下项目试试)，减少dylib的数目

1.2、检查 framework应当设为optional和required，如果该framework在当前App支持的所有iOS系统版本都存在，那么就设为required，否则就设为optional

1.3、减少ObjC类(项目中不常用的库，废弃的代码等)、方法(selector)、分类(category)的数量、无用的库、非基本类型的C++静态全局变量(通常是类或结构体)

1.4、压缩资源图片，删除无用的图片(IO操作)

1.5、少在类的+load方法里做事情，尽量把这些事情推迟到+initiailize

1.6、使用Swift structs(这是长期工作，可以考虑未来新页面用swift写)

2. main()阶段的优化

2.1、可使用友盟+u-apm先分析启动时哪些地方比较耗时，是否可以做优化

2.2、梳理各个三方库，找到可以延迟加载的库，做延迟加载处理，比如放到首页控制器或tabBar控制器的viewDidAppear方法里，并且保证只执行一次(按项目结构，放在合适的地方)

2.3、梳理业务逻辑，把可以延迟执行的逻辑，做延迟执行处理。比如检查新版本、注册推送通知等逻辑。

2.4、避免复杂/多余的计算

2.5、每次用NSLog方式打印会隐式的创建一个Calendar，因此需要删减启动时各业务方打的log

2.6、避免在用户看到的第一个界面(首页控制器或注册登录页面)的viewDidLoad和viewWillAppear做太多事情，这2个方法执行完，第一个页面才能显示，部分可以延迟创建的视图应做延迟创建/懒加载处理

2.7、首页控制器或注册登录页面用纯代码方式来构建

2.8、我们项目中每次启动会全量拉取AppServerConfig的配置，内容太多，未来需要api配合拆分，等页面使用的时候在拉取相应配置

2.9、持久化数据的读取到内存中的时间也可以评估一下

【第四】总结

综上所述，本篇文章总结了iOS启动流程中有哪些可以优化的项，以及介绍了u-apm这一应用性能检测工具，u-apm云真机测试功能模拟真机排查APP性能隐患，把可能出现的问题扼杀在源头，如果开发者是个追求完美的人，不妨试试这款辅助工具!