[iOS Animation]-CALayer 圖層性能二
CAShapeLayer
cornerRadius和maskToBounds獨立做用的時候都不會有太大的性能問題，可是當他倆結合在一塊兒，就觸發了屏幕外渲染。有時候你想顯示圓角並沿着圖層裁切子圖層的時候，你可能會發現你並不須要沿着圓角裁切，這個狀況下用CAShapeLayer就能夠避免這個問題了。git
你想要的只是圓角且沿着矩形邊界裁切，同時還不但願引發性能問題。其實你能夠用現成的UIBezierPath的構造器 +bezierPathWithRoundedRect:cornerRadius: （見清單15.1）.這樣作並不會比直接用cornerRadius更快，可是它避免了性能問題。github
清單15.1 用CAShapeLayer畫一個圓角矩形緩存
#import "ViewController.h"#import <QuartzCore/QuartzCore.h>@interface ViewController ()
@property (nonatomic, weak) IBOutlet UIView *layerView;@end@implementation ViewController- (void)viewDidLoad
{
[super viewDidLoad]; //create shape layer
CAShapeLayer *blueLayer = [CAShapeLayer layer];
blueLayer.frame = CGRectMake(50, 50, 100, 100);
blueLayer.fillColor = [UIColor blueColor].CGColor;
blueLayer.path = [UIBezierPath bezierPathWithRoundedRect:
CGRectMake(0, 0, 100, 100) cornerRadius:20].CGPath;
 //add it to our view [self.layerView.layer addSublayer:blueLayer];
}@end
可伸縮圖片
另外一個建立圓角矩形的方法就是用一個圓形內容圖片並結合第二章『寄宿圖』提到的 contentsCenter 屬性去建立一個可伸縮圖片（見清單15.2）.理論上來講，這個應該比用CAShapeLayer要快，由於一個可拉伸圖片只須要18個三角形（一個圖片是由一個3*3網格渲染而成），然而，許多都須要渲染成一個順滑的曲線。在實際應用上，兩者並無太大的區別。ide
清單15.2 用可伸縮圖片繪製圓角矩形佈局
@implementation ViewController- (void)viewDidLoad
{
[super viewDidLoad]; //create layer
CALayer *blueLayer = [CALayer layer];
blueLayer.frame = CGRectMake(50, 50, 100, 100);
blueLayer.contentsCenter = CGRectMake(0.5, 0.5, 0.0, 0.0);
blueLayer.contentsScale = [UIScreen mainScreen].scale;
blueLayer.contents = (__bridge id)[UIImage imageNamed:@"Circle.png"].CGImage; //add it to our view [self.layerView.layer addSublayer:blueLayer];
}@end
使用可伸縮圖片的優點在於它能夠繪製成任意邊框效果而不須要額外的性能消耗。舉個例子，可伸縮圖片甚至還能夠顯示出矩形陰影的效果。性能
shadowPath
在第2章咱們有提到shadowPath屬性。若是圖層是一個簡單幾何圖形如矩形或者圓角矩形（假設不包含任何透明部分或者子圖層），建立出一個對應形狀的陰影路徑就比較容易，並且Core Animation繪製這個陰影也至關簡單，避免了屏幕外的圖層部分的預排版需求。這對性能來講頗有幫助。學習
若是你的圖層是一個更復雜的圖形，生成正確的陰影路徑可能就比較難了，這樣子的話你能夠考慮用繪圖軟件預先生成一個陰影背景圖。優化
混合和過分繪製
在第12章有提到，GPU每一幀能夠繪製的像素有一個最大限制（就是所謂的fill rate），這個狀況下能夠輕易地繪製整個屏幕的全部像素。可是若是因爲重疊圖層的關係須要不停地重繪同一區域的話，掉幀就可能發生了。動畫
GPU會放棄繪製那些徹底被其餘圖層遮擋的像素，可是要計算出一個圖層是否被遮擋也是至關複雜而且會消耗處理器資源。一樣，合併不一樣圖層的透明重疊像素（即混合）消耗的資源也是至關客觀的。因此爲了加速處理進程，不到必須時刻不要使用透明圖層。任何狀況下，你應該這樣作：ui
給視圖的
backgroundColor屬性設置一個固定的，不透明的顏色設置
opaque屬性爲YES
這樣作減小了混合行爲（由於編譯器知道在圖層以後的東西都不會對最終的像素顏色產生影響）而且計算獲得了加速，避免了過分繪製行爲由於Core Animation能夠捨棄全部被徹底遮蓋住的圖層，而不用每一個像素都去計算一遍。
若是用到了圖像，儘可能避免透明除非很是必要。若是圖像要顯示在一個固定的背景顏色或是固定的背景圖以前，你不必相對前景移動，你只須要預填充背景圖片就能夠避免運行時混色了。
若是是文本的話，一個白色背景的UILabel（或者其餘顏色）會比透明背景要更高效。
最後，明智地使用shouldRasterize屬性，能夠將一個固定的圖層體系摺疊成單張圖片，這樣就不須要每一幀從新合成了，也就不會有由於子圖層之間的混合和過分繪製的性能問題了。
減小圖層數量
初始化圖層，處理圖層，打包經過IPC發給渲染引擎，轉化成OpenGL幾何圖形，這些是一個圖層的大體資源開銷。事實上，一次性可以在屏幕上顯示的最大圖層數量也是有限的。
確切的限制數量取決於iOS設備，圖層類型，圖層內容和屬性等。可是總得說來能夠容納上百或上千個，下面咱們將演示即便圖層自己並無作什麼也會遇到的性能問題。
裁切
在對圖層作任何優化以前，你須要肯定你不是在建立一些不可見的圖層，圖層在如下幾種狀況下回事不可見的：
圖層在屏幕邊界以外，或是在父圖層邊界以外。
徹底在一個不透明圖層以後。
徹底透明
Core Animation很是擅長處理對視覺效果無心義的圖層。可是常常性地，你本身的代碼會比Core Animation更早地想知道一個圖層是不是有用的。理想情況下，在圖層對象在建立以前就想知道，以免建立和配置沒必要要圖層的額外工做。
舉個例子。清單15.3 的代碼展現了一個簡單的滾動3D圖層矩陣。這看上去很酷，尤爲是圖層在移動的時候（見圖15.1），可是繪製他們並非很麻煩，由於這些圖層就是一些簡單的矩形色塊。
清單15.3 繪製3D圖層矩陣
#import "ViewController.h"#import <QuartzCore/QuartzCore.h>#define WIDTH 10#define HEIGHT 10#define DEPTH 10#define SIZE 100#define SPACING 150#define CAMERA_DISTANCE 500@interface ViewController ()

@property (nonatomic, strong) IBOutlet UIScrollView *scrollView;@end@implementation ViewController- (void)viewDidLoad
{
[super viewDidLoad]; //set content size
self.scrollView.contentSize = CGSizeMake((WIDTH - 1)*SPACING, (HEIGHT - 1)*SPACING); //set up perspective transform
CATransform3D transform = CATransform3DIdentity;
transform.m34 = -1.0 / CAMERA_DISTANCE;
self.scrollView.layer.sublayerTransform = transform; //create layers
for (int z = DEPTH - 1; z >= 0; z--) { for (int y = 0; y < HEIGHT; y++) { for (int x = 0; x < WIDTH; x++) { //create layer
CALayer *layer = [CALayer layer];
layer.frame = CGRectMake(0, 0, SIZE, SIZE);
layer.position = CGPointMake(x*SPACING, y*SPACING);
layer.zPosition = -z*SPACING; //set background color
layer.backgroundColor = [UIColor colorWithWhite:1-z*(1.0/DEPTH) alpha:1].CGColor; //attach to scroll view [self.scrollView.layer addSublayer:layer];
}
}
}
 //log
NSLog(@"displayed: %i", DEPTH*HEIGHT*WIDTH);
}@end
圖15.1 滾動的3D圖層矩陣
WIDTH，HEIGHT和DEPTH常量控制着圖層的生成。在這個狀況下，咱們獲得的是10*10*10個圖層，總量爲1000個，不過一次性顯示在屏幕上的大約就幾百個。
若是把WIDTH和HEIGHT常量增長到100，咱們的程序就會慢得像龜爬了。這樣咱們有了100000個圖層，性能降低一點兒也不奇怪。
可是顯示在屏幕上的圖層數量並無增長，那麼根本沒有額外的東西須要繪製。程序慢下來的緣由實際上是由於在管理這些圖層上花掉了很多功夫。他們大部分對渲染的最終結果沒有貢獻，可是在丟棄這麼圖層以前，Core Animation要強制計算每一個圖層的位置，就這樣，咱們的幀率就慢了下來。
咱們的圖層是被安排在一個均勻的柵格中，咱們能夠計算出哪些圖層會被最終顯示在屏幕上，根本不須要對每一個圖層的位置進行計算。這個計算並不簡單，由於咱們還要考慮到透視的問題。若是咱們直接這樣作了，Core Animation就不用費神了。
既然這樣，讓咱們來重構咱們的代碼吧。改造後，隨着視圖的滾動動態地實例化圖層而不是事先都分配好。這樣，在創造他們以前，咱們就能夠計算出是否須要他。接着，咱們增長一些代碼去計算可視區域這樣就能夠排除區域以外的圖層了。清單15.4是改造後的結果。
清單15.4 排除可視區域以外的圖層
#import "ViewController.h"#import <QuartzCore/QuartzCore.h>#define WIDTH 100#define HEIGHT 100#define DEPTH 10#define SIZE 100#define SPACING 150#define CAMERA_DISTANCE 500#define PERSPECTIVE(z) (float)CAMERA_DISTANCE/(z + CAMERA_DISTANCE)@interface ViewController () <UIScrollViewDelegate>@property (nonatomic, weak) IBOutlet UIScrollView *scrollView;@end@implementation ViewController- (void)viewDidLoad
{
[super viewDidLoad]; //set content size
self.scrollView.contentSize = CGSizeMake((WIDTH - 1)*SPACING, (HEIGHT - 1)*SPACING); //set up perspective transform
CATransform3D transform = CATransform3DIdentity;
transform.m34 = -1.0 / CAMERA_DISTANCE;
self.scrollView.layer.sublayerTransform = transform;
}
- (void)viewDidLayoutSubviews
{
[self updateLayers];
}- (void)scrollViewDidScroll:(UIScrollView *)scrollView
{
[self updateLayers];
}- (void)updateLayers
{ //calculate clipping bounds
CGRect bounds = self.scrollView.bounds;
bounds.origin = self.scrollView.contentOffset;
bounds = CGRectInset(bounds, -SIZE/2, -SIZE/2); //create layers
NSMutableArray *visibleLayers = [NSMutableArray array]; for (int z = DEPTH - 1; z >= 0; z--)
{ //increase bounds size to compensate for perspective
CGRect adjusted = bounds;
adjusted.size.width /= PERSPECTIVE(z*SPACING);
adjusted.size.height /= PERSPECTIVE(z*SPACING);
adjusted.origin.x -= (adjusted.size.width - bounds.size.width) / 2;
adjusted.origin.y -= (adjusted.size.height - bounds.size.height) / 2; for (int y = 0; y < HEIGHT; y++) { //check if vertically outside visible rect
if (y*SPACING < adjusted.origin.y || y*SPACING >= adjusted.origin.y + adjusted.size.height)
{ continue;
} for (int x = 0; x < WIDTH; x++) { //check if horizontally outside visible rect
if (x*SPACING < adjusted.origin.x ||x*SPACING >= adjusted.origin.x + adjusted.size.width)
{ continue;
}
 //create layer
CALayer *layer = [CALayer layer];
layer.frame = CGRectMake(0, 0, SIZE, SIZE);
layer.position = CGPointMake(x*SPACING, y*SPACING);
layer.zPosition = -z*SPACING; //set background color
layer.backgroundColor = [UIColor colorWithWhite:1-z*(1.0/DEPTH) alpha:1].CGColor; //attach to scroll view [visibleLayers addObject:layer];
}
}
} //update layers
self.scrollView.layer.sublayers = visibleLayers; //log
NSLog(@"displayed: %i/%i", [visibleLayers count], DEPTH*HEIGHT*WIDTH);
}@end
這個計算機制並不具備普適性，可是原則上是同樣。（當你用一個UITableView或者UICollectionView時，系統作了相似的事情）。這樣作的結果？咱們的程序能夠處理成百上千個『虛擬』圖層並且徹底沒有性能問題！由於它不須要一次性實例化幾百個圖層。
對象回收
處理巨大數量的類似視圖或圖層時還有一個技巧就是回收他們。對象回收在iOS頗爲常見；UITableView和UICollectionView都有用到，MKMapView中的動畫pin碼也有用到，還有其餘不少例子。
對象回收的基礎原則就是你須要建立一個類似對象池。當一個對象的指定實例（本例子中指的是圖層）結束了使命，你把它添加到對象池中。每次當你須要一個實例時，你就從池中取出一個。當且僅當池中爲空時再建立一個新的。
這樣作的好處在於避免了不斷建立和釋放對象（至關消耗資源，由於涉及到內存的分配和銷燬）並且也沒必要給類似實例重複賦值。
好了，讓咱們再次更新代碼吧（見清單15.5）
清單15.5 經過回收減小沒必要要的分配
@interface ViewController () <UIScrollViewDelegate>@property (nonatomic, weak) IBOutlet UIScrollView *scrollView;
@property (nonatomic, strong) NSMutableSet *recyclePool;@end@implementation ViewController- (void)viewDidLoad
{
[super viewDidLoad]; //create recycle pool
self.recyclePool = [NSMutableSet set]; //set content size
self.scrollView.contentSize = CGSizeMake((WIDTH - 1)*SPACING, (HEIGHT - 1)*SPACING); //set up perspective transform
CATransform3D transform = CATransform3DIdentity;
transform.m34 = -1.0 / CAMERA_DISTANCE;
self.scrollView.layer.sublayerTransform = transform;
}- (void)viewDidLayoutSubviews
{
[self updateLayers];
}- (void)scrollViewDidScroll:(UIScrollView *)scrollView
{
[self updateLayers];
}- (void)updateLayers {
 //calculate clipping bounds
CGRect bounds = self.scrollView.bounds;
bounds.origin = self.scrollView.contentOffset;
bounds = CGRectInset(bounds, -SIZE/2, -SIZE/2); //add existing layers to pool [self.recyclePool addObjectsFromArray:self.scrollView.layer.sublayers]; //disable animation [CATransaction begin];
[CATransaction setDisableActions:YES]; //create layers
NSInteger recycled = 0;
NSMutableArray *visibleLayers = [NSMutableArray array]; for (int z = DEPTH - 1; z >= 0; z--)
{ //increase bounds size to compensate for perspective
CGRect adjusted = bounds;
adjusted.size.width /= PERSPECTIVE(z*SPACING);
adjusted.size.height /= PERSPECTIVE(z*SPACING);
adjusted.origin.x -= (adjusted.size.width - bounds.size.width) / 2; adjusted.origin.y -= (adjusted.size.height - bounds.size.height) / 2; for (int y = 0; y < HEIGHT; y++) { //check if vertically outside visible rect
if (y*SPACING < adjusted.origin.y ||
y*SPACING >= adjusted.origin.y + adjusted.size.height)
{ continue;
} for (int x = 0; x < WIDTH; x++) { //check if horizontally outside visible rect
if (x*SPACING < adjusted.origin.x ||
x*SPACING >= adjusted.origin.x + adjusted.size.width)
{ continue;
} //recycle layer if available
CALayer *layer = [self.recyclePool anyObject]; if (layer)
{

recycled ++;
[self.recyclePool removeObject:layer]; } else
{
layer = [CALayer layer];
layer.frame = CGRectMake(0, 0, SIZE, SIZE); } //set position
layer.position = CGPointMake(x*SPACING, y*SPACING); layer.zPosition = -z*SPACING; //set background color
layer.backgroundColor =
[UIColor colorWithWhite:1-z*(1.0/DEPTH) alpha:1].CGColor; //attach to scroll view [visibleLayers addObject:layer]; }
} }
[CATransaction commit]; //update layers
self.scrollView.layer.sublayers = visibleLayers; //log
NSLog(@"displayed: %i/%i recycled: %i",
[visibleLayers count], DEPTH*HEIGHT*WIDTH, recycled);
}@end
圖層性能
要更快性能，也要作對正確的事情。 ——Stephen R. Covey
本例中，咱們只有圖層對象這一種類型，可是UIKit有時候用一個標識符字符串來區分存儲在不一樣對象池中的不一樣的可回收對象類型。
你可能注意到當設置圖層屬性時咱們用了一個CATransaction來抑制動畫效果。在以前並不須要這樣作，由於在顯示以前咱們給全部圖層設置一次屬性。可是既然圖層正在被回收，禁止隱式動畫就有必要了，否則當屬性值改變時，圖層的隱式動畫就會被觸發。
Core Graphics繪製
當排除掉對屏幕顯示沒有任何貢獻的圖層或者視圖以後，長遠看來，你可能仍然須要減小圖層的數量。例如，若是你正在使用多個UILabel或者UIImageView實例去顯示固定內容，你能夠把他們所有替換成一個單獨的視圖，而後用-drawRect:方法繪製出那些複雜的視圖層級。
這個提議看上去並不合理由於你們都知道軟件繪製行爲要比GPU合成要慢並且還須要更多的內存空間，可是在由於圖層數量而使得性能受限的狀況下，軟件繪製極可能提升性能呢，由於它避免了圖層分配和操做問題。
你能夠本身實驗一下這個狀況，它包含了性能和柵格化的權衡，可是意味着你能夠從圖層樹上去掉子圖層（用shouldRasterize，與徹底遮擋圖層相反）。
-renderInContext: 方法
用Core Graphics去繪製一個靜態佈局有時候會比用層級的UIView實例來得快，可是使用UIView實例要簡單得多並且比用手寫代碼寫出相同效果要可靠得多，更邊說Interface Builder來得直接明瞭。爲了性能而捨棄這些便利實在是不該該。
幸虧，你沒必要這樣，若是大量的視圖或者圖層真的關聯到了屏幕上將會是一個大問題。沒有與圖層樹相關聯的圖層不會被送到渲染引擎，也沒有性能問題（在他們被建立和配置以後）。
使用CALayer的-renderInContext:方法，你能夠將圖層及其子圖層快照進一個Core Graphics上下文而後獲得一個圖片，它能夠直接顯示在UIImageView中，或者做爲另外一個圖層的contents。不一樣於shouldRasterize —— 要求圖層與圖層樹相關聯 —— ，這個方法沒有持續的性能消耗。
當圖層內容改變時，刷新這張圖片的機會取決於你（不一樣於shouldRasterize，它自動地處理緩存和緩存驗證），可是一旦圖片被生成，相比於讓Core Animation處理一個複雜的圖層樹，你節省了至關客觀的性能。
總結
本章學習了使用Core Animation圖層可能遇到的性能瓶頸，並討論瞭如何避免或減少壓力。你學習瞭如何管理包含上千虛擬圖層的場景（事實上只建立了幾百個）。同時也學習了一些有用的技巧，選擇性地選取光柵化或者繪製圖層內容在合適的時候從新分配給CPU和GPU。這些就是咱們要講的關於Core Animation的所有了（至少能夠等到蘋果發明什麼新的玩意兒）。
- 1. [iOS Animation]-CALayer 圖層性能
- 2. [iOS Animation]-CALayer 圖層性能一
- 3. [iOS Animation]-CALayer 圖層樹 二
- 4. iOS 圖形性能優化
- 5. iOS 網絡優化：iOS 14 網絡層性能和安全性
- 6. iOS底層原理之性能優化
- 7. [iOS Animation]-CALayer 圖層幾何學二
- 8. [iOS Animation]CALayer-圖層時間 二
- 9. iOS開發 專用圖層（二）CATransformLayer
- 10. iOS Core Animation Advanced Techniques(七)：高效繪圖、圖像IO以及圖層性能
- 更多相關文章...
- • 網站主機 性能 - 網站主機教程
- • ionic 背景層 - ionic 教程
- • JDK13 GA發佈：5大特性解讀
- • RxJava操作符（二）Transforming Observables
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. [iOS Animation]-CALayer 圖層性能
- 2. [iOS Animation]-CALayer 圖層性能一
- 3. [iOS Animation]-CALayer 圖層樹 二
- 4. iOS 圖形性能優化
- 5. iOS 網絡優化：iOS 14 網絡層性能和安全性
- 6. iOS底層原理之性能優化
- 7. [iOS Animation]-CALayer 圖層幾何學二
- 8. [iOS Animation]CALayer-圖層時間 二
- 9. iOS開發 專用圖層（二）CATransformLayer
- 10. iOS Core Animation Advanced Techniques(七)：高效繪圖、圖像IO以及圖層性能