[IOS animation]-calayer Layer Tree

The tree structure of the layer

Trolls have layers and onions have layers, do you? We all have layers--Shrek.

Core animation is actually a misleading designation. You might think it's just for animation, but it actually evolved from a little animated name called Layer Kit , so animating this is just the tip of the core animation feature.

Core animation is a composite engine whose job is to combine different visual content on the screen as quickly as possible, which is decomposed into separate layers and stored in a system called a layer tree . So this tree forms the basis for UIKit and everything you can see on the screen in an iOS app.

Before we talk about animations, we'll start with the layer tree, which involves the static composition of the core animation and the layout characteristics.

Layers and views

If you've ever written an application on an iOS or Mac OS platform, you might be familiar with the concept of views . A view is a rectangular block (a slice, text, or video) displayed on the screen that intercepts user input like mouse clicks or touch gestures. Views can be nested with each other in hierarchical relationships, and a view can manage the location of all its child views. Figure 1.1 shows a typical view-level relationship

Figure 1.1 A typical iOS screen (left) and a hierarchical relationship to form a view (right)

In iOS, all views are derived from a UIVIew base class called, UIView can handle touch events, can support a Core graphics drawing, can do affine transformations (such as rotation or scaling), Or a simple animation similar to sliding or gradient.

Calayer

CALayerClasses are conceptually and similarly, and are also UIView some of the rectangular blocks managed by a hierarchical tree, and can also contain some content (like pictures, text, or background colors) to manage the placement of sublayers. They have some methods and properties for animating and transforming. And UIView The biggest difference is that CALayer the user's interaction is not handled.

CALayerThere is no clear response chain (the mechanism by which iOS uses a view-level relationship to deliver touch events), so it does not respond to events, even if it provides a way to determine if a contact is within the range of the layer (see chapter III, "Geometry of the Layer")

Parallel Hierarchical relationships

Each UIview has a CALayer layer property of an instance, the so-called backinglayer, and the view's responsibility is to create and manage the layer to ensure that when the sub-view is added to or removed from the hierarchy, Their associated layers also correspond to the same actions in the hierarchy tree (see Figure 1.2).

Figure 1.2 The tree structure of the layer (left) and the corresponding view level (right)

In fact, the layers behind these are the ones that are really used to display and animate on the screen, UIView just one package for it, providing some of the specific features of iOS that are similar to touch, as well as the advanced interface of the core animation underlying approach.

But why should iOS be based on UIView and CALayer provide two parallel levels of relationships? Why not use a simple hierarchy to handle everything? This is due to separation of duties, which avoids a lot of duplication of code. On iOS and Mac OS two platforms, there are many differences between event and user interaction, multi-touch based user interface and mouse-based keyboard are essential differences, which is why iOS has Uikit and UIView , but Mac OS has appkit and NSView reason. They are functionally similar, but there are significant differences in implementation.

Drawing, layout, and animation, by contrast, are similar to the concept of iphone and ipad touch screens like Mac notebooks and desktop families. By separating the logic of this function and applying it to the standalone core animation framework, Apple can share code between iOS and Mac OS, making it easier for Apple's own OS development team and third-party developers to develop two platforms.

In fact, this is not a two-tier relationship, but four, each playing a different role, in addition to the view level and the layer tree, there is also a rendering tree and a rendering tree , will be in the seventh chapter "Implicit animation" and the 12th chapter "Performance Tuning" discussed separately.

The ability of the layer

If it CALayer 's an UIView internal implementation detail, why should we know it all in all? Apple certainly provides us with a graceful and concise UIView interface, so is there no need to deal directly with the details of the core animation?

In a sense it is true that we do not need to deal with some simple needs, CALayer because UIView the advanced API that Apple has passed indirectly makes the animation simple.

But this simplicity inevitably leads to some flexible flaws. If you slightly want to make some changes at the bottom, or use some UIView of the interface features that Apple does not implement, then there is no choice but to intervene in the core animation.

We have confirmed that a layer cannot handle touch events like a view, so what views can he do that cannot be done? Here are some UIView features that are not exposed to Calayer:

• Shadows, rounded corners, colored borders
• 3D transformations
• Non-rectangular Range
• Transparent matte
• Multi-stage Nonlinear animation

We'll explore these features in the next chapters, and first we'll look at how the application CALayer is being leveraged.

Working with Layers

Let's start by creating a simple project to manipulate some layer of the properties. Open Xcode and create a project using the single View application template.

Create a small view in the center of the screen (about 200 X size), of course you can code it manually, or use interface Builder (handy). Make sure that your view controller adds a view's properties so that it can be accessed directly. We call it the layerView .

Run the project, you should be able to see a white square in the light gray screen background (Figure 1.3), if not seen, you may need to adjust the background window or view color

Fig. 1.3 A white on a gray backgroundUIView

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

We can of course simply UIView add a sub-view (arbitrary code or IB) to an existing one, but that doesn't really learn anything about the layer.

So let's create one and CALayer use it as a sublayer for the layers that are related to our view. Although the UIView layer properties are exposed in the interface of the class, the standard Xcode project template does not contain a core animation related header file. So if we do not add the appropriate library to the project, we are not able to use any layer-related methods or access its properties. So first you need to add the Quartzcore framework to the build phases tag (Figure 1.4), and then introduce the library in the VC's. m file.

Figure 1.4 Adding the Quartzcore library to the project

Properties and methods that can then be referenced directly in the code CALayer . In Listing 1.1, we created one CALayer , set its backgroundColor properties, and then added to the sublayer behind the layerView related layer (this code is created layerView and connected via IB), and figure 1.5 shows the result.

Listing 1.1 Adding a blue sublayer to the view

#import "ViewController.h" #import <QuartzCore/QuartzCore.h> @interface Viewcontroller () @property (nonatomic, Weak) Iboutlet UIView *layerview;? @end @implementation viewcontroller-(void) viewdidload{    [Super Viewdidload];    Create Sublayer    Calayer *bluelayer = [Calayer layer];    Bluelayer.frame = CGRectMake (50.0f, 50.0f, 100.0f, 100.0f);    Bluelayer.backgroundcolor = [Uicolor Bluecolor]. Cgcolor;    Add it to our view    [Self.layerView.layer Addsublayer:bluelayer];} @end

Figure 1.5 White UIView inner nesting BlueCALayer

One view has only one associated layer (created automatically), and it can also support adding countless sublayers, as shown in Listing 1.1, you can show that you create a separate layer and add it directly to the sublayer of the view's associated layer. Although it's possible to add layers like this, often we just see that the views are simply processed, and the layers they're associated with don't need to be added to the extra layers manually.

Prior to version 10.8 of the Mac OS platform, a notable performance flaw was the use of the tree hierarchy in a view hierarchy rather than a separate one CALayer . But on the iOS platform, the use of lightweight UIView classes has no significant performance impact (of course, after Mac OS 10.8, NSView the performance has also been greatly improved).

The advantage of using the view associated with a layer is CALayer that you can use CALayer UIView the advanced APIs (such as auto-typesetting, layout, and event handling) while using all the underlying features.

However, when the following conditions are met, you may need to use CALayer rather thanUIView

• Develop cross-platform applications that can run on Mac OS at the same time
• Use CALayer a variety of subclasses (see chapter Sixth, "Special layers") and do not want to create additional UIView packages to encapsulate them all
• Doing something that is particularly critical to performance, such as a UIView noticeable difference in some negligible operations (though you might want to use OpenGL drawing directly)

However, these examples are rare, and in general, processing views is more convenient than working with layers alone.

Summarize

This chapter describes the tree structure of the layer, illustrates a UIView parallel hierarchy of relationships formed by hierarchical relationships in iOS, and CALayer in subsequent experiments we create our own and CALayer add it to the layer tree.

In chapter II, "Picture of the layer associated", we will look at the CALayer associated images, as well as some of the features that the core animation provides for the operation display.

[IOS animation]-calayer Layer Tree