在第一和第二部分友酱，我們了解了Core Animation提供的關于繪制和動畫的一些特性搬泥。Core

Animation功能和性能都非常強大史煎，但如果你對背后的原理不清楚的話也會降低效率互订。讓它達到最優(yōu)的狀態(tài)是一門藝術。在這章中驹马，我們將探究一些動畫運行慢的原因，以及如何去修復這些問題除秀。

CPU VS GPU

關于繪圖和動畫有兩種處理的方式：CPU（中央處理器）和GPU（圖形處理器）糯累。在現(xiàn)代iOS設備中，都有可以運行不同軟件的可編程芯片册踩，但是由于歷史原因泳姐，我們可以說CPU所做的工作都在軟件層面，而GPU在硬件層面暂吉。

總的來說胖秒，我們可以用軟件（使用CPU）做任何事情，但是對于圖像處理慕的，通常用硬件會更快扒怖，因為GPU使用圖像對高度并行浮點運算做了優(yōu)化。由于某些原因业稼，我們想盡可能把屏幕渲染的工作交給硬件去處理盗痒。問題在于GPU并沒有無限制處理性能，而且一旦資源用完的話低散，性能就會開始下降了（即使CPU并沒有完全占用）

大多數(shù)動畫性能優(yōu)化都是關于智能利用GPU和CPU俯邓，使得它們都不會超出負荷。于是我們首先需要知道Core Animation是如何在這兩個處理器之間分配工作的熔号。

動畫的舞臺

Core

Animation處在iOS的核心地位：應用內和應用間都會用到它稽鞭。一個簡單的動畫可能同步顯示多個app的內容，例如當在iPad上多個程序之間使用手勢切換引镊，會使得多個程序同時顯示在屏幕上朦蕴。在一個特定的應用中用代碼實現(xiàn)它是沒有意義的篮条，因為在iOS中不可能實現(xiàn)這種效果（App都是被沙箱管理，不能訪問別的視圖）吩抓。

動畫和屏幕上組合的圖層實際上被一個單獨的進程管理涉茧，而不是你的應用程序。這個進程就是所謂的渲染服務疹娶。在iOS5和之前的版本是SpringBoard進程（同時管理著iOS的主屏）伴栓。在iOS6之后的版本中叫做BackBoard。

當運行一段動畫時候雨饺，這個過程會被四個分離的階段被打破：

布局- 這是準備你的視圖/圖層的層級關系钳垮，以及設置圖層屬性（位置，背景色额港，邊框等等）的階段饺窿。

顯示- 這是圖層的寄宿圖片被繪制的階段。繪制有可能涉及你的-drawRect:和-drawLayer:inContext:方法的調用路徑移斩。

準備- 這是Core Animation準備發(fā)送動畫數(shù)據(jù)到渲染服務的階段短荐。這同時也是Core Animation將要執(zhí)行一些別的事務例如解碼動畫過程中將要顯示的圖片的時間點。

提交- 這是最后的階段叹哭，Core Animation打包所有圖層和動畫屬性忍宋，然后通過IPC（內部處理通信）發(fā)送到渲染服務進行顯示。

但是這些僅僅階段僅僅發(fā)生在你的應用程序之內风罩，在動畫在屏幕上顯示之前仍然有更多的工作糠排。一旦打包的圖層和動畫到達渲染服務進程，他們會被反序列化來形成另一個叫做渲染樹的圖層樹（在第一章“圖層樹”中提到過）超升。使用這個樹狀結構入宦，渲染服務對動畫的每一幀做出如下工作：

對所有的圖層屬性計算中間值，設置OpenGL幾何形狀（紋理化的三角形）來執(zhí)行渲染

在屏幕上渲染可見的三角形

所以一共有六個階段室琢；最后兩個階段在動畫過程中不停地重復乾闰。前五個階段都在軟件層面處理（通過CPU），只有最后一個被GPU執(zhí)行盈滴。而且涯肩，你真正只能控制前兩個階段：布局和顯示。Core Animation框架在內部處理剩下的事務巢钓，你也控制不了它内地。

這并不是個問題零如，因為在布局和顯示階段，你可以決定哪些由CPU執(zhí)行秃流，哪些交給GPU去做喉悴。那么改如何判斷呢廷痘？

GPU相關的操作

GPU為一個具體的任務做了優(yōu)化：它用來采集圖片和形狀（三角形）殿较，運行變換，應用紋理和混合然后把它們輸送到屏幕上≡笊眩現(xiàn)代iOS設備上可編程的GPU在這些操作的執(zhí)行上又很大的靈活性，但是Core

Animation并沒有暴露出直接的接口破婆。除非你想繞開Core

Animation并編寫你自己的OpenGL著色器涮总，從根本上解決硬件加速的問題，那么剩下的所有都還是需要在CPU的軟件層面上完成荠割。

寬泛的說，大多數(shù)CALayer的屬性都是用GPU來繪制旺矾。比如如果你設置圖層背景或者邊框的顏色蔑鹦，那么這些可以通過著色的三角板實時繪制出來。如果對一個contents屬性設置一張圖片箕宙，然后裁剪它 - 它就會被紋理的三角形繪制出來嚎朽，而不需要軟件層面做任何繪制。

但是有一些事情會降低（基于GPU）圖層繪制柬帕，比如：

太多的幾何結構 -

這發(fā)生在需要太多的三角板來做變換哟忍，以應對處理器的柵格化的時候。現(xiàn)代iOS設備的圖形芯片可以處理幾百萬個三角板陷寝，所以在Core

Animation中幾何結構并不是GPU的瓶頸所在锅很。但由于圖層在顯示之前通過IPC發(fā)送到渲染服務器的時候（圖層實際上是由很多小物體組成的特別重量級的對象），太多的圖層就會引起CPU的瓶頸凤跑。這就限制了一次展示的圖層個數(shù)（見本章后續(xù)“CPU相關操作”）爆安。

重繪 - 主要由重疊的半透明圖層引起。GPU的填充比率（用顏色填充像素的比率）是有限的仔引，所以需要避免重繪（每一幀用相同的像素填充多次）的發(fā)生扔仓。在現(xiàn)代iOS設備上，GPU都會應對重繪咖耘；即使是iPhone 3GS都可以處理高達2.5的重繪比率翘簇，并任然保持60幀率的渲染（這意味著你可以繪制一個半的整屏的冗余信息，而不影響性能）儿倒，并且新設備可以處理更多版保。

離屏繪制 -

這發(fā)生在當不能直接在屏幕上繪制，并且必須繪制到離屏圖片的上下文中的時候夫否。離屏繪制發(fā)生在基于CPU或者是GPU的渲染找筝，或者是為離屏圖片分配額外內存，以及切換繪制上下文慷吊，這些都會降低GPU性能袖裕。對于特定圖層效果的使用，比如圓角溉瓶，圖層遮罩急鳄，陰影或者是圖層光柵化都會強制Core

Animation提前渲染圖層的離屏繪制谤民。但這不意味著你需要避免使用這些效果，只是要明白這會帶來性能的負面影響疾宏。

過大的圖片 - 如果視圖繪制超出GPU支持的2048x2048或者4096x4096尺寸的紋理张足，就必須要用CPU在圖層每次顯示之前對圖片預處理，同樣也會降低性能坎藐。

CPU相關的操作

大多數(shù)工作在Core Animation的CPU都發(fā)生在動畫開始之前为牍。這意味著它不會影響到幀率，所以很好岩馍，但是他會延遲動畫開始的時間碉咆，讓你的界面看起來會比較遲鈍。

以下CPU的操作都會延遲動畫的開始時間：

布局計算 - 如果你的視圖層級過于復雜蛀恩，當視圖呈現(xiàn)或者修改的時候疫铜，計算圖層幀率就會消耗一部分時間。特別是使用iOS6的自動布局機制尤為明顯双谆，它應該是比老版的自動調整邏輯加強了CPU的工作壳咕。

視圖懶加載 - iOS只會當視圖控制器的視圖顯示到屏幕上時才會加載它。這對內存使用和程序啟動時間很有好處顽馋，但是當呈現(xiàn)到屏幕上之前谓厘，按下按鈕導致的許多工作都會不能被及時響應。比如控制器從數(shù)據(jù)庫中獲取數(shù)據(jù)寸谜，或者視圖從一個nib文件中加載庞呕，或者涉及IO的圖片顯示（見后續(xù)“IO相關操作”），都會比CPU正常操作慢得多程帕。

Core Graphics繪制 - 如果對視圖實現(xiàn)了-drawRect:方法住练，或者CALayerDelegate的-drawLayer:inContext:方法，那么在繪制任何東西之前都會產生一個巨大的性能開銷愁拭。為了支持對圖層內容的任意繪制讲逛，Core Animation必須創(chuàng)建一個內存中等大小的寄宿圖片。然后一旦繪制結束之后岭埠，必須把圖片數(shù)據(jù)通過IPC傳到渲染服務器盏混。在此基礎上，Core Graphics繪制就會變得十分緩慢惜论，所以在一個對性能十分挑剔的場景下這樣做十分不好许赃。

解壓圖片 - PNG或者JPEG壓縮之后的圖片文件會比同質量的位圖小得多。但是在圖片繪制到屏幕上之前馆类，必須把它擴展成完整的未解壓的尺寸（通常等同于圖片寬 x 長 x 4個字節(jié)）混聊。為了節(jié)省內存，iOS通常直到真正繪制的時候才去解碼圖片（14章“圖片IO”會更詳細討論）乾巧。根據(jù)你加載圖片的方式句喜，第一次對圖層內容賦值的時候（直接或者間接使用UIImageView）或者把它繪制到Core Graphics中预愤，都需要對它解壓，這樣的話咳胃，對于一個較大的圖片植康，都會占用一定的時間。

當圖層被成功打包展懈，發(fā)送到渲染服務器之后销睁，CPU仍然要做如下工作：為了顯示屏幕上的圖層，Core

Animation必須對渲染樹種的每個可見圖層通過OpenGL循環(huán)轉換成紋理三角板存崖。由于GPU并不知曉Core

Animation圖層的任何結構冻记，所以必須要由CPU做這些事情。這里CPU涉及的工作和圖層個數(shù)成正比金句，所以如果在你的層級關系中有太多的圖層檩赢，就會導致CPU沒一幀的渲染吕嘀，即使這些事情不是你的應用程序可控的违寞。

IO相關操作

還有一項沒涉及的就是IO相關工作。上下文中的IO（輸入/輸出）指的是例如閃存或者網(wǎng)絡接口的硬件訪問偶房。一些動畫可能需要從山村（甚至是遠程URL）來加載趁曼。一個典型的例子就是兩個視圖控制器之間的過渡效果，這就需要從一個nib文件或者是它的內容中懶加載棕洋，或者一個旋轉的圖片挡闰，可能在內存中尺寸太大，需要動態(tài)滾動來加載掰盘。

IO比內存訪問更慢摄悯，所以如果動畫涉及到IO，就是一個大問題愧捕∩菅保總的來說，這就需要使用聰敏但尷尬的技術次绘，也就是多線程瘪阁，緩存和投機加載（提前加載當前不需要的資源，但是之后可能需要用到）邮偎。這些技術將會在第14章中討論管跺。

測量，而不是猜測

于是現(xiàn)在你知道有哪些點可能會影響動畫性能禾进，那該如何修復呢豁跑？好吧，其實不需要泻云。有很多種詭計來優(yōu)化動畫贩绕，但如果盲目使用的話火的，可能會造成更多性能上的問題，而不是修復淑倾。

如何正確的測量而不是猜測這點很重要馏鹤。根據(jù)性能相關的知識寫出代碼不同于倉促的優(yōu)化。前者很好娇哆，后者實際上就是在浪費時間湃累。

那該如何測量呢？第一步就是確保在真實環(huán)境下測試你的程序碍讨。

真機測試治力，而不是模擬器

當你開始做一些性能方面的工作時，一定要在真機上測試勃黍，而不是模擬器宵统。模擬器雖然是加快開發(fā)效率的一把利器，但它不能提供準確的真機性能參數(shù)覆获。

模擬器運行在你的Mac上马澈，然而Mac上的CPU往往比iOS設備要快。相反弄息，Mac上的GPU和iOS設備的完全不一樣痊班，模擬器不得已要在軟件層面（CPU）模擬設備的GPU，這意味著GPU相關的操作在模擬器上運行的更慢摹量，尤其是使用CAEAGLLayer來寫一些OpenGL的代碼時候涤伐。

這就是說在模擬器上的測試出的性能會高度失真。如果動畫在模擬器上運行流暢缨称，可能在真機上十分糟糕凝果。如果在模擬器上運行的很卡，也可能在真機上很平滑睦尽。你無法確定器净。

另一件重要的事情就是性能測試一定要用發(fā)布配置，而不是調試模式骂删。因為當用發(fā)布環(huán)境打包的時候掌动，編譯器會引入一系列提高性能的優(yōu)化，例如去掉調試符號或者移除并重新組織代碼宁玫。你也可以自己做到這些粗恢，例如在發(fā)布環(huán)境禁用NSLog語句。你只關心發(fā)布性能欧瘪，那才是你需要測試的點眷射。

最后，最好在你支持的設備中性能最差的設備上測試：如果基于iOS6開發(fā)，這意味著最好在iPhone

3GS或者iPad2上測試妖碉。如果可能的話涌庭，測試不同的設備和iOS版本，因為蘋果在不同的iOS版本和設備中做了一些改變欧宜，這也可能影響到一些性能坐榆。例如iPad3明顯要在動畫渲染上比iPad2慢很多，因為渲染4倍多的像素點（為了支持視網(wǎng)膜顯示）冗茸。

保持一致的幀率

為了做到動畫的平滑席镀，你需要以60FPS（幀每秒）的速度運行，以同步屏幕刷新速率夏漱。通過基于NSTimer或者CADisplayLink的動畫你可以降低到30FPS豪诲，而且效果還不錯，但是沒辦法通過Core Animation做到這點挂绰。如果不保持60FPS的速率屎篱，就可能隨機丟幀，影響到體驗葵蒂。

你可以在使用的過程中明顯感到有沒有丟幀交播，但沒辦法通過肉眼來得到具體的數(shù)據(jù)，也沒法知道你的做法有沒有真的提高性能刹勃。你需要的是一系列精確的數(shù)據(jù)堪侯。

你可以在程序中用CADisplayLink來測量幀率（就像11章“基于定時器的動畫”中那樣）嚎尤，然后在屏幕上顯示出來荔仁，但應用內的FPS顯示并不能夠完全真實測量出Core Animation性能，因為它僅僅測出應用內的幀率芽死。我們知道很多動畫都在應用之外發(fā)生（在渲染服務器進程中處理）乏梁，但同時應用內FPS計數(shù)的確可以對某些性能問題提供參考，一旦找出一個問題的地方关贵，你就需要得到更多精確詳細的數(shù)據(jù)來定位到問題所在遇骑。蘋果提供了一個強大的Instruments工具集來幫我們做到這些。

Instruments

Instruments是Xcode套件中沒有被充分利用的一個工具揖曾。很多iOS開發(fā)者從沒用過Instruments落萎，或者只是用Leaks工具檢測循環(huán)引用。實際上有很多Instruments工具炭剪，包括為動畫性能調優(yōu)的東西练链。

你可以通過在菜單中選擇Profile選項來打開Instruments（在這之前，記住要把目標設置成iOS設備奴拦，而不是模擬器）媒鼓。然后將會顯示出圖12.1（如果沒有看到所有選項，你可能設置成了模擬器選項）

圖12.1 Instruments工具選項窗口

就像之前提到的那樣，你應該始終將程序設置成發(fā)布選項绿鸣。幸運的是疚沐，配置文件默認就是發(fā)布選項，所以你不需要在分析的時候調整編譯策略潮模。

我們將討論如下幾個工具：

時間分析器- 用來測量被方法/函數(shù)打斷的CPU使用情況亮蛔。

Core Animation- 用來調試各種Core Animation性能問題。

OpenGL ES驅動- 用來調試GPU性能問題擎厢。這個工具在編寫Open GL代碼的時候很有用尔邓，但有時也用來處理Core Animation的工作。

Instruments的一個很棒的功能在于它可以創(chuàng)建我們自定義的工具集锉矢。除了你初始選擇的工具之外梯嗽，如果在Instruments中打開Library窗口，你可以拖拽別的工具到左側邊欄沽损。我們將創(chuàng)建以上我們提到的三個工具灯节，然后就可以并行使用了（見圖12.2）。

時間分析器

時間分析器工具用來檢測CPU的使用情況绵估。它可以告訴我們程序中的哪個方法正在消耗大量的CPU時間炎疆。使用大量的CPU并不一定是個問題 - 你可能期望動畫路徑對CPU非常依賴，因為動畫往往是iOS設備中最苛刻的任務国裳。

但是如果你有性能問題形入，查看CPU時間對于判斷性能是不是和CPU相關，以及定位到函數(shù)都很有幫助（見圖12.3）缝左。

時間分析器有一些選項來幫助我們定位到我們關心的的方法亿遂。可以使用左側的復選框來打開渺杉。其中最有用的是如下幾點：

通過線程分離 - 這可以通過執(zhí)行的線程進行分組蛇数。如果代碼被多線程分離的話，那么就可以判斷到底是哪個線程造成了問題是越。

隱藏系統(tǒng)庫 - 可以隱藏所有蘋果的框架代碼耳舅，來幫助我們尋找哪一段代碼造成了性能瓶頸。由于我們不能優(yōu)化框架方法倚评，所以這對定位到我們能實際修復的代碼很有用浦徊。

只顯示Obj-C代碼 - 隱藏除了Objective-C之外的所有代碼。大多數(shù)內部的Core Animation代碼都是用C或者C++函數(shù)天梧，所以這對我們集中精力到我們代碼中顯式調用的方法就很有用盔性。

CoreAnimation

Core Animation工具用來監(jiān)測Core Animation性能。它給我們提供了周期性的FPS腿倚，并且考慮到了發(fā)生在程序之外的動畫（見圖12.4）纯出。

Core Animation工具也提供了一系列復選框選項來幫助調試渲染瓶頸：

Color Blended Layers- 這個選項基于渲染程度對屏幕中的混合區(qū)域進行綠到紅的高亮（也就是多個半透明圖層的疊加）蚯妇。由于重繪的原因，混合對GPU性能會有影響暂筝，同時也是滑動或者動畫幀率下降的罪魁禍首之一箩言。

ColorHitsGreenandMissesRed- 當使用shouldRasterizep屬性的時候，耗時的圖層繪制會被緩存焕襟，然后當做一個簡單的扁平圖片呈現(xiàn)陨收。當緩存再生的時候這個選項就用紅色對柵格化圖層進行了高亮。如果緩存頻繁再生的話鸵赖，就意味著柵格化可能會有負面的性能影響了（更多關于使用shouldRasterize的細節(jié)見第15章“圖層性能”）务漩。

Color Copied Images- 有時候寄宿圖片的生成意味著Core Animation被強制生成一些圖片，然后發(fā)送到渲染服務器它褪，而不是簡單的指向原始指針饵骨。這個選項把這些圖片渲染成藍色。復制圖片對內存和CPU使用來說都是一項非常昂貴的操作茫打，所以應該盡可能的避免居触。

Color Immediately- 通常Core Animation Instruments以每毫秒10次的頻率更新圖層調試顏色。對某些效果來說老赤，這顯然太慢了轮洋。這個選項就可以用來設置每幀都更新（可能會影響到渲染性能，而且會導致幀率測量不準抬旺，所以不要一直都設置它）弊予。

Color Misaligned Images- 這里會高亮那些被縮放或者拉伸以及沒有正確對齊到像素邊界的圖片（也就是非整型坐標）。這些中的大多數(shù)通常都會導致圖片的不正晨疲縮放汉柒，如果把一張大圖當縮略圖顯示，或者不正確地模糊圖像床未，那么這個選項將會幫你識別出問題所在竭翠。

Color Offscreen-Rendered Yellow- 這里會把那些需要離屏渲染的圖層高亮成黃色振坚。這些圖層很可能需要用shadowPath或者shouldRasterize來優(yōu)化薇搁。

Color OpenGL Fast Path Blue- 這個選項會對任何直接使用OpenGL繪制的圖層進行高亮。如果僅僅使用UIKit或者Core Animation的API渡八，那么不會有任何效果啃洋。如果使用GLKView或者CAEAGLLayer，那如果不顯示藍色塊的話就意味著你正在強制CPU渲染額外的紋理屎鳍，而不是繪制到屏幕宏娄。

Flash Updated Regions- 這個選項會對重繪的內容高亮成黃色（也就是任何在軟件層面使用Core Graphics繪制的圖層）。這種繪圖的速度很慢逮壁。如果頻繁發(fā)生這種情況的話孵坚，這意味著有一個隱藏的bug或者說通過增加緩存或者使用替代方案會有提升性能的空間。

這些高亮圖層的選項同樣在iOS模擬器的調試菜單也可用（圖12.5）。我們之前說過用模擬器測試性能并不好卖宠，但如果你能通過這些高亮選項識別出性能問題出在什么地方的話巍杈，那么使用iOS模擬器來驗證問題是否解決也是比真機測試更有效的。

OpenGL ES驅動

OpenGL ES驅動工具可以幫你測量GPU的利用率扛伍，同樣也是一個很好的來判斷和GPU相關動畫性能的指示器筷畦。它同樣也提供了類似Core Animation那樣顯示FPS的工具（圖12.6）。

側欄的郵編是一系列有用的工具刺洒。其中和Core Animation性能最相關的是如下幾點：

Renderer Utilization- 如果這個值超過了~50%鳖宾，就意味著你的動畫可能對幀率有所限制，很可能因為離屏渲染或者是重繪導致的過度混合逆航。

Tiler Utilization- 如果這個值超過了~50%鼎文，就意味著你的動畫可能限制于幾何結構方面，也就是在屏幕上有太多的圖層占用了因俐。

一個可用的案例

現(xiàn)在我們已經(jīng)對Instruments中動畫性能工具非常熟悉了漂问，那么可以用它在現(xiàn)實中解決一些實際問題。

我們創(chuàng)建一個簡單的顯示模擬聯(lián)系人姓名和頭像列表的應用女揭。注意即使把頭像圖片存在應用本地蚤假，為了使應用看起來更真實，我們分別實時加載圖片吧兔，而不是用–imageNamed:預加載磷仰。同樣添加一些圖層陰影來使得列表顯示得更真實。清單12.1展示了最初版本的實現(xiàn)境蔼。

@interface ViewController ()

@property (nonatomic, strong) NSArray *items;

@property (nonatomic, weak) IBOutlet UITableView *tableView;

@implementationViewController

- (NSString*)randomName{

NSArray*first = @[@"Alice",@"Bob",@"Bill",@"Charles",@"Dan",@"Dave",@"Ethan",@"Frank"];NSArray*last = @[@"Appleseed",@"Bandicoot",@"Caravan",@"Dabble",@"Ernest",@"Fortune"];? ? NSUInteger index1 = (rand()/(double)INT_MAX) * [firstcount];?

? NSUInteger index2 = (rand()/(double)INT_MAX) * [lastcount];

return[NSStringstringWithFormat:@"%@%@", first[index1], last[index2]];

}

- (NSString*)randomAvatar{

NSArray*images = @[@"Snowman",@"Igloo",@"Cone",@"Spaceship",@"Anchor",@"Key"];? ? NSUIntegerindex= (rand()/(double)INT_MAX) * [imagescount];

returnimages[index];

}

- (void)viewDidLoad{??

[superviewDidLoad];//set up dataNSMutableArray*array = [NSMutableArrayarray];

for(inti =0; i <1000; i++) {? ? ? ?

//add name[arrayaddObject:@{@"name": [selfrandomName],@"image": [selfrandomAvatar]}];

? }? ?

self.items= array;

//register cell class[self.tableViewregisterClass:[UITableViewCellclass]forCellReuseIdentifier:@"Cell"];

}

- (NSInteger)tableView:(UITableView *)tableViewnumberOfRowsInSection:(NSInteger)section{

return[self.itemscount];

}

- (UITableViewCell *)tableView:(UITableView *)tableViewcellForRowAtIndexPath:(NSIndexPath*)indexPath{

//dequeue cellUITableViewCell *cell = [self.tableViewdequeueReusableCellWithIdentifier:@"Cell"forIndexPath:indexPath];

//load imageNSDictionary*item = self.items[indexPath.row];NSString*filePath = [[NSBundlemainBundle]pathForResource:item[@"image"]ofType:@"png"];

//set image and textcell.imageView.image= [UIImageimageWithContentsOfFile:filePath];? ? cell.textLabel.text= item[@"name"];//set image shadowcell.imageView.layer.shadowOffset=CGSizeMake(0,5);? ? cell.imageView.layer.shadowOpacity=0.75;??

cell.clipsToBounds=YES;//set text shadowcell.textLabel.backgroundColor= [UIColorclearColor];? ?

cell.textLabel.layer.shadowOffset=CGSizeMake(0,2);? ? cell.textLabel.layer.shadowOpacity=0.5;returncell;

}

當快速滑動的時候就會非吃钇剑卡（見圖12.7的FPS計數(shù)器）。

僅憑直覺箍土，我們猜測性能瓶頸應該在圖片加載逢享。我們實時從閃存加載圖片，而且沒有緩存吴藻，所以很可能是這個原因瞒爬。我們可以用一些很贊的代碼修復，然后使用GCD異步加載圖片沟堡，然后緩存侧但。。航罗。等一下禀横，在開始編碼之前，測試一下假設是否成立粥血。首先用我們的三個Instruments工具分析一下程序來定位問題柏锄。我們推測問題可能和圖片加載相關酿箭，所以用Time

Profiler工具來試試（圖12.8）

-tableView:cellForRowAtIndexPath:中的CPU時間總利用率只有~28%（也就是加載頭像圖片的地方），非常低趾娃。于是建議是CPU/IO并不是真正的限制因素七问。然后看看是不是GPU的問題：在OpenGL ES Driver工具中檢測GPU利用率（圖12.9）。

渲染服務利用率的值達到51%和63%茫舶⌒笛玻看起來GPU需要做很多工作來渲染聯(lián)系人列表。

為什么GPU利用率這么高呢饶氏？我們來用Core Animation調試工具選項來檢查屏幕讥耗。首先打開Color Blended Layers（圖12.10）。

屏幕中所有紅色的部分都意味著字符標簽視圖的高級別混合疹启，這很正常古程，因為我們把背景設置成了透明色來顯示陰影效果。這就解釋了為什么渲染利用率這么高了喊崖。

那么離屏繪制呢挣磨？打開Core Animation工具的Color Offscreen - Rendered Yellow選項（圖12.11）。

所有的表格單元內容都在離屏繪制荤懂。這一定是因為我們給圖片和標簽視圖添加的陰影效果茁裙。在代碼中禁用陰影，然后看下性能是否有提高（圖12.12）节仿。

問題解決了晤锥。干掉陰影之后，滑動很流暢廊宪。但是我們的聯(lián)系人列表看起來沒有之前好了矾瘾。那如何保持陰影效果而且不會影響性能呢？

好吧箭启，每一行的字符和頭像在每一幀刷新的時候并不需要變壕翩，所以看起來UITableViewCell的圖層非常適合做緩存。我們可以使用shouldRasterize來緩存圖層內容傅寡。這將會讓圖層離屏之后渲染一次然后把結果保存起來放妈，直到下次利用的時候去更新（見清單12.2）。

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath*)indexPath{

//dequeue cellUITableViewCell *cell = [self.tableViewdequeueReusableCellWithIdentifier:@"Cell"forIndexPath:indexPath];? ?

//set text shadowcell.textLabel.backgroundColor= [UIColorclearColor];? ? cell.textLabel.layer.shadowOffset=CGSizeMake(0,2);? ? cell.textLabel.layer.shadowOpacity=0.5;

//rasterizecell.layer.shouldRasterize=YES;? ? cell.layer.rasterizationScale= [UIScreenmainScreen].scale;

return cell;

}

我們仍然離屏繪制圖層內容赏僧，但是由于顯式地禁用了柵格化大猛，Core

Animation就對繪圖緩存了結果，于是對提高了性能淀零。我們可以驗證緩存是否有效，在Core Animation工具中點擊Color Hits

Green and Misses Red選項（圖12.13）膛壹。

結果和預期一致 - 大部分都是綠色驾中，只有當滑動到屏幕上的時候會閃爍成紅色唉堪。因此，現(xiàn)在幀率更加平滑了肩民。

所以我們最初的設想是錯的唠亚。圖片的加載并不是真正的瓶頸所在，而且試圖把它置于一個復雜的多線程加載和緩存的實現(xiàn)都將是徒勞持痰。所以在動手修復之前驗證問題所在是個很好的習慣灶搜！

總結

在這章中，我們學習了Core Animation是如何渲染工窍，以及我們可能出現(xiàn)的瓶頸所在割卖。你同樣學習了如何使用Instruments來檢測和修復性能問題