iOS進階--UIView的繪製 前言 文末推薦

前言

如果要研究OpenGL ES相關和 GPU 相關，這篇文章很具有參考的入門價值.

理解 UIView 的繪製, UIView 是如何顯示到 Screen 上的?

首先要從Runloop開始說,iOS 的MainRunloop 是一個60fps 的回調,也就是說16.7ms(毫秒)會繪製一次屏幕,這個時間段內要完成:

• view的緩衝區創建
• view內容的繪製(如果重寫了 drawRect)

這些 CPU的工作.

然後將這個緩衝區交給GPU渲染, 這個過程又包含:

• 多個view的拼接(compositing)
• 紋理的渲染(Texture)等.

最終現實在屏幕上.因此,如果在16.7ms 內完不成這些操作, eg: CPU做了太多的工作, 或者view層次過於多,圖片過於大,導致GPU壓力太大,就會導致"卡"的現象,也就是 丟幀,掉幀.

蘋果官方給出的最佳幀率是:60fps(60Hz),也就是一幀不丟, 當然這是理想中的絕佳體驗.

這個60fps該怎麼理解呢？

一般來說如果幀率達到 60+fps(fps >= 60幀以上,如果幀率fps > 50,人眼就基本感覺不到卡頓了,因此,如果你能讓你的 iOS 程序穩定保持在60fps已經很不錯了, 註釋,是"穩定"在60fps,而不是, 10fps,40fps,20fps這樣的跳動,如果幀頻不穩就會有卡的感覺,60fps真的很難達到, 尤其是在 iPhone 4/4s等 32bit 位機上,不過現在蘋果已經全面放棄32位,支持最低64位會好很多.

fps 代表的是刷新頻率,單位赫茲Hz,因爲電子工程中考慮到能耗和視覺以及其它方面,60Hz是一個比較理想的刷新頻率,所以家用電器也經常會出現60Hz的字樣. 視頻中幀率FPS >= 25 纔不會人眼察覺有卡頓,因爲視頻中視頻模糊視頻中的i p b幀能夠給予前後幀一些需要的像素信息方便GPU的離屏渲染,GPU的索引可以節省很多性能.

總的來說, UIView從繪製到Render的過程有如下幾步：

• 每一個UIView都有一個layer
• 每一個layer都有個content,這個content指向的是一塊緩存,叫做backing store.

UIView的繪製和渲染是兩個過程:

• 當UIView被繪製時,CPU執行drawRect，通過context將數據寫入backing store

• 當backing store寫完後，通過render server交給GPU去渲染，將backing store中的bitmap數據顯示在屏幕上.

上面提到的從CPU到GPU的過程可用下圖表示:

下面具體來討論下這個過程

• CPU bound:

假設我們創建一個 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];

這個時候不會發生任何操作, 由於 UILabel 重寫了drawRect方法,因此,這個 View會被 marked as "dirty":

類似這個樣子:

然後一個新的Runloop到來，上面說道在這個Runloop中需要將界面渲染上去，對於UIKit的渲染，Apple用的是它的Core Animation。 做法是在Runloop開始的時候調用：

[CATransaction begin]

在Runloop結束的時候調用

[CATransaction commit]

在begin和commit之間做的事情是將view增加到view hierarchy中，這個時候也不會發生任何繪製的操作。 當[CATransaction commit]執行完後，CPU開始繪製這個view:

首先CPU會爲layer分配一塊內存用來繪製bitmap，叫做backing store
創建指向這塊bitmap緩衝區的指針，叫做CGContextRef
通過Core Graphic的api，也叫Quartz2D，繪製bitmap
將layer的content指向生成的bitmap
清空dirty flag標記
這樣CPU的繪製基本上就完成了.
通過time profiler可以完整的看到個過程：

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:]

假如某個時刻修改了label的text:

label.text = @"hello world";

由於內容變了,layer的content的bitmap的尺寸也要變化，因此這個時候當新的Runloop到來時，CPU要爲layer重新創建一個backing store，重新繪製bitmap.
CPU這一塊最耗時的地方往往在Core Graphic的繪製上，關於Core Graphic的性能優化是另一個話題了，又會牽扯到很多東西，就不在這裏討論了.

GPU bound：

CPU完成了它的任務：將view變成了bitmap，然後就是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大致的工作模式如下：

整個過程也就是一件事：

CPU將準備好的bitmap放到RAM裏，GPU去搬這快內存到VRAM中處理。 而這個過程GPU所能承受的極限大概在16.7ms完成一幀的處理，所以最開始提到的60fps其實就是GPU能處理的最高頻率.
因此，GPU的挑戰有兩個：

• 將數據從RAM搬到VRAM中
• 將Texture渲染到屏幕上

這兩個中瓶頸基本在第二點上。渲染Texture基本要處理這麼幾個問題：

• Compositing:

Compositing是指將多個紋理拼到一起的過程，對應UIKit，是指處理多個view合到一起的情況，如:

[self.view addsubview : subview]。

如果view之間沒有疊加，那麼GPU只需要做普通渲染即可.
如果多個view之間有疊加部分，GPU需要做blending.

加入兩個view大小相同，一個疊加在另一個上面，那麼計算公式如下：

R = S+D*(1-Sa)

R: 爲最終的像素值
S: 代表 上面的Texture（Top Texture）
D: 代表下面的Texture(lower Texture)

其中S,D都已經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）。

基本上每個像素點都需要這麼計算一次。

因此，view的層級很複雜，或者view都是半透明的（alpha值不爲1）都會帶來GPU額外的計算工作。

• Size

這個問題，主要是處理image帶來的，假如內存裏有一張400x400的圖片，要放到100x100的imageview裏，如果不做任何處理，直接丟進去，問題就大了，這意味着，GPU需要對大圖進行縮放到小的區域顯示，需要做像素點的sampling，這種smapling的代價很高，又需要兼顧pixel alignment。 計算量會飆升。

• Offscreen Rendering And Mask

如果我們對layer做這樣的操作：

label.layer.cornerRadius = 5.0f;
label.layer.masksToBounds = YES;

會產生offscreen rendering,它帶來的最大的問題是，當渲染這樣的layer的時候，需要額外開闢內存，繪製好radius，mask，然後再將繪製好的bitmap重新賦值給layer。
因此繼續性能的考慮，Quartz提供了優化的api：

label.layer.cornerRadius = 5.0f;
label.layer.masksToBounds = YES;
label.layer.shouldRasterize = YES;
label.layer.rasterizationScale = label.layer.contentsScale;

簡單的說，這是一種cache機制。
同樣GPU的性能也可以通過instrument去衡量：

紅色代表GPU需要做額外的工作來渲染View，綠色代表GPU無需做額外的工作來處理bitmap。

全文完

文末推薦

• 更多：iOS面試題大全-（附答案）
• 更多：《BAT面試答案文集.PDF》，獲取可加iOS技術交流圈：937 194 184。

收錄：原文地址