CPU和GPU的區(qū)別
CUP和GPU之所以大不相同习瑰，是由于其設(shè)計(jì)目的的不同，它們分別針對(duì)了兩種不同的應(yīng)用場(chǎng)景。CPU需要很強(qiáng)的通用性來(lái)處理各種不同的類型數(shù)據(jù)枣耀，同時(shí)又要邏輯判斷又會(huì)引入大量的分支跳轉(zhuǎn)和中斷處理在扰。這些都使得CPU的內(nèi)部結(jié)構(gòu)異常復(fù)雜缕减。而GPU面對(duì)的則是類型高度統(tǒng)一的、相互無(wú)依賴的大規(guī)模數(shù)據(jù)和不需要被打斷純凈的計(jì)算環(huán)境芒珠。
關(guān)于繪圖和動(dòng)畫有兩種處理方法：CPU（中央處理器）和GPU（圖形處理器）桥狡。在現(xiàn)代iOS設(shè)備中，都有可以運(yùn)行不同軟件的可編程芯片皱卓，但是由于歷史原因裹芝，我們可以說(shuō)CPU所做的工作都在軟件層面，而GPU在硬件層面娜汁。
總的來(lái)說(shuō)嫂易，我們可以用軟件（使用CPU）做任何事情，但是對(duì)于圖像處理掐禁，通常用硬件會(huì)更快怜械，因?yàn)镚PU使用圖像對(duì)高度并行浮點(diǎn)運(yùn)算做了優(yōu)化颅和。由于這些原因，我們想盡可能把屏幕渲染的工作交給硬件去處理缕允。問題在于GPU并沒有無(wú)限制處理性能融虽，而且一旦資源用完的話，性能就會(huì)開始下降了（即使CPU并沒有完全占用）
大多數(shù)動(dòng)畫性能優(yōu)化都是關(guān)于智能利用GPU和CPU灼芭，使得它們都不會(huì)超出負(fù)荷有额。于是我們首先需要知道Core Animation是如何在兩個(gè)處理器之間分配工作的。
動(dòng)畫的舞臺(tái)
Core Animation 處在iOS的核心地位：應(yīng)用內(nèi)和應(yīng)用間都會(huì)用到它彼绷。一個(gè)簡(jiǎn)單的動(dòng)畫可能同步顯示多個(gè)APP的內(nèi)容巍佑，例如當(dāng)在iPad上多個(gè)應(yīng)用程序之間使用手勢(shì)切換，會(huì)使得多個(gè)程序同時(shí)顯示在屏幕上寄悯。在一個(gè)特定的應(yīng)用中用代碼實(shí)現(xiàn)它是沒有意義的萤衰，因?yàn)樵趇OS中不可能實(shí)現(xiàn)這種效果 （APP都是被沙盒管理，不能訪問別的APP）猜旬。
動(dòng)畫和屏幕上組合的圖層實(shí)際上被一個(gè)單獨(dú)的進(jìn)程管理脆栋，而不是你的應(yīng)用程序。這個(gè)進(jìn)程就是所謂的 渲染服務(wù) 洒擦。
當(dāng)運(yùn)行一段動(dòng)畫的時(shí)候椿争，這個(gè)過程會(huì)被四個(gè)分離的階段
** 布局 ** 這是準(zhǔn)備你的視圖、圖層的層級(jí)關(guān)系熟嫩，以及設(shè)置圖層屬性 （位置秦踪、背景色、邊框等等）的階段掸茅。
** 顯示** 這是圖層的寄宿圖片被繪制的階段椅邓。繪制很有可能涉及你的
-drawRect:和-drawlayer: inCpntext:的調(diào)用路徑。** 準(zhǔn)備 ** 這是Core Animation準(zhǔn)備發(fā)送動(dòng)畫數(shù)據(jù)到渲染服務(wù)的階段昧狮。這同時(shí)也是Core Animation將要執(zhí)行一些別的事務(wù)景馁，例如解碼動(dòng)畫過程中將要顯示的圖片和時(shí)間點(diǎn)。
** 提交 ** 這是最后的階段逗鸣，Core Animation打包所有圖層和動(dòng)畫屬性合住，然后通過IPC （內(nèi)部處理通信）發(fā)到渲染服務(wù)進(jìn)行顯示。
但是這些階段僅僅發(fā)生在你的應(yīng)用程序之內(nèi)慕购，在動(dòng)畫在屏幕上顯示之前仍然有更多的工作聊疲。一旦打包的圖層和動(dòng)畫到達(dá)渲染服務(wù)進(jìn)程茬底，他們會(huì)被反序列化來(lái)形成另一個(gè)叫做渲染樹的圖層樹沪悲。使用這個(gè)樹狀結(jié)構(gòu)，渲染服務(wù)對(duì)動(dòng)畫的每一幀做出如下工作：
對(duì)所有的圖層屬性計(jì)算中間值阱表，設(shè)置OpenGL幾何形狀（紋理化的三角形）來(lái)執(zhí)行渲染
在屏幕上渲染可見的三角形
所以一共有六個(gè)階段殿如；最后兩個(gè)階段在動(dòng)畫過程中不停地重復(fù)贡珊。前五個(gè)階段都在軟件層面處理（通過CPU），只有最后一個(gè)被GPU執(zhí)行涉馁。而且门岔，你真正只能控制前兩個(gè)階段：布局和顯示。Core Animation框架在內(nèi)部處理剩下的事務(wù)烤送，你也控制不了它寒随。
這并不是個(gè)問題，因?yàn)樵诓季趾惋@示階段帮坚，你可以決定哪些由CPU執(zhí)行妻往，哪些交給GPU去做。那么改如何判斷呢试和？
GPU相關(guān)的操作
GPU為一個(gè)具體的任務(wù)做了優(yōu)化：它用來(lái)采集圖片和形狀（三角形）讯泣，運(yùn)行變換，應(yīng)用紋理和混合然后把它們輸送到屏幕上≡暮罚現(xiàn)代iOS設(shè)備上可編程的GPU在這些操作的執(zhí)行上又很大的靈活性好渠，但是Core Animation并沒有暴露出直接的接口。除非你想繞開Core Animation并編寫你自己的OpenGL著色器节视，從根本上解決硬件加速的問題拳锚，那么剩下的所有都還是需要在CPU的軟件層面上完成。
寬泛的說(shuō)寻行，大多數(shù) CALayer的屬性都是用GPU來(lái)繪制晌畅。比如如果你設(shè)置圖層背景或者邊框的顏色，那么這些可以通過著色的三角板實(shí)時(shí)繪制出來(lái)寡痰。如果對(duì)一個(gè)contents屬性設(shè)置一張圖片抗楔，然后裁剪它 - 它就會(huì)被紋理的三角形繪制出來(lái)，而不需要軟件層面做任何繪制拦坠。
但是有一些事情會(huì)降低（基于GPU）圖層繪制连躏，比如：
太多的幾何結(jié)構(gòu) - 這發(fā)生在需要太多的三角板來(lái)做變換，以應(yīng)對(duì)處理器的柵格化的時(shí)候≌瓯酰現(xiàn)代iOS設(shè)備的圖形芯片可以處理幾百萬(wàn)個(gè)三角板入热，所以在Core Animation中幾何結(jié)構(gòu)并不是GPU的瓶頸所在。但由于圖層在顯示之前通過IPC發(fā)送到渲染服務(wù)器的時(shí)候（圖層實(shí)際上是由很多小物體組成的特別重量級(jí)的對(duì)象）晓铆，太多的圖層就會(huì)引起CPU的瓶頸勺良。這就限制了一次展示的圖層個(gè)數(shù)。
重繪 - 主要由重疊的半透明圖層引起骄噪。GPU的填充比率（用顏色填充像素的比率）是有限的尚困，所以需要避免重繪（每一幀用相同的像素填充多次）的發(fā)生。在現(xiàn)代iOS設(shè)備上链蕊，GPU都會(huì)應(yīng)對(duì)重繪事甜；即使是iPhone 3GS都可以處理高達(dá)2.5的重繪比率谬泌，并仍然保持60幀率的渲染（這意味著你可以繪制一個(gè)半的整屏的冗余信息，而不影響性能）逻谦，并且新設(shè)備可以處理更多掌实。
離屏繪制 -GPU在當(dāng)前屏幕緩沖區(qū)以外新開辟一個(gè)緩沖區(qū)進(jìn)行渲染操作。 這發(fā)生在當(dāng)不能直接在屏幕上繪制邦马，并且必須繪制到離屏圖片的上下文中的時(shí)候贱鼻。離屏繪制發(fā)生在基于CPU或者是GPU的渲染，或者是為離屏圖片分配額外內(nèi)存滋将，以及切換繪制上下文忱嘹，這些都會(huì)降低GPU性能。對(duì)于特定圖層效果的使用耕渴，比如圓角拘悦，圖層遮罩，陰影或者是圖層光柵化都會(huì)強(qiáng)制Core Animation提前渲染圖層的離屏繪制橱脸。但這不意味著你需要避免使用這些效果础米，只是要明白這會(huì)帶來(lái)性能的負(fù)面影響。
過大的圖片 - 如果視圖繪制超出GPU支持的2048x2048或者4096x4096尺寸的紋理添诉，就必須要用CPU在圖層每次顯示之前對(duì)圖片預(yù)處理屁桑，同樣也會(huì)降低性能。
CPU相關(guān)的操作
大多數(shù)工作在Core Animation的CPU都發(fā)生在動(dòng)畫開始之前栏赴。這意味著它不會(huì)影響到幀率蘑斧，所以很好，但是他會(huì)延遲動(dòng)畫開始的時(shí)間须眷，讓你的界面看起來(lái)會(huì)比較遲鈍竖瘾。
以下CPU的操作都會(huì)延遲動(dòng)畫的開始時(shí)間：
布局計(jì)算 - 如果你的視圖層級(jí)過于復(fù)雜，當(dāng)視圖呈現(xiàn)或者修改的時(shí)候花颗，計(jì)算圖層幀率就會(huì)消耗一部分時(shí)間捕传。特別是使用iOS6的自動(dòng)布局機(jī)制尤為明顯，它應(yīng)該是比老版的自動(dòng)調(diào)整邏輯加強(qiáng)了CPU的工作扩劝。
視圖惰性加載 - iOS只會(huì)當(dāng)視圖控制器的視圖顯示到屏幕上時(shí)才會(huì)加載它庸论。這對(duì)內(nèi)存使用和程序啟動(dòng)時(shí)間很有好處，但是當(dāng)呈現(xiàn)到屏幕上之前棒呛，按下按鈕導(dǎo)致的許多工作都會(huì)不能被及時(shí)響應(yīng)笛质。比如控制器從數(shù)據(jù)庫(kù)中獲取數(shù)據(jù)韵洋，或者視圖從一個(gè)nib文件中加載朱盐，或者涉及IO的圖片顯示似嗤，都會(huì)比CPU正常操作慢得多柴我。
Core Graphics繪制 - 如果對(duì)視圖實(shí)現(xiàn)了-drawRect:方法鸦列，或者CALayerDelegate的-drawLayer:inContext:方法，那么在繪制任何東西之前都會(huì)產(chǎn)生一個(gè)巨大的性能開銷。為了支持對(duì)圖層內(nèi)容的任意繪制气筋，Core Animation必須創(chuàng)建一個(gè)內(nèi)存中等大小的寄宿圖片拆内。然后一旦繪制結(jié)束之后旋圆，必須把圖片數(shù)據(jù)通過IPC傳到渲染服務(wù)器。在此基礎(chǔ)上麸恍，Core Graphics繪制就會(huì)變得十分緩慢灵巧，所以在一個(gè)對(duì)性能十分挑剔的場(chǎng)景下這樣做十分不好。
解壓圖片 - PNG或者JPEG壓縮之后的圖片文件會(huì)比同質(zhì)量的位圖小得多抹沪。但是在圖片繪制到屏幕上之前刻肄，必須把它擴(kuò)展成完整的未壓縮的尺寸（通常等同于圖片寬 x 長(zhǎng) x 4個(gè)字節(jié)）。為了節(jié)省內(nèi)存融欧，iOS通常直到真正繪制的時(shí)候才去解碼圖片）敏弃。根據(jù)你加載圖片的方式，第一次對(duì)圖層內(nèi)容賦值的時(shí)候（直接或者間接使用UIImageView）或者把它繪制到Core Graphics中噪馏，都需要對(duì)它解壓麦到，這樣的話，對(duì)于一個(gè)較大的圖片欠肾，都會(huì)占用一定的時(shí)間瓶颠。
當(dāng)圖層被成功打包，發(fā)送到渲染服務(wù)器之后刺桃，CPU仍然要做如下操作：為了顯示屏幕上的圖層粹淋，Core Animation必須對(duì)渲染樹中的每個(gè)可見圖層通過OpenGL循環(huán)轉(zhuǎn)換成紋理三角板。由于GPU并不知曉Core Animation圖層的任何結(jié)構(gòu)瑟慈，所以必須要由CPU做這些事情桃移。這里CPU涉及的工作和圖層個(gè)數(shù)成正比，所以如果在你的層級(jí)關(guān)系中有太多的圖層葛碧，就會(huì)導(dǎo)致CPU每一幀的渲染谴轮，即使這些事情不是你的應(yīng)用程序可控的。
IO相關(guān)操作
還有一項(xiàng)涉及的就是IO相關(guān)工作吹埠。上下文中的IO（輸入/輸出）指的是例如閃存或者是網(wǎng)絡(luò)接口的硬件訪問第步。一些動(dòng)畫可能需要從閃存（甚至是遠(yuǎn)程URL）來(lái)加載。一個(gè)典型的例子就是兩個(gè)視圖控制器的過渡效果缘琅，這就需要從一個(gè)nib文件或者是它的內(nèi)容中懶加載粘都，或者一個(gè)旋轉(zhuǎn)的圖片，可能在內(nèi)存中尺寸太大刷袍，需要?jiǎng)討B(tài)滾動(dòng)來(lái)加載翩隧。
IO比內(nèi)存訪問更慢，所以如果動(dòng)畫涉及到IO呻纹，就是一個(gè)大問題堆生∽ú總的來(lái)說(shuō)，這就需要使用聰敏但尷尬的技術(shù)淑仆，也就是多線程涝婉，緩存和投機(jī)加載（提前加載當(dāng)前不需要的資源，但是之后可能需要用到）蔗怠。
測(cè)量墩弯，而不是猜測(cè)
于是現(xiàn)在你知道有哪些點(diǎn)可能會(huì)影響動(dòng)畫性能，那該如何修復(fù)呢寞射？好吧渔工，其實(shí)不需要。有很多種詭計(jì)來(lái)優(yōu)化動(dòng)畫桥温，但如果盲目使用的話引矩，可能會(huì)造成更多性能上的問題，而不是修復(fù)侵浸。
如何正確的測(cè)量而不是猜測(cè)這點(diǎn)很重要旺韭。根據(jù)性能相關(guān)的知識(shí)寫出代碼不同于倉(cāng)促的優(yōu)化。前者很好通惫，后者實(shí)際上就是在浪費(fèi)時(shí)間茂翔。
那該如何測(cè)量呢？第一步就是確保在真實(shí)環(huán)境下測(cè)試你的程序履腋。
真機(jī)測(cè)試珊燎，而不是模擬器
一定要真機(jī)測(cè)試！
一定要真機(jī)測(cè)試!!
一定要真機(jī)測(cè)試!!!
模擬器運(yùn)行在你的Mac上遵湖，然而Mac上的CPU往往比iOS設(shè)備要快悔政。相反，Mac上的GPU和iOS設(shè)備的完全不一樣延旧，模擬器不得已要在軟件層面（CPU）模擬設(shè)備的GPU谋国，這意味著GPU相關(guān)的操作在模擬器上運(yùn)行的更慢，尤其是使用CAEAGLLayer來(lái)寫一些OpenGL的代碼時(shí)候迁沫。
這就是說(shuō)在模擬器上的測(cè)試出的性能會(huì)高度失真芦瘾。如果動(dòng)畫在模擬器上運(yùn)行流暢，可能在真機(jī)上十分糟糕集畅。如果在模擬器上運(yùn)行的很卡近弟，也可能在真機(jī)上很平滑。你無(wú)法確定挺智。
另一件重要的事情就是性能測(cè)試一定要用發(fā)布配置祷愉，而不是調(diào)試模式。因?yàn)楫?dāng)用發(fā)布環(huán)境打包的時(shí)候，編譯器會(huì)引入一系列提高性能的優(yōu)化二鳄，例如去掉調(diào)試符號(hào)或者移除并重新組織代碼赴涵。你也可以自己做到這些，例如在發(fā)布環(huán)境禁用NSLog語(yǔ)句订讼。你只關(guān)心發(fā)布性能髓窜，那才是你需要測(cè)試的點(diǎn)。
最后躯嫉，最好在你支持的設(shè)備中性能最差的設(shè)備上測(cè)試：如果基于iOS6開發(fā)纱烘，這意味著最好在iPhone 3GS或者iPad2上測(cè)試杨拐。如果可能的話祈餐，測(cè)試不同的設(shè)備和iOS版本，因?yàn)樘O果在不同的iOS版本和設(shè)備中做了一些改變哄陶，這也可能影響到一些性能帆阳。例如iPad3明顯要在動(dòng)畫渲染上比iPad2慢很多，因?yàn)殇秩?倍多的像素點(diǎn)（為了支持視網(wǎng)膜顯示）屋吨。
保持一致的幀率
為了做到動(dòng)畫的平滑蜒谤，你需要以60FPS（幀每秒）的速度運(yùn)行，以同步屏幕刷新速率至扰。通過基于NSTimer
或者CADisplayLink的動(dòng)畫你可以降低到30FPS鳍徽，而且效果還不錯(cuò)，但是沒辦法通過Core Animation做到這點(diǎn)敢课。如果不保持60FPS的速率阶祭，就可能隨機(jī)丟幀，影響到體驗(yàn)直秆。
你可以在使用的過程中明顯感到有沒有丟幀濒募，但沒辦法通過肉眼來(lái)得到具體的數(shù)據(jù)，也沒法知道你的做法有沒有真的提高性能圾结。你需要的是一系列精確的數(shù)據(jù)瑰剃。
你可以在程序中用CADisplayLink來(lái)測(cè)量幀率，然后在屏幕上顯示出來(lái)筝野，但應(yīng)用內(nèi)的FPS顯示并不能夠完全真實(shí)測(cè)量出Core Animation性能晌姚，因?yàn)樗鼉H僅測(cè)出應(yīng)用內(nèi)的幀率。我們知道很多動(dòng)畫都在應(yīng)用之外發(fā)生（在渲染服務(wù)器進(jìn)程中處理）歇竟，但同時(shí)應(yīng)用內(nèi)FPS計(jì)數(shù)的確可以對(duì)某些性能問題提供參考挥唠，一旦找出一個(gè)問題的地方，你就需要得到更多精確詳細(xì)的數(shù)據(jù)來(lái)定位到問題所在途蒋。蘋果提供了一個(gè)強(qiáng)大的Instruments工具集來(lái)幫我們做到這些猛遍。
Instruments
Instruments是Xcode套件中沒有被充分利用的一個(gè)工具。很多iOS開發(fā)者從沒用過Instruments，或者只是用Leaks工具檢測(cè)循環(huán)引用懊烤。實(shí)際上有很多Instruments工具梯醒，包括為動(dòng)畫性能調(diào)優(yōu)的東西。
你可以通過在菜單中選擇Profile選項(xiàng)來(lái)打開Instruments（在這之前腌紧，記住要把目標(biāo)設(shè)置成iOS設(shè)備茸习，而不是模擬器）。然后將會(huì)顯示出圖1（如果沒有看到所有選項(xiàng)壁肋，你可能設(shè)置成了模擬器選項(xiàng)）
圖1 Instuments工具選項(xiàng)窗口
就像之前提到的那樣号胚，你應(yīng)該始終將程序設(shè)置成發(fā)布選項(xiàng)。幸運(yùn)的是浸遗，配置文件默認(rèn)就是發(fā)布選項(xiàng)猫胁，所以你不需要在分析的時(shí)候調(diào)整編譯策略。
我們將討論如下幾個(gè)工具：
** 時(shí)間分析器 **- 用來(lái)測(cè)量被方法/函數(shù)打斷的CPU使用情況跛锌。
** Core Animation** - 用來(lái)調(diào)試各種Core Animation性能問題弃秆。
** OpenGL ES驅(qū)動(dòng) **- 用來(lái)調(diào)試GPU性能問題。這個(gè)工具在編寫Open GL代碼的時(shí)候很有用髓帽，但有時(shí)也用來(lái)處理Core Animation的工作菠赚。
Instruments的一個(gè)很棒的功能在于它可以創(chuàng)建我們自定義的工具集。除了你初始選擇的工具之外郑藏，如果在Instruments中打開Library窗口衡查，你可以拖拽別的工具到左側(cè)邊欄。我們將創(chuàng)建以上我們提到的三個(gè)工具必盖，然后就可以并行使用了
圖2 添加額外的工具到Instrumennts側(cè)邊欄
時(shí)間分析器
時(shí)間分析器工具用來(lái)檢測(cè)CPU的使用情況拌牲。它可以告訴我們程序中的哪個(gè)方法正在消耗大量的CPU時(shí)間。使用大量的CPU并不一定是個(gè)問題 - 你可能期望動(dòng)畫路徑對(duì)CPU非常依賴筑悴，因?yàn)閯?dòng)畫往往是iOS設(shè)備中最苛刻的任務(wù)们拙。
但是如果你有性能問題，查看CPU時(shí)間對(duì)于判斷性能是不是和CPU相關(guān)阁吝，以及定位到函數(shù)都很有幫助（見圖3）砚婆。
時(shí)間分析器有一些選項(xiàng)來(lái)幫助我們定位到我們關(guān)心的的方法⊥挥拢可以使用左側(cè)的復(fù)選框來(lái)打開装盯。其中最有用的是如下幾點(diǎn)：
通過線程分離 - 這可以通過執(zhí)行的線程進(jìn)行分組。如果代碼被多線程分離的話甲馋，那么就可以判斷到底是哪個(gè)線程造成了問題埂奈。
隱藏系統(tǒng)庫(kù) - 可以隱藏所有蘋果的框架代碼，來(lái)幫助我們尋找哪一段代碼造成了性能瓶頸定躏。由于我們不能優(yōu)化框架方法账磺，所以這對(duì)定位到我們能實(shí)際修復(fù)的代碼很有用芹敌。
反轉(zhuǎn)響應(yīng)樹 - 把調(diào)用層級(jí)最深的方法顯示在最上面，更容易找到最耗時(shí)的操作垮抗。
Core Animation
Core Animation工具用來(lái)監(jiān)測(cè)Core Animation性能氏捞。它給我們提供了周期性的FPS，并且考慮到了發(fā)生在程序之外的動(dòng)畫（見圖4）
圖4 使用可視化調(diào)試選項(xiàng)的Core Animation 工具
Core Animation工具也提供了一系列復(fù)選框選項(xiàng)來(lái)幫助調(diào)試渲染瓶頸：
Color Blended Layer -這個(gè)選項(xiàng)基于渲染程度對(duì)屏幕中的混合區(qū)域進(jìn)行綠到紅的高亮（也就是多個(gè)半透明圖層的疊加）冒版。由于重繪原因液茎，混合對(duì)GPU性能會(huì)有影響，同時(shí)也是滑動(dòng)或者是動(dòng)畫幀率下降的罪魁禍?zhǔn)字弧?/p>
ColorHitsGreenandMissesRed -當(dāng)使用
shouldRasterizep屬性的時(shí)候辞嗡，耗時(shí)的圖層繪制會(huì)被緩存捆等，然后當(dāng)做一個(gè)簡(jiǎn)單的扁平圖片呈現(xiàn)。當(dāng)緩存再生的時(shí)候這個(gè)選項(xiàng)就用紅色柵格化圖層進(jìn)行了高亮续室。如果緩存頻繁再生栋烤，就意味著柵格化可能會(huì)有負(fù)面的性能影響了。Color Copied Images -有時(shí)候寄宿圖片的生成意味著Core Animation被強(qiáng)制生成一些圖片猎贴，然后發(fā)送到渲染服務(wù)器班缎，而不是簡(jiǎn)單的指向原始指針蝴光。這些選項(xiàng)把這些圖片渲染成藍(lán)色她渴。復(fù)制圖片對(duì)內(nèi)存和CPU來(lái)說(shuō)是一項(xiàng)非常昂貴的操作，所以應(yīng)該盡可能的避免蔑祟。
Color Immediately -通常Core Animation Instuments 以每毫秒10次的頻率更新圖層調(diào)試顏色趁耗。對(duì)某些效果來(lái)說(shuō)，這顯然太慢啦疆虚。這個(gè)選項(xiàng)就可以用來(lái)設(shè)置每幀都更新（可能會(huì)影響到渲染性能苛败，而且會(huì)導(dǎo)致幀率測(cè)試不準(zhǔn)，所以不要一直都設(shè)置它）径簿。
Color Misaligned Images -這里會(huì)高亮那些被縮放或者拉伸以及沒有正確對(duì)齊到像素邊緣的圖片（也就是非整齊坐標(biāo)）罢屈。這些中的大多數(shù)通常都會(huì)導(dǎo)致圖片的不正常縮放篇亭，如果把一張大圖當(dāng)縮略圖顯示缠捌，或者是不正確的模糊圖像，那么這個(gè)選項(xiàng)會(huì)幫你識(shí)別出問題所在译蒂。
Color Offscreen-Rendered Yellow -這里會(huì)把那些需要離屏渲染的圖層高亮成黃色曼月。這些圖層很可能需要用
shadowPath或者shouldRasterize來(lái)優(yōu)化。Color OpenGL Fast Path Blue -這個(gè)選項(xiàng)會(huì)對(duì)任何直接使用OpenGL繪制的圖層進(jìn)行高亮柔昼。如果僅僅使用UIKit或者Core Animation的API哑芹，那么不會(huì)有任何效果。如果使用｀GLKView｀或者｀CAEAGLLayer ｀捕透，那如果不顯示藍(lán)色塊的話就意味著你正在強(qiáng)制CPU渲染額外的紋理聪姿，而不是繪制到屏幕碴萧。
Flash Updated Regions - 這個(gè)選項(xiàng)會(huì)對(duì)重繪的內(nèi)容高亮成黃色（也就是任何在軟件層面使用Core Graphics繪制的圖層）。這種繪圖的速度很慢末购。如果頻繁發(fā)生這種情況的話勿决，這意味著有一個(gè)隱藏的bug或者說(shuō)通過增加緩存或者使用替代方案會(huì)有提升性能的空間。
這些高亮圖層的選項(xiàng)同樣在iOS模擬器的調(diào)試菜單也可用（圖5）招盲。我們之前說(shuō)過用模擬器測(cè)試性能并不好低缩，但如果你能通過這些高亮選項(xiàng)識(shí)別出性能問題出在什么地方的話，那么使用iOS模擬器來(lái)驗(yàn)證問題是否解決也是比真機(jī)測(cè)試更有效的曹货。
圖5 iOS模擬器中Core Animation可視化調(diào)試選項(xiàng)
OpenGL ES驅(qū)動(dòng)
OpenGL ES驅(qū)動(dòng)工具可以幫你測(cè)量GPU的利用率咆繁，同樣也是一個(gè)很好的來(lái)判斷和GPU相關(guān)動(dòng)畫性能的指示器。它同樣也提供了類似Core Animation那樣顯示FPS的工具（圖6）顶籽。
圖6 OpenGL ES驅(qū)動(dòng)工具
側(cè)欄的右邊是一系列有用的工具玩般。其中和Core Animation性能最相關(guān)的是如下幾點(diǎn)：
Renderer Utilization - 如果這個(gè)值超過了~50%，就意味著你的動(dòng)畫可能對(duì)幀率有所限制礼饱，很可能因?yàn)殡x屏渲染或者是重繪導(dǎo)致的過度混合坏为。
Tiler Utilization - 如果這個(gè)值超過了~50%，就意味著你的動(dòng)畫可能限制于幾何結(jié)構(gòu)方面镊绪，也就是在屏幕上有太多的圖層占用了匀伏。
