作为开发者都想成为性能优化这方面的高手，因为所有App开发都离不开优化这个重要的环节，每个开发者开发出的产品都不可能一次做到最优，所以在产品上线前就需要不断的测试和优化，等到产品上线时避免一些闪退、卡顿等BUG的出现。那么，想找到问题就可以借助工具来对App进行监测，推荐使用友盟+u-apm应用性能监控这款工具！以下文章针对IOS App卡顿问题谈谈原因，以及如何监测卡顿并且如何去解决。
1.卡顿产生的原因及优化
产生卡顿是由于屏幕的成像显示导致，而屏幕画面的显示离不开手机的CPU和GPU;先来看下IOS屏幕成像显示的过程：
1.1屏幕成像显示的过程
从上图可以看出，CPU先计算出图像的布局，大小，位置等信息;(CPU计算出来的数据是不能直接显示到屏幕上的)
GPU将CPU计算的数据，渲染到帧缓存中;
要显示图像的时候，视频控制器从帧缓存中读取图像，显示到屏幕上;
1.2 屏幕成像显示的原理：
iPhone的刷帧频率是 60 FPS，也就是每秒显示60帧数据;
每帧图像显示的时间间隔是：1000ms / 60 fps = 16ms;
屏幕在显示一帧数据的时候：
会先发送一条垂直同步信号；
然后会从上至下发送水平同步信号，填充整个屏幕，显示这一帧的数据;
重点：每隔16ms就会显示下一帧数据，接收到垂直同步信号 代表开始显示下一帧的内容
1.3 显示和卡顿产生的根本原因：
之前介绍，屏幕成像在CPU计算和GPU渲染到帧缓存区之后，再由视频控制器读取并显示到屏幕上。如下图所示：
1、2、3、4、5 代表5帧数据的显示流程；
红色箭头代表CPU计算所用时间，蓝色箭头代表GPU渲染所用时间;
第一帧 1：CPU和GPU所花的时间 ==16ms，所以在垂直同步信号到来的时候，帧缓存中有完整的数据，正常展示;
第二帧 2：CPU和GPU所花的时间 < 16ms, 超前将要显示的内容绘制到帧缓存中，正常展示;
第三帧 3：CPU和GPU所花的时间 > 16ms, 16ms内这一帧的数据还没渲染完成，垂直同步信号已经到来，帧缓存中的数据不全，这一帧会继续显示上一帧(第二帧)的内容;所以这就是卡顿的原因;
第四帧 4：在这一次的显示中，第三帧的内容CPU和GPU渲染刚完成，当垂直信号到来时，去帧缓存中去读取并直接显示第三帧的内容;
第五帧 5：同第二帧，正常展示;
所以我们找到了IOS App卡顿产生的根本原因：
在一帧显示的频率16ms中，如果CPU和GPU没有将要显示的内容渲染到帧缓存中，当前垂直同步信号到来的时候，就会显示上一帧的内容;这一帧的内容，会在下一个周期16ms后，垂直同步信号再次到来的时候，显示到屏幕上。
1.4卡顿检测：
平时所说的“卡顿”主要是因为在主线程执行了比较耗时的操作，可以添加Observer到主线程RunLoop中，通过监听RunLoop状态切换的耗时，以达到监控卡顿的目的。
可以使用检测工具检测卡顿出现的原因，这里推荐友盟+u-apm应用性能检测工具。
1.4 解决卡顿的方式CPU和GPU：
CPU：
1、使用轻量级的对象：比如不用点击的地方，使用CALayer代替UIView;
2、不要频繁的修改属性：frame，bounds，transfrom等，这些都需要CPU的计算;
3、尽量提前计算好布局：计算好frame，bounds等，一次性修改，不要多次修改;
4、使用AutoLayout比直接设置frame消耗更多的资源;
5、图片的size最好和UIImageView的size保持一致，这样就不用耗费CPU资源去进行缩放操作;
6、控制线程的最大并发数量：比如说3，不要无限制的开辟新的线程;
7、尽量耗时操作放到子线程。
GPU：
1、尽量减少视图的数量和层级：多层次的视图绘制更占用GPU资源;
2、尽量避免短时间大量图片的显示：可以合成为一张图片展示;
3、GPU能处理的图片的最大尺寸是4096x4096,尽量不要超过这个尺寸;
4、减少透明视图的使用 alpha < 1,重叠部分：有透明度：需要混合计算;不透明：计算一次(最上层的颜色)；
5、避免离屏渲染。
综上所述，介绍了IOS App卡顿产生的原因，以及卡顿的优化方式，希望能够给大家提供帮助。那么，针对App卡顿的问题可以借助工具来进行监测，友盟+u-apm应用性能监控平台，可以帮助开发者监测App遇到的问题，比如：卡顿、内存、App崩溃、闪退等问题。另外，友盟还提供了“云真机”服务，助力开发者从研发测试质量验收到线上问题复现排查，保障应用品质，提升测试效率。在云真机测试期间自动采集崩溃信息，提供详尽的崩溃报告协助筛查，真正实现监控测试全流程深度打通。
