W3Cschool
恭喜您成為首批注冊用戶
獲得88經(jīng)驗值獎勵
????關(guān)于繪圖和動畫有兩種處理的方式:CPU(中央處理器)和GPU(圖形處理器)。在現(xiàn)代iOS設(shè)備中,都有可以運(yùn)行不同軟件的可編程芯片,但是由于歷史原因,我們可以說CPU所做的工作都在軟件層面,而GPU在硬件層面。
????總的來說,我們可以用軟件(使用CPU)做任何事情,但是對于圖像處理,通常用硬件會更快,因為GPU使用圖像對高度并行浮點運(yùn)算做了優(yōu)化。由于某些原因,我們想盡可能把屏幕渲染的工作交給硬件去處理。問題在于GPU并沒有無限制處理性能,而且一旦資源用完的話,性能就會開始下降了(即使CPU并沒有完全占用)
????大多數(shù)動畫性能優(yōu)化都是關(guān)于智能利用GPU和CPU,使得它們都不會超出負(fù)荷。于是我們首先需要知道Core Animation是如何在這兩個處理器之間分配工作的。
????Core Animation處在iOS的核心地位:應(yīng)用內(nèi)和應(yīng)用間都會用到它。一個簡單的動畫可能同步顯示多個app的內(nèi)容,例如當(dāng)在iPad上多個程序之間使用手勢切換,會使得多個程序同時顯示在屏幕上。在一個特定的應(yīng)用中用代碼實現(xiàn)它是沒有意義的,因為在iOS中不可能實現(xiàn)這種效果(App都是被沙箱管理,不能訪問別的視圖)。
????動畫和屏幕上組合的圖層實際上被一個單獨(dú)的進(jìn)程管理,而不是你的應(yīng)用程序。這個進(jìn)程就是所謂的渲染服務(wù)。在iOS5和之前的版本是SpringBoard進(jìn)程(同時管理著iOS的主屏)。在iOS6之后的版本中叫做BackBoard
。
????當(dāng)運(yùn)行一段動畫時候,這個過程會被四個分離的階段被打破:
布局?- 這是準(zhǔn)備你的視圖/圖層的層級關(guān)系,以及設(shè)置圖層屬性(位置,背景色,邊框等等)的階段。
顯示?- 這是圖層的寄宿圖片被繪制的階段。繪制有可能涉及你的-drawRect:
和-drawLayer:inContext:
方法的調(diào)用路徑。
準(zhǔn)備?- 這是Core Animation準(zhǔn)備發(fā)送動畫數(shù)據(jù)到渲染服務(wù)的階段。這同時也是Core Animation將要執(zhí)行一些別的事務(wù)例如解碼動畫過程中將要顯示的圖片的時間點。
????但是這些僅僅階段僅僅發(fā)生在你的應(yīng)用程序之內(nèi),在動畫在屏幕上顯示之前仍然有更多的工作。一旦打包的圖層和動畫到達(dá)渲染服務(wù)進(jìn)程,他們會被反序列化來形成另一個叫做渲染樹的圖層樹(在第一章“圖層樹”中提到過)。使用這個樹狀結(jié)構(gòu),渲染服務(wù)對動畫的每一幀做出如下工作:
對所有的圖層屬性計算中間值,設(shè)置OpenGL幾何形狀(紋理化的三角形)來執(zhí)行渲染
????所以一共有六個階段;最后兩個階段在動畫過程中不停地重復(fù)。前五個階段都在軟件層面處理(通過CPU),只有最后一個被GPU執(zhí)行。而且,你真正只能控制前兩個階段:布局和顯示。Core Animation框架在內(nèi)部處理剩下的事務(wù),你也控制不了它。
????這并不是個問題,因為在布局和顯示階段,你可以決定哪些由CPU執(zhí)行,哪些交給GPU去做。那么改如何判斷呢?
????GPU為一個具體的任務(wù)做了優(yōu)化:它用來采集圖片和形狀(三角形),運(yùn)行變換,應(yīng)用紋理和混合然后把它們輸送到屏幕上?,F(xiàn)代iOS設(shè)備上可編程的GPU在這些操作的執(zhí)行上又很大的靈活性,但是Core Animation并沒有暴露出直接的接口。除非你想繞開Core Animation并編寫你自己的OpenGL著色器,從根本上解決硬件加速的問題,那么剩下的所有都還是需要在CPU的軟件層面上完成。
????寬泛的說,大多數(shù)CALayer
的屬性都是用GPU來繪制。比如如果你設(shè)置圖層背景或者邊框的顏色,那么這些可以通過著色的三角板實時繪制出來。如果對一個contents
屬性設(shè)置一張圖片,然后裁剪它 - 它就會被紋理的三角形繪制出來,而不需要軟件層面做任何繪制。
????但是有一些事情會降低(基于GPU)圖層繪制,比如:
太多的幾何結(jié)構(gòu) - 這發(fā)生在需要太多的三角板來做變換,以應(yīng)對處理器的柵格化的時候?,F(xiàn)代iOS設(shè)備的圖形芯片可以處理幾百萬個三角板,所以在Core Animation中幾何結(jié)構(gòu)并不是GPU的瓶頸所在。但由于圖層在顯示之前通過IPC發(fā)送到渲染服務(wù)器的時候(圖層實際上是由很多小物體組成的特別重量級的對象),太多的圖層就會引起CPU的瓶頸。這就限制了一次展示的圖層個數(shù)(見本章后續(xù)“CPU相關(guān)操作”)。
重繪 - 主要由重疊的半透明圖層引起。GPU的填充比率(用顏色填充像素的比率)是有限的,所以需要避免重繪(每一幀用相同的像素填充多次)的發(fā)生。在現(xiàn)代iOS設(shè)備上,GPU都會應(yīng)對重繪;即使是iPhone 3GS都可以處理高達(dá)2.5的重繪比率,并任然保持60幀率的渲染(這意味著你可以繪制一個半的整屏的冗余信息,而不影響性能),并且新設(shè)備可以處理更多。
離屏繪制 - 這發(fā)生在當(dāng)不能直接在屏幕上繪制,并且必須繪制到離屏圖片的上下文中的時候。離屏繪制發(fā)生在基于CPU或者是GPU的渲染,或者是為離屏圖片分配額外內(nèi)存,以及切換繪制上下文,這些都會降低GPU性能。對于特定圖層效果的使用,比如圓角,圖層遮罩,陰影或者是圖層光柵化都會強(qiáng)制Core Animation提前渲染圖層的離屏繪制。但這不意味著你需要避免使用這些效果,只是要明白這會帶來性能的負(fù)面影響。
????大多數(shù)工作在Core Animation的CPU都發(fā)生在動畫開始之前。這意味著它不會影響到幀率,所以很好,但是他會延遲動畫開始的時間,讓你的界面看起來會比較遲鈍。
????以下CPU的操作都會延遲動畫的開始時間:
布局計算 - 如果你的視圖層級過于復(fù)雜,當(dāng)視圖呈現(xiàn)或者修改的時候,計算圖層幀率就會消耗一部分時間。特別是使用iOS6的自動布局機(jī)制尤為明顯,它應(yīng)該是比老版的自動調(diào)整邏輯加強(qiáng)了CPU的工作。
視圖懶加載 - iOS只會當(dāng)視圖控制器的視圖顯示到屏幕上時才會加載它。這對內(nèi)存使用和程序啟動時間很有好處,但是當(dāng)呈現(xiàn)到屏幕上之前,按下按鈕導(dǎo)致的許多工作都會不能被及時響應(yīng)。比如控制器從數(shù)據(jù)庫中獲取數(shù)據(jù),或者視圖從一個nib文件中加載,或者涉及IO的圖片顯示(見后續(xù)“IO相關(guān)操作”),都會比CPU正常操作慢得多。
Core Graphics繪制 - 如果對視圖實現(xiàn)了-drawRect:
方法,或者CALayerDelegate
的-drawLayer:inContext:
方法,那么在繪制任何東西之前都會產(chǎn)生一個巨大的性能開銷。為了支持對圖層內(nèi)容的任意繪制,Core Animation必須創(chuàng)建一個內(nèi)存中等大小的寄宿圖片。然后一旦繪制結(jié)束之后,必須把圖片數(shù)據(jù)通過IPC傳到渲染服務(wù)器。在此基礎(chǔ)上,Core Graphics繪制就會變得十分緩慢,所以在一個對性能十分挑剔的場景下這樣做十分不好。
UIImageView
)或者把它繪制到Core Graphics中,都需要對它解壓,這樣的話,對于一個較大的圖片,都會占用一定的時間。????當(dāng)圖層被成功打包,發(fā)送到渲染服務(wù)器之后,CPU仍然要做如下工作:為了顯示屏幕上的圖層,Core Animation必須對渲染樹種的每個可見圖層通過OpenGL循環(huán)轉(zhuǎn)換成紋理三角板。由于GPU并不知曉Core Animation圖層的任何結(jié)構(gòu),所以必須要由CPU做這些事情。這里CPU涉及的工作和圖層個數(shù)成正比,所以如果在你的層級關(guān)系中有太多的圖層,就會導(dǎo)致CPU沒一幀的渲染,即使這些事情不是你的應(yīng)用程序可控的。
????還有一項沒涉及的就是IO相關(guān)工作。上下文中的IO(輸入/輸出)指的是例如閃存或者網(wǎng)絡(luò)接口的硬件訪問。一些動畫可能需要從山村(甚至是遠(yuǎn)程URL)來加載。一個典型的例子就是兩個視圖控制器之間的過渡效果,這就需要從一個nib文件或者是它的內(nèi)容中懶加載,或者一個旋轉(zhuǎn)的圖片,可能在內(nèi)存中尺寸太大,需要動態(tài)滾動來加載。
????IO比內(nèi)存訪問更慢,所以如果動畫涉及到IO,就是一個大問題。總的來說,這就需要使用聰敏但尷尬的技術(shù),也就是多線程,緩存和投機(jī)加載(提前加載當(dāng)前不需要的資源,但是之后可能需要用到)。這些技術(shù)將會在第14章中討論。
Copyright©2021 w3cschool編程獅|閩ICP備15016281號-3|閩公網(wǎng)安備35020302033924號
違法和不良信息舉報電話:173-0602-2364|舉報郵箱:jubao@eeedong.com
掃描二維碼
下載編程獅App
編程獅公眾號
聯(lián)系方式:
更多建議: