ios开发优化,iOS app优化

iOS性能优化 - 整理

本文主要包含：

创新互联主营南部网站建设的网络公司,主营网站建设方案,App定制开发,南部h5小程序设计搭建,南部网站营销推广欢迎南部等地区企业咨询

卡顿产生的主要原因是又CPU、GPU引起的。

CPU(中央处理器): 对象的创建和销毁、对象属性的调整、布局计算、文本的计算和排版、图片的格式转换和解码、图像的绘制(Core Graphics)

GPU(图形处理器)：纹理的渲染

在OpenGL中，GPU有两种渲染方式

app中主要的耗电来源于： CPU处理、网络、定位、图像处理

优化方案：

描述一下ios的内存管理，在开发中对于内存的使用和优化包含哪些方面

内存管理准则：谁强引用过，谁就在不再使用时使引用计数减一。

对于内存的使用和优化常见的有以下方面：

重用问题：如UITableViewCells、UICollectionViewCells、UITableViewHeaderFooterViews设置正确的reuseIdentifier，充分重用。

尽量把views设置为透明：如果你有透明的Views你应该设置它们的opaque属性为YES。opaque这个属性给渲染系统提供了一个如何处理这个view的提示。如果设为YES，渲染系统就认为这个view是完全不透明的，这使得渲染系统优化一些渲染过程和提高性能。如果设置为NO，渲染系统正常地和其它内容组成这个View。默认值是YES。

不要使用太复杂的XIB/Storyboard：载入时就会将XIB/storyboard需要的所有资源，包括图片全部载入内存，即使未来很久才会使用。那些相比纯代码写的延迟加载，性能及内存就差了很多。

选择正确的数据结构：学会选择对业务场景最合适的数组结构是写出高效代码的基础。比如，数组: 有序的一组值。使用索引来查询很快，使用值查询很慢，插入/删除很慢。字典: 存储键值对，用键来查找比较快。集合: 无序的一组值，用值来查找很快，插入/删除很快。

gzip/zip压缩：当从服务端下载相关附件时，可以通过gzip/zip压缩后再下载，使得内存更小，下载速度也更快。

延迟加载：对于不应该使用的数据，使用延迟加载方式。对于不需要马上显示的视图，使用延迟加载方式。比如，网络请求失败时显示的提示界面，可能一直都不会使用到，因此应该使用延迟加载。

数据缓存：对于cell的行高要缓存起来，使得reload数据时，效率也极高。而对于那些网络数据，不需要每次都请求的，应该缓存起来，可以写入数据库，也可以通过plist文件存储。

处理内存警告：一般在基类统一处理内存警告，将相关不用资源立即释放掉

重用大开销对象：一些objects的初始化很慢，比如NSDateFormatter和NSCalendar，但又不可避免地需要使用它们。通常是作为属性存储起来，防止反复创建。

避免反复处理数据：许多应用需要从服务器加载功能所需的常为JSON或者XML格式的数据。在服务器端和客户端使用相同的数据结构很重要。

使用Autorelease Pool：在某些循环创建临时变量处理数据时，自动释放池以保证能及时释放内存。

正确选择图片加载方式：详情阅读细读UIImage加载方式

ios开发之uitableview优化机制有哪些

iOS开发UI篇—UITableviewcell的性能问题

一、UITableviewcell的一些介绍

UITableView的每一行都是一个UITableViewCell,通过dataSource的 tableView:cellForRowAtIndexPath:方法来初始化每⼀行

UITableViewCell内部有个默认的子视图:contentView,contentView是UITableViewCell所显示内容的父视图,可显示一些辅助指示视图

辅助指示视图的作⽤是显示一个表示动作的图标,可以通过设置UITableViewCell的 accessoryType来显示,默认是UITableViewCellAccessoryNone(不显⽰示辅助指⽰示视图), 其他值如下:

UITableViewCellAccessoryDisclosureIndicator

UITableViewCellAccessoryDetailDisclosureButton

UITableViewCellAccessoryCheckmark

还可以通过cell的accessoryView属性来自定义辅助指示视图(⽐如往右边放一个开关)

二、问题

cell的工作：在程序执行的时候，能看到多少条，它就创建多少条数据，如果视图滚动那么再创建新显示的内容。（系统自动调用）。即当一个cell出现在视野范围内的时候，就会调用创建一个cell。这样的逻辑看上去没有什么问题，但是真的没有任何问题吗？

当创建调用的时候，我们使用nslog打印消息，并打印创建的cell的地址。我们发现如果数据量非常大，用户在短时间内来回滚动的话，那么会创建大量的cell,一直开辟空间，且如果是往回滚，通过打印地址，我们会发现它并没有重用之前已经创建的cell，而是重新创建，开辟新的存储空间。

那有没有什么好的解决办法呢？

三、cell的重用原理

（1） iOS设备的内存有限,如果用UITableView显示成千上万条数据,就需要成千上万 个UITableViewCell对象的话,那将会耗尽iOS设备的内存。要解决该问题,需要重用UITableViewCell对象

（2）重⽤原理:当滚动列表时,部分UITableViewCell会移出窗口,UITableView会将窗口外的UITableViewCell放入一个对象池中,等待重用。当UITableView要求dataSource返回 UITableViewCell时,dataSource会先查看这个对象池,如果池中有未使用的UITableViewCell,dataSource则会用新的数据来配置这个UITableViewCell,然后返回给 UITableView,重新显示到窗口中,从而避免创建新对象 。这样可以让创建的cell的数量维持在很低的水平，如果一个窗口中只能显示5个cell，那么cell重用之后，只需要创建6个cell就够了。

（3）注意点：还有⼀个非常重要的问题:有时候需要自定义UITableViewCell(用⼀个子类继 承UITableViewCell),而且每⼀行⽤的不一定是同一种UITableViewCell,所以一 个UITableView可能拥有不同类型的UITableViewCell,对象池中也会有很多不同类型的 UITableViewCell,那么UITableView在重⽤用UITableViewCell时可能会得到错误类型的 UITableViewCell

解决⽅方案:UITableViewCell有个NSString *reuseIdentifier属性,可以在初始化UITableViewCell的时候传入一个特定的字符串标识来设置reuseIdentifier(一般用UITableViewCell的类名)。当UITableView要求dataSource返回UITableViewCell时,先 通过一个字符串标识到对象池中查找对应类型的UITableViewCell对象,如果有,就重用,如果没有,就传入这个字符串标识来初始化⼀一个UITableViewCell对象。

图片示例：

说明：一个窗口放得下（可视）三个cell，整个程序只需要创建4个该类型的cell即可。

四、cell的优化代码

代码示例：

1 #import "NJViewController.h"

2 #import "NJHero.h"

3

4 // #define ID @"ABC"

5

6 @interface NJViewController ()UITableViewDataSource, UITableViewDelegate

7 /**

8 * 保存所有的英雄数据

9 */

10 @property (nonatomic, strong) NSArray *heros;

11 @property (weak, nonatomic) IBOutlet UITableView *tableView;

12

13 @end

14

15 @implementation NJViewController

16

17 #pragma mark - 懒加载

18 - (NSArray *)heros

19 {

20 if (_heros == nil) {

21 // 1.获得全路径

22 NSString *fullPath = [[NSBundle mainBundle] pathForResource:@"heros" ofType:@"plist"];

23 // 2.更具全路径加载数据

24 NSArray *dictArray = [NSArray arrayWithContentsOfFile:fullPath];

25 // 3.字典转模型

26 NSMutableArray *models = [NSMutableArray arrayWithCapacity:dictArray.count];

27 for (NSDictionary *dict in dictArray) {

28 NJHero *hero = [NJHero heroWithDict:dict];

29 [models addObject:hero];

30 }

31 // 4.赋值数据

32 _heros = [models copy];

33 }

34 // 4.返回数据

35 return _heros;

36 }

37

38 - (void)viewDidLoad

39 {

40 [super viewDidLoad];

41 // 设置Cell的高度

42 // 当每一行的cell高度一致的时候使用属性设置cell的高度

43 self.tableView.rowHeight = 160;

44 }

45

46 #pragma mark - UITableViewDataSource

47 // 返回多少组

48 - (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView

49 {

50 return 1;

51 }

52 // 返回每一组有多少行

53 - (NSInteger) tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section

54 {

55 return self.heros.count;

56 }

57 // 当一个cell出现视野范围内的时候就会调用

58 // 返回哪一组的哪一行显示什么内容

59 - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath

60 {

61 // 定义变量保存重用标记的值

62 static NSString *identifier = @"hero";

63

64 // 1.先去缓存池中查找是否有满足条件的Cell

65 UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:identifier];

66 // 2.如果缓存池中没有符合条件的cell,就自己创建一个Cell

67 if (cell == nil) {

68 // 3.创建Cell, 并且设置一个唯一的标记

69 cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleSubtitle reuseIdentifier:identifier];

70 NSLog(@"创建一个新的Cell");

71 }

72 // 4.给cell设置数据

73 NJHero *hero = self.heros[indexPath.row];

74 cell.textLabel.text = hero.name;

75 cell.detailTextLabel.text = hero.intro;

76 cell.imageView.image = [UIImage imageNamed:hero.icon];

77

78 // NSLog(@"%@ - %d - %p", hero.name, indexPath.row, cell);

79

80 // 3.返回cell

81 return cell;

82 }

83

84 #pragma mark - 控制状态栏是否显示

85 /**

86 * 返回YES代表隐藏状态栏, NO相反

87 */

88 - (BOOL)prefersStatusBarHidden

89 {

90 return YES;

91 }

92 @end

iOS性能优化 视图渲染

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重新绘制会消耗性能，因此重绘区域越小越少，性能越好。

iOS性能优化

在性能优化中一个最具参考价值的属性是FPS:Frames Per Second,其实就是屏幕刷新率，苹果的iphone推荐的刷新率是60Hz，也就是说GPU每秒钟刷新屏幕60次，这每刷新一次就是一帧frame，FPS也就是每秒钟刷新多少帧画面。静止不变的页面FPS值是0，这个值是没有参考意义的，只有当页面在执行动画或者滑动的时候，FPS值才具有参考价值，FPS值的大小体现了页面的流畅程度高低，当低于45的时候卡顿会比较明显。

图层混合：

每一个layer是一个纹理，所有的纹理都以某种方式堆叠在彼此的顶部。对于屏幕上的每一个像素，GPU需要算出怎么混合这些纹理来得到像素RGB的值。

当Sa = 0.5时，RGB值为(0.5, 0, 0)，可以看出，当两个不是完全不透明的CALayer覆盖在一起时,GPU大量做这种复合操作，随着这中操作的越多，GPU越忙碌，性能肯定会受到影响。

公式：

R = S + D * ( 1 – Sa )

结果的颜色是源色彩(顶端纹理)+目标颜色(低一层的纹理)*(1-源颜色的透明度)。

当Sa = 1时，R = S,GPU将不会做任何合成，而是简单从这个层拷贝，不需要考虑它下方的任何东西(因为都被它遮挡住了)，这节省了GPU相当大的工作量。

1、模拟器debug- 选中 color blended layers红色区域表示图层发生了混合

2、Instrument-选中Core Animation-勾选Color Blended Layers

避免图层混合：

1、确保控件的opaque属性设置为true，确保backgroundColor和父视图颜色一致且不透明

2、如无特殊需要，不要设置低于1的alpha值

3、确保UIImage没有alpha通道

UILabel图层混合解决方法：

iOS8以后设置背景色为非透明色并且设置label.layer.masksToBounds=YES让label只会渲染她的实际size区域，就能解决UILabel的图层混合问题

iOS8 之前只要设置背景色为非透明的就行

为什么设置了背景色但是在iOS8上仍然出现了图层混合呢？

UILabel在iOS8前后的变化，在iOS8以前，UILabel使用的是CALayer作为底图层，而在iOS8开始，UILabel的底图层变成了_UILabelLayer，绘制文本也有所改变。在背景色的四周多了一圈透明的边，而这一圈透明的边明显超出了图层的矩形区域设置图层的masksToBounds为YES时，图层将会沿着Bounds进行裁剪 图层混合问题解决了

iOS离屏渲染

怎么检测离屏渲染：

1、模拟器debug-选中color Offscreen - Renderd离屏渲染的图层高亮成黄 可能存在性能问题

2、真机Instrument-选中Core Animation-勾选Color Offscreen-Rendered Yellow

离屏渲染的触发方式

设置了以下属性时，都会触发离屏绘制：

1、layer.shouldRasterize（光栅化）

光栅化概念：将图转化为一个个栅格组成的图象。

光栅化特点：每个元素对应帧缓冲区中的一像素。

2、masks（遮罩）

3、shadows（阴影）

4、edge antialiasing（抗锯齿）

5、group opacity（不透明）

6、复杂形状设置圆角等

7、渐变

8、drawRect

例如我们日程经常打交道的TableViewCell,因为TableViewCell的重绘是很频繁的（因为Cell的复用）,如果Cell的内容不断变化,则Cell需要不断重绘,如果此时设置了cell.layer可光栅化。则会造成大量的离屏渲染,降低图形性能。

如果将不在GPU的当前屏幕缓冲区中进行的渲染都称为离屏渲染，那么就还有另一种特殊的“离屏渲染”方式：CPU渲染。如果我们重写了drawRect方法，并且使用任何Core Graphics的技术进行了绘制操作，就涉及到了CPU渲染。整个渲染过程由CPU在App内同步地完成，渲染得到的bitmap最后再交由GPU用于显示。

现在摆在我们面前得有三个选择：当前屏幕渲染、离屏渲染、CPU渲染，该用哪个呢？这需要根据具体的使用场景来决定。

尽量使用当前屏幕渲染

鉴于离屏渲染、CPU渲染可能带来的性能问题，一般情况下，我们要尽量使用当前屏幕渲染。

离屏渲染 VS CPU渲染

由于GPU的浮点运算能力比CPU强，CPU渲染的效率可能不如离屏渲染；但如果仅仅是实现一个简单的效果，直接使用CPU渲染的效率又可能比离屏渲染好，毕竟离屏渲染要涉及到缓冲区创建和上下文切换等耗时操作

UIButton 的 masksToBounds = YES又设置setImage、setBackgroundImage、[button setBackgroundColor:[UIColor colorWithPatternImage:[UIImage imageNamed:@"btn_selected"]]];

下发生离屏渲染，但是[button setBackgroundColor:[UIColor redColor]];是不会出现离屏渲染的

关于 UIImageView,现在测试发现(现版本: iOS10),在性能的范围之内,给UIImageView设置圆角是不会触发离屏渲染的,但是同时给UIImageView设置背景色则肯定会触发.触发离屏渲染跟 png.jpg格式并无关联

日常我们使用layer的两个属性，实现圆角

imageView.layer.cornerRaidus = CGFloat(10);

imageView.layer.masksToBounds = YES;

这样处理的渲染机制是GPU在当前屏幕缓冲区外新开辟一个渲染缓冲区进行工作，也就是离屏渲染，这会给我们带来额外的性能损耗。如果这样的圆角操作达到一定数量，会触发缓冲区的频繁合并和上下文的的频繁切换，性能的代价会宏观地表现在用户体验上——掉帧

光栅化

光栅化是将几何数据经过一系列变换后最终转换为像素，从而呈现在显示设备上的过程，光栅化的本质是坐标变换、几何离散化

我们使用 UITableView 和 UICollectionView 时经常会遇到各个 Cell 的样式是一样的，这时候我们可以使用这个属性提高性能：

cell.layer.shouldRasterize=YES;

cell.layer.rasterizationScale=[[UIScreenmainScreen]scale];

页面间跳转的性能优化：

ios app性能优化有哪些方面

一、优先级别不同：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终端正在摆脱卡顿不流畅的束缚，未来安卓用户的期待同样有望得到更好的满足。