图片展示卡顿优化之范儿首页实战

进新公司2个月，业务慢慢熟悉起来了，新项目值得借鉴和学习的地方很多，项目大了，发现的问题也不少。最近进行的首页快速滑动卡顿的问题，优化方案的思路和优化过程遇到的问题，借论坛发泄下，不吐不快啊。

说先说下我的思路：滚动卡顿，我的理解就是负责渲染的主线程被阻塞。阻塞的原因有无外乎：耗时的单任务 或 不太耗时但多的子任务。

耗时的单任务主要体现在图片下载，大图读取这些步骤。项目中也是走的大众的SDWebImage做图片加载，所以不细谈。多子任务卡顿在我这个话题里，主要体现在滚动，滚动的时候有大量的redraw，问题的几个主要惯犯 动画animations，透明的视图，border和shadow,这些在许多论坛都有不少。借助Instruments也大致能找到相应的问题。

小发现：之前做memory leak,malloc检测分析的时候 Instruments是必须依赖app跑起来的。检测core animation的时候，发现功能项是直接和手机里的特定功能点挂钩的，勾选功能点后，系统界面里直接就能呈现出变化，是系统级别的。所以我们可以分析任何app的core animation性能。

上一张Instruments中 core animation检查的功能选项图

我这次主要发现了三个问题

1.Color Blended layers 情况最严重。
2.Color misaligned 。
3.Color Offscreen-Rendered Yellow 。

1.意思就是图层渲染的时候，采用了混合算法，也就是有透明的渲染对象存在。这种情况比较严重，很多子视图都是用的clearColor，果断的将其设置为父视图的背景色，这个问题解决的比较容易。

透过blend layers,我查看了些帖子,GPU在绘制纹理的时候,如果透明通道存在，在绘制的时候，会对原画布对应的像素有一个混合算法，得出一个新的像素值再绘制（1-alaph）*rgb,所以如果这种图层多的画，特别是在滚动条这种反复绘制特别频繁的场景里，是不太可能有好的用户体验的。

2.纹理有压缩处理。体现再图片尺寸和图片显示的大小不符，GPU需要将源纹理进行处理，才能恰好在指定区域里画出来。SDWebImage确实给了开发者很多便利，这个时候就比较坑了。不支持提供给用户指定尺寸的图片。现在项目里的SDWebImage已经根据业务需求，做了很多优化改动，但在提供裁剪图的功能还不是太完善。其实就是需要在有原大图的基础上，裁剪出一份我想展示的尺寸的图来使用，思路很简单，但在项目里SDWebImage由其他团队负责，这个问题只有先delay，后续他们改进优化。

3.离屏渲染（CPU渲染出bitmap）。据有些帖子上说Layer的shadow和mask相关接口会导致这个问题。我查看了下，没有使用相关接口。后来试出，发现是SDWebImage图片设置的时候，animations导致的。这个就比较难取舍了，要流畅还是要过渡比较好的体验。这块感觉还是有很大优化点的。时间问题，没有太深入分析，而且怕成效太低。

抛开Instruments工具检测出来的问题，其实首页代码本身也是有问题的。比如Cell的子视图层次太深，而且有多种cell混合。这些都是于业务相关了，修改成单view多layer的代价比较大，也没有下手优化。

优化结果，确实比原先的卡顿要减轻了不少。还有些许卡顿是在分页加载的时候，这些都是历史原因，没有动。

总结：滚动卡顿，往往不是一个简单的问题导致，通常都是集多病于一身才比较明显。优化时也不能太大刀阔斧了，一点一点逐步优化，力求做到每一次优化都能量化，有一次提升。