看下demo的效果：

CPU 和GPU

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

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

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

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

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

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

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

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

當(dāng)你開始做一些性能方面的工作時(shí)候，一定要在真機(jī)上測(cè)試，而不是模擬器，模擬器雖然可以加快開發(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àn)?，只需要關(guān)心發(fā)布性能。

測(cè)試幀率

可以在程序中使用CADisplayLink來測(cè)量幀率，在屏幕上顯示出來,我用Swift3.0模仿YY大神的代碼寫了一個(gè)簡(jiǎn)單的FPS指示器 YWFPSLabel ,使用CADisplayLink監(jiān)視FPS數(shù)值，日常開發(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)畫都是在應(yīng)用外發(fā)生（在渲染進(jìn)程中處理），但應(yīng)用內(nèi)FPS計(jì)數(shù)可以對(duì)一些性能問題提供參考，一旦找到問題，需要更多的精確詳細(xì)信息來定位問題所在，我們就要使用Instuments了，它可以看到更多準(zhǔn)確是信息，查看到所有與顯示的數(shù)據(jù)。

Instuments

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

Activity Monitor

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

Allocations

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

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

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

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

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

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

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

Core Animation

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

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

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

Color Blended Layers（混合過度繪制）

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

這個(gè)選項(xiàng)基于渲染程度對(duì)屏幕中的混合區(qū)域進(jìn)行綠到紅的高亮（也就是多個(gè)半透明圖層的疊加），由于重繪的原因，混合對(duì)GPU性能會(huì)有影響，同時(shí)也是滑動(dòng)或者動(dòng)畫掉幀的罪魁禍?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，也就是說，只要不是認(rèn)為設(shè)置成透明，都不會(huì)出現(xiàn)圖層混合

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

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

retweededTextLab?.layer.masksToBounds = trueretweededTextLab?.backgroundColor = UIColor.groupTableViewBackgroundstatusLab.layer.masksToBounds = truestatusLab.backgroundColor = UIColor.white

看下效果圖：

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

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è)我們有無濫用或正確使用layer的shouldRasterize屬性.成功被緩存的layer會(huì)標(biāo)注為綠色,沒有成功緩存的會(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è)試的過程中,第一次加載時(shí),開啟光柵化的layer會(huì)顯示為紅色,這是很正常的,因?yàn)檫€沒有緩存成功。但是如果在接下來的測(cè)試,。例如我們來回滾動(dòng)TableView時(shí),我們?nèi)匀话l(fā)現(xiàn)有許多紅色區(qū)域,那就需要謹(jǐn)慎對(duì)待了

Color Copied Image (拷貝的圖片)

這個(gè)選項(xiàng)主要檢查我們有無使用不正確圖片格式,由于手機(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的圖片并沒有那么大，因?yàn)樗鼈儗?duì)圖片做了壓縮，但是是可逆的。所以此時(shí)，如果圖片的格式不正確，則系統(tǒng)將圖片轉(zhuǎn)化為像素的時(shí)間就有可能變長(zhǎng)。而該選項(xiàng)就是檢測(cè)圖片的格式是否是系統(tǒng)所支持的，若是GPU不支持的色彩格式的圖片則會(huì)標(biāo)記為青色,則只能由CPU來進(jìn)行處理。CPU被強(qiáng)制生成了一些圖片，然后發(fā)送到渲染服務(wù)器，而不是簡(jiǎn)單的指向原始圖片的的指針。我們不希望在滾動(dòng)視圖的時(shí)候,CPU實(shí)時(shí)來進(jìn)行處理,因?yàn)橛锌赡軙?huì)阻塞主線程。

Color Immediately (顏色立即更新)

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

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

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

圖片尺寸 170 * 220px

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

蘋果的單位以點(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)聽self.layer.shouldRasterize = true //使用 “柵格化” 必須指定分辨率self.layer.rasterizationScale = UIScreen.main.scale

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

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

這行代碼制定了陰影路徑，如果沒有手動(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ù)將圓角緩存起來：

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

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

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

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

1). 對(duì)于label類，可以通過CoreGraphics來畫出一個(gè)圓角的label

2). 對(duì)于imageView，通過CoreGraphics對(duì)繪畫出來的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 = 1lineColor.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í)在屏幕上沒有任何反應(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)問題，這種解釋，不知道是不是我寫代碼的問題，所以，就不多說了

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

紅框中的選項(xiàng)，上面都有解釋，這里就不說了，勾選項(xiàng)，打開模擬器，一看就知道了~

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

Leaks

又一個(gè)灰常重要的工具，主要檢查內(nèi)存泄漏，在前面Allcations里面我們提到內(nèi)存泄漏分兩種，現(xiàn)在我們研究Leaked Memory， 從用戶使用角度來看，內(nèi)存泄漏本身不會(huì)產(chǎn)生什么危害，作為用戶，根本感覺不到內(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)方法等信息.打開擴(kuò)展視圖, 可以看到右邊的跟蹤堆棧信息，4 黑色代碼最有可能出現(xiàn)內(nèi)存泄漏的方法

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

Time Profiler

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

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

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

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

代碼截圖如下：

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

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

看效果圖：

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

還是以例子說說吧，Viewcontroller里面一個(gè)button，點(diǎn)擊跳到SecondViewcontroller，SecondViewcontroller里面有個(gè)View，view里面有個(gè)button，button點(diǎn)擊回到ViewController,實(shí)現(xiàn)是通過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)問題了，這是因?yàn)椋琒econdViewController強(qiáng)引用了SubView，而我們SubView也強(qiáng)引用了SecondViewcontroller，就造成相互強(qiáng)引用，引用計(jì)數(shù)器不能為0，不能銷毀了，我們只要把屬性前面加個(gè)weak，變成弱引用就可以了

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

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

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

來自：http://ios.jobbole.com/90819/