iOS 首页渲染优化 -- imageName:

4,050 阅读3分钟

前言

随着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函数我们天天都在用,但是从没想过它在某些地方能产生这么大的影响。问题的定位和解决其实都很简单,但是这种简单的问题往往会被我们开发者忽略掉,产生一些不好的结果,值得反思。