前言

随着APP功能的逐渐强大和业务上的逐渐完善，目前对于iOS开发者来说，对于APP的优化逐渐显得尤为重要，本篇基于APP渲染优化上探讨一下imageName:的爱恨情仇，下面以UITabBarItem渲染图片为例，一步步以实践的方式进行分析。

分析

首先看下未优化前的效果图：

测试设备:iPhone7 ，系统：12.1

细心的同学应该能够发现，在登录进入首页，到首页渲染结束，中间会有一段白屏，为什么会白屏一会而没有马上渲染首页呢，第一感觉肯定是这中间形成主线程阻塞了，让UI没有立即渲染出来，其实事实上确实是这样，那接下来我们通过Instruments分析一下哪里执行了耗时操作以至于首页渲染被阻塞了。Instruments里面有个工具TimeProfiler，可以用来帮我们查看哪里有耗时操作。关于这个工具的使用和配置网上很多介绍本篇不做重点分析了，我直接粘调试的图片了。

通过TimeProfiler的结果一目了然，在CustomTabBarItem里面做了什么用了387ms。可以在工具里面直接右键进入到到这段耗时代码的位置。我总共测试了五个tabbar渲染item图片的耗时：

看打点日志就很恐怖了，执行两个imageName:就消耗了主线程差不多100ms的时间，五个tabbar那就是500ms的时间，显然这就是上面效果图出现白屏的原因了，实际上imageName:是会对图片进行解码之后再渲染的。

既然原因找到了，那就尝试解决一下。将这个耗时的操作放到子线程执行，这里也是参考了SDWebImage的图片编解码的思路，SD在拿到图片data的时候并没有将它直接转为image对象，而是在子线程里面做了一个解码的操作，这样已经被解码的图片就赋值给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);
            });
        }
    });
}
复制代码

代码实现很简单，就是将图片的操作放入到一个全局队列中，当然也可以自己创建一个队列去执行这个异步操作。decodedImageWithImage:为SD的代码，需要#import "SDWebImageDecoder.h"，具体实现网上对这一块的源码解释的比较多，很容易理解。

这样我们的图片经过这层处理之后，我们再来看一下优化之后的效果：

从总计500ms降到了6ms，基本可以忽略不及了，我们再在真机上面看一下优化后的效果：

经过同事的提醒和评论区小伙伴的质疑，我又重新测试了一下imageName:的加载耗时，得到一种现象，如果将图片资源放入在文件目录中，每张图片第一次加载依旧耗时大概30ms左右，因为imageName:方法对图片有缓存，所以测试多次加载需要多张不同的图片进行测试。另外我将测试图片放入Assets.xcassets中每张图片加载耗时大概在1ms左右，猜测Assets.xcassets提前将图片做了缓存。

测试图片：

总结

通过上面的分析，实际上imageName:这样的UI函数我们天天都在用，但是从没想过它在某些地方能产生这么大的影响。问题的定位和解决其实都很简单，但是这种简单的问题往往会被我们开发者忽略掉，产生一些不好的结果，值得反思。