上一篇《AutoLayout 相关概念介绍和动画demo》提到了一些Core Aniamtion的基础知识,这篇依然介绍一些基本概念,最后提到一点iOS8的动画改动。
说到Core Animation 不能不说Layer, 一个个Layer通过tree的结构组织起来,在Display的过程中实际上有3种Layer tree。
model Layer tree
中的Layer是我们通常意义说的Layer。当我们修改layer中的属性时,就会立刻修改model layer tree。
layer.position = CGPointMake(0,0); //这里的修改会直接影响model layer tree
presentation tree
是Layer在屏幕中的真实位置。比如我们创建一个动画
1 2 3 4 5 6 7 8 9 |
|
下面是屏幕输出结果
model:{73.5, 155.5}, presentLayer{73.5, 155.5}
model:{200, 400}, presentLayer{73.559769, 155.61552}//开始动画
model:{200, 400}, presentLayer{73.814095, 156.10709}
model:{200, 400}, presentLayer{74.267357, 156.98315}
...
...
...
model:{200, 400}, presentLayer{199.99576, 399.99182}
model:{200, 400}, presentLayer{200, 400}
Note: render tree 在apple的render server进程中,是真正处理动画的地方。而且线程的优先级也比我们主线程优先级高。所以有时候即使我们的App主线程busy,依然不会影响到手机屏幕的绘制工作。
了解cocos2dx对CADisplayLink一点也不陌生,对APP开发者可能就有一点远,但是facebook的Pop一下子拉近了我们和CADisplayLink的距离。通过设置callback函数,当屏幕刷新的时候,就可以执行我们的代码。当然,我们也可以利用NSTimer 或是GCD来实现类似的功能。但是CADisplayLink是最优的,因为不管是哪种类型的Timer,即使我们的刷新间隔和屏幕刷新保持一致。我们都无法知道系统什么时候刷新屏幕。
1-1 NSTimer中每一帧其实只有8ms的时间,如果大于8ms,那么就会丢帧
facebook的Pop非常类似UIDynamic,但是我们需要注意一点,相对于传统的model动画来说,CADisplayLink导致部分绘制工作放在了我们APP的地址空间中,也就是说,增大了APP内存,CPU的开销。也更容易遇到性能瓶颈。
Note: model layer的这部分绘制是完全在render server,而render server运行在比APP更高优先级的进程中,而这个也意味着会有进程间通讯的开销。传递的数据包括整个render tree还有动画,所以,Apple 并不推荐我们手动commit transaction, Core Animation 默认会在run loop 中提交transaction。
Apple 最近在推荐一些Modern APP的设计,其中有一条是希望responsive。比如下面的场景,启动一个动画之后,在动画还没有完成之前取消这个动画。
这里我们看到了3种情况。
UIKit的动画最后都会通过Core Animation 来实现, 那么当我们修改layer(model layer)的数值时,系统是如何理解并创建动画呢? 比如这里有一个线性的动画,将animationView的坐标从(0,0)移动到(0,500)
1 2 3 4 5 6 7 8 9 |
|
animationView.center = CGPointMake(0, 500);
之后会立刻修改animationView
的model Layer中的position
的值为(0, 500)。animationView
当前在屏幕的真实位置(渲染位置),因为还没有”动”起来,所以还是(0,0)Note: Animation的部分如果没有明白,可以结合后面的回头再看
这是在0.4s时刻之前的状态。Model Layer的数值没有变化,而Presentation则在变化,和真正的屏幕动画保持一致。
如果我们在0.5时刻创建一个reverse动画,animationView.center = CGPointMake(0, 0);
1 2 3 4 5 6 7 8 |
|
到目前为止,我们可以清楚的理解为什么红色的view会有一个大的跳跃,在我们这里的理解就是presentation layer的一个不连续的修改。
在上面的基础之前,绿色的就可以简单说一些
linear animation 图中的颜色和本文的颜色无关,只是表示2个动画的stage
EseInOut animation 图中的颜色和本文的颜色无关,只是表示2个动画的stage
可以看出来2个动画相接的曲线不平滑,而造成这个不平滑的原因在于把之前的动画覆盖了, 丢掉了之前动画的速度,如果要实现一个更一般化的解决方案,我们很自然的想到了动画合成。
蓝色的动画比较复杂,使用了Core Animation中的additive属性,动画被设置成相对的,那么就和动画具体的位置无关。最后还合成了2个动画。
首先,解释一下什么是相对的动画。
这里很容易看到,view的真实位置是Animation 的值 + Model的值。系统的理解就是相对目标值(0, 500)来说,创建一个从-500 到 0 的动画。
其次,相比之前的动画,在0.6时刻(为了方便计算,把之前的0.5时刻移动到了0.6时刻)并没有删除掉之前的动画,而是添加了一个新的动画Animation2。也就是一个相对目标值(0,0)来说,创建一个从500到0的动画。整个运动变成了2个动画的合成。
Note: Animation2的duration修改了,在demo code里面并没有修改 :)
这里,我们就得到了一个一般化的解决方案。
图中的颜色和本文的颜色无关,只是表示2个动画的stage
Core Animation 有一个additive的属性实际上已经存在很久了,但是却很少被大家知道(我自己也是)。在iOS8 之前,UIKit创建的动画默认是不使用additive的,而在iOS8之后,默认是Additive的。有兴趣的同学可以试一试download demo code用Xcode6(这会还是beta)并打开macro#define USING_UIKIT 1
看一下新的UIKit animation效果。
在了解背后的机制之后,其中的变化也很容易理解。
……