梳理各个二方/三方库，找到可以延迟加载的库，做延迟加载处理，比如放到首页控制器的viewDidAppear方法里。
梳理业务逻辑，把可以延迟执行的逻辑，做延迟执行处理。比如检查新版本、注册推送通知等逻辑。
避免复杂/多余的计算。
避免在首页控制器的viewDidLoad和viewWillAppear做太多事情，这2个方法执行完，首页控制器才能显示，部分可以延迟创建的视图应做延迟创建/懒加载处理。
采用性能更好的API。
首页控制器用纯代码方式来构建。
阿里数据iOS端优化实践
在以上的认知指导下，阿里数据iOS端开始着手优化，在pre-main阶段和main()阶段分别做了一系列优化，取得了一定的成果。
1. pre-main阶段的优化
1.1. 排查无用的dylib，移除不再使用的libicucore.tbd
1.2. 删除无用文件&库，合并重复文件（多个重复的分类）。移除不再使用的库UMSocial、PSTCollectionView、MCSwipeTableViewCell，移除功能重复的库Mantle。
1.3. 梳理各个类的+load方法，将多个类中+load方法做的事延迟到+initiailize里去做。
优化前pre-main阶段耗时:
优化前pre-main阶段耗时.png
优化后pre-main阶段耗时：
优化后pre-main阶段耗时.png
测试环境：Xcode8.3.3 iOS10.2的模拟器，热启动。
备注：测试发现，pre-main阶段耗时有一定波动，冷启动时波动更大，这里截图贴的是一个中位数水平。
可以看到热启动下，pre-main阶段耗时有一定下降。
2. main()阶段的优化
2.1. 去掉其中100ms的dispatch_after...检查代码发现之前会故意让启动图多显示100ms，不知道是什么逻辑...
2.2. 将多个二方/三方库延迟加载。包括TBCrashReporter、TBAccsSDK、UT、TRemoteDebugger、ATSDK等。
2.3. 将若干系统UI配置、业务逻辑延迟执行。包括注册推送、检查新版本、更新Orange配置等。
2.4. 避免多余的计算。之前会前后两次获取是否要显示广告图，每次获取都需要反序列化Orange中的配置信息，再比较配置中的开始/结束时间，大约耗时20ms。目前的解决方案是第一次计算后，用一个BOOL属性缓存起来，下次直接取用。
2.5. 延迟加载&懒加载部分视图。快捷密码验证页是启动图消失后用户看到的第一个页面，这个页面由于涉及到图片的解码、多个视图的创建&布局，viewDidLoad阶段会耗时100ms左右。目前的解决方案是把其中密码输入框视图延迟到viewDidAppear里加载，对密码错误提示视图做成懒加载，耗时降低到30m左右。
