iOS Core Animation 性能调优 学习笔记.docx
《iOS Core Animation 性能调优 学习笔记.docx》由会员分享，可在线阅读，更多相关《iOS Core Animation 性能调优 学习笔记.docx（12页珍藏版）》请在冰豆网上搜索。
iOSCoreAnimation性能调优学习笔记
iOSCoreAnimation性能调优学习笔记
高效绘图
一些关键词
软件绘图
上下文：
指代软件绘图（意即：
不由GPU协助的绘图）软件绘图通常是由CoreGraphics框架完成来完成
绘制速度OpenGL>CoreAnimation>CoreGraphics
消耗可观的内存
CALayer只需要一些与自己相关的内存：
只有它的寄宿图会消耗一定的内存空间。
即使直接赋给contents属性一张图片，也不需要增加额外的照片存储大小。
如果相同的一张图片被多个图层作为contents属性，那么他们将会共用同一块内存，而不是复制内存块。
如果你实现了
-drawLayer:
inContext:
-drawRect:
这两个方法中的任意一个方法，图层就创建了了一个绘制上下文，这个上下文需要的大小的内存可从这个算式得出：
图层宽*图层高*4字节，宽高的单位均为像素。
对于一个在RetinaiPad上的全屏图层来说，这个内存量就是2048*1526*4字节，相当于12MB内存，图层每次重绘的时候都需要重新抹掉内存然后重新分配。
你应该避免重绘你的视图。
提高绘制性能的秘诀就在于尽量避免去绘制。
矢量图形
我们用CoreGraphics来绘图的一个通常原因就是只是用图片或是图层效果不能轻易地绘制出矢量图形。
矢量绘图包含一下这些：
-任意多边形（不仅仅是一个矩形）-斜线或曲线-文本-渐变CoreAnimation为这些图形类型的绘制提供了专门的类，并给他们提供硬件支持（第六章『专有图层』有详细提到）。
CAShapeLayer可以绘制多边形，直线和曲线。
CATextLayer可以绘制文本。
CAGradientLayer用来绘制渐变。
这些总体上都比CoreGraphics更快，同时他们也避免了创造一个寄宿图。
脏矩形
，MacOS和iOS设备将会把屏幕区分为需要重绘的区域和不需要重绘的区域。
那些需要重绘的部分被称作『脏区域』。
在实际应用中，鉴于非矩形区域边界裁剪和混合的复杂性，通常会区分出包含指定视图的矩形位置，而这个位置就是『脏矩形』。
但是CoreAnimation通常并不了解你的自定义绘图代码，它也不能自己计算出脏区域的位置。
然而，你的确可以提供这些信息。
当你检测到指定视图或图层的指定部分需要被重绘，你直接调用-setNeedsDisplayInRect:
来标记它，然后将影响到的矩形作为参数传入。
这样就会在一次视图刷新时调用视图的
-drawRect:
图层代理的
--drawLayer:
inContext:
异步绘制
UIKit的单线程天性意味着寄宿图通畅要在主线程上更新，这意味着绘制会打断用户交互，甚至让整个app看起来处于无响应状态。
针对这个问题，有一些方法可以用到：
一些情况下，我们可以推测性地提前在另外一个线程上绘制内容，然后将由此绘出的图片直接设置为图层的内容。
这实现起来可能不是很方便，但是在特定情况下是可行的。
CoreAnimation提供了一些选择：
CATiledLayer和drawsAsynchronously属性。
图像IO
优化从闪存驱动器或者网络中加载和显示图片
加载和潜伏
加载
解压
线程加载
图像加载的优化异步加载图片，避免主线程堵塞
注意事项，异步加载图片造成的问题
由于视图在UICollectionView会被循环利用，我们加载图片的时候不能确定是否被不同的索引重新复用。
为了避免图片加载到错误的视图中，我们在加载前把单元格打上索引的标签，然后在设置图片的时候检测标签是否发生了改变。
+
延迟解压
当加载图片的时候，iOS通常会延迟解压图片的时间，直到加载到内存之后。
这就会在准备绘制图片的时候影响性能，因为需要在绘制之前进行解压
-+imageNamed:
这个方法会在加载图片后立刻解压,但是只对应用资源束中的图片有效
-+imageWithContentsOfFile:
会延迟解压图片的时间，直到加载到内存之后
另一种立刻加载图片的方法就是把它设置成图层内容，或者是UIImageView的image属性。
不幸的是，这又需要在主线程执行，所以不会对性能有所提升。
第三种方式就是绕过UIKit，像下面这样使用ImageIO框架：
NSIntegerindex=indexPath.row;
NSURL*imageURL=[NSURLfileURLWithPath:
self.imagePaths[index]];
NSDictionary*options=@{（__bridgeid）kCGImageSourceShouldCache:
@YES};
CGImageSourceRefsource=CGImageSourceCreateWithURL（（__bridgeCFURLRef）imageURL,NULL）;
CGImageRefimageRef=CGImageSourceCreateImageAtIndex（source,0,（__bridgeCFDictionaryRef）options）;
UIImage*image=[UIImageimageWithCGImage:
imageRef];
CGImageRelease（imageRef）;
CFRelease（source）;
这样就可以使用kCGImageSourceShouldCache来创建图片，强制图片立刻解压，然后在图片的生命周期保留解压后的版本。
最后一种方式就是使用UIKit加载图片，但是立刻会知道CGContext中去。
图片必须要在绘制之前解压，所以就强制了解压的及时性。
这样的好处在于绘制图片可以再后台线程（例如加载本身）执行，而不会阻塞UI。
有两种方式可以为强制解压提前渲染图片：
将图片的一个像素绘制成一个像素大小的CGContext。
这样仍然会解压整张图片，但是绘制本身并没有消耗任何时间。
这样的好处在于加载的图片并不会在特定的设备上为绘制做优化，所以可以在任何时间点绘制出来。
同样iOS也就可以丢弃解压后的图片来节省内存了。
将整张图片绘制到CGContext中，丢弃原始的图片，并且用一个从上下文内容中新的图片来代替。
这样比绘制单一像素那样需要更加复杂的计算，但是因此产生的图片将会为绘制做优化，而且由于原始压缩图片被抛弃了，iOS就不能够随时丢弃任何解压后的图片来节省内存了。
需要注意的是苹果特别推荐了不要使用这些诡计来绕过标准图片解压逻辑（所以也是他们选择用默认处理方式的原因），但是如果你使用很多大图来构建应用，那如果想提升性能，就只能和系统博弈了。
如果不使用+imageNamed:
，那么把整张图片绘制到CGContext可能是最佳的方式了。
尽管你可能认为多余的绘制相较别的解压技术而言性能不是很高，但是新创建的图片（在特定的设备上做过优化）可能比原始图片绘制的更快。
-（UICollectionViewCell*）collectionView:
（UICollectionView*）collectionView
cellForItemAtIndexPath:
（NSIndexPath*）indexPath
{
//dequeuecell
UICollectionViewCell*cell=[collectionViewdequeueReusableCellWithReuseIdentifier:
@"Cell"forIndexPath:
indexPath];
...
//switchtobackgroundthread
dispatch_async（dispatch_get_global_queue（DISPATCH_QUEUE_PRIORITY_LOW,0）,^{
//loadimage
NSIntegerindex=indexPath.row;
NSString*imagePath=self.imagePaths[index];
UIImage*image=[UIImageimageWithContentsOfFile:
imagePath];
//redrawimageusingdevicecontext
UIGraphicsBeginImageContextWithOptions（imageView.bounds.size,YES,0）;
[imagedrawInRect:
imageView.bounds];
image=UIGraphicsGetImageFromCurrentImageContext（）;
UIGraphicsEndImageContext（）;
//setimageonmainthread,butonlyifindexstillmatchesup
dispatch_async（dispatch_get_main_queue（）,^{
if（index==cell.tag）{
imageView.image=image;
}
}）;
}）;
returncell;
}
CATiledLayer
如第6章“专用图层”中的例子所示，CATiledLayer可以用来异步加载和显示大型图片，而不阻塞用户输入。
但是我们同样可以使用CATiledLayer在UICollectionView中为每个表格创建分离的CATiledLayer实例加载传动器图片，每个表格仅使用一个图层。
这样使用CATiledLayer有几个潜在的弊端：
CATiledLayer的队列和缓存算法没有暴露出来，所以我们只能祈祷它能匹配我们的需求
CATiledLayer需要我们每次重绘图片到CGContext中，即使它已经解压缩，而且和我们单元格尺寸一样（因此可以直接用作图层内容，而不需要重绘）。
#import"ViewController.h"
#import
@interfaceViewController（）
@property（nonatomic,copy）NSArray*imagePaths;
@property（nonatomic,weak）IBOutletUICollectionView*collectionView;
@end
@implementationViewController
-（void）viewDidLoad
{
//setupdata
self.imagePaths=[[NSBundlemainBundle]pathsForResourcesOfType:
@"jpg"inDirectory:
@"VacationPhotos"];
[self.collectionViewregisterClass:
[UICollectionViewCellclass]forCellWithReuseIdentifier:
@"Cell"];
}
-（NSInteger）collectionView:
（UICollectionView*）collectionViewnumberOfItemsInSection:
（NSInteger）section
{
return[self.imagePathscount];
}
-（UICollectionViewCell*）collectionView:
（UICollectionView*）collectionViewcellForItemAtIndexPath:
（NSIndexPath*）indexPath
{
//dequeuecell
UICollectionViewCell*cell=[collectionViewdequeueReusableCellWithReuseIdentifier:
@"Cell"forIndexPath:
indexPath];
//addthetiledlayer
CATiledLayer*tileLayer=[cell.contentView.layer.sublayerslastObject];
if（!
tileLayer）{
tileLayer=[CATiledLayerlayer];
tileLayer.frame=cell.bounds;
tileLayer.contentsScale=[UIScreenmainScreen].scale;
tileLayer.tileSize=CGSizeMake（cell.bounds.size.width*[UIScreenmainScreen].scale,cell.bounds.size.height*[UIScreenmainScreen].scale）;
tileLayer.delegate=self;
[tileLayersetValue:
@（indexPath.row）forKey:
@"index"];
[cell.contentView.layeraddSublayer:
tileLayer];
}
//tagthelayerwiththecorrectindexandreload
tileLayer.contents=nil;
[tileLayersetValue:
@（indexPath.row）forKey:
@"index"];
[tileLayersetNeedsDisplay];
returncell;
}
-（void）drawLayer:
（CATiledLayer*）layerinContext:
（CGContextRef）ctx
{
//getimageindex
NSIntegerindex=[[layervalueForKey:
@"index"]integerValue];
//loadtileimage
NSString*imagePath=self.imagePaths[index];
UIImage*tileImage=[UIImageimageWithContentsOfFile:
imagePath];
//calculateimagerect
CGFloataspectRatio=tileImage.size.height/tileImage.size.width;
CGRectimageRect=CGRectZero;
imageRect.size.width=layer.bounds.size.width;
imageRect.size.height=layer.bounds.size.height*aspectRatio;
imageRect.origin.y=（layer.bounds.size.height-imageRect.size.height）/2;
//drawtile
UIGraphicsPushContext（ctx）;
[tileImagedrawInRect:
imageRect];
UIGraphicsPopContext（）;
}
@end
需要解释几点：
CATiledLayer的tileSize属性单位是像素，而不是点，所以为了保证瓦片和表格尺寸一致，需要乘以屏幕比例因子。
在-drawLayer:
inContext:
方法中，我们需要知道图层属于哪一个indexPath以加载正确的图片。
这里我们利用了CALayer的KVC来存储和检索任意的值，将图层和索引打标签。
分辨率交换
视网膜分辨率（根据苹果市场定义）代表了人的肉眼在正常视角距离能够分辨的最小像素尺寸。
但是这只能应用于静态像素。
当观察一个移动图片时，你的眼睛就会对细节不敏感，于是一个低分辨率的图片和视网膜质量的图片没什么区别了。
+
如果需要快速加载和显示移动大图，简单的办法就是欺骗人眼，在移动传送器的时候显示一个小图（或者低分辨率），然后当停止的时候再换成大图。
这意味着我们需要对每张图片存储两份不同分辨率的副本，但是幸运的是，由于需要同时支持Retina和非Retina设备，本来这就是普遍要做到的。
如果从远程源或者用户的相册加载没有可用的低分辨率版本图片，那就可以动态将大图绘制到较小的CGContext，然后存储到某处以备复用。
为了做到图片交换，我们需要利用UIScrollView的一些实现UIScrollViewDelegate协议的委托方法（和其他类似于UITableView和UICollectionView基于滚动视图的控件一样）：
-（void）scrollViewDidEndDragging:
（UIScrollView*）scrollViewwillDecelerate:
（BOOL）decelerate;
-（void）scrollViewDidEndDecelerating:
（UIScrollView*）scrollView;
你可以使用这几个方法来检测传送器是否停止滚动，然后加载高分辨率的图片。
只要高分辨率图片和低分辨率图片尺寸颜色保持一致，你会很难察觉到替换的过程（确保在同一台机器使用相同的图像程序或者脚本生成这些图片）。
缓存
如果有很多张图片要显示，最好不要提前把所有都加载进来，而是应该当移出屏幕之后立刻销毁。
通过选择性的缓存，你就可以避免来回滚动时图片重复性的加载了。
+imageNamed:
方法
之前我们提到使用[UIImageimageNamed:
]加载图片有个好处在于可以立刻解压图片而不用等到绘制的时候。
但是[UIImageimageNamed:
]方法有另一个非常显著的好处：
它在内存中自动缓存了解压后的图片，即使你自己没有保留对它的任何引用。
对于iOS应用那些主要的图片（例如图标，按钮和背景图片），使用[UIImageimageNamed:
]加载图片是最简单最有效的方式。
在nib文件中引用的图片同样也是这个机制，所以你很多时候都在隐式的使用它。
但是[UIImageimageNamed:
]并不适用任何情况。
它为用户界面做了优化，但是并不是对应用程序需要显示的所有类型的图片都适用。
有些时候你还是要实现自己的缓存机制，原因如下：
-[UIImageimageNamed:
]方法仅仅适用于在应用程序资源束目录下的图片，但是大多数应用的许多图片都要从网络或者是用户的相机中获取，所以[UIImageimageNamed:
]就没法用了。
-[UIImageimageNamed:
]缓存用来存储应用界面的图片（按钮，背景等等）。
如果对照片这种大图也用这种缓存，那么iOS系统就很可能会移除这些图片来节省内存。
那么在切换页面时性能就会下降，因为这些图片都需要重新加载。
对传送器的图片使用一个单独的缓存机制就可以把它和应用图片的生命周期解耦。
-[UIImageimageNamed:
]缓存机制并不是公开的，所以你不能很好地控制它。
例如，你没法做到检测图片是否在加载之前就做了缓存，不能够设置缓存大小，当图片没用的时候也不能把它从缓存中移除。
自定义缓存
构建一个所谓的缓存系统非常困难。
菲尔卡尔顿曾经说过：
“在计算机科学中只有两件难事：
缓存和命名”。
如果要写自己的图片缓存的话，那该如何实现呢？
让我们来看看要涉及哪些方面：
-选择一个合适的缓存键-缓存键用来做图片的唯一标识。
如果实时创建图片，通常不太好生成一个字符串来区分别的图片。
在我们的图片传送带例子中就很简单，我们可以用图片的文件名或者表格索引。
-提前缓存-如果生成和加载数据的代价很大，你可能想当第一次需要用到的时候再去加载和缓存。
提前加载的逻辑是应用内在就有的，但是在我们的例子中，这也非常好实现，因为对于一个给定的位置和滚动方向，我们就可以精确地判断出哪一张图片将会出现。
-缓存失效-如果图片文件发生了变化，怎样才能通知到缓存更新呢？
这是个非常困难的问题（就像菲尔卡尔顿提到的），但是幸运的是当从程序资源加载静态图片的时候并不需要考虑这些。
对用户提供的图片来说（可能会被修改或者覆盖），一个比较好的方式就是当图片缓存的时候打上一个时间戳以便当文件更新的时候作比较。
-缓存回收-当内存不够的时候，如何判断哪些缓存需要清空呢？
这就需要到你写一个合适的算法了。
幸运的是，对缓存回收的问题，苹果提供了一个叫做NSCache通用的解决方案
NSCache
NSCache和NSDictionary类似。
你可以通过-setObject:
forKey:
和-object:
forKey:
方法分别来插入，检索。
和字典不同的是，NSCache在系统低内存的时候自动丢弃存储的对象。
NSCache用来判断何时丢弃对象的算法并没有在文档中给出，但是你可以使用-setCountLimit:
方法设置缓存大小，以及-setObject:
forKey:
cost:
来对每个存储的对象指定消耗的值来提供一些暗示。
指定消耗数值可以用来指定相对的重建成本。
如果对大图指定一个大的消耗值，那么缓存就知道这些物体的存储更加昂贵，于是当有大的性能问题的时候才会丢弃这些物体。
你也可以用-setTotalCostLimit:
方法来指定全体缓存的尺寸。
NSCache是一个普遍的缓存解决方案，我们创建一个比传送器案例更好的自定义的缓存类。
（例如，我们可以基于不同的缓存图片索引和当前中间索引来判断哪些图片需要首先被释放）。
但是NSCache对我们当前的缓存需求来说已经足够了；没必要过早做优化。
#import"ViewController.h"
@interfaceViewController（）
@property（nonatomic,copy）NSArray*imagePaths;
@property（nonatomic,weak）IBOutletUICollectionView*collectionView;
@end
@implementationViewController
-（void）viewDidLoad
{
//setupdata
self.imagePaths=[[NSBundlemainBundle]pathsForResourcesOfType:
@"png"inDirectory:
@"VacationPhotos"];
//registercellclass
[self.collectionViewregisterClass:
[UICollectionViewCellclass]forCellWithReuseIdentifier:
@"Cell"];
}
-（NSInteger）collectionView:
（UICollectionView*）collectionViewnumberOfItemsInSection:
（NSInteger）section
{
return[self.imagePathscount];
}
-（UIImage*）loadImageAtIndex:
（NSUInteger
升级会员 