ios性能优化-卡顿优化和耗电优化

1 卡顿产生的原因及优化

产生卡顿是由于屏幕的成像显示导致，而屏幕画面的显示离不开手机的CPU和GPU；

CPU：（Central Processing Unit 中央处理器）
对象的创建和销毁，对象属性的调整，布局的计算，文本的布局计算和排版，图片格式的转换和解码，图像的绘制（Core Graphics）

GPU：（Graphics Processing Unit 图形处理器）
纹理的绘制

iOS是双帧缓存机制，有前帧缓存，后帧缓存

image.png

1.1屏幕成像显示的过程是：

CPU先计算出图像的布局，大小，位置等信息；（CPU计算出来的数据是不能直接显示到屏幕上的）
GPU将CPU计算的数据，渲染到帧缓存中；
要显示图像的时候，视频控制器从帧缓存中读取图像，显示到屏幕上；

1.2 屏幕成像显示的原理：

iPhone的刷帧频率是 60 FPS，也就是每秒显示60帧数据；

每帧图像显示的时间间隔是： 1000ms / 60 fps = 16ms；

如图：

屏幕成像

屏幕在显示一帧数据的时候：

会先发送一条垂直同步信号
然后会 从上至下 发送水平同步信号，填充整个屏幕，显示这一帧的数据；

重点：每隔16ms就会显示下一帧数据，接收到 垂直同步信号 代表开始显示下一帧的内容

1.3 显示和卡顿产生的根本原因：

之前介绍，屏幕成像在CPU计算和GPU渲染到帧缓存区之后，再由视频控制器读取并显示到屏幕上。

如下图所示：

1、2、3、4、5 代表5帧数据的显示流程，
其中红色箭头代表CPU计算所用时间，蓝色箭头代表GPU渲染所用时间；

image.png

第一帧 1：CPU和GPU所花的时间 ==16ms，所以在垂直同步信号到来的时候，帧缓存中有完整的数据，正常展示；
第二帧 2：CPU和GPU所花的时间 < 16ms, 超前将要显示的内容绘制到帧缓存中，正常展示；
第三帧 3：CPU和GPU所花的时间 > 16ms, 16ms内这一帧的数据还没渲染完成，垂直同步信号已经到来，帧缓存中的数据不全，这一帧会继续显示上一帧（第二帧）的内容；
所以这就是卡顿的原因；
第四帧 4：在这一次的显示中，第三帧的内容CPU和GPU渲染刚完成，当垂直信号到来时，去帧缓存中去读取并直接显示 第三帧 的内容；
第五帧 5：同第二帧，正常展示；

由上图直接展示了卡顿产生的 根本原因：

在一帧显示的频率16ms中，如果CPU和GPU没有将要显示的内容渲染到帧缓存中，当前垂直同步信号到来的时候，就会显示上一帧的内容；

这一帧的内容，会在下一个周期16ms后，垂直同步信号再次到来的时候，显示到屏幕上。

1.4 解决卡顿的方式CPU和GPU：

CPU：

1、使用轻量级的对象：比如不用点击的地方，使用CALayer代替UIView；

2、不要频繁的修改属性：frame，bounds，transfrom等，这些都需要CPU的计算；

3、尽量提前计算好布局：计算好frame，bounds等，一次性修改，不要多次修改；

4、使用AutoLayout比直接设置frame消耗更多的资源；

5、图片的size最好和UIImageView的size保持一致，这样就不用耗费CPU资源去进行缩放操作；

6、控制线程的最大并发数量：比如说3，不要无限制的开辟新的线程；

7、尽量耗时操作放到子线程：

文本的计算（高度），绘制（排版）等

    // 文字计算
    [@"text" boundingRectWithSize:CGSizeMake(100, MAXFLOAT) options:NSStringDrawingUsesLineFragmentOrigin attributes:nil context:nil];
        
    // 文字绘制
    [@"text" drawWithRect:CGRectMake(0, 0, 100, 100) options:NSStringDrawingUsesLineFragmentOrigin attributes:nil context:nil];

图片的解码、绘制

正常图片的展示：imageView.image = [UIImage imageNamed:@"test.png"];

    UIImageView *imageView = [[UIImageView alloc] init];
    imageView.frame = CGRectMake(100, 100, 100, 56);
    imageView.image = [UIImage imageNamed:@"test.png"];
    [self.view addSubview:imageView];

其实正常图片的显示，不是直接展示到屏幕上的，需要解码成能够展示的二进制数据，而这个解码的过程，可以异步的放到子线程中去做：

- (void)viewDidLoad {
    [super viewDidLoad];
    
    UIImageView *imageView = [[UIImageView alloc] init];
    imageView.frame = CGRectMake(100, 100, 100, 56);
    [self.view addSubview:imageView];
    self.imageView = imageView;
    
    [self image]; //异步解码图片，解码成功后再回主线程展示
}

- (void)image{
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        // 获取CGImage
        CGImageRef cgImage = [UIImage imageNamed:@"test.png"].CGImage;

        // alphaInfo
        CGImageAlphaInfo alphaInfo = CGImageGetAlphaInfo(cgImage) & kCGBitmapAlphaInfoMask;
        BOOL hasAlpha = NO;
        if (alphaInfo == kCGImageAlphaPremultipliedLast ||
            alphaInfo == kCGImageAlphaPremultipliedFirst ||
            alphaInfo == kCGImageAlphaLast ||
            alphaInfo == kCGImageAlphaFirst) {
            hasAlpha = YES;
        }

        // bitmapInfo
        CGBitmapInfo bitmapInfo = kCGBitmapByteOrder32Host;
        bitmapInfo |= hasAlpha ? kCGImageAlphaPremultipliedFirst : kCGImageAlphaNoneSkipFirst;

        // size
        size_t width = CGImageGetWidth(cgImage);
        size_t height = CGImageGetHeight(cgImage);

        // context
        CGContextRef context = CGBitmapContextCreate(NULL, width, height, 8, 0, CGColorSpaceCreateDeviceRGB(), bitmapInfo);

        // draw
        CGContextDrawImage(context, CGRectMake(0, 0, width, height), cgImage);

        // get CGImage
        cgImage = CGBitmapContextCreateImage(context);

        // into UIImage
        UIImage *newImage = [UIImage imageWithCGImage:cgImage];

        // release
        CGContextRelease(context);
        CGImageRelease(cgImage);

        // back to the main thread
        dispatch_async(dispatch_get_main_queue(), ^{
            self.imageView.image = newImage;
        });
    });
}

其实就是将image转化成CGImage，然后将CGImage解码，首先创建一个上下文，通过drawImage方法将image画到上下文context完成解码操作，然后从上下文获取解码后的图片；

GPU：

1、尽量减少视图的数量和层级：多层次的视图绘制更占用GPU资源；

2、尽量避免短时间大量图片的显示：可以合成为一张图片展示；

3、GPU能处理的图片的最大尺寸是4096x4096,尽量不要超过这个尺寸;

4、减少透明视图的使用 alpha < 1,
重叠部分：有透明度：需要混合计算；不透明：计算一次（最上层的颜色）

5、避免离屏渲染：

离屏渲染：

当前屏幕渲染：（On-Screen Rendering）在当前显示的屏幕缓冲区进行操作；
离屏渲染：（Off-Screen Rendering）在当前屏幕缓冲区以外，开辟一个新的缓冲区；

离屏渲染消耗性能的原因：

需要开辟新的缓冲区；
需要多次切换上下文状态：从当前屏幕（On-Screen）切换到离屏（Off-Screen），等离屏渲染结束以后，又要从离屏切换到当前屏幕；

哪些操作会触发离屏渲染？

1、光栅化：layer.shouldRasterize = YES；
2、遮罩：layer.mask；
3、圆角，同时设置layer.masksToBounds = YES、layer.cornerRadius大于0；

解决办法：考虑通过CoreGraphics绘制裁剪圆角，或者叫美工提供圆角图片；
4、阴影，layer.shadowXXX；
如果设置了layer.shadowPath就不会产生离屏渲染（不设置路径默认是围绕这个view）

卡顿检测：

平时所说的“卡顿”主要是因为在主线程执行了比较耗时的操作

可以添加Observer到主线程RunLoop中，通过监听RunLoop状态切换的耗时，以达到监控卡顿的目的

耗电优化

耗电的主要来源：

CPU处理计算
网络请求
定位
图形的处理

耗电优化的处理：

1、尽可能减少CPU和GPU的消耗；
2、优化I/O操作：
- 尽量不要频繁的读写小数据，可以批量一次性写入
- 读写大量重要数据时，考虑用dispatch_io，其提供了基于GCD的异步操作文件I/O的API。用dispatch_io系统会优化磁盘访问
- 数据量比较大的，建议使用数据库（比如SQLite、CoreData）
3、网络优化：
- 减少、压缩网络数据
- 如果多次请求的结果是相同的，尽量使用缓存
- 使用断点续传，否则网络不稳定时可能多次传输相同的内容
- 网络不可用时，不要尝试执行网络请求
- 让用户可以取消长时间运行或者速度很慢的网络操作，设置合适的超时时间
- 批量传输，比如，下载视频流时，不要传输很小的数据包，直接下载整个文件或者一大块一大块地下载。如果下载广告，一次性多下载一些，然后再慢慢展示。如果下载电子邮件，一次下载多封，不要一封一封地下载
4、定位优化
- 如果只是需要快速确定用户位置，最好用CLLocationManager的requestLocation方法。
- 定位完成后，会自动让定位硬件断电
- 如果不是导航应用，尽量不要实时更新位置，定位完毕就关掉定位服务
- 尽量降低定位精度，比如尽量不要使用精度最高的kCLLocationAccuracyBest
- 需要后台定位时，尽量设置pausesLocationUpdatesAutomatically为YES，如果用户不太可能移动的时候系统会自动暂停位置更新
- 尽量不要使用startMonitoringSignificantLocationChanges，优先考虑startMonitoringForRegion: