看下demo的效果：

CPU 和GPU

關(guān)于繪圖和動(dòng)畫(huà)有兩種處理方式CPU(中央處理器)和GPU(圖形處理器)，CPU的工作都在軟件層面，而GPU的在硬件層面。

總的來(lái)說(shuō)，可以使用CPU做任何事情，但是對(duì)于圖像的處理，通常GPU會(huì)更快，因?yàn)镚PU使用圖像對(duì)高度并行浮點(diǎn)運(yùn)算做了優(yōu)化（盡管我也不知道是什么鬼？？），所以，我們想盡可能的把屏幕渲染的工作交給硬件去處理，而問(wèn)題在于GPU并沒(méi)有無(wú)限制處理的性能，一旦資源用盡，即使CPU并沒(méi)有完全占用，GPU性能還是會(huì)下降。

所以，目前大多的性能優(yōu)化都是關(guān)于智能利用GPU和CPU，平衡它們之間工作負(fù)載。

測(cè)量，而不是猜測(cè)

現(xiàn)在知道哪些可能會(huì)影響性能，該如何修復(fù)呢？有許多傳統(tǒng)的詭計(jì)來(lái)優(yōu)化，但如果盲目使用的話，可能會(huì)造成更多性能上的問(wèn)題，而不是優(yōu)化了

如何正確的測(cè)量而不是猜測(cè)這點(diǎn)很重要，根據(jù)性能相關(guān)知識(shí)寫(xiě)出的代碼不同于倉(cāng)促優(yōu)化，前者是正確的姿勢(shì)，后者則是在浪費(fèi)生命

那改如何測(cè)量，第一步就是確保在真實(shí)環(huán)境下測(cè)試你的程序

真機(jī)測(cè)試，而不是模擬器

當(dāng)你開(kāi)始做一些性能方面的工作時(shí)候，一定要在真機(jī)上測(cè)試，而不是模擬器，模擬器雖然可以加快開(kāi)發(fā)效率，但卻不能準(zhǔn)確提供真機(jī)的性能參數(shù)

模擬器運(yùn)行在Mac上，然而Mac上的cpu比ios設(shè)備要快很多，相反，Mac上的GPU和ios設(shè)備上的不一樣，模擬器不得已需要在軟件層面(CPU)模擬ios設(shè)備，所以GPU的相關(guān)操作在模擬器上面運(yùn)行的會(huì)更慢

另一件重要的就是性能測(cè)試的時(shí)候一定要用發(fā)布配置，而不是調(diào)試模式，因?yàn)楫?dāng)用發(fā)布環(huán)境打包的時(shí)候，編譯器會(huì)引入一些提高性能的優(yōu)化，比如：去除調(diào)試符號(hào)或者移除并重新組織代碼，因?yàn)榭梢宰约鹤龅竭@些，比如禁用NSlog、print語(yǔ)句，因?yàn)?，只需要關(guān)心發(fā)布性能。

測(cè)試幀率

可以在程序中使用CADisplayLink來(lái)測(cè)量幀率，在屏幕上顯示出來(lái),我用Swift3.0模仿YY大神的代碼寫(xiě)了一個(gè)簡(jiǎn)單的FPS指示器 YWFPSLabel ,使用CADisplayLink監(jiān)視FPS數(shù)值，日常開(kāi)發(fā)的時(shí)候，可以有直接的體現(xiàn)，不用再靠猜了…

YWFPSLabel 集成也很方便,在AppDelegate的application方法里加下面兩句即可

        letFPSLab = YWFPSLabel(frame: CGRect())
        UIApplication.shared.keyWindow!.addSubview(FPSLab)

不知道大家有木有看到頭部那個(gè)小label啊~~~

但是應(yīng)用內(nèi)的FPS顯示并不能完全真實(shí)的測(cè)量出性能，因?yàn)樗鼉H僅能測(cè)試出應(yīng)用內(nèi)的幀率，還有很多是動(dòng)畫(huà)都是在應(yīng)用外發(fā)生（在渲染進(jìn)程中處理），但應(yīng)用內(nèi)FPS計(jì)數(shù)可以對(duì)一些性能問(wèn)題提供參考，一旦找到問(wèn)題，需要更多的精確詳細(xì)信息來(lái)定位問(wèn)題所在，我們就要使用Instuments了，它可以看到更多準(zhǔn)確是信息，查看到所有與顯示的數(shù)據(jù)。

Instuments

Instuments是Xcode套件中沒(méi)有被充分利用的工具，很多iOS開(kāi)發(fā)者從來(lái)沒(méi)用過(guò)Instrument，特別是通過(guò)短暫培訓(xùn)出來(lái)的同學(xué)們，所以，很多面試官也會(huì)問(wèn)性能條調(diào)優(yōu)方面的知識(shí)，來(lái)判斷面試的同學(xué)是否真正應(yīng)用對(duì)年開(kāi)發(fā)經(jīng)驗(yàn)。

• Activity Monitor

  個(gè)人覺(jué)的很像Windows的任務(wù)管理器，可以查看所有的進(jìn)程，以及進(jìn)程的內(nèi)存、cpu使用百分比等數(shù)據(jù)等，就不多介紹了，打開(kāi)一看大概就知道怎么回事

• Allocations

  管理內(nèi)存是app開(kāi)發(fā)中最重要的一個(gè)方面，對(duì)于開(kāi)發(fā)者來(lái)說(shuō)，在程序架構(gòu)中減少內(nèi)存的使用通常都是使用Allocations去定位和找出減少內(nèi)存使用的方式

  接下來(lái)，談一下內(nèi)存泄漏的兩種情況

• 第一種：為對(duì)象A申請(qǐng)了內(nèi)存空間，之后再也沒(méi)用過(guò)對(duì)象A，也沒(méi)釋放過(guò)A導(dǎo)致內(nèi)存泄漏，這種是Leaked Memory內(nèi)存泄漏
• 第二種：類(lèi)似于遞歸，不斷地申請(qǐng)內(nèi)存空間導(dǎo)致的內(nèi)存泄漏，這種情況是Abandoned Momory

  此工具可以讓開(kāi)發(fā)者很好的了解每個(gè)方法占用內(nèi)存的情況，并定位相關(guān)的代碼

  

   

  右鍵就可以打開(kāi)Xcode自動(dòng)定位到相關(guān)占用內(nèi)存方法的代碼上

第二種情況可以根據(jù)下圖的操作清晰的找到對(duì)用的代碼問(wèn)題

 

解釋一下，第二種情況我們應(yīng)該如何操作，重復(fù)的執(zhí)行一系列的操作時(shí)候內(nèi)存不會(huì)繼續(xù)增加，比如打開(kāi)和關(guān)閉一個(gè)窗口，這樣的操作，每一次操作的前后，內(nèi)存應(yīng)該是相同的，通過(guò)多次循環(huán)操作，內(nèi)存不會(huì)遞增下去，通過(guò)這種分析結(jié)果，觀察內(nèi)存分配趨勢(shì)，當(dāng)發(fā)現(xiàn)不正確的結(jié)果或者矛盾的結(jié)果，就可以研究是不是Abandoned Momory的問(wèn)題，并可以修正這個(gè)問(wèn)題了

Core Animation

之前說(shuō)過(guò)自己寫(xiě)的 YWFPSLabel 只能檢測(cè)應(yīng)用內(nèi)的FPS,而此工具考慮到了程序外的動(dòng)畫(huà)，理想的FPS值為60左右，過(guò)低的話就用該進(jìn)性?xún)?yōu)化了，根據(jù)WWDC的說(shuō)法，當(dāng)FPS 低于45的時(shí)候，用戶就會(huì)察覺(jué)到到滑動(dòng)有卡頓

 

圈著數(shù)字紅色方框中的數(shù)字，代表著FPS值，理論上60最佳，實(shí)際過(guò)程中59就可以了，說(shuō)明就是很流暢的，說(shuō)明一下操作方式：在手指不離開(kāi)屏幕的情況下，上下滑動(dòng)屏幕列表

介紹一下Deug Display中選項(xiàng)的作用

• Color Blended Layers（混合過(guò)度繪制）

打開(kāi)此選項(xiàng)屏幕的效果圖如下：

 

這個(gè)選項(xiàng)基于渲染程度對(duì)屏幕中的混合區(qū)域進(jìn)行綠到紅的高亮（也就是多個(gè)半透明圖層的疊加），由于重繪的原因，混合對(duì)GPU性能會(huì)有影響，同時(shí)也是滑動(dòng)或者動(dòng)畫(huà)掉幀的罪魁禍?zhǔn)字��?/p>

GPU每一幀的繪制的像素有最大限制，這個(gè)情況下可以輕易繪制整個(gè)屏幕的像素，但如果發(fā)生重疊像素的關(guān)系需要不停的重繪同一區(qū)域的，掉幀和卡頓就有可能發(fā)生

GPU會(huì)放棄繪制那些完全被其他圖層遮擋的像素，但是要計(jì)算出一個(gè)圖層是否被遮擋也是相當(dāng)復(fù)雜并且會(huì)消耗CPU的資源，同樣，合并不同圖層的透明重疊元素消耗的資源也很大，所以，為了快速處理，一般不要使用透明圖層，

1). 給View添加一個(gè)固定、不透明的顏色

2). 設(shè)置opaque 屬性為true

但是這對(duì)性能調(diào)優(yōu)的幫助并不大，因?yàn)閁IView的opaque 屬性默認(rèn)為true，也就是說(shuō)，只要不是認(rèn)為設(shè)置成透明，都不會(huì)出現(xiàn)圖層混合

而對(duì)于UIIimageView來(lái)說(shuō)，不僅需要自身需要不是透明的，它的圖片也不能含有alpha通道，這也上圖9張圖片是綠色的原因，因此圖像自身的性質(zhì)也可能會(huì)對(duì)結(jié)果有影響，所以你確定自己的代碼沒(méi)問(wèn)題，還出現(xiàn)了混合圖層可能就是圖片的問(wèn)題了

而針對(duì)于屏幕中的文字高亮成紅色，是因?yàn)橐粵](méi)有給文字的label增加不透明的背景顏色，而是當(dāng)UILabel內(nèi)容為中文時(shí)，label的實(shí)際渲染區(qū)域要大于label的size，因?yàn)橥鈬�有了一圈的陰影，才�?huì)出現(xiàn)圖層混合我們需要給中文的label加上如下代碼：

        retweededTextLab?.layer.masksToBounds = true
        retweededTextLab?.backgroundColor = UIColor.groupTableViewBackground
        statusLab.layer.masksToBounds = true
        statusLab.backgroundColor = UIColor.white

看下效果圖：

 

那些label的顏色也變成藍(lán)色的了，這里有一點(diǎn)需要說(shuō)明一下，

1). statusLab.layer.masksToBounds = true 單獨(dú)使用不會(huì)出現(xiàn)離屏渲染

2). 如果對(duì)label設(shè)置了圓角的話，圓角部分會(huì)離屏渲染，離屏渲染的前提是位圖發(fā)生了形變

• Color Hits Green and Misses Red(光柵化緩存圖層的命中情況)

這個(gè)選項(xiàng)主要是檢測(cè)我們有無(wú)濫用或正確使用layer的shouldRasterize屬性.成功被緩存的layer會(huì)標(biāo)注為綠色,沒(méi)有成功緩存的會(huì)標(biāo)注為紅色。

很多視圖Layer由于Shadow、Mask和Gradient等原因渲染很高，因此UIKit提供了API用于緩存這些Layer, self.layer.shouldRasterize = true 系統(tǒng)會(huì)將這些Layer緩存成Bitmap位圖供渲染使用，如果失效時(shí)便丟棄這些Bitmap重新生成。圖層Rasterization柵格化好處是對(duì)刷新率影響較小，壞處是刪格化處理后的Bitmap緩存需要占用內(nèi)存，而且當(dāng)圖層需要縮放時(shí)，要對(duì)刪格化后的Bitmap做額外計(jì)算。 使用這個(gè)選項(xiàng)后時(shí)，如果Rasterized的Layer失效，便會(huì)標(biāo)注為紅色，如果有效標(biāo)注為綠色。當(dāng)測(cè)試的應(yīng)用頻繁閃現(xiàn)出紅色標(biāo)注圖層時(shí)，表明對(duì)圖層做的Rasterization作用不大。

在測(cè)試的過(guò)程中,第一次加載時(shí),開(kāi)啟光柵化的layer會(huì)顯示為紅色,這是很正常的,因?yàn)檫�沒(méi)有緩存成功。但是如果在接下來(lái)的測(cè)試,。例如我們來(lái)回滾動(dòng)TableView時(shí),我們?nèi)匀话l(fā)現(xiàn)有許多紅色區(qū)域,那就需要謹(jǐn)慎對(duì)待了

• Color Copied Image (拷貝的圖片)

這個(gè)選項(xiàng)主要檢查我們有無(wú)使用不正確圖片格式,由于手機(jī)顯示都是基于像素的，所以當(dāng)手機(jī)要顯示一張圖片的時(shí)候，系統(tǒng)會(huì)幫我們對(duì)圖片進(jìn)行轉(zhuǎn)化。比如一個(gè)像素占用一個(gè)字節(jié)，故而RGBA則占用了4個(gè)字節(jié)，則1920 x 1080的圖片占用了7.9M左右，但是平時(shí)jpg或者png的圖片并沒(méi)有那么大，因?yàn)樗鼈儗?duì)圖片做了壓縮，但是是可逆的。所以此時(shí)，如果圖片的格式不正確，則系統(tǒng)將圖片轉(zhuǎn)化為像素的時(shí)間就有可能變長(zhǎng)。而該選項(xiàng)就是檢測(cè)圖片的格式是否是系統(tǒng)所支持的，若是GPU不支持的色彩格式的圖片則會(huì)標(biāo)記為青色,則只能由CPU來(lái)進(jìn)行處理。CPU被強(qiáng)制生成了一些圖片，然后發(fā)送到渲染服務(wù)器，而不是簡(jiǎn)單的指向原始圖片的的指針。我們不希望在滾動(dòng)視圖的時(shí)候,CPU實(shí)時(shí)來(lái)進(jìn)行處理,因?yàn)橛锌赡軙?huì)阻塞主線程。

• Color Immediately (顏色立即更新)

通常 Core Animation 以每秒10此的頻率更新圖層的調(diào)試顏色，對(duì)于某些效果來(lái)說(shuō)，這可能太慢了，這個(gè)選項(xiàng)可以用來(lái)設(shè)置每一幀都更新（可能會(huì)影響到渲染性能，所以不要一直都設(shè)置它）

• Color Misaligned Image (圖片對(duì)齊方式)

這里會(huì)高亮那些被縮放或者拉伸以及沒(méi)有正確對(duì)齊到像素邊界的圖片，即圖片Size和imageView中的Size不匹配，會(huì)使圖過(guò)程片縮放，而縮放會(huì)占用CPU，所以在寫(xiě)代碼的時(shí)候保證圖片的大小匹配好imageView，如下圖所示：

圖片尺寸 170 * 220px

        letimageView = UIImageView(frame: CGRect(x: 50, y: 100, width: 170, height: 220))
        imageView.image = UIImage(named: "cat")
        view.addSubview(imageView)

蘋(píng)果的單位以點(diǎn)計(jì)算，而 imageView的尺寸是170 220 pt 而圖片是 170 220px，所以相當(dāng)于在屏幕上對(duì)圖片方法了一倍，看效果圖如下：

 

可以看到圖片高亮成黃色顯示，更改下imageView的大小

        letimageView = UIImageView(frame: CGRect(x: 50, y: 100, width: 85, height: 110))
        imageView.image = UIImage(named: "cat")
        view.addSubview(imageView)

看下效果圖

 

當(dāng)imageView和image的大小一致的時(shí)候，就正常顯示了

• Color Offscreen- Rendered Yellow (離屏渲染)

這里會(huì)把那些需要離屏渲染的到圖層高亮成黃色，而出發(fā)離屏渲染的可能有

/* 圓角處理 */
view.layer.maskToBounds = truesomeView.clipsToBounds = true
/* 設(shè)置陰影 */
view.shadow..
/* 柵格化 */
view.layer.shouldRastarize = true

針對(duì)柵格化處理，我們需要指定屏幕的分辨率

        //離屏渲染 - 異步繪制  耗電
        self.layer.drawsAsynchronously = true
 
        //柵格化 - 異步繪制之后 ，會(huì)生成一張獨(dú)立的圖片 cell 在屏幕上滾動(dòng)的時(shí)候，本質(zhì)上滾動(dòng)的是這張圖片
        //cell 優(yōu)化，要盡量減少圖層的數(shù)量，想當(dāng)于只有一層
        //停止?jié)L動(dòng)之后，可以接受監(jiān)聽(tīng)
        self.layer.shouldRasterize = true
 
        //使用 “柵格化” 必須指定分辨率
        self.layer.rasterizationScale = UIScreen.main.scale

指定陰影的路徑，可以防止離屏渲染

        // 指定陰影曲線，防止陰影效果帶來(lái)的離屏渲染
        imageView.layer.shadowPath = UIBezierPath(rect: imageView.bounds).cgPath

這行代碼制定了陰影路徑，如果沒(méi)有手動(dòng)指定，Core Animation會(huì)去自動(dòng)計(jì)算，這就會(huì)觸發(fā)離屏渲染。如果人為指定了陰影路徑，就可以免去計(jì)算，從而避免產(chǎn)生離屏渲染。

設(shè)置cornerRadius本身并不會(huì)導(dǎo)致離屏渲染，但很多時(shí)候它還需要配合layer.masksToBounds = true使用。根據(jù)之前的總結(jié)，設(shè)置masksToBounds會(huì)導(dǎo)致離屏渲染。解決方案是盡可能在滑動(dòng)時(shí)避免設(shè)置圓角，如果必須設(shè)置圓角，可以使用光柵化技術(shù)將圓角緩存起來(lái)：

// 設(shè)置圓角
label.layer.masksToBounds = true
label.layer.cornerRadius = 8
label.layer.shouldRasterize = true
label.layer.rasterizationScale = layer.contentsScale

如果界面中有很多控件需要設(shè)置圓角，比如tableView中，當(dāng)tableView有超過(guò)25個(gè)圓角，使用如下方法

view.layer.cornerRadius = 10
view.maskToBounds = Yes

那么fps將會(huì)下降很多，特別是對(duì)某些控件還設(shè)置了陰影效果，更會(huì)加劇界面的卡頓、掉幀現(xiàn)象，對(duì)于不同的控件將采用不同的方法進(jìn)行處理：

1). 對(duì)于label類(lèi)，可以通過(guò)CoreGraphics來(lái)畫(huà)出一個(gè)圓角的label

2). 對(duì)于imageView，通過(guò)CoreGraphics對(duì)繪畫(huà)出來(lái)的image進(jìn)行裁邊處理，形成一個(gè)圓角的imageView,代碼如下:

    /// 創(chuàng)建圓角圖片
    ///
    /// - parameter radius:    圓角的半徑
    /// - parameter size:      圖片的尺寸
    /// - parameter backColor: 背景顏色 默認(rèn) white
    /// - parameter lineWith:  圓角線寬 默認(rèn) 1
    /// - parameter lineColor: 線顏色 默認(rèn) darkGray
    ///
    /// - returns: image
    funcyw_drawRectWithRoundCornor(radius: CGFloat, size: CGSize, backColor: UIColor = UIColor.white, lineWith: CGFloat = 1, lineColor: UIColor = UIColor.darkGray) -> UIImage? {
        letrect = CGRect(origin: CGPoint(x: 0, y: 0), size: size)
        UIGraphicsBeginImageContextWithOptions(rect.size, true, 0)
        letbezier = UIBezierPath(roundedRect: rect, byRoundingCorners: UIRectCorner.allCorners, cornerRadii: CGSize(width: radius, height: radius))
 
        backColor.setFill()
        UIRectFill(rect)
 
        bezier.addClip()
        draw(in: rect)
 
        bezier.lineWidth = 1
        lineColor.setStroke()
        bezier.stroke()
        letresult = UIGraphicsGetImageFromCurrentImageContext()
        UIGraphicsEndImageContext()
        return result
    }

• Color Compositing Fast-Path Blue

這個(gè)選項(xiàng)會(huì)對(duì)任何直接使用OpenGL繪制的圖層進(jìn)行高亮，如果僅僅使用UIKit或者Core Animation的API，不會(huì)有任何效果，恕我才疏學(xué)淺，所以，我在測(cè)試的時(shí)候，確實(shí)在屏幕上沒(méi)有任何反應(yīng)的，openGL 繪制，我也不會(huì)，所以，就不知道到底會(huì)有什么效果了，哪位大神會(huì)的話，貼段代碼，給我試試啊~~~

• Flash Updated Regions (Core Graphics 繪制的圖層)

此選項(xiàng)會(huì)對(duì)重繪的內(nèi)容進(jìn)行高亮成黃色，也就是軟件層面使用Core Graphics 繪制的圖層。我測(cè)試的時(shí)候，好像有點(diǎn)問(wèn)題，這種解釋?zhuān)�不知道是不是我�?xiě)代碼的問(wèn)題，所以，就不多說(shuō)了

上面說(shuō)的這些高亮圖層，幾個(gè)常用的選項(xiàng)在模擬器里面可以直接調(diào)試，非常方便

 

紅框中的選項(xiàng)，上面都有解釋?zhuān)�這里就不說(shuō)了，勾選項(xiàng)，打開(kāi)模擬器，一看就知道了~

麻蛋、Core Animation 部分終于扯完了，扯了好多啊。。。

• Leaks

又一個(gè)灰常重要的工具，主要檢查內(nèi)存泄漏，在前面Allcations里面我們提到內(nèi)存泄漏分兩種，現(xiàn)在我們研究Leaked Memory， 從用戶使用角度來(lái)看，內(nèi)存泄漏本身不會(huì)產(chǎn)生什么危害，作為用戶，根本感覺(jué)不到內(nèi)存泄漏的存在，真正的危害在于內(nèi)存泄漏的堆積，最終會(huì)耗盡系統(tǒng)所有的內(nèi)存。我們直接看圖：

在 instruments 中,雖然選擇了 Leaks 模板,但默認(rèn)情況下也會(huì)添加 Allocations 模板.基本上凡是內(nèi)存分析都會(huì)使用 Allocations 模板, 它可以監(jiān)控內(nèi)存分布情況。

選中 Allocations 模板3區(qū)域會(huì)顯示隨著時(shí)間的變化內(nèi)存使用的折線圖,同時(shí)在4區(qū)域會(huì)顯示內(nèi)存使用的詳細(xì)信息,以及對(duì)象分配情況.

點(diǎn)擊 Leaks 模板, 可以查看內(nèi)存泄露情況。如果在3區(qū)域有 紅X 出現(xiàn), 則有內(nèi)存泄露, 4區(qū)域則會(huì)顯示泄露的對(duì)象.

打用leaks進(jìn)行監(jiān)測(cè)：點(diǎn)擊泄露對(duì)象可以在(下圖)看到它們的內(nèi)存地址, 占用字節(jié), 所屬框架和響應(yīng)方法等信息.打開(kāi)擴(kuò)展視圖, 可以看到右邊的跟蹤堆棧信息，4 黑色代碼最有可能出現(xiàn)內(nèi)存泄漏的方法

監(jiān)測(cè)結(jié)果的分析，

Time Profiler

在開(kāi)發(fā)的過(guò)程中，我們經(jīng)常能感覺(jué)到，點(diǎn)擊某一按鈕，或者做了某一操作，有卡頓，這就是延遲，那使用此工具，就可以揪出耗時(shí)的函數(shù)，先看一下，調(diào)試界面介紹：

 

根據(jù)查看的相關(guān)耗時(shí)操作，我們就可以右鍵定位當(dāng)耗時(shí)的方法：

寫(xiě)一個(gè)簡(jiǎn)單例子看一下：

看上圖，可以很清楚看到此方法耗時(shí)比較嚴(yán)重，右鍵打開(kāi)定位到此方法的代碼：

代碼截圖如下：

這時(shí)候，我們把循環(huán)放到子線程來(lái)做

    @IBActionfunc btnAction(_ sender: AnyObject) {
        let svc = SecondViewController()
        svc.title = "第二個(gè)頁(yè)面"
        //全局隊(duì)列異步執(zhí)行
        DispatchQueue.global().async {
            for i in 0..<8888 {
                print(i)
            }
        }
        navigationController?.pushViewController(svc, animated: true)
    }

看效果圖：

到這里比較重要Instrument調(diào)試工具介紹的差不多了，說(shuō)一個(gè)Xcode8.0新出的功能，很好用也很重要的功能：

還是以例子說(shuō)說(shuō)吧，Viewcontroller里面一個(gè)button，點(diǎn)擊跳到SecondViewcontroller，SecondViewcontroller里面有個(gè)View，view里面有個(gè)button，button點(diǎn)擊回到ViewController,實(shí)現(xiàn)是通過(guò)view的屬性拿到SecondviewConroller的引用，pop回去

子view的代碼如下：

class SubView: UIView {
    var  delegate: SecondViewController?
    @IBActionfuncbrnAction(_ sender: AnyObject) {
        delegate?.navigationController!.popViewController(animated: true)
    }
}

當(dāng)我們從第二個(gè)控制器，回到第一個(gè)控制器的時(shí)候，我們點(diǎn)一下，剛那個(gè)按鈕，看圖：

第二個(gè)控制器和子View都內(nèi)存中，我們很容易，就可以發(fā)現(xiàn)問(wèn)題了，這是因?yàn)�，SecondViewController強(qiáng)引用了SubView，而我們SubView也強(qiáng)引用了SecondViewcontroller，就造成相互強(qiáng)引用，引用計(jì)數(shù)器不能為0，不能銷(xiāo)毀了，我們只要把屬性前面加個(gè)weak，變成弱引用就可以了

weakvar  delegate: SecondViewController?
    @IBActionfuncbrnAction(_ sender: AnyObject) {
        delegate?.navigationController!.popViewController(animated: true)
    }

這時(shí)候，我們從第二個(gè)控制器pop回來(lái)的時(shí)候，看下內(nèi)存：

現(xiàn)在就沒(méi)問(wèn)題了，怎樣這個(gè)工具是不是挺好用啊

 

來(lái)自：http://ios.jobbole.com/90819/

 

標(biāo)簽： isp 代碼 服務(wù)器 開(kāi)發(fā)者

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。