animation - 1

最新推荐文章于 2022-11-25 14:52:08 发布

绘风铃

最新推荐文章于 2022-11-25 14:52:08 发布

阅读量595

点赞数

本文链接：https://blog.csdn.net/u013743777/article/details/46789087

版权

iOS - Animation 专栏收录该内容

17 篇文章 0 订阅

订阅专栏

转自：http://www.zhihu.com/question/21132970
iOS自带的基本动画效果一般有三种：（也有一种Block动画，纳入UIView里面）
1、UIView animation 动画。
2、UIImageView.images 形式的帧动画。
3、CoreAnimation的一些3D动画。
基本上2D的动画，用1和2单独或叠加使用就会有很好的效果了，但对设计师的动画设计要求比较高。3D动画，3能实现的也有限，简单的翻转一类的动画可用下，复杂的动画效果也不好用。
其它的3D/2D游戏引擎，如cocos2d，unity3d，等会有很多方便好用的动画实现方式，但不是iOS原生的了。

但是我们不着急先从动画入手，我们从动画的载体入手－ UIView

来一篇篇层次性地看看官方文档对UIView的阐述和介绍：

7月28日补充：无意接触的一篇博客：http://objccn.io/issue-12-1/

看完之后真想把我写的都删掉，我靠，写得太棒了！

View object

A view is an object that draws itself within a rectangular area of a window and that can respond to user actions such as finger taps or mouse clicks. A view draws a visual representation of itself and presents a surface that responds to touches and input from devices. Not all views handle events, but views are more likely to handle events than other types of responder objects (that is, objects capable of responding to events). Views also provide the content for printing. For a view to be useful, it must be situated in the view hierarchy of a window.

Views inherit, directly or indirectly, froma target="_self" NSView/a in Mac OSX or from UIView in iOS. These classes perform no drawing or event-handling themselves, but provide the interface and infrastructure for subclasses. The AppKit and UIKit frameworks provide almost all views that you see in an application’s window, including buttons, table views, text fields, toolbars, and sliders. These views are available to your project in the Interface Builder library. You can also subclassUIView orNSView and create custom views that draw themselves and handle events in distinctive ways.

view是一种能够绘制自身在矩形窗口并且能够对用户的动作例如手机点击或者鼠标点击有所响应的对象。一个视图画出一个可视化代表本身或者是代表一个界面并且这个界面对触碰和从界面设备输入有所响应。不是所有的视图都能处理事件，但是view比别的响应式对象更具备处理事件的能力（即能够响应事件的对象）。Views同时提供了打印的内容。为了view能够充分使用，它必须在被位于window的视图继承层次结构上。（view hierarchy 之后会介绍）

views继承，直接地或间接地，从： a target = "_self" NSView/a 在Mac OS X系统或者是从UIView在iOS系统。这些类并不执行任何绘制或者是事件处理，但是提供了接口或者是基础的架构给子类们。AppKit和UIKit框架提供了几乎任何你能在一个应用中看到的的视图，包括按钮，列表，输入框，toolbar和滚动条。这些视图在你的工程都可用。你也能够自定义UIView或者是NSView的子类不同地绘制并且用不同的方式去处理事件。

The Core Properties of Views

Views in both the UIKit and AppKit frameworks have important characteristics defined by a handful of properties:

View boundary and placement. The frame and bounds of a view define its boundaries and its relationships to other views. The frame specifies the placement and size of a view within its superview’s coordinate system; the bounds of a view specifies the local coordinate system that a view uses for drawing itself. (Views in UIKit also have a property that locates the center of their rectangular area.)
Relationship to other views. The superview, subview, and window properties specify a view’s place in the view hierarchy of its window. You add views (subviews) to enclosing views (superviews) to create compound views and, ultimately, to create a user interface. An autoresizing property specifies how a view’s subviews position and resize themselves when the enclosing view itself is resized.

Views无论在UIKit还是AppKit框架都有着重要的显著的特性并且被定义成非常好用的属性：

视图的界面和布局。视图的frame和bounds决定着view的界面和与其他view的布局关系。frame决定了视图相对于父视图的布局系统（以最近的superview的bounds来建立的坐标系）的布局和大小；而bounds决定了自身绘制的本地坐标系（frame，bounds就不啰嗦了，讲到烂的东西）。（UIkit框架同时还提供了一个定位中心点的属性）。

和其他视图的布局关系。 superview，subview和window属性指明了view在它的window所处的继承层次的位置。你添加视图（子视图）来封闭视图（父视图）从而创建了封闭的视图和最终的，来创建用户界面（各种视图的组合）。有一个autoresizing来指明视图的子视图的位置如何布局和重新调整它们的大小当这个复合封闭视图本身重新调整了大小。

@interface UIView(UIViewHierarchy)

@property(nonatomic,readonly) UIView       *superview;
@property(nonatomic,readonly,copy) NSArray *subviews;
@property(nonatomic,readonly) UIWindow     *window;

上面提到的几个属性是由UIViewHierarchy这个扩展来的。

@property(nonatomic) UIViewAutoresizing autoresizingMask;    // simple resize. default is UIViewAutoresizingNone
- (BOOL)translatesAutoresizingMaskIntoConstraints NS_AVAILABLE_IOS(6_0); // Default YES

而autoresizing则是由这两个提供。

相信这图也非常好理解。

Views Are Inherently Capable of Animation

In both iOS and OS X, each view is (or can be) backed by a Core Animation layer object (CALayer), which is accessible through the layer property. The layer object caches a view’s drawing content, assists in the layout and rendering of that content, and can composite and animate that content. Certain properties of a view, such as the view’s frame and its opacity, are implicitly capable of animation. In addition, an application may explicitly animate a view using facilities of the Core Animation framework.

In OS X, CALayer-support is optional whereas in iOS this support is built into each view’s rendering implementation.

在iOS或者是OS X平台上，每一个view是（或者是能够）被核心层动画对象所支持（CALayer），这是通过图层属性来访问的。层对象缓存了对象的绘制内容，在布局和渲染其内容作了很多的作用（这两句话就能说明UIView CALayer的核心区别啦），并且能够复合和动画表现其内容。具体的视图的属性，例如view的frame和它的opacity（透明度），都隐含在了动画。另外，一个应用可能会使用Core Animation框架的工具来明确地展现一个view 的动画。

在OS X平台，CALayer-support是可选的而iOS这个支持时建立在任意一个view的渲染实现上。

View hierarchy

A view hierarchy defines the relationships of views in a window to each other. You can think of a view hierarchy as an inverted tree structure with the window being the top node of the tree. Under it come views structurally specified by parent-child relationships. From a visual perspective, the essential fact of a view hierarchy is enclosure: one view contains one or more other views, and the window contains them all.

The view hierarchy is a major part of the responder chain, and it is something that the application frameworks use to determine the layering order of views when they render the content of a window in a drawing pass. The view hierarchy is also the governing concept behind view composition: You construct compound views by adding subviews to a superview. Finally, the view hierarchy is a critical factor in the multiple coordinate systems found in a window.

view hierarchy定义了视图在一个窗口中相互的关系，你可以把view hierarchy想象成一个倒置的继承树结构并且窗口从最顶端的节点出发。根据这种结构视图间结构性地被定义为父－子的继承关系。从可视化的角度上来看，view hierarchy核心的因素是enclosure：一个视图包含着一个或多个视图，而窗口包含它们全部（重要啊windows）

view hierarchy是responder chain的重要环节，同时它是应用框架用来确定视图的层级顺序当它们在窗口开始了传递绘制时渲染了内容。view hierarchy同时也是管理概念在视图复合的时候。你构造复合视图通过在父类上添加子类。最终，view hierarchy是核心要素当在多坐标系系统窗口。

非常好理解的继承树。

Three View Properties Define Relationships in the Hierarchy

A view is related to other views through two properties, and these relationships determine the form of the hierarchy:

superview — The view above a given view in the hierarchy; this is the view that encloses it. All views except the topmost view must have a superview.
subviews — The views below a given view in the hierarchy; these are the views that it encloses. A view may have any number of subviews, or it may have none.

视图和其他视图间的关系通过两个属性表现，和这些关系确定了继承的形式：

直接父视图 — 视图直接上层并给予了view一个继承关系；这个视图包裹了它。所有视图除了最顶端的都存在一个superview。
直接子视图 — 视图的直接下层并给予了view一个继承关系；这个视图包裹了它。一个视图可能有任意数量的子视图，或者一个都没有。

非常好理解吧，最上面的window就是第三个window属性，注意有一些情况是不存在window属性的，这时候会返回nil值。

In iOS, a Window is a View

In OS X a window has a single “content view,” a background view from which, structurally, all other views in the hierarchy descend. However, in iOS applications, a window is a view (UIWindow inherits from UIView), and so it acts as its own content view.

在OS X平台上，window有一个单一的“content view”，一个背景视图，结构性地，所有视图在继承层上。然而，在iOS应用上，一个window是视图（UIWindow类继承至UIView类），所以它作为自己的内容视图。

Responder object

A responder is an object that can respond to events and handle them. All responder objects are instances of classes that ultimately inherit from UIResponder (iOS) ora target="_self" NSResponder/a (OS X). These classes declare a programmatic interface for event handling and define a default behavior for responders. The visible objects of an app are almost always responders—for example, windows, views, and controls—and the app object is a responder as well. In iOS, view controllers (UIViewController objects) are also responder objects.

Responder是一个能够响应事件并且处理它们的对象。所有具有响应能力的对象都是类的实例并且都是最终继承至UIResponder（iOS）或者 a target = "_self" NSResponder/a （OS X）。这些类声明了一个编程性的接口为事件处理和定义默认的响应者行为。应用的可视化对象通常都是响应者－例如，windows，views和controls －并且UIApplication对象也是作为响应者的。在iOS中，view controllers视图控制器（UIViewController 对象）也是响应对象。

NS_CLASS_AVAILABLE_IOS(2_0) @interface UIView : UIResponder <NSCoding, UIAppearance, UIAppearanceContainer, UIDynamicItem, UITraitEnvironment, UICoordinateSpace> { ----- }

NS_CLASS_AVAILABLE_IOS(2_0) @interface UIViewController : UIResponder <NSCoding, UIAppearanceContainer, UITraitEnvironment, UIContentContainer> { ----- }

查看头文件会明显看到UIView，UIViewController都是继承UIResponder的。

从这个图片很清晰看到UIWindow和NSWindow的区别啦，上面也有简单阐述。

To receive events, a responder must implement the appropriate event-handling methods and, in some cases, tell the app that it can become the first responder.

为了接收事件，响应者必须实现合适的事件处理方法同时在一些情况下，告诉app应该成为第一响应者。

注意上面UIKit framework 和 AppKit framework 的区别，下面提到的iOS 和 OS X的一些区别就是如此。

The First Responder Receives Some Events First

In an app, the responder object that first receives many kinds of events is known as the first responder. It receives key events, motion events, and action messages, among others. (Mouse events and multitouch events first go to the view that is under the mouse pointer or finger; that view might or might not be the first responder.) The first responder is typically the view in a window that an app deems best suited for handling an event. To receive an event, the responder must also indicate its willingness to become first responder; it does this in different ways for each platform:

// OS X

- (BOOL)acceptsFirstResponder { return YES; }

//iOS

- (BOOL)canBecomeFirstResponder { return YES; }

In addition to receiving event messages, a responder can receive action messages that have no target specified. (Action messages are sent by controls such as buttons and controls when users manipulate them.)

在app中，响应对象首先接收不同类型的事件被称为第一响应者。它接收关键事件，移动事件和事件消息或者其他。（鼠标事件和多点触碰首先达到view在鼠标点击或者手指按下；视图可能是或者不是第一响应者。）在窗口视图的第一响应者通常被认为是最适合去处理事件的。为了接收一个事件，响应者也必须指明称为第一响应者的倾向程度；在不同的平台有着不同的方式（如上图的方法）：

willingness to become first responder ：通过返回布尔值来控制。

除了接受事件消息，响应者可以接收没有明确目标的action消息。（action消息被controls发送例如按钮和controls当用户对它们做相应的操作。）

The Responder Chain Enables Cooperative Event Handling

If the first responder cannot handle an event or action message, it forwards it to the “next responder” in a linked series called the responder chain. The responder chain allows responder objects to transfer responsibility for handling an event or action message to other objects in the app. If an object in the responder chain cannot handle the event or action, it passes the message to the next responder in the chain. The message travels up the chain, toward higher-level objects, until it is handled. If it isn't handled, the app discards it.

如果第一响应者不能够处理一个事件或者action消息，它将把处理任务传递给“下一个响应者”在一个系列链称为：响应链。响应链允许响应者对象去传递对事件处理或者action消息的处理给另外的响应者在同一个app生命周期里。如果响应链的对象不能够处理相应的事件或者action（action：操作），它将会在链中把消息传给下一个响应者。消息通过响应链传递，传向更高级别的对象，直到它能被处理了。如果它还是不被处理，app将抛弃它。

The path of an event. The general path of an event up the responder chain starts with a view—the first responder or the view under the mouse pointer or finger. From there, it proceeds up the view hierarchy to the window object and then to the global app object. However, the responder chain for events in iOS adds a variation to this path: If a view is managed by a view controller and if the view cannot handle an event, the view controller becomes the next responder.

事件的路径。 通常的响应链的路径是从最高的视图开始—第一个响应者或者视图在鼠标或者手指的点击下。从这里，它进入窗口的视图继承层结构同时传递到全局的app对象。然而，iOS的事件的响应链添加了一个变动给它的路径：如果一个视图是用一个视图控制器来控制并且如果这个视图无法处理该事件，这个视图控制器将会成为下一个响应者。

The path of an action message. For action messages, both OS X and iOS extend the responder chain to other objects. In OS X, the responder chain for action messages differs for an app based on the document architecture, an app that uses window controllers (a target="_self" NSWindowController/a), and an app that fits neither of those categories. Additionally, if an app on OS X has both a key window and a main window, the responder chain along which an action message travels might involve the view hierarchies of both windows.

action消息的路径。 对于action消息，OS X和iOS把响应链扩展至其它对象。在OS X中，action消息的响应链根据app的文件架构不同而不同，一个app使用window控制器（a target = "_self" NSWindowController/a），和一个app都不适合这种类型。另外，如果一个在OS X的app有着key window和main window，伴随着action消息的响应链可以会涉及到view hierachies的两个window。

抽个时间对上两图的好好分析，包括响应链的流向，条件（归在触摸事件的处理）等。

待续...