写本篇文章的原因是在开发过程中，遇到了列表加载和滑动会卡顿掉帧的情况，于是打算开始逐渐排查各种原因，最先想到的便是会不会是列表中头像的圆角设置导致掉帧卡顿？
于是便开始了测试。
首先，关于UIButton的离屏渲染，并不是设置了 layer 的 CornerRadius 和 MasksToBounds 就会导致离屏渲染，在设置了以上两种的情况下，只有设置 UIButton 的背景图片，才会导致离屏渲染，光设置背景颜色和 CornerRadius、MasksToBounds 并不会导致离屏渲染，那么在此情况下，CPU才是影响性能的关键。
原因：layer 渲染的时候分三层:backgroundColor、content 和 border。如果只设置 CornerRadius 则不会对 content 进行渲染(即图片)，设置了 MasksToBounds 后，则会将渲染扩张到修改 content 图层。但是，如果我们不设置图片，content 为 nil 系统进行了优化, 不用切圆角，所以直接对 backgroundColor 层操作后，输出到 FrameBuffer 便可。不用离屏渲染。
先初始设置，不设置背景图片，设置圆角和背景颜色
?
这个时候，CPU的情况如下，启动后 视图加载完毕后CPU占3%，当上下快速滑动的时候，CPU占用最高值到达17%?
接下来设置背景图片，但不对图片设置圆角。
这个时候的CPU情况大致为：启动后 视图加载完毕后CPU占20～30%，当上下快速滑动的时候，CPU占用最高值到达18～20% 左右，可以看出相比不设置图片，加载所占用的CPU资源大量增加，而快速滑动所占用的CPU资源只有少量增加。
那么上述两种情况出现的原因肯定不是离屏渲染，因为两者甚至都没有离屏渲染，那么出现这种情况的原因，就在于CPU在渲染过程中的作用
CPU在渲染过程中的作用主要有 显示逻辑、计算布局、图片的解码和格式转换、提交等。
上述两种情况，CPU占有率增大的主要原因就在于添加了图片，导致CPU需要计算尺寸、解压成显示的尺寸，同时这种情况 图片越大所需的时间就越多。这也就导致，如果图片过大，也会使画面有些许卡顿的情况。当我把同样的图片，像素从698*698 修改到300*300 的时候，滑动时所占用的CPU有轻微减少，峰值在16%左右，同时在滑动减速时，页面不会出现明显卡顿。
为了验证，我将图片替换成3024*4032的图片后，CPU的占用资源如下图，大量增加。在滑动减速时，更是会出现明显卡顿、掉帧严重。
接下来则是第三种情况：设置圆角且带图片的UIButton
?此时，CPU的占用情况为加载时的CPU占用20%左右，上下快速滑动占用16%。这很奇怪是不是，为什么设置圆角反而减少了CPU的使用？
?其实，原因就在，正是因为离屏渲染减轻了cpu的负担。我们都知道离屏渲染会增加gpu的负担，创建了很多额外缓存空间已经大量的上下文切换，如上图的情况，即使CPU的占用率相比不设圆角降低了，但仍然会出现掉帧、卡顿的情况，而这与图片大小已无关系。
iOS设备的硬件时钟会发出Vsync（垂直同步信号），然后App的CPU会去计算屏幕要显示的内容，之后将计算好的内容提交到GPU去渲染。随后，GPU将渲染结果提交到帧缓冲区，等到下一个VSync到来时将缓冲区的帧显示到屏幕上。也就是说，一帧的显示是由CPU和GPU共同决定的。
假设在一个Vsync到来时，GPU还没有渲染好，这一帧就会被丢弃，等待下一次机会，此时屏幕上显示的还是之前的内容，这就是界面卡顿的原因。也就是说，不管GPU还是CPU阻碍了显示的流程，都会造成掉帧的现象。而上述的大量的圆角触发离屏渲染，使GPU的资源占满，而CPU的资源消耗很少，此时造成掉帧和卡顿。
那么cpu消耗的资源更少的原因是什么？（如果有大佬知道为什么，也请告诉一下= =）
这我也无法给出准确答案，猜测是因为CPU此时所需要渲染的显示比切圆角前更少。
写本篇文章参考了不少资料，在自己测试的过程中慢慢找原因，对于自己最初的问题，列表滑动及加载的时候卡顿掉帧的原因，也算是找到了其中一部分，但没有完全解决，回头会慢慢写出来
总结：
- 在设置列表中的图片时，特别是头像类的，可以使用压缩后的图片，减小图片的大小，能有效减少卡顿，若使用用户拍的照片或者别的大图片，在列表的滑动和加载过程中，可能会出现卡顿掉帧
- 在设置头像的圆角时，不应该使用 CornerRadius 和 MasksToBound ，在少量的情况下也许不会影响什么性能，但若图片很多且滑动比较快的话，因为离屏渲染造成的卡顿掉帧也会比较明显。