江湖传言
初入iOS江湖，涉世未深的少侠们，如果不是做特别复杂的UI和交互，那么可能根本从来没想要过iOS里竟然还要性能优化。毕竟iPhone的性能越来越强了，而做一个普通的APP的话，UIKit还是那个UIKit，同样一套代码，iphone4、iphone5的年代里，可能有些卡顿，但当前已经是有着最强CPU和最强GPU的iPhone8以及8Plus了，卡顿什么的，不存在的。
都这么说了，老夫干嘛还在这里矫情?
矫情还是要矫情的，毕竟除了iphone8和8Plus，有些用户可能还用着iphone5，phone6，用户是上帝，上帝的体验还要是照顾的。而且程序猿的身边往往还坐着个产品经理，经常会有意无意的迸发出奇妙的灵感，“欸，这里加个动画比较好” “这边整体搞个阴影比较好” “这里这个效果我觉得可以更酷炫一些”，站在公司业务的角度上，站在APP整体风格的基础上，对于不合理的需求和灵感吾等程序猿必要据理力争，能不做就不做。但是如果那个灵感较大的提升了用户体验，增加了用户趣味，但是确实实现起来可能对性能有些影响，这个时候吾等程序猿，不能牙齿紧闭、眉头紧锁，不敢应答。要气沉丹田，暗暗运力，祭出性能优化大法，方可快速完成任务，从而在产品妹子面前扳回一局。
话不多说，言归正传，性能优化大法在此:
熟读了上面两本秘籍，少侠便可千秋万载，一统江湖。
有的少侠说了，上面的秘籍不好消化，一不小心，几万行代码，量太多，杀鸡焉用牛刀，况且就算练完了也会有点囫囵吞枣的感觉，完全不清楚内里的运作，怕日后走火入魔，能不能我先练点简单的，稳扎稳打，待到日后我基本功深厚的时候，再去修炼绝世秘籍，方可天下无敌。
不错不错小小年纪，既有如此胸襟，小兄弟日后前程不可限量，老夫就把毕生所学传授与你罢。
唯快不破
iPhone每秒刷新60次，高端一点来说FPS(Frames Per Second)为60，1000ms除以60大约为16.7ms，意味着每次刷新只有16.7ms的时间给iPhone用来处理各种事务，当前事务不多时，iPhone可以轻松处理，FPS此时为60，体验如丝般顺滑。但当事务较多时，iPhone力不从心，不能在16.7ms处理完成，怎么办呢，当前这一帧就会被丢弃，等待下一次重新提交，而此时屏幕上的内容则保持不变，一次力不从心不影响，多几次就会被火眼金睛的用户发现啦，你们APP卡顿了哟。
所以我们的目的就是要快，争取在16.7ms内让iPhone顺利做完我们交代的所有事情，天下武功无坚不破，唯快不破，要让iPhone运行的够快，我们就需要分清楚它不够快的原因，对症下药。
内外兼修
习武之人，外修体，内练气，内外兼修，方能立于不败之地。iOS优化，也当以此为切入点，扬长补短。
CPU主外：对象创建、对象调整、对象销毁、布局计算、文本计算、文本渲染、图片解码、图像的绘制等操作是放在CPU上执行的。
GPU主内：纹理的渲染、视图混合、离屏渲染都是在GPU上执行的。
要想让CPU、GPU的速度够快，就要适当给它们减轻负担，活干的开心了，自然速度就上去了。了解了各自的分工，就能针对加强，扬长补短。
针对CPU，老夫先授予你些个入门招数：
- 使用手动布局
UI相关的操作，只能在主线程执行，不然就崩溃给你看，就是这么任性。苹果如此设计之初，可能也没有想到APP后来的发展会如此复杂，会比电脑还要强劲，但是悔不当初，当前APP已经太多了，想要修改也没那么容易了，不然还各种开源框架什么事。既然只能在主线程，那在性能要求敏感的页面，就不要使用Xib和StoreBoard了，手动创建往往是一个更好的选择。关于Xib和StoreBoard对性能的影响，感兴趣的同学可以自行搜索秘籍。
- 费时费力的操作放在后台线程执行
非UI相关的操作，选择就多了，现在CPU，都已经是多核的了，合理利用多线程，做到左手画方，右手画圆，往往事半功倍。例如把文件读取，数据计算放在子线程会给CPU更多的时间去处理UI相关的任务。
- 缓存Cell高度
对于高度可变的Cell，在网络数据请求完成的时候，在后台线程计算Cell的高度，并缓存在内存当中，这样tableView滚动的时候，就无需多次计算。不止Cell的高度，例如Cell里有一个行数不固定label，把label的高度也提前计算好并缓存，少侠会有意想不到的效果。当然这一操作也是要放在后台线程执行的。
- 图片的实际大小和UIImageView的大小一致
当对一个UIImageView设置一个较大的image时，需要在主线程完成重采样的过程，耗时耗内存，所以尽量在设置图片时设置的和UIImageView的大小相近。
针对GPU老夫也先教你些个入门招数：
- 减少图层混合操作
当只有一个视图显示屏幕上的时候，那么视图是什么颜色就显示什么颜色，这个时候不存在图层混合。
当有多个视图叠加的时候，如果最上层的视图是不透明的，有背景色的，那么也不存在视图混合。
当多个视图叠加，放在上面的视图是半透明的，那么这个时候GPU就要进行混合，把透明的颜色加上放在下面的视图的颜色混合之后得出一个颜色再显示在屏幕上，这一步是消耗GPU资源的，当混合的视图比较多的时候，GPU消耗的资源也越多。
所以为了减轻GPU负担，我们要减少图层混合操作。
这里老夫有几个小技巧，少侠可参考:
- UIView的backgroundColor不要设置为clearColor，最好设置的和superView的backgroundColor颜色一样。
- 图片避免使用带alpha通道的图片，无论是本地图片还是后台返回图片。什么，设计妹子不同意，少侠这就要靠你的魅力啦。
- 适当使用shouldRasterize
开启shouldRasterize后，layer会被光栅化bitmap，layer的各种边框、阴影等效果会被缓存在bitmap中，待下一次使用时，就可以直接拿bitmap来用，就不需要再次费时费力的做效果了。
有的少侠一听说这个，这可好，那都开启shouldRasterize不就完事了吗，效果和性能兼顾了。
且慢，老夫有言相劝：
- 针对内容比较固定的cell，建议采用光栅化。
- 效果复杂的静态内容，建议采用光栅化。
- 配合rasterizationScale使用，可以在不同屏幕上都显示良好的效果。
- 如果更新已经光栅化的layer，会造成离屏渲染，这就不好了。
- 不要过度使用，系统限制了缓存的大小，超过缓存大小，就造成离屏渲染，也是极不好的。
小有所成
现在少侠已经了学习了性能优化的入门秘籍，做到了内外双修，行走iOS江湖有了一定的技能傍身，日后遇上产品小师妹必能挺起胸膛，为伊人遮风挡雨。
欲知后事如何，且看下回分解： iOS性能优化（中级）
