本文主要包含：
桥西网站建设公司成都创新互联,桥西网站设计制作，有大型网站制作公司丰富经验。已为桥西1000多家提供企业网站建设服务。企业网站搭建\成都外贸网站建设公司要多少钱，请找那个售后服务好的桥西做网站的公司定做！
卡顿产生的主要原因是又CPU、GPU引起的。
CPU(中央处理器): 对象的创建和销毁、对象属性的调整、布局计算、文本的计算和排版、图片的格式转换和解码、图像的绘制(Core Graphics)
GPU(图形处理器)：纹理的渲染
在OpenGL中，GPU有两种渲染方式
app中主要的耗电来源于： CPU处理、网络、定位、图像处理
优化方案：
入门级（建议）
1. 用ARC管理内存
2. 在正确的地方使用reuseIdentifier
3. 尽可能使Views透明
4. 避免庞大的XIB
5. 不要block主线程
6. 在Image Views中调整图片大小
7. 选择正确的Collection
8. 打开gzip压缩
中级（这些是你可能在一些相对复杂情况下可能用到的）
9. 重用和延迟加载Views
10. Cache, Cache, 还是Cache！
11. 权衡渲染方法
12. 处理内存警告
13. 重用大开销的对象
14. 使用Sprite Sheets
15. 避免反复处理数据
16. 选择正确的数据格式
17. 正确地设定Background Images
18. 减少使用Web特性
19. 设定Shadow Path
20. 优化你的Table View
21. 选择正确的数据存储选项
进阶级（这些建议只应该在你确信他们可以解决问题和得心应手的情况下采用）
22. 加速启动时间
23. 使用Autorelease Pool
24. 选择是否缓存图片
25. 尽量避免日期格式转换
一、优先级别不同：iOS最先响应屏幕
当我们使用iOS或者是Android手机时，第一步就是滑屏解锁找到相应程序点击进入。而这个时候往往是所有操控开始的第一步骤，iOS系统产品就表现出来了流畅的一面，但Android产品却给人一种卡顿的现象，更别说后续深入玩游戏或者进行其它操控了。这是为什么？
其实这与两个系统的优先级有关，iOS对屏幕反应的优先级是最高的，它的响应顺序依次为Touch--Media--Service--Core架构，换句话说当用户只要触摸接触了屏幕之后，系统就会最优先去处理屏幕显示也就是Touch这个层级，然后才是媒体（Media），服务（Service）以及Core架构。而Android系统的优先级响应层级则是Application--Framework--Library--Kernal架构，和显示相关的图形图像处理这一部分属于Library，你可以看到到第三位才是它，当你触摸屏幕之后Android系统首先会激活应用，框架然后才是屏幕最后是核心架构。
优先级的不同导致了iOS产品以及Android手机在操控过程中的表现差异，当你滑动屏幕进行操控的时候，iOS系统会优先处理Touch层级，而Android系统则是第三个才响应Library层级，这是造成它们流畅度不同的因素之一。
二、硬件工作配置不同：iOS基于GPU加速
目前智能手机硬件装备竞赛当中，其实处理器等配置已经达到了一个瓶颈期，各大旗舰产品在硬件比拼当中基本上没有太大的区别，而这时候GPU就成为了一个凸显差异的重要因素。一些大型软件像是3D游戏对GPU性能要求都会比较高，苹果iPhone产品采用的Power VR SGX系列GPU在当下来说非常的主流，跑分测试数据证明了它并不会比一些旗舰级别的Android产品差劲。
而iOS系统对图形的各种特效处理基本上正好都是基于GPU硬件进行加速的，它可以不用完全借助CPU或者程序本身，而是通过GPU进行渲染以达到更流畅的操控表现。但是Android系统产品则并非如此，因为Android需要适应不同的手机硬件，需要满足各种差异配置，所以很多图形特效大多都要靠程序本身进行加速和渲染，并严重依赖CPU运算的操作自然会加大处理器的负荷，从而出现卡顿的问题。虽然Android 4.0以及4.1等更高版本中进行了改进将硬件加速设为默认开启，但依旧无法做到所有特效全部都靠GPU进行加速。在很多Android手机里面都自带有“是否开启GPU渲染”这个功能选项，不过开启之后的改善也是微乎其微。
屏幕最先响应的优先级关系，再加上iSO本身GPU加速程序的特性，使得大家在操控过程中感觉iOS手机拥有着不错的流畅性。因为它本身的整个流程都是在为最大化的流畅做服务，不管是第一印象的滑动接触屏幕，还是你进一步使用程序之后的更深层操作都是如此。而GPU加速这点特性，应该是它优于Android系统流畅性的又一个因素。
三、开发机制不同：安卓机制效率低
Android的编程语言是JAVA，而iOS的则为Objective-C，不过要是说Android系统之所以有些卡顿是因为JAVA开发语言的关系，或者是拿它和Objective-C对比肯定会有人提出质疑。Objective-C的优势是效率高但比较“唯一”，而JAVA的优势则是跨平台不过运行效率相对偏低，其实这两个编程语言所带来的机制不同，就已经造成了各自系统之间的流畅性差异化。
iOS的Objective-C，编译器gcc，而这个gcc编译出来的代码又被苹果专为iOS架构优化到了极致，运行过程中也不需要虚拟机在中间插手，执行效率自然很高。这一段话应该是iOS系统本身运行程序的执行过程，而Android是通过JAVA虚拟机来执行，并且系统需要占用大量内存来换取执行速度，再加上不定期的内存自动回收机制，从而直接导致了卡顿现象的出现。
Android的JAVA编程本身运行效率比Objective-C低一些，而且再加上内存自动回收的机制，所以造成了一些卡顿不流畅的现象出现。但根据技术人员讲解，现代的JAVA虚拟机效率已经不再是最大的瓶颈，Android 4.0系统版本之后的卡顿现象明显得到了改善，所以这也是有用户并没有发现自己新买的Android手机出现太多卡顿现象的原因。看来编程语言和机制已经被Android进行了改善，这同样也不是造成它与iOS流畅性偏差的唯一因素，不过影响却是实实在在存在着。
三、系统设计不同：安卓APP无法统一
因为iOS产品的封闭性，所以所有的APP运行对象都比较单一，因为每个应用程序都是被运行在iPhone，iPad等iOS产品当中，它们有着很高的硬件利用效率。因为iOS系统的配件供应商只有那么几家，CPU也是一年换一次，这点不像Android终端年年变月月变，开发者很难遇见未来终端分辨率会包含多少种，GPU驱动会包含哪些等等，所以相对来说Android应用开发成本较高且收益较慢。而iOS应用开发则因为软硬件垂直整合而受益，这样一来苹果自然就保证了应用本身其与硬件产品之间的完美结合程度。
其实Android和iOS两大系统APP开发情况的不同，也正是它们开发和不开放的特性所造成的。如果要是拿旗舰Android手机加上一个专为这款旗舰产品设计的游戏，来和苹果iPhone运行对比的话，你真的不会遇到Android旗舰机出现卡顿延迟的问题，为什么因为这款游戏针对这款手机设计，在软硬等方面都达到了最大化的兼容和优化，自然就不会出现停滞的现象。
而Android系统程序要被安装在各种符合要求的手机上面，开发者也不可能针对所有的机器型号进行开发，只能在比较主流的机器上进行测试并保证运行效果，所以他们为了兼顾整个产品线只能不得不降低游戏体验以达到高中低产品可以共用的效果。最后那些占据了Android终端份额的大量大众用户们由于自己的手机不是旗舰产品而得不到流畅的使用体验，自然而然就会产生Android产品不如iOS流畅的抱怨。
不管是iOS产品感觉比Android流畅还是真的比它流畅，其实说到底原因很简单。苹果会花费一年甚至两年的时间去开发一个桌面icon，一种字体，并去测试屏幕点位，而Android终端中除了Nexus系列之外似乎没有太多产品可以做到用这么长的时间去做这么细致的事情。有网友说得好，Android做的更多的是“让系统跑起来”，而iOS拥有着苹果做的更多的则是“让系统以最高的效率跑起来”，或许这就是iOS产品比Android更流畅的原因吧。但更好的一面的是，随着谷歌对Android的持续升级以及各厂商对自家产品的循序改进，使得越来越多的Android终端正在摆脱卡顿不流畅的束缚，未来安卓用户的期待同样有望得到更好的满足。
在我们 iOS 开发的过程中，会遇到 APP 不流畅的情况。在 屏幕图像显示的那些事儿中 , 讲述了屏幕渲染的流程，当 GPU 或者 CPU 没有在屏幕每一次刷新时完成内容的提交，而造成渲染流水线耗时过长，就会导致重复渲染同一帧数据造成 图像掉帧 ，也就是所谓的”卡顿“。
为了保持流程的UI交互，App的刷新拼搏应该保持在 60fps 左右，其原因是因为 iOS 设备默认的刷新频率是60次/秒，而1次刷新（即 VSync 信号发出）的间隔是 ，所以如果在 16.67ms 内没有准备好下一帧数据，就会产生”卡顿"。 可以在程序中用 CADisplayLink 来测量帧率），然后在屏幕上显示出来，但应用内的 FPS 显示并不能够完全真实测量出性能，因为它仅仅测出应用内的帧率。
通过子线程监测主线程的 RunLoop ，判断两个状态（ kCFRunLoopBeforeSources 和 kCFRunLoopAfterWaiting ）之间的耗时是否达到一定阈值
UIKit 的单线程天性意味着 UI 要在主线程上更新，这意味着绘制会打断用户交互，甚至让整个 App 看起来处于无响应状态。但是如果能避免用户等待绘制完成就好多了。 针对这个问题，有一些方法可以用到：例如 异步渲染 ， Core Animation 提供了 drawsAsynchronously 属性。
drawsAsynchronously 属性对传入 -drawLayer:inContext:的CGContext 进行改动，允许 CGContext 延缓绘制命令的执行以至于不阻塞用户交互。它自己的 -drawLayer:inContext: 方法只会在主线程调用，但是 CGContext 并不等待每个绘制命令的结束。相反地，它会将命令加入队列，当方法返回时，在后台线程逐个执行真正的绘制。 根据苹果的说法。这个特性在需要频繁重绘的视图上效果最好（比如我们的绘图应用，或者诸如 UITableViewCell 之类的），对那些只绘制一次或很少重绘的图层内容来说没什么太大的帮助。
iOS性能优化的一个重要方面是视图渲染，在渲染的过程中避免出现图层混合，离屏渲染等问题，从而减少CPU和GPU的性能开销，达到性能优化的目的。
我们在开发调试过程中，可通过Xcode中的视图调试选项来帮助我们快速查找出渲染过程中的问题。
真机调试运行App项目，在Xcode的工具栏中选择，Debug - View Debugging - Rendering，其中有9个选项。
若使用的是模拟器，在Simulator工具栏的Debug选栏中也有视图调试的选项。
调试这几个选项，我们来具体看看，针对视图渲染有哪些具体问题需要优化。
在多个UI视图叠加的情况下，如果有透明或者半透明的控件，那么GPU会根据透明度去计算这些layer叠加在一起最终的显示的颜色。举例，如果顶层VeiwA颜色是红色RGB(255,0,0)，透明度是40%，底层ViewB颜色是绿色RGB(0,255,0)，那么最终叠加显示出来颜色是RGB(102,153,0)。
计算公式
这个渲染过程会消耗GPU性能，因此要避免出现图层混合。
顺便提一下：UIView的opaque属性默认为Yes。
opaque这个属性不是决定视图是否透明，而是决定在视图渲染过程的处理方式。视图是否透明跟 alpha 和 hidden 有直接关系。
如果视图不透明，就设置opaque为Yes，表示图形系统会将视图视为完全不透明，完全不透明视图应该使用完全不透明的内容来填充，该内容的alpha值应该为1.0（自身的alpha和填充颜色的alpha都应该为1.0），这样图形系统将不考虑它与其他视图的混合颜色计算，从而提高性能。若设置为NO，图形系统通常会将视图与其他内容合成，消耗性能。如果View是在scrollView中或者在动画中，对性能的提升更为明显。
有些View的子类使用drawRect:方法绘制自己的内容，那么opaque属性对其无效。
这个选项用来检测是否正确使用layer的shouldRasterize属性，该属性默认是NO，若 shouldRasterize为YES则开启光栅化。光栅化是将layer预先渲染成位图(bitmap)，然后缓存起来，缓存未被复用则标注为红色，缓存被复用会标注为绿色，红色越多，性能越差。使用光栅化的视图清晰度会降低。
苹果的GPU只解析32bit的颜色格式，32bit的颜色格式由RGBA(红、绿、蓝、透明度)四个颜色通道组成，每一个颜色通道都占据8bit，取值范围是[0, 255]。
如果某图片是GPU 不支持的颜色格式，那么图片需要被复制到CPU进行颜色格式转换，这样的图片会被标注为蓝色。蓝色越多，性能越差。
这个选项用来解析图层的颜色格式，具体用途暂不清楚。
打开这个选项后，UILabel都会被标注，标注为银白色或橙色，UIImageView的图片内容有部分透明时标注为紫罗兰色，全不透明时标注为橙色；有趣的是，xib中调整UILabel的textColor，当RGB三个颜色通道的色值一致时（如000000、999999、FFFFFF等），UILabel会被标注为银白色，当RGB三个颜色通道的色值不一样时（如999897等），UILabel会被标注为橙色。
这个选项用来调整颜色刷新频率。通常情况是以每10毫秒一次的频率更新图层调试颜色，选中这个选项则设置每帧画面都会刷新，没有了10毫秒的延迟。在需要加快颜色刷新频率的场景下使用，通常情况下用不到。
这个选项用来检测图片在展示时是否被放大或缩小，以及像素是否对齐。如果image.size和imageView.size不匹配（例如，image的实际大小是50×50，imageView的尺寸大小25×25，或者为200×200），图片在展示时会缩放或者放大图片，会消耗资源，imageView会被标注为黄色，黄色越多，性能越差。避免出现黄色标注，将imageView.size设置成与image.size一样的。
这个选项用来检测是会把那些离屏渲染的图层显示为黄色。黄色越多，性能越差。
屏幕渲染有 当前屏幕渲染 和 离屏渲染 两种方式。
常见的会引起离屏渲染的操作：
这个选项用来检测是否是直接使用 OpenGL 绘制的， 使用 OpenGL 绘制的图层会标注为蓝色。蓝色越多，性能越好。如果仅仅使用 UIKitAPI，那么不会有任何效果。
这个选项用来检测是否出现重新绘制，进行了重绘的区域会标注成黄色，使用Core Graphics重新绘制会消耗性能，因此重绘区域越小越少，性能越好。