江湖傳言

初入iOS江湖，涉世未深的少俠們，如果不是做特別複雜的UI和互動，那麼可能根本從來沒想要過iOS裡竟然還要效能優化。畢竟iPhone的效能越來越強了，而做一個普通的APP的話，UIKit還是那個UIKit，同樣一套程式碼，iphone4、iphone5的年代裡，可能有些卡頓，但當前已經是有著最強CPU和最強GPU的iPhone8以及8Plus了，卡頓什麼的，不存在的。

都這麼說了，老夫幹嘛還在這裡矯情?

矯情還是要矯情的，畢竟除了iphone8和8Plus，有些使用者可能還用著iphone5，phone6，使用者是上帝，上帝的體驗還要是照顧的。而且程式猿的身邊往往還坐著個產品經理，經常會有意無意的迸發出奇妙的靈感，“欸，這裡加個動畫比較好” “這邊整體搞個陰影比較好” “這裡這個效果我覺得可以更酷炫一些”，站在公司業務的角度上，站在APP整體風格的基礎上，對於不合理的需求和靈感吾等程式猿必要據理力爭，能不做就不做。但是如果那個靈感較大的提升了使用者體驗，增加了使用者趣味，但是確實實現起來可能對效能有些影響，這個時候吾等程式猿，不能牙齒緊閉、眉頭緊鎖，不敢應答。要氣沉丹田，暗暗運力，祭出效能優化大法，方可快速完成任務，從而在產品妹子面前扳回一局。

話不多說，言歸正傳，效能優化大法在此:

Texture
YYKit

熟讀了上面兩本祕籍，少俠便可千秋萬載，一統江湖。

有的少俠說了，上面的祕籍不好消化，一不小心，幾萬行程式碼，量太多，殺雞焉用牛刀，況且就算練完了也會有點囫圇吞棗的感覺，完全不清楚內裡的運作，怕日後走火入魔，能不能我先練點簡單的，穩紮穩打，待到日後我基本功深厚的時候，再去修煉絕世祕籍，方可天下無敵。

不錯不錯小小年紀，既有如此胸襟，小兄弟日後前程不可限量，老夫就把畢生所學傳授與你罷。

唯快不破

iPhone每秒重新整理60次，高階一點來說FPS(Frames Per Second)為60，1000ms除以60大約為16.7ms，意味著每次重新整理只有16.7ms的時間給iPhone用來處理各種事務，當前事務不多時，iPhone可以輕鬆處理，FPS此時為60，體驗如絲般順滑。但當事務較多時，iPhone力不從心，不能在16.7ms處理完成，怎麼辦呢，當前這一幀就會被丟棄，等待下一次重新提交，而此時螢幕上的內容則保持不變，一次力不從心不影響，多幾次就會被火眼金睛的使用者發現啦，你們APP卡頓了喲。

所以我們的目的就是要快，爭取在16.7ms內讓iPhone順利做完我們交代的所有事情，天下武功無堅不破，唯快不破，要讓iPhone執行的夠快，我們就需要分清楚它不夠快的原因，對症下藥。

內外兼修

習武之人，外修體，內練氣，內外兼修，方能立於不敗之地。iOS優化，也當以此為切入點，揚長補短。

CPU主外：物件建立、物件調整、物件銷燬、佈局計算、文字計算、文字渲染、圖片解碼、影象的繪製等操作是放在CPU上執行的。

GPU主內：紋理的渲染、檢視混合、離屏渲染都是在GPU上執行的。

要想讓CPU、GPU的速度夠快，就要適當給它們減輕負擔，活幹的開心了，自然速度就上去了。瞭解了各自的分工，就能針對加強，揚長補短。

針對CPU，老夫先授予你些個入門招數：

1. 使用手動佈局

UI相關的操作，只能在主執行緒執行，不然就崩潰給你看，就是這麼任性。蘋果如此設計之初，可能也沒有想到APP後來的發展會如此複雜，會比電腦還要強勁，但是悔不當初，當前APP已經太多了，想要修改也沒那麼容易了，不然還各種開源框架什麼事。既然只能在主執行緒，那在效能要求敏感的頁面，就不要使用Xib和StoreBoard了，手動建立往往是一個更好的選擇。關於Xib和StoreBoard對效能的影響，感興趣的同學可以自行搜尋祕籍。

2. 費時費力的操作放在後臺執行緒執行

非UI相關的操作，選擇就多了，現在CPU，都已經是多核的了，合理利用多執行緒，做到左手畫方，右手畫圓，往往事半功倍。例如把檔案讀取，資料計算放在子執行緒會給CPU更多的時間去處理UI相關的任務。

3. 快取Cell高度

對於高度可變的Cell，在網路資料請求完成的時候，在後臺執行緒計算Cell的高度，並快取在記憶體當中，這樣tableView滾動的時候，就無需多次計算。不止Cell的高度，例如Cell裡有一個行數不固定label，把label的高度也提前計算好並快取，少俠會有意想不到的效果。當然這一操作也是要放在後臺執行緒執行的。

4. 圖片的實際大小和UIImageView的大小一致

當對一個UIImageView設定一個較大的image時，需要在主執行緒完成重取樣的過程，耗時耗記憶體，所以儘量在設定圖片時設定的和UIImageView的大小相近。

針對GPU老夫也先教你些個入門招數：

1. 減少圖層混合操作

當只有一個檢視顯示螢幕上的時候，那麼檢視是什麼顏色就顯示什麼顏色，這個時候不存在圖層混合。

當有多個檢視疊加的時候，如果最上層的檢視是不透明的，有背景色的，那麼也不存在檢視混合。

當多個檢視疊加，放在上面的檢視是半透明的，那麼這個時候GPU就要進行混合，把透明的顏色加上放在下面的檢視的顏色混合之後得出一個顏色再顯示在螢幕上，這一步是消耗GPU資源的，當混合的檢視比較多的時候，GPU消耗的資源也越多。

所以為了減輕GPU負擔，我們要減少圖層混合操作。

這裡老夫有幾個小技巧，少俠可參考:

• UIView的backgroundColor不要設定為clearColor，最好設定的和superView的backgroundColor顏色一樣。
• 圖片避免使用帶alpha通道的圖片，無論是本地圖片還是後臺返回圖片。什麼，設計妹子不同意，少俠這就要靠你的魅力啦。

2. 適當使用shouldRasterize

開啟shouldRasterize後，layer會被光柵化bitmap，layer的各種邊框、陰影等效果會被快取在bitmap中，待下一次使用時，就可以直接拿bitmap來用，就不需要再次費時費力的做效果了。

有的少俠一聽說這個，這可好，那都開啟shouldRasterize不就完事了嗎，效果和效能兼顧了。

且慢，老夫有言相勸：

• 針對內容比較固定的cell，建議採用光柵化。
• 效果複雜的靜態內容，建議採用光柵化。
• 配合rasterizationScale使用，可以在不同螢幕上都顯示良好的效果。
• 如果更新已經光柵化的layer，會造成離屏渲染，這就不好了。
• 不要過度使用，系統限制了快取的大小，超過快取大小，就造成離屏渲染，也是極不好的。

小有所成

現在少俠已經了學習了效能優化的入門祕籍，做到了內外雙修，行走iOS江湖有了一定的技能傍身，日後遇上產品小師妹必能挺起胸膛，為伊人遮風擋雨。

欲知後事如何，且看下回分解： iOS效能優化（中級）