一、启动时间测量(优化启动时间)
1、main函数前执行的时间
在此阶段系统做的任务为：
1.1. 加载应用的可执行文件
1.2. 加载动态链接库加载器dyld（dynamic loader）
1.3. dyld递归加载应用所有依赖的dylib（dynamic library 动态链接库）
测试方法：在 Xcode 中 Edit scheme -> Run -> Auguments 将环境变量DYLD_PRINT_STATISTICS 设为1 。然后就可以看到控制台打印出main之前的时间
打印结果如下：(单位:毫秒)
Total pre-main time: 675.00 milliseconds (100.0%)
dylib loading time: 42.79 milliseconds (6.3%)
rebase/binding time: 39.88 milliseconds (5.9%)
ObjC setup time: 161.19 milliseconds (23.8%)
initializer time: 431.02 milliseconds (63.8%)
slowest intializers :
libSystem.B.dylib : 10.13 milliseconds (1.5%)
libMainThreadChecker.dylib : 21.36 milliseconds (3.1%)
libglInterpose.dylib : 86.58 milliseconds (12.8%)
libMTLInterpose.dylib : 21.31 milliseconds (3.1%)
ModelIO : 17.24 milliseconds (2.5%)
XXX : 371.80 milliseconds (55.0%)
Load dylibs
这一阶段dyld会分析应用依赖的dylib，找到其mach-o文件，打开和读取这些文件并验证其有效性，接着会找到代码签名注册到内核，最后对dylib的每一个segment调用mmap()。
一般情况下，iOS应用会加载100-400个dylibs，其中大部分是系统库，这部分dylib的加载系统已经做了优化。
所以，依赖的dylib越少越好。在这一步，我们可以做的优化有：
尽量不使用内嵌（embedded）的dylib，加载内嵌dylib性能开销较大
合并已有的dylib和使用静态库（static archives），减少dylib的使用个数
懒加载dylib，但是要注意dlopen()可能造成一些问题，且实际上懒加载做的工作会更多
Rebase/Bind
在dylib的加载过程中，系统为了安全考虑，引入了ASLR（Address Space Layout Randomization）技术和代码签名。由于ASLR的存在，镜像（Image，包括可执行文件、dylib和bundle）会在随机的地址上加载，和之前指针指向的地址（preferred_address）会有一个偏差（slide），dyld需要修正这个偏差，来指向正确的地址。
Rebase在前，Bind在后，Rebase做的是将镜像读入内存，修正镜像内部的指针，性能消耗主要在IO。Bind做的是查询符号表，设置指向镜像外部的指针，性能消耗主要在CPU计算。所以，指针数量越少越好。
在这一步，我们可以做的优化有：
减少ObjC类（class）、方法（selector）、分类（category）的数量
减少C++虚函数的的数量（创建虚函数表有开销）
使用Swift structs（内部做了优化，符号数量更少）
Objc setup
大部分ObjC初始化工作已经在Rebase/Bind阶段做完了，这一步dyld会注册所有声明过的ObjC类，将分类插入到类的方法列表里，再检查每个selector的唯一性。
在这一步倒没什么优化可做的，Rebase/Bind阶段优化好了，这一步的耗时也会减少。
Initializers
到了这一阶段，dyld开始运行程序的初始化函数，调用每个Objc类和分类的+load方法，调用C/C++ 中的构造器函数（用attribute((constructor))修饰的函数），和创建非基本类型的C++静态全局变量。Initializers阶段执行完后，dyld开始调用main()函数。
在这一步，我们可以做的优化有：
1.少在类的+load方法里做事情，尽量把这些事情推迟到+initiailize
2.减少构造器函数个数，在构造器函数里少做些事情
3.减少C++静态全局变量的个数
2、main函数后到didlaunchoption或者到RootVC的Viewdidload方法
2.1. dyld调用main()
2.2. 调用UIApplicationMain()
2.3. 调用applicationWillFinishLaunching
2.4. 调用didFinishLaunchingWithOptions
测试方法:
在main函数中声明 CFAbsoluteTime startTime; startTime = CFAbsoluteTimeGetCurrent();//记录进入main函数时的时间
在RootViewController中声明extern CFAbsoluteTime startTime;在viewdidload中计算时差：CFAbsoluteTimeGetCurrent() - startTime
这一阶段的优化主要是减少didFinishLaunchingWithOptions方法里的工作，在didFinishLaunchingWithOptions方法里，我们会创建应用的window，指定其rootViewController，调用window的makeKeyAndVisible方法让其可见。由于业务需要，我们会初始化各个二方/三方库，设置系统UI风格，检查是否需要显示引导页、是否需要登录、是否有新版本等，由于历史原因，这里的代码容易变得比较庞大，启动耗时难以控制。
所以，满足业务需要的前提下，didFinishLaunchingWithOptions在主线程里做的事情越少越好。在这一步，我们可以做的优化有：
1.梳理各个二方/三方库，找到可以延迟加载的库，做延迟加载处理，比如放到首页控制器的2.viewDidAppear方法里。
3.梳理业务逻辑，把可以延迟执行的逻辑，做延迟执行处理。比如检查新版本、注册推送通知等逻辑。
4.避免复杂/多余的计算。
5.避免在首页控制器的viewDidLoad和viewWillAppear做太多事情，这2个方法执行完，首页控制器才能显示，部分可以延迟创建的视图应做延迟创建/懒加载处理。
6.采用性能更好的API。
7.首页控制器用纯代码方式来构建。
二、循环引用(如下常见举例)
1、对象相互引用无法释放
2、block(block里面引用自身对象需要用__weak typedeof(self) weakSelf = self)
VC1——》push到VC2
VC2中命名block
Self.block = ^{
执行 5s后打印weakSelf.str
};
若在5s内从VC2返回VC1，则VC2的block执行的内容结果为null
若在5s后从VC2返回VC1，则VC2的block执行的结果为真实打印出self.str的值
从而为了避免上面的情况的发生则需要用__Strong来修饰self。
三、内存泄漏检测
一般4种方法
1、静态检测analyze
2、instrument
3、leaks(三方工具MLeaksFinder)
4、dealloc方法检测页面销毁的时候是否释放对应的对象
四、算法复杂度&函数性能测试(结合单元测试)
具体可以参考单元测试里面的测试代码执行时间方法。
五、imageNamed:和imageWithContentsOfFile:加载图片的选择
imageNamed：
这个方法用一个指定的名字在系统缓存中查找并返回一个图片对象如果它存在的话。如果缓存中没有找到相应的图片，这个方法从指定的文档中加载然后缓存并返回这个对象。因此imageNamed的优点是当加载时会缓存图片。所以当图片会频繁的使用时，那么用imageNamed的方法会比较好。例如：你需要在 一个TableView里的TableViewCell里都加载同样一个图标，那么用imageNamed加载图像效率很高。系统会把那个图标Cache到内存，在TableViewCell里每次利用那个图 像的时候，只会把图片指针指向同一块内存。正是因此使用imageNamed会缓存图片，即将图片的数据放在内存中，iOS的内存非常珍贵并且在内存消耗过大时，会强制释放内存，即会遇到memory warnings。而在iOS系统里面释放图像的内存是一件比较麻烦的事情，有可能会造成内存泄漏。例如：当一 个UIView对象的animationImages是一个装有UIImage对象动态数组NSMutableArray，并进行逐帧动画。当使用imageNamed的方式加载图像到一个动态数组NSMutableArray，这将会很有可能造成内存泄露。原因很显然的。
imageWithContentsOfFile：
仅加载图片，图像数据不会缓存。因此对于较大的图片以及使用情况较少时，那就可以用该方法，降低内存消耗。
六、本地图片资源的优化
1、清除与项目无关的图片资源，比如测试阶段使用到、前期使用到、前后期更换，上线以后就没有用途了， 删除这些图片。
2、对项目所有的引用图片资源统一进行压缩后再使用。(https://tinypng.com)可以在这个网站进行图片压缩。
