写在前面：
之前（很久以前）产品跑来说，我们这个app启动很慢，需要优化下....就有了这篇文章。关于这块的原理，随便搜一下就有很多
参考
具体实现
我们罗列一下需要优化的点：
1. pre-main()：从按下桌面的图标到main函数获得控制权之前的时间。
动态库加载越多，启动越慢。
ObjC类，方法越多，启动越慢。
ObjC的+load越多，启动越慢。
C的constructor函数越多，启动越慢。
C++静态对象越多，启动越慢。
重新梳理架构，减少动态库、ObjC类的数目，减少Category的数目
定期扫描不再使用的动态库、类、函数
2. after-main()：main函数获得控制权之后，到看到首页展示。
didFinishLaunchingWithOptions里面要做很多初始化的东西，关于这一点，我的iOS 小伙伴已经做过处理了。主要是把初始化的东西，按照轻重缓急的顺序，分布处理。
针对第一点
优化前一共用了
Total pre-main time: 323.61 milliseconds (100.0%)
dylib loading time: 29.05 milliseconds (8.9%)//加载动态库
rebase/binding time: 39.22 milliseconds (12.1%)//指针重定位
ObjC setup time: 42.80 milliseconds (13.2%)//ObjC类初始化
initializer time: 212.42 milliseconds (65.6%)
slowest intializers :
libSystem.B.dylib : 15.74 milliseconds (4.8%)//在初始化耗费的212.42ms中，用时最多的初始化是libSystem.B.dylib占了4.8%
libBacktraceRecording.dylib : 7.29 milliseconds (2.2%)//debug用的一个追溯库
libMainThreadChecker.dylib : 11.15 milliseconds (3.4%)//debug时候检查线程的，比如你在后台线程操作了UI，这个库就会在你的控制台打印警告信息
libglInterpose.dylib : 97.03 milliseconds (29.9%)
libMTLInterpose.dylib : 20.23 milliseconds (6.2%)
DaZhuanJia : 80.18 milliseconds (24.7%)
优化后：
//也许是Debug模式的原因吧，这个数据的波动性很大
Total pre-main time: 283.67 milliseconds (100.0%)
dylib loading time: 44.52 milliseconds (15.6%)
rebase/binding time: 45.97 milliseconds (16.2%)
ObjC setup time: 28.03 milliseconds (9.8%)
initializer time: 164.95 milliseconds (58.1%)
slowest intializers :
libSystem.B.dylib : 3.66 milliseconds (1.2%)
libMainThreadChecker.dylib : 28.64 milliseconds (10.0%)
libglInterpose.dylib : 53.12 milliseconds (18.7%)
libMTLInterpose.dylib : 19.33 milliseconds (6.8%)
DaZhuanJia : 78.86 milliseconds (27.8%)
先删除项目中不用的类和图片
- 使用CATClearProjectTool找出未被引用到的类（！！！记得自己一个个文件确认好没有使用在删除，不要偷懒一键删除）
- 使用LSUnusedResources删除不用的图片
我差不多删除了300个文件。。。还不算pod里的
然后就是不用的方法和分类的归并
其实这部分我们能做的主要就是减少+load()方法里的事情，关于删除没有使用到的方法问题，我暂时还没有解决。
总结
其实这种类型的优化，是一个日积月累的过程。只有业务稳定了，项目中的类才能好好的安排下，不然就是过一段时间又可以删除300个文件了
网友评论