背景

前不久我做了一個(gè)富文本編輯工具，編輯器遇到了一個(gè)性能問題是添加多張圖片，當(dāng)滾動編輯區(qū)域，遇到圖片切換的時(shí)候會有明顯的卡頓現(xiàn)象。這篇文章基于這個(gè)卡頓的性能問題進(jìn)行性能瓶頸的分析以及做對應(yīng)的優(yōu)化。

可以打開這個(gè)鏈接 iOS使用UITableView實(shí)現(xiàn)的富文本編輯器 查看我的文章，這篇文章所用的項(xiàng)目也是基于這個(gè)項(xiàng)目的。

結(jié)果

最終的分析優(yōu)化的結(jié)果把時(shí)間從90ms的數(shù)量級降低到了2ms的數(shù)量級，達(dá)到了一個(gè)比較流暢的效果。具體的分析優(yōu)化步驟請往下看。

問題分析

既然問題是發(fā)生在圖片切換的時(shí)候，圖片是放在單獨(dú)的一個(gè)Cell中的，那么就嘗試在Cell的渲染方法 cellForRowAtIndexPath 添加兩個(gè)Log，查看方法執(zhí)行所用的時(shí)間。

對應(yīng)的結(jié)果：

2017-08-11 06:12:48.744 RichTextEditDemo[6867:1064632] ======begin render cell 
 
2017-08-11 06:12:48.749 RichTextEditDemo[6867:1064632] ======end render cell 
 
2017-08-11 06:12:49.261 RichTextEditDemo[6867:1064632] ======begin render cell 
 
2017-08-11 06:12:49.266 RichTextEditDemo[6867:1064632] ======end render cell  

從日志打印的時(shí)間上看，大概每渲染一個(gè)Cell只要發(fā)幾毫秒的時(shí)間，貌似問題不會出現(xiàn)在這個(gè)位置，然而這并不是真相，很明顯的，其他地方不會影響到，所以得用更高級的分析工具去分析查看。

發(fā)現(xiàn)問題

Instrument是一個(gè)很好的性能分析工具，可以分析內(nèi)存分配、內(nèi)存泄漏、網(wǎng)絡(luò)情況、CPU占用等和性能有關(guān)的問題，當(dāng)前的性能問題是耗時(shí)的問題，可以使用 Instrument 的 Time Profiler 進(jìn)行分析

讓這個(gè)列表滾動，并且有進(jìn)行圖片Cell的切換 

可以看到Time Profiler 有下面的記錄，紅色框中就是Cell切換所耗費(fèi)的時(shí)間值，這個(gè)時(shí)間的增長很明顯的高于其他值了，所以這個(gè)就是我們要定位到的地方了。

Tips

• alt + 鼠標(biāo)滾輪 -> 縮放時(shí)間軸
• shift + 鼠標(biāo)滾輪 -> 移動時(shí)間軸
• 按住鼠標(biāo)框選 -> 選擇和定位時(shí)間軸

***步要在時(shí)間軸上框選一個(gè)范圍，標(biāo)識選擇這個(gè)范圍進(jìn)行分析，才能準(zhǔn)確定位到這個(gè)問題，如圖(1)位置所示;第二步要選在堆棧中的某一個(gè)函數(shù)，一般的選擇到OC函數(shù)調(diào)用，更底層的函數(shù)調(diào)用就到了CF層是C語言實(shí)現(xiàn)的就不好分析了，所以這里選擇的是 [UIImage drawInRect:blendMode:alpha] 這個(gè)函數(shù)分析，可以看到這個(gè)函數(shù)調(diào)用說花費(fèi)的時(shí)間是 92ms，這是一個(gè)比較長的時(shí)間了，所以應(yīng)該就是這里導(dǎo)致的卡頓了。

這個(gè)函數(shù)花費(fèi)的時(shí)間和image圖片的大小有關(guān)系的，選擇另一個(gè)時(shí)間峰值范圍，這個(gè)時(shí)間峰值范圍是發(fā)生在小圖之間的切換的 

這個(gè)地方耗費(fèi)的時(shí)間就比較小一點(diǎn)，不過也是達(dá)到了25ms，對于性能也是有一定的影響的。

解決問題

以上的分析可以得出結(jié)論：[UIImage drawInRect:blendMode:alpha] 函數(shù)的調(diào)用是會導(dǎo)致性能問題的，因?yàn)閁ITextView內(nèi)部處理圖片的方式是通過調(diào)用 [UIImage drawInRect:blendMode:alpha] 函數(shù)繪制圖片實(shí)現(xiàn)的。

既然是UITextView內(nèi)部的處理方式，所以這個(gè)函數(shù)調(diào)用行為是應(yīng)用層改變不了的，不過UIImage對象是我們可以控制的，或者可以改變圖片的顯示方式來達(dá)到優(yōu)化的目的，所以就有了以下的兩種方案。

方案1

***種方案就是對預(yù)覽的圖片進(jìn)行壓縮，然后再設(shè)置到NSTextAttachmen中，放到UITextView中顯示

textAttachment.image = self.image; 
// ===> 修改為 
// scaletoSize用于壓縮原始的圖片，textAttachment中的image對象是壓縮過后的 
textAttachment.image = [self.image scaletoSize:showImageWidth];  

這樣修改之后大圖的滾到加載時(shí)間減少到了40ms左右

雖然減少了一半的時(shí)間，不過，40ms的時(shí)間還是比較長的，下面會繼續(xù)進(jìn)行優(yōu)化。

方案2

上面的方案進(jìn)行了圖片的壓縮，時(shí)間的耗費(fèi)還是因?yàn)?[UIImage drawInRect:blendMode:alpha] 函數(shù)的調(diào)用，所以有沒有一種更好的方案呢?答案是肯定的，可以把傳給UITextView的image壓縮成一個(gè)很小的，(這一步也可以不必，傳遞一個(gè)空的UIImageView對象即可，這里設(shè)置圖片的主要原因是圖片區(qū)域需要一個(gè)編輯的光標(biāo))，然后在 UITextView 所對應(yīng)的圖片區(qū)域添加一個(gè)UIImageView，在UIImageView中設(shè)置原始的圖片即可，這種方案會比方案1的效果好很多。

方案二幾個(gè)修改點(diǎn)：

1.設(shè)置NSTextAttachment的image為空的UIImage對象

//.... 
    NSTextAttachment *textAttachment = [[NSTextAttachment alloc] init]; 
    CGRect rect = CGRectZero; 
    rect.size.width = showImageWidth; 
    rect.size.height = showImageHeight; 
    textAttachment.bounds = rect; 
    textAttachment.image = [UIImage new]; 
 
    NSAttributedString *attachmentString = [NSAttributedString attributedStringWithAttachment:textAttachment]; 
    //....  

2.Cell添加ImageView顯示Image

[self.imageContentView mas_remakeConstraints:^(MASConstraintMaker *make) { 
    make.left.equalTo(self).offset(_imageModel.imageFrame.origin.x); 
    make.top.equalTo(self).offset(_imageModel.imageFrame.origin.y); 
    make.height.equalTo(@(_imageModel.imageFrame.size.height)); 
    make.width.equalTo(@(_imageModel.imageFrame.size.width)); 
}]; 

下面是使用方案2優(yōu)化之后的分析圖

圖中可以看到 cellForRowAtIndexPath 方法總共占用了2ms的時(shí)間，從分析的堆棧中可以看到 UITextView setAttributedText: 方法才占用了1ms的時(shí)間，所以這個(gè)提升是很明顯的，因?yàn)閭鬟f了一個(gè)空的UIImageView對象，不用執(zhí)行 [UIImage drawInRect:blendMode:alpha] 方法，使用了UIImageView直接設(shè)置Image的方式幾乎不會占用時(shí)間，所以堆棧中看不到 [UIImageView setImage:] 方法調(diào)用的時(shí)間。

總結(jié)

Instrument是一個(gè)很好工具，你用它可以很方便的幫我們定位到性能問題，問題找到了，那么也就很容易找到解決方案了。