Core Animation-1: layer tree, coreanimation-1

Core Animation-1: layer tree, coreanimation-1
Tree Structure of Layers

> The giant demon has layers, and the onion also has layers. Do you understand? We all have layers -- Shrek

Core Animation is a misunderstanding. You may think it is only used for animation, but it actually evolved from an animation-less name called * Layer Kit, therefore, Animation is just the tip of the iceberg of Core Animation.

Core Animation is a * Composite engine * that combines different visual content on the screen as quickly as possible. This content is divided into independent * layers *, stored in a system called * layer tree. This tree is the basis for ** UIKit ** and everything you can see on the screen in iOS apps.

Before we discuss the Animation, we will start with the layer tree, involving the * Static * combination and layout features of Core Animation.

# Layers and views
If you have written applications on iOS or Mac OS, you may be familiar with the concept of * view. A view is a rectangle (slice, text, or video) displayed on the screen. It can intercept user input similar to mouse clicks or touch gestures. A view can be nested in hierarchical relationships. A view can manage the positions of all its subviews. Figure 1.1 shows a typical view-level relationship

 

Figure 1.1 A typical iOS screen (left) and hierarchical view (right)

In iOS, all views are derived from a base class called 'uiview'. 'uiview' can process touch events and support plotting Based on * Core Graphics, it can be used for affine transformations (such as rotation or scaling), or a simple animation similar to sliding or gradient.

### CALayer
The 'calayer 'class is similar to 'uiview' in concept. It is also a rectangular block managed by the hierarchical relationship tree. It can also contain some content (such as images, text, or background colors ), manage the positions of child layers. They have some methods and attributes for animation and transformation. The biggest difference from 'uiview' is that 'calayer' does not process user interaction.

'Calayer 'does not know the specific * response chain * (iOS uses the view hierarchy to send touch events), so it cannot respond to events, even if it provides some methods to determine whether a contact is within the scope of the layer (See Chapter 3, "layer ry ")

### Parallel hierarchical relationships
Each 'uiview' has a layer attribute of a 'calayer 'instance, that is, the so-called * backing layer *. The view is responsible for creating and managing this layer, to ensure that when a child view is added or removed from a hierarchy, the associated layers also have the same operations in the hierarchy tree (see Figure 1.2 ).

 

Figure 1.2 tree structure of layers (left side) and corresponding view level (right side)

In fact, the associated layers are actually used for display and animation on the screen. 'uiview' is just an encapsulation of IT and provides some iOS functions similar to processing touch, and advanced interfaces of Core Animation underlying methods.

But why does iOS provide two parallel hierarchical relationships based on 'uiview' and 'calayer? Why don't we have to deal with everything at a simple level? The reason is the separation of duties, which can avoid a lot of repeated code. There are many differences between events and user interaction on iOS and Mac OS. The multi-touch-based user interface is essentially different from the mouse and keyboard, this is why iOS has UIKit and 'uiview', but Mac OS has AppKit and 'nsview. They have similar functions, but there are significant differences in implementation.

In contrast, drawing, layout, and animation are similar to Mac laptops and desktop series applied to iPhone and iPad touch screens. By separating the logic of this function and applying it to an independent Core Animation framework, Apple can share code between iOS and Mac OS, this makes it easier for Apple's OS development team and third-party developers to develop applications on two platforms.

In fact, there are not two hierarchical relationships, but four. Each role plays a different role. Besides the view hierarchy and layer tree, there are * rendering tree * and * rendering tree *, we will discuss performance tuning in Chapter 7 "implicit Animation" and Chapter 12th "performance tuning.

### Layer capabilities
If 'calayer' is the internal implementation details of 'uiview', why should we fully understand it? Of course, Apple provided us with a beautiful and concise 'uiview' interface, so do we have to deal with the details of Core Animation directly?

In a sense, this is indeed true. For some simple needs, we do not have to deal with 'callayer ', because Apple has indirectly made the animation very simple through the 'uiview' advanced API.

However, this simplicity will inevitably lead to some flexibility defects. If you want to make some changes at the underlying layer or use some interface functions that Apple does not implement on 'uiview', you have no choice but to intervene in the underlying layer of Core Animation.

We have confirmed that a layer cannot process touch events like a view. What views can it do? Here are some 'uiview' functions that are not exposed by CALayer:

* Shadow, rounded corner, and colored border
* 3D Transformation
* Non-rectangular range
* Transparent mask
* Multi-level nonlinear Animation

We will explore these features in subsequent sections. First, let's take a look at how 'callayer' is used in applications.

# Use Layers
First, create a simple project to manipulate some 'layer' attributes. Open Xcode and use the * Single View Application * template to create a project.

Create a small view (approximately 200X200 in size) in the center of the screen. Of course, you can encode it manually or use Interface Builder (for your convenience ). Make sure that your view controller adds a view attribute so that you can directly access it. We call it 'layerview '.

When running the project, you should be able to see a white square in the light gray background (Figure 1.3). If you do not see it, you may need to adjust the color of the background window or view.

 

Figure 1.3 a white 'uiview' on a gray background'

There is nothing exciting about this. Let's add a color block and add a small blue block in the middle of the white block.

Of course, we can simply add a subview (using code or IB at Will) to an existing 'uiview', but we cannot really learn anything about layers.

So we create a 'calayer 'and use it as a child layer of our view-related layers. Although the 'uiview' class interface exposes layer properties, the standard Xcode Project template does not contain header files related to Core Animation. Therefore, if we do not add a proper Library to the project, we cannot use any layer-related methods or access its attributes. Therefore, you must first add the QuartzCore framework to the Build Phases tag (Figure 1.4), and then introduce the <QuartzCore/QuartzCore. h> library in the. m file of vc.

Figure 1.4 Add the QuartzCore Library to the Project

Then you can directly reference the attributes and methods of 'calayer' in the code. In listing 1.1, we created a 'calayer 'and set its 'backgroundcolor' attribute, then add the child layers of the related layers to the 'layerview' (the premise of this Code is that the 'layerview' is created through IB and connected), and Figure 1.5 shows the result.

Listing 1.1 adds a blue child layer to the view
'''Objective-c
# Import "ViewController. h"
# Import <QuartzCore/QuartzCore. h>
@ Interface ViewController ()

@ Property (nonatomic, weak) IBOutlet UIView * layerView;
Bytes
@ End

@ Implementation ViewController

-(Void) viewDidLoad
{
[Super viewDidLoad];
// Create sublayer
CALayer * blueLayer = [CALayer layer];
BlueLayer. frame = CGRectMake (50366f, 50366f, 100366f, 100366f );
BlueLayer. backgroundColor = [UIColor blueColor]. CGColor;
// Add it to our view
[Self. layerView. layer addSublayer: blueLayer];
}
@ End
'''

 

Figure 1.5 white 'uiview' nested blue 'calayer'

A view has only one associated layer (automatically created). It also supports adding numerous child layers. As shown in listing 1.1, you can create a separate layer, and add it directly to the child layer of the view associated layer. Although layers can be added in this way, we often simply process the view. The layers they associate do not need to be manually added.

Before Mac OS 10.8, a major performance defect was that the view hierarchy was used instead of the 'calayer 'tree hierarchy in a single view. However, on the iOS platform, the use of the lightweight 'uiview' class has no significant performance impact (of course, after Mac OS 10.8, the performance of 'nsview' is also greatly improved ).

The advantage of using layer-associated views instead of 'calayer 'is that you can use all the underlying features of 'calayer', or use advanced APIs of 'uiview' (such as automatic layout, layout and event processing ).

However, when the following conditions are met, you may need to use 'callayer' instead of 'uiview'

* Develop cross-platform applications that can run on Mac OS at the same time
* Use a variety of 'calayer' subclasses (see chapter 6, "special layers") and do not want to create additional 'uiview' to encapsulate all of them
* Do some work that is especially picky about performance. For example, some negligible operations on 'uiview' may cause significant differences (although in this case, you may want to use OpenGL for plotting)

However, these examples are rare. In general, it is easier to process a view than to process layers separately.

# Summary
This chapter describes the tree structure of layers and describes how to form a parallel 'calayer 'hierarchy in iOS based on the hierarchical relationship of 'uiview'. In subsequent experiments, we created our own 'calayer' and added it to the layer tree.

In Chapter 2, "layer-associated images", we will study the associated images of 'calayer' and some features of Operation display provided by Core Animation.