13518219792
一、优先级别不同：iOS最先响应屏幕
创新互联是一家专业的成都网站建设公司，我们专注成都网站设计、网站制作、外贸营销网站建设、网络营销、企业网站建设，卖友情链接，一元广告为企业客户提供一站式建站解决方案，能带给客户新的互联网理念。从网站结构的规划UI设计到用户体验提高，创新互联力求做到尽善尽美。
当我们使用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终端正在摆脱卡顿不流畅的束缚，未来安卓用户的期待同样有望得到更好的满足。
面试的时候总会遇到以下问题：
在屏幕成像的过程中，CPU和GPU起着至关重要的作用。
那CPU和GPU是怎么协作呢？
一个app的展示会包含很多内容，诸如，label，imageview，button等等。这些控件的位置，大小，颜色则都是由CPU来计算，计算完成后CPU会将这些数据提交给GPU来进行渲染，只有经过GPU的渲染才能显示在屏幕上。GPU做的操作则是：将收到的数据转成屏幕能显示的数据格式，所以要进行渲染的操作。渲染的操作是直接放在帧缓存（缓存区）。然后视频控制器从缓存区 读取的数据显示在屏幕上。就完成了一个显示的操作。
在屏幕显示过程中是有信号发送的。一帧一帧的。
屏幕内容是怎么显示到屏幕上的？
CPU（红色）——GPU（蓝色）
1.CPU完成计算，提交给GPU渲染，这是来个垂直同步信号，则会将渲染的内容显示到屏幕上。
2.CPU计算时间正常，CPU渲染时间短，等待VSync
3.CPU计算时间正常或慢，GPU渲染时间长，这时来了VSync，而这一帧还没有渲染完，那么就会出现掉帧现象，屏幕回去显示上一帧的画面。这样就产生了卡顿。
4.而当下一帧VSync出现时，丢掉的那一帧画面才会出现。
1.On-SCreen Rendering：当前屏幕渲染，在当前用语显示的屏幕缓冲区进行渲染操作。
2.Off-Screen Rendring： 离屏渲染，在当前屏幕缓冲区以外新开辟一个缓冲区进行渲染操作。
1.需要创建新的缓冲区；
2离屏渲染的整个过程，需要多次切换上下文环境，先是从当前屏幕切换到离屏；等到离屏渲染结束以后，将离屏缓冲区的渲染结果显示到屏幕上，又需要将上下文环境从离屏切换到当前屏幕
1.光栅化，layer.shouldRasterize = YES
2.遮罩，layer.mask
3.圆角，同时设置layer.maskToBounds = Yes，Layer.cornerRadis 大于0
考虑通过CoreGraphics绘制裁剪圆角，或者美工提供圆角图片
4.阴影，layer.shadowXXX
如果设置了layer.shadowPath就不会产生离屏渲染
平时所说的“卡顿”主要是因为在主线程执行了耗时的操作。
可以添加Observer到主线程RunLoop中，通过监听RunLoop状态切换的耗时，以达到监听卡顿的目的
推荐一个库：LXDAppFluecyMonitor
1.关于关键字volatile
一个定义为volatile的变量是说这变量可能会被意想不到地改变，这样，编译器就不会去假设这个变量的值了。精确地说就是，优化器在用到这个变量时必须每次都小心地重新读取这个变量的值，而不是使用保存在寄存器里的备份。就像大家更熟悉的const一样，volatile是一个类型修饰符。它是被设计用来修饰被不同线程访问和修改的变量。如果不加入volatile，基本上会导致这样的结果：要么无法编写多线程程序，要么编译器失去大量优化的机会。
Volatile变量具有 synchronized 的可见性特性，但是不具备原子特性。这就是说线程能够自动发现 volatile变量的最新值。Volatile变量可用于提供线程安全，但是只能应用于非常有限的一组用例：多个变量之间或者某个变量的当前值与修改后值之间没有约束。因此，单独使用 volatile 还不足以实现计数器、互斥锁或任何具有与多个变量相关的不变式（Invariants）的类（例如 “start =end”）。
出于简易性或可伸缩性的考虑，您可能倾向于使用 volatile变量而不是锁。当使用 volatile变量而非锁时，某些习惯用法更加易于编码和阅读。此外，volatile变量不会像锁那样造成线程阻塞，因此也很少造成可伸缩性问题。在某些情况下，如果读操作远远大于写操作，volatile变量还可以提供优于锁的性能优势。
代码示例
volatile int i=10;
int j = i;
...
int k = i;
volatile 告诉编译器i是随时可能发生变化的，每次使用它的时候必须从i的地址中读取，因而编译器生成的可执行码会重新从i的地址读取数据放在k中。编译器在产生release版可执行码时会进行编译优化，加volatile关键字的变量有关的运算，将不进行编译优化。
而优化做法是，由于编译器发现两次从i读数据的代码之间的代码没有对i进行过操作，它会自动把上次读的数据放在k中。而不是重新从i里面读。这样以来，如果i是一个寄存器变量或者表示一个端口数据就容易出错，所以说volatile可以保证对特殊地址的稳定访问，不会出错。
int square(volatile int *ptr) { return *ptr * *ptr; }
这段代码的目的是用来返指针ptr指向值的平方，但是，由于ptr指向一个volatile型参数，编译器将产生类似下面的代码：
int square(volatile int *ptr) {
int a,b;
a = *ptr;
b = *ptr;
return a * b;
}
由于*ptr的值可能被意想不到地该变，因此a和b可能是不同的。结果，这段代码可能返不是你所期望的平方值！正确的代码如下：
long square(volatile int *ptr) { int a; a = *ptr; return a * a; }
下面是volatile变量的几个使用：
并行设备的硬件寄存器（如：状态寄存器）
一个中断服务子程序中会访问到的非自动变量(Non-automatic variables)
多线程应用中被几个任务共享的变量
那么问题来了：
一个参数既可以是const还可以是volatile吗？答案是是的。一个例子是只读的状态寄存器。它是volatile因为它可能被意想不到地改变。它是const因为程序不应该试图去修改它。
一个指针可以是volatile 吗？答案是是的。尽管这并不很常见。一个例子是当一个中服务子程序修该一个指向一个buffer的指针时。
在编写多线程程序中使用volatile的关键点：
1.将所有的共享对象声明为volatile；
2.不要将volatile直接作用于基本类型；
3.当定义了共享类的时候，用volatile成员函数来保证线程安全；
在多线程中，我们可以利用锁的机制来保护好资源临界区。在临界区的外面操作共享变量则需要volatile，在临界区的里面则non-volatile了。
2.关键字const的位置
const意味着”只读”，分析下面的含义：
const int a;
int const a;// 前两个的作用是一样，a是一个常整型数。
const int *a;// 第三个意味着a是一个指向常整型数的指针（整型数是不可修改的，但指针可以）
int * const a;// 第四个意思a是一个指向整型数的常指针（指针指向的整型数是可以修改的，但指针是不可修改的）
int const * const a;// a是一个指向常整型数的常指针（指针指向的整型数是不可修改的，同时指针也是不可修改的）。表示a是一个指针常量，初始化的时候必须固定指向一个int常量或者int变量，之后就不能再指向别的地方了，它总是把它所指向的目标当作一个int常量。也可以写成const int* const a;含义相同。
合理地使用关键字const可以使编译器很自然地保护那些不希望被改变的参数，防止其被无意的代码修改。这样可以减少bug的出现。欲阻止一个变量被改变，可以使用 const 关键字。
在定义 const 变量时，通常需要对它进行初始化，因为以后就没有机会再去改变它了；对指针来说，可以指定指针本身为 const，也可以指定指针所指的数据为 const，或二者同时指定为 const；在一个函数声明中，const 可以修饰形参，表明它是一个输入参数，在函数内部不能改变其值；对于类的成员函数，若指定其为 const 类型，则表明其是一个常函数，不能修改类的成员变量；对于类的成员函数，有时候必须指定其返回值为 const 类型，以使得其返回值不为“左值”。
3.滑动的时候隐藏navigation bar
navigationController.hidesBarsOnSwipe = Yes;
4. 消除导航条返回键带的title
[[UIBarButtonItem appearance] setBackButtonTitlePositionAdjustment:UIOffsetMake(0, -60)
forBarMetrics:UIBarMetricsDefault];
5. 将Navigationbar变成透明而不模糊
[self.navigationController.navigationBar setBackgroundImage:[UIImage new]
forBarMetrics:UIBarMetricsDefault];
self.navigationController.navigationBar .shadowImage = [UIImage new];
self.navigationController.navigationBar .translucent = YES;
6. static
函数体内 static 变量的作用范围为该函数体，不同于 auto 变量，该变量的内存只被分配一次，因此其值在下次调用时仍维持上次的值；在模块内的 static 全局变量可以被模块内所用函数访问，但不能被模块外其它函数访问；在模块内的 static 函数只可被这一模块内的其它函数调用，这个函数的使用范围被限制在声明它的模块内；在类中的 static 成员变量属于整个类所拥有，对类的所有对象只有一份拷贝；在类中的 static 成员函数属于整个类所拥有，这个函数不接收 this 指针，因而只能访问类的static 成员变量。
7.用一个pan手势来代替UISwipegesture的各个方向
- (void)pan:(UIPanGestureRecognizer *)sender
{
typedef NS_ENUM(NSUInteger, UIPanGestureRecognizerDirection) {
UIPanGestureRecognizerDirectionUndefined,
UIPanGestureRecognizerDirectionUp,
UIPanGestureRecognizerDirectionDown,
UIPanGestureRecognizerDirectionLeft,
UIPanGestureRecognizerDirectionRight
};
static UIPanGestureRecognizerDirection direction = UIPanGestureRecognizerDirectionUndefined;
switch (sender.state) {
case UIGestureRecognizerStateBegan: {
if (direction == UIPanGestureRecognizerDirectionUndefined) {
CGPoint velocity = [sender velocityInView:recognizer.view];
BOOL isVerticalGesture = fabs(velocity.y) fabs(velocity.x);
if (isVerticalGesture) {
if (velocity.y 0) {
direction = UIPanGestureRecognizerDirectionDown;
}
else {
direction = UIPanGestureRecognizerDirectionUp;
}
}
else
{
if (velocity.x 0) {
direction = UIPanGestureRecognizerDirectionRight;
}
else
{
direction = UIPanGestureRecognizerDirectionLeft;
}
}
}
break ;
}
case UIGestureRecognizerStateChanged: {
switch (direction) {
case UIPanGestureRecognizerDirectionUp: {
[self handleUpwardsGesture:sender];
break ;
}
case UIPanGestureRecognizerDirectionDown: {
[self handleDownwardsGesture:sender];
break;
}
case UIPanGestureRecognizerDirectionLeft: {
[self handleLeftGesture:sender];
break;
}
case UIPanGestureRecognizerDirectionRight: {
[self handleRightGesture:sender];
break ;
}
default : {
break;
}
}
break;
}
case UIGestureRecognizerStateEnded: {
direction = UIPanGestureRecognizerDirectionUndefined;
break;
}
default:
break;
}
}
8. 拉伸图片不变形
??
等同于：
[[UIImage imageNamed:@""] stretchableImageWithLeftCapWidth:10 topCapHeight:10];
[[UIImage imageNamed:@""] resizableImageWithCapInsets:UIEdgeInsetsMake(10, 10, 10, 10)];
9. Gif图片显示优化
FLAnimatedImage可以帮你完成GIF的显示处理。解决GIF显示卡顿的情况。
FLAnimatedImage *image = [FLAnimatedImage animatedImageWithGIFData:[NSData dataWithContentsOfURL:[NSURL URLWithString:@""]]];
FLAnimatedImageView *imageView = [[FLAnimatedImageView alloc] init];
imageView.animatedImage = image;
imageView.frame = CGRectMake(0.0, 0.0, 100.0, 100.0);
[self.view addSubview:imageView];
使用就是这么简单。
10. CollectionView实现tableview的悬停header
??
CSStickyHeaderFlowLayout可以解决您的疑问。
#import "CSStickyHeaderFlowLayout.h"
- (void)viewDidLoad {
[super viewDidLoad]; // Locate your layout
CSStickyHeaderFlowLayout *layout = (id)self.collectionViewLayout;
if ([layout isKindOfClass:[CSStickyHeaderFlowLayout class]]) {
layout.parallaxHeaderReferenceSize = CGSizeMake(320, 200);
}
}
- (UICollectionReusableView *)collectionView:(UICollectionView *)collectionView viewForSupplementaryElementOfKind:(NSString *)kind atIndexPath:(NSIndexPath *)indexPath { // Check the kind if it's CSStickyHeaderParallaxHeader
if ([kind isEqualToString:CSStickyHeaderParallaxHeader]) {
UICollectionReusableView *cell = [collectionView dequeueReusableSupplementaryViewOfKind:kind withReuseIdentifier:@"header" forIndexPath:indexPath];
return cell;
}
}
就是这么简单。
然而问题恰恰就出现在这里，小同学千不该万不该把 _audioPlayer 对象作为了锁对象。
在 iOS离屏渲染 介绍了离屏渲染的逻辑和原理，我们知道离屏渲染对于性能会有较大的消耗，那么开发中怎么避免产生离屏渲染或者优化离屏渲染呢？
Color Off-screen Rendered 开启后会把那些需要离屏渲染的图层高亮成黄色，这就意味着黄色图层可能存在性能问题。
所以不裁剪子视图设置圆角的情况下是不会产生离屏渲染的
在iOS9之后苹果系统对圆角进行了优化，UIImageView和UILabel即使使用了layer.masksToBounds = YES;仍然不会产生离屏渲染，但是UIButton如果使用layer.masksToBounds = YES剪切子视图仍然会产生离屏渲染
②. 对图片进行提前切圆角的操作：
需要注意的是对图片切圆角时，最终的圆角是可能有缩放的，比如图片的尺寸imgSize为（100，200）而UIImageView的尺寸为（50，50）圆角尺寸如果为10，那么最终的效果是（100，200）的图片圆角为10，显示到UIImageView上x轴方向缩放2倍，y轴方向缩放4倍，所以这种方案缺点比较明显。
③. YYImage的圆角处理方案：
YYImage本质和第一种方案相同，都是对image的切圆角操作
④. 让UI切一个中间透明的镂空图片覆盖在UIImageView上
