背景

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

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

結(jié)果

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

問題分析

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

輸入圖片說明

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í)間，貌似問題不會(huì)出現(xiàn)在這個(gè)位置驱敲，然而這并不是真相铁蹈，很明顯的，其他地方不會(huì)影響到众眨，所以得用更高級(jí)的分析工具去分析查看握牧。

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

Instrument是一個(gè)很好的性能分析工具，可以分析內(nèi)存分配围辙、內(nèi)存泄漏我碟、網(wǎng)絡(luò)情況、CPU占用等和性能有關(guān)的問題姚建，當(dāng)前的性能問題是耗時(shí)的問題矫俺，可以使用 Instrument 的 Time Profiler 進(jìn)行分析
讓這個(gè)列表滾動(dòng)，并且有進(jìn)行圖片Cell的切換

圖片列表

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

Tips

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

Time Profiler 截圖

第一步要在時(shí)間軸上框選一個(gè)范圍铅匹，標(biāo)識(shí)選擇這個(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，對(duì)于性能也是有一定的影響的讨永。

解決問題

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

UITextView內(nèi)部處理圖片

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

方案1

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

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

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

方案1優(yōu)化

方案2

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

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

        //....
        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)化之后的分析圖

優(yōu)化方案2

總結(jié)

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