UIView是如何在Screen上顯示的？
也許要先從Runloop開始說，iOS的mainRunloop是一個(gè)60fps的回調(diào)，也就是說每16.7ms會繪制一次屏幕，這個(gè)時(shí)間段內(nèi)要完成view的緩沖區(qū)創(chuàng)建，view內(nèi)容的繪制（如果重寫了drawRect），這些CPU的工作。然后將這個(gè)緩沖區(qū)交給GPU渲染，這個(gè)過程又包括多個(gè)view的拼接(compositing)，紋理的渲染（Texture）等，最終顯示在屏幕上。因此，如果在16.7ms內(nèi)完不成這些操作，比如，CPU做了太多的工作，或者view層次過于多，圖片過于大，導(dǎo)致GPU壓力太大，就會導(dǎo)致“卡”的現(xiàn)象，也就是丟幀。
蘋果官方給出的最佳幀率是：60fps，也就是1幀不丟，當(dāng)然這是理想中的絕佳的體驗(yàn)。
這個(gè)60fps改怎么理解呢？一般來說如果幀率達(dá)到25+fps，人眼就基本感覺不到停頓了，因此，如果你能讓你ios程序穩(wěn)定的保持在30fps已經(jīng)很不錯了，注意，是“穩(wěn)定”在30fps，而不是，10fps，40fps，20fps這樣的跳動，如果幀頻不穩(wěn)就會有卡的感覺。60fps真的很難達(dá)到，尤其在iphone4，4s上。
總的來說，UIView從繪制到Render的過程有如下幾步：
每一個(gè)UIView都有一個(gè)layer，每一個(gè)layer都有個(gè)content，這個(gè)content指向的是一塊緩存，叫做backing store。
UIView的繪制和渲染是兩個(gè)過程，當(dāng)UIView被繪制時(shí)，CPU執(zhí)行drawRect，通過context將數(shù)據(jù)寫入backing store
當(dāng)backing store寫完后，通過render server交給GPU去渲染，將backing store中的bitmap數(shù)據(jù)顯示在屏幕上
上面提到的從CPU到GPU的過程可用下圖表示：
下面具體來討論下這個(gè)過程
CPU bound：
假設(shè)我們創(chuàng)建一個(gè)UILabel：
UILabel* label = [[UILabel alloc]initWithFrame:CGRectMake(10, 50, 300, 14)];
label.backgroundColor = [UIColor whiteColor];
label.font = [UIFont systemFontOfSize:14.0f];
label.text = @"test";
[self.view addSubview:label];
這個(gè)時(shí)候不會發(fā)生任何操作，由于UILabel重寫了drawRect，因此，這個(gè)view會被marked as “dirty”：
類似這個(gè)樣子：
)
然后一個(gè)新的Runloop到來，上面說道在這個(gè)Runloop中需要將界面渲染上去，對于UIKit的渲染，Apple用的是它的Core Animation。
做法是在Runloop開始的時(shí)候調(diào)用：
[CATransaction begin]
在Runloop結(jié)束的時(shí)候調(diào)用
[CATransaction commit]
在begin和commit之間做的事情是將view增加到view hierarchy中，這個(gè)時(shí)候也不會發(fā)生任何繪制的操作。
當(dāng)[CATransaction commit]執(zhí)行完后，CPU開始繪制這個(gè)view：
首先CPU會為layer分配一塊內(nèi)存用來繪制bitmap，叫做backing store
創(chuàng)建指向這塊bitmap緩沖區(qū)的指針，叫做CGContextRef
通過Core Graphic的api，也叫Quartz2D，繪制bitmap
將layer的content指向生成的bitmap
清空dirty flag標(biāo)記
這樣CPU的繪制基本上就完成了。
通過time profiler 可以完整的看到個(gè)過程：
Running Time Self Symbol Name
2.0ms 1.2% 0.0 +[CATransaction flush]
2.0ms 1.2% 0.0 CA::Transaction::commit()
2.0ms 1.2% 0.0 CA::Context::commit_transaction(CA::Transaction*)
1.0ms 0.6% 0.0 CA::Layer::layout_and_display_if_needed(CA::Transaction*)
1.0ms 0.6% 0.0 CA::Layer::display_if_needed(CA::Transaction*)
1.0ms 0.6% 0.0 -[CALayer display]
1.0ms 0.6% 0.0 CA::Layer::display()
1.0ms 0.6% 0.0 -[CALayer _display]
1.0ms 0.6% 0.0 CA::Layer::display_()
1.0ms 0.6% 0.0 CABackingStoreUpdate_
1.0ms 0.6% 0.0 backing_callback(CGContext*, void*)
1.0ms 0.6% 0.0 -[CALayer drawInContext:]
1.0ms 0.6% 0.0 -[UIView(CALayerDelegate) drawLayer:inContext:]
1.0ms 0.6% 0.0 -[UILabel drawRect:]
1.0ms 0.6% 0.0 -[UILabel drawTextInRect:]
假如某個(gè)時(shí)刻修改了label的text：
label.text = @"hello world";
由于內(nèi)容變了，layer的content的bitmap的尺寸也要變化，因此這個(gè)時(shí)候當(dāng)新的Runloop到來時(shí)，CPU要為layer重新創(chuàng)建一個(gè)backing store，重新繪制bitmap。
CPU這一塊最耗時(shí)的地方往往在Core Graphic的繪制上，關(guān)于Core Graphic的性能優(yōu)化是另一個(gè)話題了，又會牽扯到很多東西，就不在這里討論了。
GPU bound：
CPU完成了它的任務(wù)：將view變成了bitmap，然后就是GPU的工作了，GPU處理的單位是Texture。
基本上我們控制GPU都是通過OpenGL來完成的，但是從bitmap到Texture之間需要一座橋梁，Core Animation正好充當(dāng)了這個(gè)角色：
Core Animation對OpenGL的api有一層封裝，當(dāng)我們的要渲染的layer已經(jīng)有了bitmap content的時(shí)候，這個(gè)content一般來說是一個(gè)CGImageRef，CoreAnimation會創(chuàng)建一個(gè)OpenGL的Texture并將CGImageRef（bitmap）和這個(gè)Texture綁定，通過TextureID來標(biāo)識。
這個(gè)對應(yīng)關(guān)系建立起來之后，剩下的任務(wù)就是GPU如何將Texture渲染到屏幕上了。
GPU大致的工作模式如下：
整個(gè)過程也就是一件事：CPU將準(zhǔn)備好的bitmap放到RAM里，GPU去搬這快內(nèi)存到VRAM中處理。
而這個(gè)過程GPU所能承受的極限大概在16.7ms完成一幀的處理，所以最開始提到的60fps其實(shí)就是GPU能處理的最高頻率。
因此，GPU的挑戰(zhàn)有兩個(gè)：
將數(shù)據(jù)從RAM搬到VRAM中
將Texture渲染到屏幕上
這兩個(gè)中瓶頸基本在第二點(diǎn)上。渲染Texture基本要處理這么幾個(gè)問題：
Compositing：
Compositing是指將多個(gè)紋理拼到一起的過程，對應(yīng)UIKit，是指處理多個(gè)view合到一起的情況，如
[self.view addsubview : subview]。
如果view之間沒有疊加，那么GPU只需要做普通渲染即可。 如果多個(gè)view之間有疊加部分，GPU需要做blending。
加入兩個(gè)view大小相同，一個(gè)疊加在另一個(gè)上面，那么計(jì)算公式如下：
R = S+D*(1-Sa)
R: 為最終的像素值
S: 代表 上面的Texture（Top Texture）
D: 代表下面的Texture(lower Texture)
其中S,D都已經(jīng)pre-multiplied各自的alpha值。
Sa代表Texture的alpha值。
假如Top Texture（上層view）的alpha值為1，即不透明。那么它會遮住下層的Texture。即,R = S。是合理的。 假如Top Texture（上層view）的alpha值為0.5，S 為 (1,0,0)，乘以alpha后為(0.5,0,0）。D為(0，0，1)。 得到的R為（0.5，0，0.5）。
基本上每個(gè)像素點(diǎn)都需要這么計(jì)算一次。
因此，view的層級很復(fù)雜，或者view都是半透明的（alpha值不為1）都會帶來GPU額外的計(jì)算工作。
Size
這個(gè)問題，主要是處理image帶來的，假如內(nèi)存里有一張400x400的圖片，要放到100x100的imageview里，如果不做任何處理，直接丟進(jìn)去，問題就大了，這意味著，GPU需要對大圖進(jìn)行縮放到小的區(qū)域顯示，需要做像素點(diǎn)的sampling，這種smapling的代價(jià)很高，又需要兼顧pixel alignment。計(jì)算量會飆升。
Offscreen Rendering And Mask
如果我們對layer做這樣的操作：
label.layer.cornerRadius = 5.0f;
label.layer.masksToBounds = YES;
會產(chǎn)生offscreen rendering,它帶來的最大的問題是，當(dāng)渲染這樣的layer的時(shí)候，需要額外開辟內(nèi)存，繪制好radius，mask，然后再將繪制好的bitmap重新賦值給layer。
因此繼續(xù)性能的考慮，Quartz提供了優(yōu)化的api：
label.layer.cornerRadius = 5.0f;
label.layer.masksToBounds = YES;
label.layer.shouldRasterize = YES;
label.layer.rasterizationScale = label.layer.contentsScale;
簡單的說，這是一種cache機(jī)制。
同樣GPU的性能也可以通過instrument去衡量：
紅色代表GPU需要做額外的工作來渲染View，綠色代表GPU無需做額外的工作來處理bitmap。
