轉載于:http://bihongbo.com/

?

?

?

內存惡鬼drawRect

標題有點嚇人，但是對于drawRect的評價倒是一點都不過分。在平日的開發中，隨意覆蓋drawRect方法，稍有不慎就會讓你的程序內存暴增。下面我們來看一個例子。

去年的某天午后，北京的霧霾依舊像現在這樣醇厚，我的同事輝哥像往常一樣與我樓下約煙。我見輝哥表情凝重，便詢問究竟。輝哥做了一個畫板功能，但是苦于內存問題一直得不到解決。畫板功能很簡單，就是記錄手指觸摸的軌跡然后繪制在屏幕上。下面我們來看一張效果圖：

如圖我們看到左側內存的狀況隨著手指的繪制逐漸惡化。另外細心的同學可以觀察到，點擊圖中藍色矩形按鈕之后，便會彈出畫板，而這時并沒有進行任何的手指繪制，內存就突變為114MB，然后每當手指繪制開始時，內存立即增加到300MB左右穩定下來。對于正常的iOS App來講，這么大的內存消耗是不能容忍的。

下面分析一下原因：
可能的原因有兩個，一是在手指繪制的過程中創建的大量點對象沒有及時釋放或者其他資源沒有及時釋放。
二是系統在繪制的過程中開始大量消耗內存。

第一個原因，手指繪制的過程中創建的大量點對象沒有及時釋放或者其他資源沒有及時釋放。這一點我們暫時排除以節省時間，因為這個畫板功能工程是用ARC寫的，并且我們已經做過代碼檢查和使用Instruments工具來檢測內存使用情況，這里并沒有所謂的對象沒有及時釋放的問題存在。

第二個原因，系統在繪制的過程中開始大量消耗內存。首先我們曾經注意到一個詭異并且不尋常的事情就是，當黃色的畫板剛剛彈出的時候內存就瞬間從18MB暴增至114MB。這一點更加說明第一個原因不是問題所在，因為這時手指還沒有進行任何繪制，也就是說不存在任何點與線的對象，那么內存怎么會暴增呢？

這時我們要考慮這個畫板功能是如何實現的，畫板分為兩步，第一步記錄用戶手指的軌跡，這一步會生成大量點的對象（已排除嫌疑）。第二步繪制到視圖或者圖層上，我們平常使用頻繁的繪圖方式基本上是Quarz2D的那套C語言框架，而繪制代碼所在的地點在哪呢？我們今天的主角終于上場了－－drawRect。

下面我們來看一段畫板功能繪制的代碼：

- (void)drawRect:(CGRect)rect {if (!self.paths.count) return; CGContextRef ctx = UIGraphicsGetCurrentContext(); for (BHBPaintPath *path in self.paths) { CGContextSaveGState(ctx); [[UIColor blackColor] set]; [path stroke]; //關鍵的一步繪制 CGContextRestoreGState(ctx); } }

去掉繪圖上下文棧和其余判斷邊界的代碼，我們只是在當前view上繪制了n條黑色的線。看起來普普通通的繪圖方式，怎么會導致內存的劇增呢？我們現在說罪魁禍首是drawRect證據并不充分。我們回想畫板剛彈出時的內存狀況，接下來我們注釋掉drawRect所有的代碼。運行的效果圖如下：

效果立竿見影，注釋掉drawRect之后，內存立刻恢復正常，我們終于抓到了消耗內存的惡鬼，問題就出在對drawRect方法的覆蓋。那么抓到了犯人，本文是否應該完結了？非也非也，我們雖說知道了內存暴增的原因，但是我們并沒有深入的去分析drawRect為什么對內存的影響這么大，而且我們也沒有給出問題的解決方案。請接著往下看。

那么現在我們分析一下drawRect導致內存暴增的真正原因：

重寫drawRect為何會導致內存大量上漲？

要想搞明白這個問題，我們需要擼一擼在iOS程序上圖形顯示的原理。在iOS系統中所有顯示的視圖都是從基類UIView繼承而來的，同時UIView負責接收用戶交互。但是實際上你所看到的視圖內容，包括圖形等，都是由UIView的一個實例圖層屬性來繪制和渲染的，那就是CALayer。

CALayer類的概念與UIView非常類似，它也具有樹形的層級關系，并且可以包含圖片文本、背景色等。它與UIView最大的不同在于它不能響應用戶交互，可以說它根本就不知道響應鏈的存在，它的API雖然提供了“某點是否在圖層范圍內的方法”，但是它并不具有響應的能力。

在每一個UIView實例當中，都有一個默認的支持圖層，UIView負責創建并且管理這個圖層。實際上這個CALayer圖層才是真正用來在屏幕上顯示的，UIView僅僅是對它的一層封裝，實現了CALayer的delegate，提供了處理事件交互的具體功能，還有動畫底層方法的高級API。

可以說CALayer是UIView的內部實現細節。

腦補了這么多，它與今天的主題drawRect有何關系呢？別著急，我們既然已經確定CALayer才是最終顯示到屏幕上的，只要順藤摸瓜，即可分析清楚。CALayer其實也只是iOS當中一個普通的類，它也并不能直接渲染到屏幕上，因為屏幕上你所看到的東西，其實都是一張張圖片。而為什么我們能看到CALayer的內容呢，是因為CALayer內部有一個contents屬性。contents默認可以傳一個id類型的對象，但是只有你傳CGImage的時候，它才能夠正常顯示在屏幕上。所以最終我們的圖形渲染落點落在contents身上如圖。

contents也被稱為寄宿圖，除了給它賦值CGImage之外，我們也可以直接對它進行繪制，繪制的方法正是這次問題的關鍵，通過繼承UIView并實現-drawRect:方法即可自定義繪制。-drawRect: 方法沒有默認的實現，因為對UIView來說，寄宿圖并不是必須的，UIView不關心繪制的內容。如果UIView檢測到-drawRect:方法被調用了，它就會為視圖分配一個寄宿圖，這個寄宿圖的像素尺寸等于視圖大小乘以contentsScale(這個屬性與屏幕分辨率有關，我們的畫板程序在不同模擬器下呈現的內存用量不同也是因為它)的值。

那么回到我們的畫板程序，當畫板從屏幕上出現的時候，因為重寫了-drawRect:方法，-drawRect :方法就會自動調用。生成一張寄宿圖后，方法里面的代碼利用Core Graphics去繪制n條黑色的線，然后內容就會緩存起來，等待下次你調用-setNeedsDisplay時再進行更新。

畫板視圖的-drawRect:方法的背后實際上都是底層的CALayer進行了重繪和保存中間產生的圖片，CALayer的delegate屬性默認實現了CALayerDelegate協議，當它需要內容信息的時候會調用協議中的方法來拿。當畫板視圖重繪時，因為它的支持圖層CALayer的代理就是畫板視圖本身，所以支持圖層會請求畫板視圖給它一個寄宿圖來顯示，它此刻會調用：

(void)displayLayer:(CALayer *)layer;

如果畫板視圖實現了這個方法，就可以拿到layer來直接設置contents寄宿圖，如果這個方法沒有實現，支持圖層CALayer會嘗試調用：

- (void)drawLayer:(CALayer *)layer inContext:(CGContextRef)ctx;

這個方法調用之前，CALayer創建了一個合適尺寸的空寄宿圖（尺寸由bounds和contentsScale決定）和一個Core Graphics的繪制上下文環境，為繪制寄宿圖做準備，它作為ctx參數傳入。在這一步生成的空寄宿圖內存是相當巨大的，它就是本次內存問題的關鍵，一旦你實現了CALayerDelegate協議中的-drawLayer:inContext:方法或者UIView中的-drawRect:方法（其實就是前者的包裝方法），圖層就創建了一個繪制上下文，這個上下文需要的內存可從這個公式得出：圖層寬*圖層高*4字節，寬高的單位均為像素。而我們的畫板程序因為要支持像猿題庫一樣兩指挪動的效果，我們開辟的畫板大小為：

_myDrawer = [[BHBMyDrawer alloc] initWithFrame:CGRectMake(0, 0, SCREEN_SIZE.width*5, SCREEN_SIZE.height*2)];

我們的畫板程序的畫板視圖它在iPhone6s plus機器上的上下文內存量就是 1920*2*1080*5*4字節，相當于79MB內存，圖層每次重繪的時候都需要重新抹掉內存然后重新分配。它就是我們畫板程序內存暴增的真正原因。

最終我們將內存暴增的原因找出來了，那么我們有沒有合理的解決方案呢？

我認為最合理的辦法處理類似于畫板這樣畫線條的需求直接用專有圖層CAShapeLayer。讓我們看看它是什么：

CAShapeLayer是一個通過矢量圖形而不是bitmap來繪制的圖層子類。用CGPath來定義想要繪制的圖形，CAShapeLayer會自動渲染。它可以完美替代我們的直接使用Core Graphics繪制layer，對比之下使用CAShapeLayer有以下優點：

• 渲染快速。CAShapeLayer使用了硬件加速，繪制同一圖形會比用Core Graphics快很多。
• 高效使用內存。一個CAShapeLayer不需要像普通CALayer一樣創建一個寄宿圖形，所以無論有多大，都不會占用太多的內存。
• 不會被圖層邊界剪裁掉。
• 不會出現像素化。

所以最終我們的畫板程序使用CAShapeLayer來實現線條的繪制，性能非常穩定，效果圖如下：

總結一下繪制性能優化原則：

• 1.繪制圖形性能的優化最好的辦法就是不去繪制。
• 2.利用專有圖層代替繪圖需求。
• 3.不得不用到繪圖盡量縮小視圖面積，并且盡量降低重繪頻率。
• 4.異步繪制，推測內容，提前在其他線程繪制圖片，在主線程中直接設置圖片。

本文最后一個效果圖為仿寫猿題庫練題畫板功能，demo請在github搜索BHBDrawBoarderDemo。或者直接戳這里。

好了，就是這么多，文章比較亂，如有紕漏請不吝指出！想看對本文的補充請到這里

• ?

轉載于:https://www.cnblogs.com/zhao-jie-li/p/5163654.html

總結

以上是生活随笔為你收集整理的内存恶鬼drawRect的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。