前言
隨著APP功能的逐漸強大和業(yè)務(wù)上的逐漸完善，目前對于iOS開發(fā)者來說，對于APP的優(yōu)化逐漸顯得尤為重要，本篇基于APP渲染優(yōu)化上探討一下imageName:的愛恨情仇，下面以UITabBarItem渲染圖片為例，一步步以實踐的方式進行分析。
分析
首先看下未優(yōu)化前的效果圖：
測試設(shè)備:iPhone7 ，系統(tǒng)：12.1
細心的同學應(yīng)該能夠發(fā)現(xiàn)，在登錄進入首頁，到首頁渲染結(jié)束，中間會有一段白屏，為什么會白屏一會而沒有馬上渲染首頁呢，第一感覺肯定是這中間形成主線程阻塞了，讓UI沒有立即渲染出來，其實事實上確實是這樣，那接下來我們通過Instruments分析一下哪里執(zhí)行了耗時操作以至于首頁渲染被阻塞了。Instruments里面有個工具TimeProfiler，可以用來幫我們查看哪里有耗時操作。關(guān)于這個工具的使用和配置網(wǎng)上很多介紹本篇不做重點分析了，我直接粘調(diào)試的圖片了。
通過TimeProfiler的結(jié)果一目了然，在CustomTabBarItem里面做了什么用了387ms。可以在工具里面直接右鍵進入到到這段耗時代碼的位置。我總共測試了五個tabbar渲染item圖片的耗時：
看打點日志就很恐怖了，執(zhí)行兩個imageName:就消耗了主線程差不多100ms的時間，五個tabbar那就是500ms的時間，顯然這就是上面效果圖出現(xiàn)白屏的原因了，實際上imageName:是會對圖片進行解碼之后再渲染的。
既然原因找到了，那就嘗試解決一下。將這個耗時的操作放到子線程執(zhí)行，這里也是參考了SDWebImage的圖片編解碼的思路，SD在拿到圖片data的時候并沒有將它直接轉(zhuǎn)為image對象，而是在子線程里面做了一個解碼的操作，這樣已經(jīng)被解碼的圖片就賦值給imageView的時候就不會再進行解碼，也就不會妨礙主線程了。
- (void)decodedImageWithImageName:(NSString *)imageName block:(void(^)(UIImage *image))block {
dispatch_async(dispatch_get_global_queue(0, 0), ^{
@autoreleasepool{
UIImage *image = [[UIImage imageNamed:imageName] imageWithRenderingMode:UIImageRenderingModeAlwaysOriginal];
image = [UIImage decodedImageWithImage:image];
dispatch_async(dispatch_get_main_queue(), ^{
if(block)
block(image);
});
}
});
}
代碼實現(xiàn)很簡單，就是將圖片的操作放入到一個全局隊列中，當然也可以自己創(chuàng)建一個隊列去執(zhí)行這個異步操作。decodedImageWithImage:為SD的代碼，需要#import "SDWebImageDecoder.h"，具體實現(xiàn)網(wǎng)上對這一塊的源碼解釋的比較多，很容易理解。
這樣我們的圖片經(jīng)過這層處理之后，我們再來看一下優(yōu)化之后的效果：
從總計500ms降到了6ms，基本可以忽略不及了，我們再在真機上面看一下優(yōu)化后的效果：
經(jīng)過同事的提醒和評論區(qū)小伙伴的質(zhì)疑，我又重新測試了一下
imageName:的加載耗時，得到一種現(xiàn)象，如果將圖片資源放入在文件目錄中，每張圖片第一次加載依舊耗時大概30ms左右，因為imageName:方法對圖片有緩存，所以測試多次加載需要多張不同的圖片進行測試。另外我將測試圖片放入Assets.xcassets中每張圖片加載耗時大概在1ms左右，猜測Assets.xcassets提前將圖片做了緩存。
測試圖片：
總結(jié)
通過上面的分析，實際上imageName:這樣的UI函數(shù)我們天天都在用，但是從沒想過它在某些地方能產(chǎn)生這么大的影響。問題的定位和解決其實都很簡單，但是這種簡單的問題往往會被我們開發(fā)者忽略掉，產(chǎn)生一些不好的結(jié)果，值得反思。
