iOS图片绘制的过程:
CPU和GPU相互协作
一.CPU计算frame,图片的解码,通过数据总线将需要绘制的纹理交给GPU
二.GPU负责处理纹理的混合,顶点变化和计算,像素点的计算渲染到帧缓冲区
加载
假设从磁盘加载图片
首先加载一张图片(并未压缩),然后将生成的UIImage赋值给UIImageView,一个隐式CATransaction捕捉到UIImageView图层树的变化.
在主线程下的一个runloop到来时, Coreanimation 提交了这个隐式的transation.
这个过程可能会对图片进行copy操作,因为图片的字节对齐问题.
1.分配缓冲区用于文件的IO和解压缩处理
2.将文件数据从磁盘读取到缓存
3.将压缩的图片处理成位图的格式(非常耗时)
4.Coreanimation的CALayer对位图渲染到UIImageView层,
渲染
1.GPU获取图片的坐标
2.将坐标交给顶点着色器(顶点计算)
3.将图片光栅化(获取图片对应的屏幕点)
4.片元着色器计算(计算每个像素点最终显示的值)
5.从缓存区渲染到屏幕
/*由于图片压缩是一个非常耗时的 CPU 操作，并且它是默认在主线程中执行，当需要加载的图片比较多的时候，就会对应用性能造成严重影响，尤其是在快速滑动列表时，这个问题尤其明显*/
//图片解码的代码
- (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;
});
});
}
位图
位图就是一个像素数组，数组中的每个像素点就代表图片中的一个点。
我们经常接触到的 JPEG 和 PNG 图片就是位图，而他们事实上是一种压缩的位图图形格式，只不过 PNG 是无损压缩，并且支持 alpha 通道，
而 JPEG 图片则是有损压缩，可以指定 0-100%的压缩比。
因此，在将磁盘中的图片渲染到屏幕之前，
必须先要得到图片的原始像素数据，才能执行后续的绘制操作，
这就是为什么要对图片解压缩的原因。
总结:
1.图片在渲染的时候,CPU对其进行解压缩,CPU对要压缩的图片会进行缓存,防止解压缩的性能消耗.
2.图形的渲染过程是->图片加载->计算Frame->图片解码->解码后的位图通过数据总线传到GPU->GPU获取图片Frame->顶点变换->光栅化->根据纹理坐标获取相应的每个像素点的颜色值(如果有透明度还要对相应的像素点进行计算)->渲染到帧缓存区->渲染到屏幕
基于CPU的性能优化:
1.尽量用轻量级的对象，比如用不到事件处理的地方，可以考虑使用CAlayer取代UIView；能用基本数据类型，就别用NSNumber类型。
2.不要频繁地跳用UIVIew的相关属性，比如frame、bounds、transform等属性，尽量减少不必要的修改
3.尽量提前计算好布局，在有需要时一次性调整对应的布局，不要多次修改属性
4.Autolayout会比直接设置frame消耗更多的CPU资源
5.图片的size最好刚好跟UIImageView的size保持一致
6.控制一下线程的最大并发数量
7.尽量把耗时的操作放到子线程
8.文本处理（尺寸的计算，绘制）
9.图片处理（解码、绘制）
基于GPU的性能优化
1.尽量减少视图数量和层次
2.GPU能处理的最大纹理尺寸是4096x4096，一旦超过这个尺寸，就会占用CPU资源进行处理，所以纹理尽量不要超过这个尺寸
3.尽量避免短时间内大量图片的显示，尽可能将多张图片合成一张图片显示
4.减少透明的视图（alpha<1），不透明的就设置opaque为yes
5.尽量避免出现离屏渲染
那么什么叫离屏渲染
1.On-SCreen Rendering：当前屏幕渲染，在当前用语显示的屏幕缓冲区进行渲染操作。
2.Off-Screen Rendring： 离屏渲染，在当前屏幕缓冲区以外新开辟一个缓冲区进行渲染操作
一般造成的操作:
(1).光栅化，layer.shouldRasterize = YES
(2).遮罩，layer.mask
(3).圆角，同时设置layer.maskToBounds = Yes，Layer.cornerRadis 大于0
考虑通过CoreGraphics绘制裁剪圆角，或者美工提供圆角图片
(4).阴影，layer.shadowXXX
如果设置了layer.shadowPath就不会产生离屏渲染
需要在当前视图绘制完成之后才能进行阴影和遮罩,圆角等的操作,就会造成离屏渲染.
为什么耗性能?
1.需要创建新的缓冲区；
2离屏渲染的整个过程，需要多次切换上下文环境，先是从当前屏幕切换到离屏；等到离屏渲染结束以后，将离屏缓冲区的渲染结果显示到屏幕上，又需要将上下文环境从离屏切换到当前屏幕
那么View的绘制过程?
当在操作 UI 时，比如改变了 Frame、更新了 UIView/CALayer 的层次时，或者手动调用了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay方法后，这个 UIView/CALayer 就被标记为待处理，并被提交到一个全局的容器去。
苹果注册了一个 Observer 监听 BeforeWaiting(即将进入休眠) 和 Exit (即将退出Loop) 事件，回调去执行一个很长的函数：
_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()。这个函数里会遍历所有待处理的 UIView/CAlayer 以执行实际的绘制和调整，并更新 UI 界面。
这个函数内部的调用栈大概是这样的：
_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()
QuartzCore:CA::Transaction::observer_callback:
CA::Transaction::commit();
CA::Context::commit_transaction();
CA::Layer::layout_and_display_if_needed();
CA::Layer::layout_if_needed();
[CALayer layoutSublayers];
[UIView layoutSubviews];
CA::Layer::display_if_needed();
[CALayer display];
[UIView drawRect];
列表卡顿到底是原因
iOS的mainRunloop是一个60fps的回调，也就是说每16.7ms会绘制一次屏幕，
这个时间段内要完成view的缓冲区创建，view内容的绘制（如果重写了drawRect），这些CPU的工作。
然后将这个缓冲区交给GPU渲染，
这个过程又包括多个view的拼接(compositing)，纹理的渲染（Texture）等，最终显示在屏幕上。
因此，如果在16.7ms内完不成这些操作，
比如，CPU做了太多的工作，或者view层次过于多，
图片过于大，导致GPU压力太大，就会导致“卡”的现象，也就是丢帧
底层原理
1、 在[ZYYView drawRect:] 方法之前，先调用了 [UIView(CALayerDelegate) drawLayer:inContext:]
和 [CALayer drawInContext:]
2、如果 [self.view addSubview:view]; 被注销掉 则 drawRect 不执行。
可以肯定 drawRect
方法是由 addSubview 函数触发的。
每一个UIView都有一个layer，每一个layer都有个content，这个content指向的是一块缓存，叫做backing store
当UIView被绘制时（从 CA::Transaction::commit:以后），CPU执行drawRect，通过context将数据写入backing store
当backing store写完后，通过render server交给GPU去渲染，将backing store中的bitmap数据显示在屏幕上
所以在 drawRect 方法中 要首先获取 context
优化处理
1、尽量用轻量的对象代替重量的对象，可以对性能有所优化。比如 CALayer 比 UIView 要轻量，如果不需要响应触摸事件，用 CALayer 显示会更加合适。如果对象不涉及 UI 操作，则尽量放到后台线程去创建，但如果是包含了 CALayer 的控件，都只能在主线程创建和操作。
2、通过 Storyboard 创建视图对象时，其资源消耗会比直接通过代码创建对象要大非常多。
3、使用懒加载，尽量推迟对象创建的时间，并把对象的创建分散到多个任务中去。
View渲染在CPU阶段的处理
• addsubview 的时候 触发的
• CPU会为layer分配一块内存用来绘制bitmap，叫做backing store
• layer创建指向这块bitmap缓冲区的指针，叫做CGContextRef
• 通过CoreGraphic的api，也叫Quartz2D，绘制bitmap
• 将layer的content指向生成的bitmap
CPU性能瓶颈：
创建对象会分配内存，对象过多，比较消耗 CPU 资源 。
View渲染机制和GPU之间关系
GPU功能
GPU处理的单位是Texture
基本上我们控制GPU都是通过OpenGL来完成的，但是从bitmap到Texture之间需要一座桥梁，Core Animation正好充当了这个角色：
Core Animation对OpenGL的api有一层封装，当我们的要渲染的layer已经有了bitmap content的时候，这个content一般来说是一个CGImageRef，CoreAnimation会创建一个OpenGL的Texture并将CGImageRef（bitmap）和这个Texture绑定，通过TextureID来标识。
这个对应关系建立起来之后，剩下的任务就是GPU如何将Texture渲染到屏幕上了。
GPU性能瓶颈
因此，GPU的挑战有两个：
• 将数据从RAM搬到VRAM中
• 将Texture渲染到屏幕上
这两个中瓶颈基本在第二点上。渲染Texture基本要处理这么几个问题：
Compositing：
Compositing是指将多个纹理拼到一起的过程，对应UIKit，是指处理多个view合到一起的情况，如
如果view之间没有叠加，那么GPU只需要做普通渲染即可。 如果多个view之间有叠加部分，GPU需要做blending。
加入两个view大小相同，一个叠加在另一个上面，那么计算公式如下：
因此，view的层级很复杂，或者view都是半透明的（alpha值不为1）都会带来GPU额外的计算工作。
应用应当尽量减少视图数量和层次，并在不透明的视图里标明 opaque 属性以避免无用的 Alpha 通道合成。
