性能优化-详解
性能测试:实时监测应用内存、CPU消耗
部分性能指标及定义
性能指标 指标描述
应用首次启动时间 测量系统从开始处理 activity到完成运行进入主界面的时间,即冷启动响应时间
界面帧率 FPS指应用每秒渲染帧数,是用户对应用界面所量现的画面流畅度的体验,FPS过低，用户可感知的流畅度差。
应用前台运行内存占用 应用在前台且运行稳定时的内存占用情况
应用后台运行CPU占用 应用在后台且亮屏时的cPU占用情况。
CPU&GPU理解
CPU：中央处理器(Central Processing Unit)
GPU：图形处理器(Grphics Processing Unit)
屏幕成像原理：
屏幕的显示成像是结合CPU数据处理和GPU渲染而来的，即每次屏幕刷新时都会受到CPU和GPU的影响。CPU计算显示内容(视图的创建、布局计算、图片解码、文本绘制等)，完成后将计算好的内容提交到GPU,由GPU进行变换、合成、渲染，随后GPU会把渲染结构提交的帧缓冲区去，等待下一此垂直同步信号到来时显示到屏幕上。iOS系统图形服务提供CADisplayLink等机制通知App，App在主线程开始上述操作。如果在一个刷新时间内，CPU或GPU没有完成内容提交，则那一帧就会被丢弃，等待下一次机会再显示，而此时显示屏会保持之前的内容不变，从而产生掉帧情况，从而导致界面卡顿。
离屏渲染
在OpenGL中，GPU有两种渲染方式
①On-Screen Rendering : 当前屏幕渲染，在当前用于显示的屏幕缓冲区进行渲染操作.
②Off-Screen Rendering : 离屏渲染 ,在当前屏幕缓冲区以外新开辟一个缓冲区进行渲染操作.
离屏渲染消耗性能的原因
1.需要创建新的缓冲区
2.离屏渲染的整个过程，需要多次切换上下文环境，先是从当前屏幕(On-Screen)切换到离屏(Off-Screen);
当离屏渲染结束以后，将离屏缓冲区的渲染结果显示到屏幕上，又需要将上下文环境从离屏切换到当前屏幕。
哪些操作会触发离屏渲染？
1.光栅化, layer.shouldRasterize = YES.
(rasterizedLayer栅格化的空间是有限的，iOS大概有屏幕大小两倍的空间来存储rasterizedLayer或是屏幕外缓冲区)如果设置了shouldRasterize=YES,也要设置rasterizationScale 为 contentsScale.即
self.layer.shoudlRasterize = YES;
self.layer.rasteriztionScale = [UIScreen mainScreen].scale;
2.遮罩, layer.mask
3.圆角, 同时设置layer.masksToBounds = YES、layer.cornerRadious 大于0(通过CoreGraphics绘制裁剪圆角，或者美工提供圆角图片)
4.阴影, layer.shadowXX (如果设置了layer.shadowPath就不会产生离屏渲染)
5.系统的切圆角也会触发离屏渲染
view.layer.cornerRadious = 5; view.layer.maskToBounds = true;
①卡顿优化-CPU
1.尽量用轻量级的对象，比如，用不到事件处理的地方，可以考虑用CALayer代替UIView.
2.不要频繁调用UIView的相关属性，比如frame、bounds、transform等属性，尽量减少不必要的修改.
3.尽量提前计算好布局，在有需要时一次性调整对应的属性，不要多次修改属性。
4.AutoLayout要比直接修改frame消耗更多的CPU资源。
5.图片的size最好和UIImageView的size保持一致
6.控制一下线程的最大并发数量
7.尽量把耗时的操作放在子线程
②卡顿优化-GPU
1.尽量避免短时间内大量图片的显示，尽可能将多张图片合成一张进行显示
2.尽量减少视图数量和层次
3.减少透明的视图(alpha<1),不透明的就设置opaque为YES.
4.尽量避免出现离屏渲染
其他：
A.频繁操作部分界面
B.自定义绘图渲染(代码)
C.App启动(冷启动、热启动)
D.选择API 多线程/UIImageAPI
E.文件读写
F.APP太大了（如何给APP瘦身）？
G.内存使用不正确
③耗电优化
耗电的主要来源：
- 1.CPU处理, Processing
- 2.网络 ,Networking
- 3.定位, Location
- 4.图像, Graphics
④定位优化:
- 如果只是快速确认位置，最好用CLLocationManager的requestLocation方法。定位完成后，会自动让定位硬件断电。
- 如果不是导航应用，尽量不要实时更新位置，定位完毕就关掉定位服务
- 尽量降低定位精度，比如尽量不要使用精度最高的kCLLocationAccuracyBest
- 需要后台定位时, 尽量设置pausesLocationUpdatesAutomatically为YES， 如果用户不太可能移动的时候系统就会自动暂停位置更新。
- 尽量不要使用startMonitoringSignificantLocationChanges, 优先考虑startMonitoringForRegin
⑤App启动优化
App启动方式：
1.冷启动:(Cold Launch): 从零开始启动App
2.热启动(Warm Launch) App 已经在内存中，在后台存活着，再次点击图标启动APP
App启动时间的优化主要针对冷启动进行优化
通过添加环境变量可以打印出来App的启动时间分析(Edit scheme - >Run ->Arguments)
1.DYLD_PRINT_STRATISTICS设置为1
2.如果需要更详细的信息，那就将DYLD_PRINT_STRATISTICS_DETAILS设置为1
App冷启动大致分三个阶段
①dyld , Apple的动态链接器，可以用来装在Mach-O文件(可执行文件、动态库)
启动App时，dyld做的事
1.装载App的可执行文件，同时会递归加载所有依赖的动态库
2.当dyld把可执行文件、动态库都装载完毕后，会通知Runtime进行下一步的处理
②runtime
1.调用map_images进行可执行文件的内容的解析和处理
2.在load_images中调用call_load_methods，调用所有的Class和Category的+load方法
3.进行各种objc结构的初始化(注册Objc类、初始化类对象等等)
4.调用C++静态初始化器和_attribute_((constructor))修饰的函数
到此为止，可执行文件和动态库中所有的符号(Class,Protocol,Selector,IMP…)都已经按照格式成功加载到内存中，被runtime管理。
③main
1.App的启动由dyld主导，将可执行文件加载到内存，顺便加载所有的依赖的动态库、
2.并由runtiem负责加载成objc定义的结构。
3.所有初始化工作结束后，dyld就会调用main函数
4.接下来就是UIApplicationMain函数，AppDelegate的application:didFinishLaunchingWithOptions:方法
优化方案
一、dyld
减少动态库、合并一些动态库(定期清理不必要的动态库)
减少Objc类、分类的数量、减少Selector的数量(定期清理不必要的类，分类)
减少C++虚函数数量
Swift尽量使用Struct
二、runtime
用+initialize方法和dispatch_once取代所有的__attribute__((constructor))、C++静态构造器、ObjC的+load方法
三、main
在不影响用户体验的前提下，尽可能将一些操作延迟，不要全部都放在finishLaunching方法中，按需加载。
⑥圆角终极优化方案
/* 实际中重绘圆角的优化方案需要考虑的是，将图像重新绘制为为圆角图像相当于多了一份拷贝，要不要缓存？A.第一次重绘后将这些圆角图像缓存在磁盘里，第二次加载直接使用缓存的圆角图像；B.直接保存在内存里，在内存比较吃紧时显然不是个好选择；C.不缓存，和系统圆角一样，每次都重绘，浪费电量。 */ // 终极优化方案: /* //Ultimate Solution: Rasterization Typical use cases: Avoid redrawing expensive effects for static content Avoid redrawing of complex view hierarchies */ func enableRasterizationOn(_ view: UIView) { view.layer.shouldRasterize = true view.layer.rasterizationScale = view.layer.contentsScale }
总结
1.RoundedCorner 在仅指定cornerRadius时不会触发离屏渲染，仅适用于特殊情况：contents为 nil 或者contents不会遮挡背景色圆角；
2.Shawdow 可以通过指定路径来取消离屏渲染；
3. Mask 无法取消离屏渲染；
以上效果在同等数量的规模下，对性能的影响等级：Shadow > RoundedCorner > Mask > GroupOpacity(迷之效果)。
任何时候优先考虑避免触发离屏渲染，无法避免时优化方案有两种：
1. Rasterization：适用于静态内容的视图，也就是内部结构和内容不发生变化的视图，对上面的所有效果而言，在实现成本以及性能上最均衡的。即使是动态变化的视图，开启 Rasterization 后能够有效降低 GPU 的负荷，不过在动态视图里是否启用还是看 Instruments 的数据。
2. 规避离屏渲染，用其他手法来模拟效果，混合图层是个性能最好、耗能最少的通用优化方案，尤其对于 rounded corer 和 mask。
⑦稳定App缓存
scrollViewDidScrollView，清除缓存
// 清除缓存 [[SDImageCache sharedImageCache] clearMemory]; // 设置缓存时长为1个月 // [SDImageCache sharedImageCache].maxCacheAge = 30 * 24 * 60 * 60; // 清除沙盒中所有使用SD缓存的过期图片（缓存时长 > 一个星期） // [[SDImageCache sharedImageCache] cleanDisk]; // 清除沙盒中所有使用SD缓存的图片 // [[SDImageCache sharedImageCache] clearDisk];
⑧UITableView-hightForRow调用时机+Cell行高计算(缓存)
⑨内存优化分析 如何检测内存方面的问题
公共配置:
A:打开全局断点, 僵尸对象检测，Zombie Objects 进行野指针的检测
[Person release]: message sent to deallocated instance 0x60400001e690
B:打开全局断点
C.(dealloc方法)析构方法打印看调没调用
常见问题汇总:
循环引用 / 错误的内存访问 / 内存消耗<RAM :运行内存 ROM:SD卡>
内存泄漏 / 内存溢出
Exc_BAD_ACESS野指针(错误的内存访问 )
/* (a 向一个已经释放的对象发送消息) (b weak) (c 指针) 检测方法: 打开僵尸断点 Edit Scheme-> Run->Diagnostics->Memory Management ->Malloc Scribble (Bugly 函数 )(增大野指针的崩溃率) -> Zombie Objects 僵尸对象 */
1.需求分析：UIViewController是否释放，pop/push
2.思路分析：
①ViewWillAppear / DidDisAppear
②确定对象是否存活
1.静态检测方法
手动：选中Xcode -> Product -> Analyze 【Shift +Command + B】
自动检测：Build-settings 搜索 Analyze
Analyze During ‘Build’ 设置为YES
2.动态检测方法 Instruments->Leaks
1.跟踪收集信息
2.分析信息，定位问题
3.定位问题，解决问题
分析在绘制过程中捕获的数据。修复源代码中的任何问题
建议：Instruments 每次修改代码切记使用 cmd + I 进行profile记录
内存泄漏检查 常见的内存问题（内存泄露、野指针、僵尸对象、循环引用）
Xcode - > Open Developer Tool -> Instruments -Leaks
循环引用：精确到类名
Leaks -> Cycles & Roots >Leak Cycles
3.第三方检测工具
pod ‘MLeaksFinder’, ‘~> 1.0.0’
思路:
/* UIViewController 延迟发送消息 push ->viewWillAppear: NO pop -> YES viewDidDisappear: 标识信息，发送消息 */