iOS：浅谈视图优化

引言：
让我们来思考几个问题，你开发过的产品，它还有可以优化的地方吗？能增加它的帧率吗？能减少多余的CPU计算吗？是不是存在多余的GPU渲染？业务这点工作量对于越来越强大的设备面前显得微不足道，但作为一个细心的开发者，我觉得很有必要来谈谈iOS中的视图优化。

本文从开发者最容易犯错的地方出发，举个例子，从以下几个角度阐述如何进行视图优化：

• Color Blended Layers
• Color Copied Images
• Color Misaligned Images
• Color Offscreen-Rendered

这个 4 个选项，可以从模拟器的 Debug 选项中看到：

别急，我们一个个来看，首先是 Color Blended Layers。

Color Blended Layers

官方是这么描述它的：

Shows blended view layers. Multiple view layers that are drawn on top of each other with blending enabled are highlighted in red. Reducing the amount of red in your app when this option is selected can dramatically improve your app’s performance. Blended view layers often cause slow table scrolling.

简单来说，屏幕上的每个像素点的颜色是由当前像素点上的多层 Layer (如果存在)共同决定的， GPU 会进行计算出混合颜色的 RGB 值，最终显示在屏幕上。而这需要让 GPU 计算，所以我们要尽量避免设置 alpha，这样 GPU 会忽略下面所有的 layer，节约计算量。

下面让我们来看一下设置 alpha 的效果，上面的灰色小块是透明的。

效果很明显，设置了透明的 view 会让 GPU 计算图层混合后的最终结果。

我想再提一下 opaque 这个属性，网上普遍认为 view.opaque = YES，GPU 就不会进行图层混合计算了。而这个结论是错误的，其实 view.opaque 事实上并没什么卵用。

如果你真的想达到这个效果，可以用 layer.opaque，这个才是正确的做法。

Color Copied Images

“If an image is in a color format that the GPU can not directly work with, it will be converted in the CPU.”

Session 419 WWDC 2014 中详细介绍了这货，其实这个东西跟开发者并没什么关系，遇到这种情况，我们大可以摔锅给设计（当然你乱做优化导致图片颜色格式改变，那就没办法了）。

简而言之，苹果的 GPU 只解析 32bit 的颜色格式，记住是 32bit。

如果你放一张图片，而它的颜色格式却不是 32bit，CPU 会先进行颜色格式转换，再让 GPU 渲染。乖乖的 CPU 就默默做了这个多余的工作。

所以给你两个选择：

• 让设计湿都给你切 32bit 的图
• 自己去跑个异步线程来转换颜色去吧，不要去堵塞本来就压力很大的主线程！

你选哪个？当然是让设计湿切图啦，我才不愿意多写代码。

而且于情于理，就算异步转换颜色，也会导致性能损耗，比如电量增多，发热强变大等等。

Demo 示例：


两个一样的图，仅仅是采用了不同颜色格式，上面是 32bit，下面是 8bit，于是乎，8bit的会导致Color Copied Images 8，让 CPU 多运算了。

Color Misaligned Images

Misaligned Image 表示要绘制的点无法直接映射到频幕上的像素点，此时系统需要对相邻的像素点做 anti-aliasing 反锯齿计算，增加了图形负担，通常这种问题出在对某些 View 的 Frame 重新计算和设置时产生的。

很简单，不要出现 image size 与 imageView size 不同的情况，这样会触发反锯齿计算，增加性能损耗。

Demo 示例：

一下就好看出来，下面的图片尺寸不合适。

所以，实际开发中，本地的图片比较好把控，只需要写好对应的尺寸就好了，但是对于 download 下来的图片，可以在加载完后进行 size 处理，以满足 imageView frame。特别是对于很多 App，有大量的 tableview，如果进行处理，则会大幅度提高流畅度。

Color Offscreen-Rendered

最后就是 Offscreen-Rendered（离屏渲染）了。

这个东西讲起来感觉非常复杂，我觉得只需要知道，离屏渲染会导致 CPU 在后台保存一份 bitmap，所以会导致 CPU 多余运算。

而避免的方式则是避免去做触发的动作：

• 重写 drawRect 方法
• masksToBounds
• 其他一些手动触发离屏渲染的动作

最后看个 Demo：


如图所示，触发了离屏渲染。

总结：

如果开发阶段都注意到这些细节，那么我觉得性能将不会是很大的问题了。