注意！这里全是个人花碎片时间整理，整理不易，转载请注明出处：https://www.cnblogs.com/shisishao/p/15084530.html
1、性能优化有哪些？
1、卡顿解决的主要思路
- 尽可能减少CPU、GPU资源消耗
- 按照60FPS的刷帧率，每隔16ms就会有一次VSync信号
- 尽量用轻量级的对象，比如用不到事件处理的地方，可以考虑使用CALayer取代UIView
- 不要频繁地调用UIView的相关属性，比如frame、bounds、transform等属性，尽量减少不必要的修改
- 尽量提前计算好布局，在有需要时一次性调整对应的属性，不要多次修改属性
- Autolayout会比直接设置frame消耗更多的CPU资源
图片的size最好刚好跟UIImageView的size保持一致- 控制一下线程的最大并发数量
- 尽量把耗时的操作放到子线程
- 文本处理（尺寸计算、绘制）
- 图片处理（解码、绘制、圆角）
- 尽量避免短时间内大量图片的显示，尽可能将多张图片合成一张进行显示
- GPU能处理的最大纹理尺寸是4096x4096，一旦超过这个尺寸，就会占用CPU资源进行处理，所以纹理尽量不要超过这个尺寸
- 尽量减少视图数量和层次
- 减少透明的视图（alpha<1），不透明的就设置opaque为YES
- 尽量避免出现离屏渲染
2、哪些操作会触发离屏渲染？
- 光栅化，layer.shouldRasterize = YES
- 遮罩，layer.mask
- 圆角，同时设置layer.masksToBounds = YES、
- layer.cornerRadius大于0
- 考虑通过CoreGraphics绘制裁剪圆角，或者叫美工提供圆角图片
- 阴影，layer.shadowXXX
- 如果设置了layer.shadowPath就不会产生离屏渲染
3、卡顿检测
- 平时所说的“卡顿”主要是因为在主线程执行了比较耗时的操作
- 可以添加Observer到主线程RunLoop中，通过监听RunLoop状态切换的耗时，以达到监控卡顿的目的
4、耗电的主要来源及优化
耗电的主要来源：
- CPU处理，Processing
- 网络，Networking
- 定位，Location
- 图像，Graphics
耗电优化：
- 尽可能降低CPU、GPU功耗
- 少用定时器
- 优化I/O操作
- 尽量不要频繁写入小数据，最好批量一次性写入
- 读写大量重要数据时，考虑用dispatch_io，其提供了基于GCD的异步操作文件I/O的API。用dispatch_io系统会优化磁盘访问
- 数据量比较大的，建议使用数据库（比如SQLite、CoreData）
5、网络优化
- 减少、压缩网络数据
- 如果多次请求的结果是相同的，尽量使用缓存
- 使用断点续传，否则网络不稳定时可能多次传输相同的内容
- 网络不可用时，不要尝试执行网络请求
- 让用户可以取消长时间运行或者速度很慢的网络操作，设置合适的超时时间
- 批量传输，比如，下载视频流时，不要传输很小的数据包，直接下载整个文件或者一大块一大块地下载。如果下载广告，一次性多下载一些，然后再慢慢展示。如果下载电子邮件，一次下载多封，不要一封一封地下载
5、点位优化
- 如果只是需要快速确定用户位置，最好用CLLocationManager的requestLocation方法。定位完成后，会自动让定位硬件断电
- 如果不是导航应用，尽量不要实时更新位置，定位完毕就关掉定位服务
- 尽量降低定位精度，比如尽量不要使用精度最高的kCLLocationAccuracyBest
- 需要后台定位时，尽量设置pausesLocationUpdatesAutomatically为YES，如果用户不太可能移动的时候系统会自动暂停位置更新
- 尽量不要使用startMonitoringSignificantLocationChanges，优先考虑startMonitoringForRegion:
5、APP的启动优化
1、pre-main阶段：
- 查看main()函数之前耗时方法：在Xcode的菜单中选择Project→Scheme→Edit Scheme...，然后找到 Run → Environment Variables →+，添加name为DYLD_PRINT_STATISTICSvalue为1的环境变量。
Total pre-main time: 1.0 seconds (100.0%)
dylib loading time: 108.34 milliseconds (9.8%)
rebase/binding time: 90.54 milliseconds (8.2%)
ObjC setup time: 20.12 milliseconds (1.8%)
initializer time: 877.95 milliseconds (80.0%)
slowest intializers :
libSystem.B.dylib : 7.08 milliseconds (0.6%)
GPUToolsCore : 48.63 milliseconds (4.4%)
libglInterpose.dylib : 537.58 milliseconds (49.0%)
libMTLCapture.dylib : 21.97 milliseconds (2.0%)
解读：
- main()函数之前总共使用了1.0 s
在94.33ms中，加载动态库用了08.34ms，指针重定位使用了90.54ms，ObjC类初始化使用了20.12ms，各种初始化使用了877.95ms。
- 动态库加载越多，启动越慢。
- ObjC类越多，启动越慢
- C的constructor函数越多，启动越慢
- C++静态对象越多，启动越慢
- ObjC的+load越多，启动越慢
2、main()阶段：
- 执行main()函数的耗时
- 执行applicationWillFinishLaunching的耗时
- rootViewController及其childViewController的加载、view及其subviews的加载
此阶段的优化才是我们app优化的核心与重点，大部分的启动时间消耗出现在此阶段，由于业务需要，我们会初始化各个三方库，推送、定位、im、埋点上报等基础服务的初始化，检查是否需要显示引导页、是否需要登录、是否有新版本等，由于历史原因，这里的代码容易变得比较庞大，启动耗时难以控制。所以，满足业务需要的前提下，didFinishLaunchingWithOptions在主线程里做的事情越少越好，可以把一些事情放在子线程去处理。
优化方向及方案
- 1、梳理各个三方库，找到可以延迟加载的库，做延迟加载处理，或者用到此功能的时候再去加载。
- 2、梳理业务逻辑，把可以延迟执行的逻辑，做延迟执行处理。比如检查新版本、注册推送通知等逻辑。
- 3、复杂的计算（例如UI控件的位置信息及mode的解析）放到子线程中去处理。
- 4、避免在首页控制器的viewDidLoad和viewWillAppear做太多事情，部分可以延迟创建的视图应做延迟创建/懒加载处理。
- 5、首页控制器用纯代码方式来构建，xib及storyboard创建的界面第一次加载的时候相对来说要比纯代码加载速度稍慢。
2、AFNetworking源码解析
- 先看下AFNetworking的代码结构：
可以看到AFN分为5个功能模块：
- 网络通信模块（最核心）（AFURLSessionManager、AFHTTPSessionManager）
- 网络状态监听模块（Reachability）
- 网络通信安全策略模块（Security）
- 网络通信信息序列化/反序列化模块（Serialization）
- 对于iOS UIkit库的拓展（UIKit）
在分析AFNetworking之前先来介绍一下使用 NSURLSession 发起一次网络请求的步骤：
- 创建NSURLSessionCoftig对象
- 创建NSURLSession对象
- 创建task
- 调用resume开始执行请求
- 代理响应网络事件及数据
核心类讲解：
1.AFURLSessionManager
- AFURLSessionManager遵守NSSecureCoding, NSCopying两个协议，以及遵守
NSURLSessionDelegate，NSURLSessionTaskDelegate，NSURLSessionDataDelegate，NSURLSessionDownloadDelegate四个代理。在AFURLSessionManager中实现协议里的方法，用来处理网络请求中不同的情况：例如：暂停，取消，数据保存，更新数据进度条一样。
| 属性 | 含义 |
|---|---|
| NSURLSession *session | 会话管理器管理的绘画 |
| NSOperationQueue *operationQueue | 用于执行代理回调方法的队列 |
| id responseSerializer | 返回数据的解析器 |
| AFSecurityPolicy *securityPolicy | 安全会话使用的安全策略 |
| AFNetworkReachabilityManager *reachabilityManager | 网络状态管理器 |
| NSArray *tasks | 当前会话所关联的所有任务，包括数据请求、下载、上传任务 |
| NSArray *dataTasks | 当前会话所有关联的数据请求任务 |
| NSArray *uploadTasks | 当前会话关联的上传任务 |
| NSArray *downloadTasks | 当前会话关联的下载任务 |
| dispatch_queue_t completionQueue | 指定 completionBlock 执行的队列，默认为Null，使用主队列 |
| dispatch_group_t completionGroup | 指定 completionBlock 执行的线程组，默认为NULL，将创建一个私有线程组 |
| 关键方法名 | 含义 |
|---|---|
| - (instancetype)initWithSessionConfiguration:(nullable NSURLSessionConfiguration *)configuration | 如果入参configuration为nil，则调用NSURLSessionConfiguration的defaultSessionConfiguration方法，创建一个会话配置，并使用该配置创建一个会话对象，同时还初始化了安全策略、锁、返回数据解析器（JSON 数据解析器）等属性。 |
| - (void)invalidateSessionCancelingTasks:(BOOL)cancelPendingTasks resetSession:(BOOL)resetSession | 此方法是取消会话Session，发现cancelPendingTasks是一个BOOL类型，如果返回NO，意思是允许会话中的任务执行完毕后，再取消会话，但是会话一经取消将无法重启；反之如果返回YES，那么直接取消会话，其相关联的任务和回调都将会释放。 |
| - (NSURLSessionDataTask *)dataTaskWithRequest:(NSURLRequest *)request uploadProgress:(nullable void (^)(NSProgress *uploadProgress))uploadProgressBlock downloadProgress:(nullable void (^)(NSProgress *downloadProgress))downloadProgressBlock completionHandler:(nullable void (^)(NSURLResponse *response, id _Nullable responseObject, NSError * _Nullable error))completionHandler | 创建数据服务，这里在使用会话对象 session 和入参 request 创建任务时，如果 NSFoundationVersionNumber 的值小于 NSFoundationVersionNumber_iOS_8_0 那么 dataTask 的创建会放在 af_url_session_manager_creation_queue 串行队列中同步执行，否则就由当前线程执行 |
| - (void)addDelegateForDataTask:(NSURLSessionDataTask *)dataTask uploadProgress:(nullable void (^)(NSProgress *uploadProgress)) uploadProgressBlock downloadProgress:(nullable void (^)(NSProgress *downloadProgress)) downloadProgressBlock completionHandler:(void (^)(NSURLResponse *response, id responseObject, NSError *error))completionHandler | 在这个方法中会创建一个AFURLSessionManagerTaskDelegate对象，设置其相关联的管理器，任务描述以及回调等苏醒，还会将当前会话注册为监听者，监听 task 任务发出的 AFNSURLSessionTaskDidResumeNotification 和 AFNSURLSessionTaskDidSuspendNotification 通知。当接收到该通知后，分别执行 taskDidResume: 和 taskDidSuspend: 方法，在这两个方法中又发出了 AFNetworkingTaskDidResumeNotification 和 AFNetworkingTaskDidSuspendNotification 通知。 |
2.AFHTTPSessionManager
AFHTTPSessionManager是继承AFURLSessionManager并遵守 NSSecureCoding, NSCopying，所以AHFTTPSessionManager相当于对AFURLSessionManager做了一层封装，提供了各种请求方式POST、PUT、GET、DELETE、PATCH等
请求方式：
1. GET 请求是向服务端发起请求数据，用来获取或查询资源信息
2. POST 请求是向服务端发送数据的，用来更新资源信息，它可以改变数据的种类等资源
3. PUT 请求和POST请求很像，都是发送数据的，但是PUT请求不能改变数据的种类等资源，它只能修改内容
4. DELETE 请求就是用来删除某个资源的
5. PATCH 请求和PUT请求一样，也是用来进行数据更新的，它是HTTP verb推荐用于更新的
在实际开发过程中，我们还是使用【GET 和 POST】请求是最多的。
这里只做核心模块的讲解，其他几个模块暂时不做讲解。