导航控制器在pushViewController时的动画卡顿问题
问题描述：
在使用UINavigationController的-pushViewController:animated:执行入栈一个子控制器操作时(即最新栈顶子控制器)，会出现推出(即入栈)"卡顿"现象
[self.navigationController pushViewController:detailVC animated:YES];
原因：
这是因为从iOS7开始， UIViewController的根view的背景颜色默认为透明色(即clearColor)，所谓"卡顿"其实就是由于透明色重叠后，造成视觉上的错觉，所以这并不是真正的"卡顿"，但这种"卡顿"现象还是让人觉得极其不舒服的，还是务必得解决的！
解决方法：
只要在该UINavigationController所push的那个子控制器C(C即当前最新栈顶子控制器)中设置该C的根view的背景颜色赋值为某颜色，即取缔默认的透明色 (即clearColor)，就能解决所谓的"卡顿"问题啦！
如：在C的-viewDidLoad方法中写上
self.view.backgroundColor = [UIColor whiteColor];
一些扩展...
iOS 滑动性能优化
一、 减少图层的Blend操作
展示半透明的view，设备会把当前图层和背景图层进行alpha叠加，这是一项很耗性能的一件事。如果动画中每一帧都做叠加，性能的损耗是很严重。
UIView的背景色避免使用clearColor
UIView记得设置成和SuperView相同的颜色
动作虽小，效果却好
尤其是在需要滑动的场景控件贴图避免使用带alpha的图片
视觉给出的贴图最好不带Alpha通道
如果必须使用Alpha，则主动去Alpha，提前和背景色合成为不含Alpha的图片
针对同一场景图片合成只需要做一次
一次合成，长期使用UIImageView 使用时避免半透明
Disable alpha blending except where needed. Unless you are intentionally working with images that contain transparency (drawing UI elements, for example), you should generally mark the view as opaque by checking Opaque checkbox in the attributes inspector, or setting the opaque property on the view itself.
UIImageView的半透明取决于以下几项：
显示的图片
View的opaque属性的值
View的alpha值
View的背景色
An opaque view is expected to fill its bounds with entirely opaque content—that is, the content should have an alpha value of 1.0. If the view is opaque and either does not fill its bounds or contains wholly or partially transparent content, the results are unpredictable. You should always set the value of this property to NO if the view is fully or partially transparent.
规则如下：
当Opaque属性为YES的时候，imageView的alpha属性会被忽略，图层是否半透明取决于图片和imageView本身的背景色的叠加结果。
如果叠加结果图全部不透明，则图层不透明，不会触发blend操作。
如果叠加结果中出现半透明区域，则整个图层都会变成不透明，会触发blend操作。
如果Opaque属性为NO的时候，图层是否半透明取决于图片和imageView的multiplied叠加结果确定。
简单理解，如果可能尽量：
设置Opaque为YES
背景色设置为不含alpha的颜色
alpha值最好也是1(不透明)。
适用场景
通用优化规则，不会造成副作用
二、适当使用Rasterize
针对内容比较固定的Cell，建议采用光栅化，让Core Animation框架帮我们完成图层的混合，生成一个静态图，优化帧率。
//离屏渲染 - 异步绘制 耗电
self.layer.drawsAsynchronously = true
//栅格化 - 异步绘制之后 ，会生成一张独立的图片 cell 在屏幕上滚动的时候，本质上滚动的是这张图片
//cell 优化，要尽量减少图层的数量，想当于只有一层
//停止滚动之后，可以接受监听
self.layer.shouldRasterize = true
//使用 “栅格化” 必须指定分辨率
self.layer.rasterizationScale = UIScreen.main.scale
适用场景
UITableView & UICollectionView & UIScrollView中内容变化不频繁的Cell
注：此优化需要Profile，使用Core Animation工具中的“ColorHitsGreenandMissesRed”工具调优
如果使用不当，可能适得其反
开启shouldRasterize后,CALayer会被光栅化为bitmap,layer的阴影等效果也会被保存到bitmap中。
当我们开启光栅化后,需要注意三点问题。
如果我们更新已光栅化的layer,会造成大量的offscreen渲染。
因此CALayer的光栅化选项的开启与否需要我们仔细衡量使用场景。只能用在图像内容不变的前提下的：
用于避免静态内容的复杂特效的重绘,例如前面讲到的UIBlurEffect
用于避免多个View嵌套的复杂View的重绘。
而对于经常变动的内容,这个时候不要开启,否则会造成性能的浪费。
例如我们日程经常打交道的TableViewCell,因为TableViewCell的重绘是很频繁的（因为Cell的复用）,如果Cell的内容不断变化,则Cell需要不断重绘,如果此时设置了cell.layer可光栅化。则会造成大量的offscreen渲染,降低图形性能。
当然,合理利用的话,是能够得到不少性能的提高的,因为使用shouldRasterize后layer会缓存为Bitmap位图,对一些添加了shawdow等效果的耗费资源较多的静态内容进行缓存,能够得到性能的提升。
三、避免图片资源的重采样
Image views can perform two operations that are relatively expensive performance-wise: scaling the image and alpha compositing the image with lower layers.
减少图片资源的重采样是一个费时给力的过程，涉及到插值算法，以双线性插值为例，每插值一个点需要用到周围四个点的像素值，运算量可见一斑。
直接对于UIImageView设置一个大图，在实际展示的时候会在主线程完成重采样的过程，耗时耗内存。
如何避免？
网络图片资源
请求接口时，服务端根据场景返回尺寸尽可能接近展示的图片资源。
此举既可以节省流量，又可以节省重采样的时间。
本地图片资源
有可能的话，针对不同场景放置多个尺寸的图片资源
针对应用场景生成一个适用于使用场景尺寸的图片资源，并在该场景中生成的图片
适用场景
所有需要使用图片的场景都可以使用此方案优化，无副作用。
总结
滑动性能优化这块儿涉及到的知识还是挺多的，不要盲目，过早的优化。使用Instrument找出瓶颈，然后合理使用不同的方案。性能优化有很多奇淫技巧，但通常做到上面几个大的点，基本上性能就能接受了。
