來源：kuailejim 

鏈接：http://www.jianshu.com/p/5c968a240e27

引言：

讓我們來思考幾個(gè)問題,，你開發(fā)過的產(chǎn)品,，它還有可以優(yōu)化的地方嗎？能增加它的幀率嗎,？能減少多余的CPU計(jì)算嗎,？是不是存在多余的GPU渲染？業(yè)務(wù)這點(diǎn)工作量對于越來越強(qiáng)大的設(shè)備面前顯得微不足道,，但作為一個(gè)細(xì)心的開發(fā)者,，我覺得很有必要來談?wù)刬OS中的視圖優(yōu)化。

本文從開發(fā)者最容易犯錯(cuò)的地方出發(fā),，結(jié)合例子,，從以下幾個(gè)角度闡述如何進(jìn)行視圖優(yōu)化：

• Color Blended Layers

• Color Copied Images

• Color Misaligned Images

• Color Offscreen-Rendered

這個(gè)4個(gè)選項(xiàng)，可以從模擬器的Debug選項(xiàng)中看到

模擬器選項(xiàng)

別急,，我們一個(gè)個(gè)來看,，首先是Color Blended Layers。

Color Blended Layers

官方是這么描述它的：

Shows blended view layers. Multiple view layers that are drawn on top of each other with blending enabled are highlighted in red. Reducing the amount of red in your app when this option is selected can dramatically improve your app’s performance. Blended view layers often cause slow table scrolling.

簡單來說,，屏幕上的每個(gè)像素點(diǎn)的顏色是由當(dāng)前像素點(diǎn)上的多層layer(如果存在)共同決定的,，GPU會(huì)進(jìn)行計(jì)算出混合顏色的RGB值，最終顯示在屏幕上,。而這需要讓GPU計(jì)算,，所以我們要盡量避免設(shè)置alpha，這樣GPU會(huì)忽略下面所有的layer,，節(jié)約計(jì)算量,。

下面讓我們來看一下設(shè)置alpha的效果，上面的灰色小塊是透明的,。

demo

檢測后

效果很明顯,，設(shè)置了透明的view會(huì)讓GPU計(jì)算圖層混合后的最終結(jié)果。

我想再提一下opaque這個(gè)屬性,，網(wǎng)上普遍認(rèn)為view.opaque = YES,，GPU就不會(huì)進(jìn)行圖層混合計(jì)算了,。而這個(gè)結(jié)論是錯(cuò)誤的，其實(shí)view.opaque事實(shí)上并沒什么卵用,。

如果你真的想達(dá)到這個(gè)效果,，可以用layer.opaque,這個(gè)才是正確的做法。

Color Copied Images

“If an image is in a color format that the GPU can not directly work with, it will be converted in the CPU.”

Session 419 WWDC 2014中詳細(xì)介紹了這貨,，其實(shí)這個(gè)東西跟開發(fā)者并沒什么關(guān)系,，遇到這種情況，我們大可以摔鍋給設(shè)計(jì)（當(dāng)然你亂做優(yōu)化導(dǎo)致圖片顏色格式改變,，那就沒辦法了）,。

簡而言之，蘋果的GPU只解析32bit的顏色格式,，記住是32bit,。

如果你放一張圖片，而它的顏色格式卻不是32bit,，CPU會(huì)先進(jìn)行顏色格式轉(zhuǎn)換,，再讓GPU渲染。乖乖的CPU就默默做了這個(gè)多余的工作,。

所以給你兩個(gè)選擇：

• 讓設(shè)計(jì)濕都給你切32bit的圖

• 自己去跑個(gè)異步線程來轉(zhuǎn)換顏色去吧,，不要去堵塞本來就壓力很大的主線程！

你選哪個(gè),？當(dāng)然是讓設(shè)計(jì)濕切圖啦,，我才不愿意多寫代碼。

而且于情于理,，就算異步轉(zhuǎn)換顏色,，也會(huì)導(dǎo)致性能損耗，比如電量增多,，發(fā)熱強(qiáng)變大等等等等,。

上demo：

demo

檢測后

兩個(gè)一樣的圖，僅僅是采用了不同顏色格式,，上面是32bit,，下面是8bit，于是乎,，8bit的會(huì)導(dǎo)致Color Copied Images8,，讓CPU多運(yùn)算了。

Color Misaligned Images

Misaligned Image表示要繪制的點(diǎn)無法直接映射到頻幕上的像素點(diǎn),，此時(shí)系統(tǒng)需要對相鄰的像素點(diǎn)做anti-aliasing反鋸齒計(jì)算,，增加了圖形負(fù)擔(dān)，通常這種問題出在對某些View的Frame重新計(jì)算和設(shè)置時(shí)產(chǎn)生的,。

很簡單,，不要出現(xiàn)image size與imageView size不同的情況，這樣會(huì)觸發(fā)反鋸齒計(jì)算,，增加性能損耗,。

上demo：

demo

一下就好看出來，下面的圖片尺寸不合適,。

所以,，實(shí)際開發(fā)中，本地的圖片比較好把控,，只需要寫好對應(yīng)的尺寸就好了,，但是對于download下來的圖片，可以在加載完后進(jìn)行size處理,，以滿足imageView frame,。特別是對于很多app，有大量的tableview,，如果進(jìn)行處理,，則會(huì)大幅度提高流暢度。

Color Offscreen-Rendered

最后就是Offscreen-Rendered（離屏渲染）了,。

這個(gè)東西講起來感覺非常復(fù)雜,，我覺得只需要知道，離屏渲染會(huì)導(dǎo)致CPU在后臺(tái)保存一份bitmap,，所以會(huì)導(dǎo)致CPU多余運(yùn)算,。

而避免的方式則是避免去做觸發(fā)的動(dòng)作：

• 重寫drawRect方法

• masksToBounds

• 其他一些手動(dòng)觸發(fā)離屏渲染的動(dòng)作

最后看個(gè)demo：

萬惡的圓角

發(fā)現(xiàn)罪惡

如圖所示，觸發(fā)了離屏渲染,。

總結(jié)：

如果開發(fā)階段都注意到這些細(xì)節(jié),，那么我覺得性能將不會(huì)是很大的問題了。