卡顿优化

CPU和GPU

CPU和GPU的作用

在屏幕成像的过程中，CPU和GPU起着至关重要的作用。

CPU（中央处理器）

对象的创建和销毁
对象属性的调整
布局计算
文本的计算和排版
图片格式转码和解码
图像的绘制（Core Graphics）

GPU（图形处理器）

纹理的渲染（OpenGL）

CPU和GPU协作流程

一个app的展示会包含很多内容，诸如，label，imageview，button等等。这些控件的位置，大小，颜色则都是由CPU来计算，计算完成后CPU会将这些数据提交给GPU来进行渲染，只有经过GPU的渲染才能显示在屏幕上。GPU做的操作则是：将收到的数据转成屏幕能显示的数据格式，所以要进行渲染的操作。渲染的操作是直接放在帧缓存（缓存区）。然后视频控制器从缓存区读取的数据显示在屏幕上。就完成了一个显示的操作。

在iOS中是双缓存机制，有前帧缓存、后帧缓存。

屏幕成像原理

在屏幕显示过程中是有信号发送的。一帧一帧的。

发出垂直同步信号（VSync）时，即将显示一页的数据。水平同步信号（HSync）发出时，就一行一行的显示。

卡顿的原因

屏幕内容是怎么显示到屏幕上的？

CPU（红色）——>GPU（蓝色）

1.CPU完成计算，提交给GPU渲染，这是来个垂直同步信号，则会将渲染的内容显示到屏幕上。

2.CPU计算时间正常，CPU渲染时间短，等待VSync

3.CPU计算时间正常或慢，GPU渲染时间长，这时来了VSync，而这一帧还没有渲染完，那么就会出现掉帧现象，屏幕回去显示上一帧的画面。这样就产生了卡顿。

4.而当下一帧VSync出现时，丢掉的那一帧画面才会出现。

卡顿解决的主要思路：

尽可能减少CPU、GPU资源的消耗。

按照60FPS的刷帧率，每隔16ms就会有一次VSync信号。

卡顿优化-CPU

尽量用轻量级的对象，比如用不到事件处理的地方，可以考虑使用CAlayer取代UIView；能用基本数据类型，就别用NSNumber类型。
不要频繁地跳用UIVIew的相关属性，比如frame、bounds、transform等属性，尽量减少不必要的修改
尽量提前计算好布局，在有需要时一次性调整对应的布局，不要多次修改属性
Autolayout会比直接设置frame消耗更多的CPU资源
图片的size最好刚好跟UIImageView的size保持一致
控制一下线程的最大并发数量
尽量把耗时的操作放到子线程
文本处理（尺寸的计算，绘制）
图片处理（解码、绘制）

//图片解码的代码
- (void)image
{
    UIImageView *imageView = [[UIImageView alloc] init];
    imageView.frame = CGRectMake(100, 100, 100, 56);
    [self.view addSubview:imageView];
    self.imageView = imageView;

    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        // 获取CGImage
        CGImageRef cgImage = [UIImage imageNamed:@"timg"].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;
        });
    });
}

卡顿优化-GPU

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

离屏渲染

在OpenGL中，GPU有2种渲染方式：

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

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

需要创建新的缓冲区；
离屏渲染的整个过程，需要多次切换上下文环境，先是从当前屏幕切换到离屏；
等到离屏渲染结束以后，将离屏缓冲区的渲染结果显示到屏幕上，又需要将上下文环境从离屏切换到当前屏幕；

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

光栅化，layer.shouldRasterize = YES。
遮罩，layer.mask。
圆角，同时设置layer.maskToBounds = Yes，Layer.cornerRadis 大于0。考虑通过CoreGraphics绘制裁剪圆角，或者美工提供圆角图片。
阴影，layer.shadowXXX。如果设置了layer.shadowPath就不会产生离屏渲染。

卡顿检测

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

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

推荐一个库：LXDAppFluecyMonitor

耗电优化

耗电的来源

CPU处理，Processing
网络，Networking
定位，Location
图像，Graphics

优化的方案

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

启动优化

启动流程

APP的启动类别

冷启动（Cold Launch）：从零开始启动APP
热启动（Warm Launch）：APP已经在内存中，在后台存活着，再次点击图标启动APP

APP启动时间的优化，主要是针对冷启动进行优化

APP冷启动的三大阶段

dyld

Apple的动态链接器，可以用来装载Mach-O文件（可执行文件、动态库等）
启动APP时，dyld所做的事情有
- 装载APP的可执行文件，同时会递归加载所有依赖的动态库
- 当dyld把可执行文件、动态库都装载完毕后，会通知Runtime进行下一步的处理

runtime

启动APP时，runtime所做的事情有
- 调用map_images进行可执行文件内容的解析和处理
- 在load_images中调用call_load_methods，调用所有Class和Category的+load方法
- 进行各种objc结构的初始化（注册Objc类、初始化类对象等等）
- 调用C++静态初始化器和attribute((constructor))修饰的函数
到此为止，可执行文件和动态库中所有的符号(Class，Protocol，Selector，IMP，…)都已经按格式成功加载到内存中，被runtime 所管理

main

APP的启动由dyld主导，将可执行文件加载到内存，顺便加载所有依赖的动态库
并由runtime负责加载成objc定义的结构
所有初始化工作结束后，dyld就会调用main函数
接下来就是UIApplicationMain函数，AppDelegate的application:didFinishLaunchingWithOptions:方法

APP启动时间分析方法

通过添加环境变量可以打印出APP的启动时间分析（Edit scheme -> Run -> Arguments）

DYLD_PRINT_STATISTICS设置为1
如果需要更详细的信息，那就将DYLD_PRINT_STATISTICS_DETAILS设置为1

优化的方案

dyld
- 减少动态库、合并一些动态库（定期清理不必要的动态库）
- 减少Objc类、分类的数量、减少Selector数量（定期清理不必要的类、分类）
- 减少C++虚函数数量
- Swift尽量使用struct
runtime
- 用+initialize方法和dispatch_once取代所有的attribute((constructor))、C++静态构造器、ObjC的+load
main
- 在不影响用户体验的前提下，尽可能将一些操作延迟，不要全部都放在finishLaunching方法中
- 按需加载

安装包瘦身

安装包构成

可执行文件
资源

优化的方案

资源（图片、音频、视频等）
- 采取无损压缩: TinyPng、Squoosh、图好快等等
- 去除没用到的资源：开源项目可以检测项目里没用的资源文件
- 可执行文件瘦身
可执行文件优化
编译器优化
- 现在的新版Xcode已经自动给优化了，如果你的项目比较旧的话，可以去XCode设置这些选项，不确定的话最好都去搜下然后设置下 Strip Linked Product、Make Strings Read-Only、Symbols Hidden by Default设置为YES
- 去掉异常支持，Enable C++ Exceptions、Enable Objective-C Exceptions设置为NO， Other C Flags添加-fno-exceptions
利用AppCode（这个软件是收费的，可以试用30天，当然有钱的大家可以支持下正版，没钱的话想办法也可以搞到）检测未使用的代码：菜单栏 -> Code -> Inspect Code
编写LLVM插件检测出重复代码、未被调用的代码
- LinkMap(可以查看可执行文件的具体组成),我们可以用Xcode来生成LinkMap文件
- 借助三方工具来分析LinkMap文件，GItHub上有开源Mac OS项目

网络性能优化

指导原则

减少网络请求次数
减少数据传输量

优化的方案

聚合接口

在一些复杂业务中，可能进入一个页面会同时请求很多接口，这个时候可以考虑改成聚合接口。聚合接口的优势是：只需要发一个请求，节省了并发发多个网络请求的请求头大小（一个头可能有几百乃至上千字节），并且可能能节省网络rtt时间(Round-Trip Time)。比如首页、商详页这种业务逻辑很复杂的页面基本都是采用聚合接口。

接口支持请求多个服务

在网关层面支持接口能请求多个服务的数据。此种方案的实现思路是：客户端在请求里面指定好服务的路径和请求参数请求一个特定的接口，这个接口同时返回几个服务的数据。

按需加载

只有需要时才加载。比如微信群里的图片，在聊天界面显示缩略图，点击后去下载大图。

采用webp图片

据google官方实验显示：无损WebP相比PNG减少26%大小；有损WebP在相同的SSIM（Structural Similarity Index，结构相似性）下相比JPEG减少25%~34%的大小；有损WebP也支持透明通道，大小通常约为对应PNG的1/3。对于原生图片：可以通过拦截SDWebImageManager的loadImageWithURL:options:context:progress:completed:方法去下载webp图片。SDWebImage支持webp下载。对于webview里的图片：可以通过拦截webview图片加载，返回SDWebImage的图片。

采用CDN

用阿里或者腾讯CDN进行网络加速，比如分区域机房，分运营商就近接入。CDN可以用来图片，视频下载加速等。也可以用oss进行文件上传。

接口支持压缩

由于网络库支持gzip解压，让后台对返回的数据做gzip压缩，客户端自动进行解压。

http 2.0

从iOS9.0开始，NSURLSession支持http2.0，http2.0相比1.0的优势是：多路复用，头部压缩。能大大节省流量和缩短并发请求时间。

HTTPDNS

我们在请求一个域名的时候，需要把域名解析成ip，这就是dns解析过程。我们可以通过HTTPDNS来优化dns解析过程。

预加载

通过预加载机制来加快页面显示。比如在app启动时候先请求首页聚合接口进行预加载，这样进入首页就能直接拿到数据进行显示了。

网络数据缓存

对网路数据进行缓存，先显示缓存数据，再去请求网络数据。

优化接口性能

我们监控到网络接口性能，可以在后台做成监控系统，监控耗时，错误率多的接口，然后有针对性进行优化。

采用tcp而不是http

由于http请求头会带几百甚至上千个字节的请求头，而且http是无状态的，用tcp能客户端和后台同时通信，能大大节省流量。

采用pb传输数据

我们一般是采用json传输数据，如果可以的话采用pb，同等数据pb传输大小xml>json>pb.

不同网络环境优化

在不同的网络环境下，客户端进行不同的操作。比如非wifi下只下载小图， wifi下除了下载小图还自动下载大图。

崩溃处理

非主线程刷新UI

问题原因：UIKit Called on Non-Main Thread，非主线程刷新UI 解决方法：通过runtime的方法替换,替换UIView 的 setNeedsLayout， layoutIfNeeded，layoutSubviews， setNeedsUpdateConstraints。方法，判断当前线程是否为主线程，如果不是，在主线程执行。

KVO

问题原因：添加删除不对称导致。

解决方法为，添加Map进行缓存。所以我在addObserver:forKeyPath:options:context:这个方法里新建了一个字典，用来记录observer和keyPath。下面需要解决的就是什么时候去调用的问题，我首先想到的是在dealloc时去判断是否添加了KVO的监视，但是当我直接交换了dealloc方法后发现，这个方法调用的太多了，并不适合直接交换，不然整个程序都会卡顿起来，需要找一个时机，于是我又修改为在添加监视的时候去交换dealloc，这次成功了，这样可以减少对不必要的类进行方法交换，同时提高效率。唯一需要注意的是在ARC的情况下，不能直接@selector(dealloc)来做方法交换，需要变形一下NSSelectorFromString(@"dealloc")，这样才能做方法交换。

容器越界（NSArray， NSDictionary,…）

解决方法：这个问题，就是运用方法替换进行,目前对以下类进行防范，类中可能导致crash 的方法，逐步进行增量扩充。

NSArray
NSMutableArray
NSAttributedString
NSDictionary
NSFileManager
NSIndexPath
NSJSONSerialization
NSMutableAttributedString
NSMutableDictionary
NSMutableSet
NSMutableString
NSSet
NSString
NSURL

nil值问题

解决方法：方法替换，对于Nil不添加，不处理。

unrecognized selector crash

问题原因：这个很多时候是由于class使用错误导致

解决方法：方法替换，对于unrecognized selector，执行一个空方法。

EXC_BAD_ACCESS野指针

问题原因：访问了某些已经释放的对象，或者访问了他们已经释放的成员变量或方法。

解决方法：

设置全局断点，快速定位缺陷所在
重写Obeject的respondToSelector方法
使用Zombie和Address Sanitzer

系统优化相关

卡顿优化

CPU和GPU

CPU和GPU的作用

CPU和GPU协作流程

屏幕成像原理

卡顿的原因

卡顿优化-CPU

卡顿优化-GPU

离屏渲染

卡顿检测

耗电优化

耗电的来源

优化的方案

启动优化

启动流程

APP的启动类别

APP冷启动的三大阶段

APP启动时间分析方法

优化的方案

安装包瘦身

安装包构成

优化的方案

网络性能优化

指导原则

优化的方案

崩溃处理

非主线程刷新UI

KVO

容器越界（NSArray， NSDictionary,…）

nil值问题

unrecognized selector crash

EXC_BAD_ACCESS野指针