iOS 应用性能优化

性能优化

说起应用优化，就不得不先了解一下 CPU 与 GPU，在屏幕成像的过程中，CPU 与 GPU 起着至关重要的作用。

CPU（Center Processing Unit，中央处理器）

。对象的创建和销毁、对象属性的调整、布局计算、文本的计算和排版、图片格式转换和解码、图像的绘制（Core Craphics）都是由 cpu 来处理的，总的来说，CPU负责复杂的计算任务。

GPU：（Craphics Processing Unit，图形处理器）

负责纹理的渲染，纹理是渲染显示到屏幕上的一种数据，是一种数据格式。

CPU 与 GPU 的协作

App 显示到屏幕上的页面，都是需要 CPU 和 GPU 共同协作的。协作过程如下：

image.png

过程讲解：CPU 将计算好的数据传给 CPU，GPU 将 CPU提供好的数据进行渲染处理，然后放入帧缓存，再由视频控制器读取显示到屏幕上。（在 iOS 中是双缓冲机制的，有前帧缓存和后帧缓存。）

屏幕成像原理

屏幕显示一帧数据时会发出一个垂直同步信号，每一行水平同步信号显示一行数据，到最后一行水平同步信号，显示一帧数据完后，又会发出新的垂直同步信号。

image.png

产生卡顿的原因

image.png

上图，红色代表 CPU 处理时间，蓝色代表 GPU 处理时间。(
按照60FPS 的刷新率，每个16ms 就会有一个 VSync 信号)

情况1：CPU 计算GPU 渲染好后，垂直同步信号刚好到达，此时拿出渲染好的数据进行显示，一切正常。
情况2：CPU 计算GPU 渲染还没来的吃处理完毕，此时垂直同步信号已经来了，需要数据显示，而此时渲染数据还没处理好，那么就只能拿上一帧的数据进行显示，这就会丢帧，造成卡顿。这时的渲染数据就只能乖乖等待一个垂直同步信号。
情况三：CPU计算 GPU 渲染已经早早的准备好渲染数据，在等待者垂直同步信号的到来，垂直同步信号到达后拿出渲染数据进行显示，一切正常。

解决卡顿的主要思路：

我们理解了卡顿的原因后就好对症下药了，就是尽可能的减少 CPU、GPU 的资源消耗。

CPU 资源消耗优化

尽量使用轻量级的对象，比如用不到事件处理的地方，可以考虑使用 CALayer取代 UIView
不要频繁地调用 UIView 的相关属性，比如 frame、center、transform 等属性，可以提前计算好布局，在有需要时一次性调整属性，尽量减少修改属性次数。
不要过度依赖 AutoLayout ，AutoLayeout是通过相关约束计算出对应位置和尺寸的，相比直接设置 frame 会消耗更多的 CPU 资源
图片的 size 最好跟跟 UIImageView 的 size 尺寸保持一直
控制线程的最大并发数，高并发会消耗更多的 CPU 资源
尽量把耗时操作放到子线程，比如可以将文本处理，尺寸计算、绘制等，图片的解码、绘制等放到子线程进行处理。

图片异步解码

//图片要显示是需要解码的，
self.imageView.image = [UIImage imageNamed:@"xxx"] 
//imageNamed 默认是没有解码的，只有在赋值的时候才解码，而且默认是在主线程进行的，图片越大解码时间越长，我们可以把解码操作放在子线程进行

异步解码代码如下

dispatch_async(dispatch_get_global_queue(0, 0), ^{
    // 获取 CGImage
    CGImageRef cgImg = [UIImage imageNamed:@"kebi.jpeg"].CGImage;
    
    //设置位图相关信息
    //alphaInfo
    CGImageAlphaInfo alphaInfo = CGImageGetAlphaInfo(cgImg) & kCGBitmapAlphaInfoMask;
    BOOL hasAlpha = NO;
    if (alphaInfo == kCGImageAlphaPremultipliedLast ||
        alphaInfo == kCGImageAlphaPremultipliedFirst ||
        alphaInfo == kCGImageAlphaLast ||
        alphaInfo == kCGImageAlphaFirst) {
        hasAlpha = YES;
    }
    // bitmapInfo
    CGBitmapInfo bitmapInfo = kCGBitmapByteOrder32Host;
    bitmapInfo |= hasAlpha ? kCGImageAlphaPremultipliedFirst : kCGImageAlphaNoneSkipFirst;
    
    // 创建位图上下文
    CGContextRef contextRef = CGBitmapContextCreate(NULL, CGImageGetWidth(cgImg), CGImageGetHeight(cgImg), 8, 0, CGColorSpaceCreateDeviceRGB(), bitmapInfo);
    
    // 绘制
    CGContextDrawImage(contextRef, CGRectMake(0, 0, CGImageGetWidth(cgImg), CGImageGetHeight(cgImg)), cgImg);
    
    // 获取解码后的 CGImage
    cgImg = CGBitmapContextCreateImage(contextRef);
    // 转换为 UIImage ,此时的newImage 是解码后的 image
    UIImage *newImage = [UIImage imageWithCGImage:cgImg];
    
    // 释放相关资源
    CGContextRelease(contextRef);
    CGImageRelease(cgImg);
    
    // 切换主线程设置图片
    dispatch_async(dispatch_get_main_queue(), ^{
        self.imageView.image = newImage;
    });
});

GPU优化

尽量避免短时间内大量图片的显示，尽可能将多张图片合成一张进行显示
GPU 能处理的最大尺寸时4096x096，一旦超过这个尺寸，就会占用 CPU 资源进行处理，所以经量不要超过这个尺寸
尽量减少视图数量和层次
尽量减少透明视图（alpha<1）的使用，不透明的就设置 opaque 为 YES，透明重叠部分是需要额外的时间计算处理的
尽量避免出现离屏渲染

离屏渲染

在OpenGL中，GPU有2种渲染方式
On-Screen Rendering：当前屏幕渲染，在当前用于显示的屏幕缓冲区进行渲染操作
Off-Screen Rendering：离屏渲染，在当前屏幕缓冲区以外新开辟一个缓冲区进行渲染操作
离屏渲染消耗性能的原因
需要创建新的缓冲区
离屏渲染的整个过程，需要多次切换上下文环境，先是从当前屏幕（On-Screen）切换到离屏（Off-Screen）；等到离屏渲染结束以后，将离屏缓冲区的渲染结果显示到屏幕上，又需要将上下文环境从离屏切换到当前屏幕

以下几点会触发离屏渲染

光栅化，layer.shouldRasterize = YES
遮罩，layer.mask
圆角，同时设置layer.masksToBounds = YES、layer.cornerRadius大于0
阴影，layer.shadowXXX（如果设置了layer.shadowPath就不会产生离屏渲染）

图片圆角是我们常用到的，我们可以使用CoreCraphics绘制裁剪圆角，给 UIImaet添加分类方法，示例代码如下：

- (UIImage *)cornerImageWithRadius:(CGFloat)radius{
    //1.开启图形上下文，获取图片上下文
    UIGraphicsBeginImageContextWithOptions(self.size, NO, 0.0);
    CGContextRef contextRef = UIGraphicsGetCurrentContext();
    //2.裁剪区域
    CGRect rect = CGRectMake(0, 0, self.size.width, self.size.height);
    UIBezierPath *path = [UIBezierPath bezierPathWithRoundedRect:rect cornerRadius:radius];
    CGContextAddPath(contextRef, path.CGPath);
    CGContextClip(contextRef);
    // 绘制
    [self drawInRect:rect];
    //3.从图形中获取裁剪好的图片
    UIImage *img = UIGraphicsGetImageFromCurrentImageContext();
    //4.关闭图形上下文
    UIGraphicsEndImageContext();
    return img;
}

卡顿检测

平时我们感觉到的"卡顿"，主要是在主线程执行了比较耗时的操作
我们可以利用 RunLoop机制，在主线程 RunLoop 添加 Observer，通过监听 RunLoop 状态切换的耗时，达到监控卡顿的目的。相关第三方库LXDAppFluecyMonitor

启动优化

APP 的启动方式可以分为两种
APP的启动可以分为2种
冷启动（Cold Launch）：从零开始启动APP
热启动（Warm Launch）：APP已经在内存中，在后台存活着，再次点击图标启动APP
APP启动时间的优化，主要是针对冷启动进行优化
通过添加环境变量可以打印出APP的启动时间分析（Edit scheme -> Run -> Arguments）DYLD_PRINT_STATISTICS设置为1，如果需要更详细的信息，那就将DYLD_PRINT_STATISTICS_DETAILS设置为1

APP 的启动可以概括为三个阶段

dyld（dynamic link editor），动态链接器，装载相关的 Mach-O 文件（可执行文件、动、静态库等）
runtime机制加载类相关信息
执行 main 函数

image.png

dyld 加载可执行文件阶段
启动APP时，dyld装载APP的可执行文件，同时会递归加载所有依赖的动态库，当dyld把可执行文件、动态库都装载完毕后，会通知Runtime进行下一步的处理。
Runtime 阶段
调用map_images进行可执行文件内容的解析和处理
在load_images中调用call_load_methods，调用所有Class和Category的+load方法
进行各种objc结构的初始化（注册Objc类、初始化类对象等等）
调用C++静态初始化器和__attribute__((constructor))修饰的函数
main函数执行阶段
在上面的工作结束后，dyld 就会调用 main 函数，接下来就是UIApplicationMain函数，AppDelegate的application:didFinishLaunchingWithOptions:方法

优化

尽量减少动态库数量、可以考虑合并一些动态库，还有定期清理一些不必要的动态库
尽量减少减少Objc类、分类的数量、减少Selector数量，定期清理不必要的类、分类
减少C++虚函数数量
Swift尽量使用struct
减少ObjC的+load的使用，一些不需要在加载时立马执行的操作，可以延后处理，比如用+initialize方法和dispatch_once组合使用替换+load方法
main 函数执行阶段的优化，在不影响用户体验的前提下，尽可能将一些操作延迟，不要全部都放在finishLaunching方法中，按需加载

安装包瘦身

安装包（ipa）主要由可执行文件和资源组成

对于资源（图片、音频、视频）部分
我们可以采取无损压缩的方式，压缩资源。还有去除没有用到的资源，相关工具链接：https://github.com/tinymind/LSUnusedResources
对于可执行文件部分
利用 AppCode，检测未使用的代码然后删除，打开 AppCode：菜单栏 -> Code -> Inspect Code 开始检测
去掉异常支持，设置 XCode Build Setting 相关参数， Enable C++ Exceptions、Enable Objective-C Exceptions设置为NO， Other C Flags添加-fno-exceptions