iOS 卡顿原因及优化思路

很多iOS 开发，都会面临到解决开发过程中的卡顿问题。卡顿就是在应用使用过程中出现界面不响应或者界面渲染粘滞的情况，用户在 *** 作App时，会出现的页面掉帧现象，给用户直接观感受就是页面卡卡的，严重影响用户体验。这种情况下可以使用友盟+U-APM应用监控平台，对应用进行分析，找到卡顿原因，进行优化。

卡顿原因

卡顿产生的原因就是CPU和GPU没有及时处理好数据，针对卡顿的优化就有思路了：尽可能减少 CPU 和 GPU 资源的消耗。

卡顿优化 — CPU

1、尽量用轻量级的对象，比如用不到事件处理的地方使用CALayer取代UIView、能用 int 就不要去使用 NSNumber。

2、不要频繁地调用和调整UIView的相关属性，比如frame、bounds、transform等属性，尽量提前计算好布局，需要时一次性修改属性，减少不必要的调用和修改(UIView的显示属性实际都是CALayer的映射，而CALayer本身是没有这些属性的，都是初次调用属性时通过resolveInstanceMethod添加并创建Dictionry保存的，耗费资源)。

3、如果对象不涉及 UI *** 作，尽量放到后台子线程去处理。

4、Autolayout 会比直接设置 frame 消耗更多的 CPU 资源，相对布局最终到CPU那里也是计算出视图的绝对大小和位置的，如果不是特备复杂的位置关系，尽量用绝对布局，减少CPU的计算。

5、图片的 size 和 UIImageView 的 size 保持一致。大小一致，CPU不需要做拉伸压缩 *** 作。

6、控制线程的最大并发数量，线程过多CPU会很忙，而且CPU调度也需要时间。

7、针对不规则列表，缓存cell的高度、通过设置view的显示和隐藏替代动态创建。

8、xib和storyboard创建视图比纯代码更加消耗资源，不推荐使用。

9、耗时的 *** 作放到子线程，如文本处理（尺寸计算、绘制）、图片在子线程强制解码。

卡顿优化 — GPU

1、尽量避免短时间内大量图片的显示，尽可能将多张图片合成一张进行显示。

2、尽量减少透视图的数量和层次。

3、减少透明的视图（alpha < 1），不透明的就设置 opaque 为 YES，透明度涉及到混合颜色的计算。

4、GPU 能处理的最大纹理尺寸是 4096 * 4096，超过这个尺寸就会占用 CPU 资源，所以纹理不能超过这个尺寸。

5、尽量避免出现离屏渲染。

ios卡顿优化工作是一个复杂而艰巨的过程，尤其到后期更是如此，越是庞大的项目越需要对流畅度做优化，它涉及到代码的重构、逻辑的重写，甚至是底层架构，牵一发而动全身，所以开发人员必须在熟悉现有业务逻辑的前提下做优化，在不发生crash的情况下尽可能保持App的流畅性如行云流水一般。这就显出友盟+U-APM的重要性了，它能精准检测到APP的卡顿原因，让你根据问题根源进行优化。

U-APM应用性能监控平台，通过轻量级的集成接入即可拥有实时、可靠、全面的应用崩溃、ANR、自定义异常等捕获能力， 及卡顿、启动分析、内存分析、网络分析等性能监测能力，支持多场景、多通道智能告警监测，帮助 开发者高效还原异常、卡顿用户的访问路径和业务现场，缩短故障排查时间。提供云真机测试能力，助力开发者从研发测试质量验收到线上问题复现排查，保障应用品质，提升测试效率。在云真机测试 期间自动采集崩溃信息，提供详尽的崩溃报告协助筛查，真正实现监控测试全流程深度打通。