View Programming Guide for iOS_读书笔记[正在更新……]

原文：View Programming Guide for iOS

1 Introduction

先熟悉一下基本概念.

Window

• Windows do not have any visible content themselves but provide a basic container for your application’s views.
• Every application has at least one window that displays the application’s user interface on a device’s main screen.

view

• You can also use views to organize and manage other views.

• Views Manage Your Application’s Visual Content.

• Views are responsible for drawing content, handling multitouch events, and managing the layout of any subviews.

window和view关系

• Views define a portion of a window that you want to fill with some content.

Animation

• Animations Provide the User with Visible Feedback for Interface Changes

Interface Builder

• Interface Builder is an application that you use to graphically construct and configure your application’s windows and views.
• When you load a nib file at runtime, the objects inside it are reconstituted into actual objects that your code can then manipulate programmatically.

 

 2 View and Window Architecture

2.1 View Architecture Fundamentals

2.1.1 View Hierarchies and Subview Management

• Views and windows present your application’s user interface and handle the interactions with that interface.
• A view object defines a rectangular region on the screen and handles the drawing and touch events in that region.
• window ——which is also a view.

View 和 Layer 的关系

• To understand the relationship between views and layers。通过下面的图理解view和layer的关系。

通过上图我们可以看出：

Every view in UIKit is backed by a layer object (usually an instance of the CALayer class), which manages the backing store for the view and handles view-related animations.

Every view has a corresponding layer object that can be accessed from that view’s layer property. (Because a bar button item is not a view, you cannot access its layer directly.)

注意：a bar button item ——which is not a view itself but which manages a view internally。

• 在开发时，要尽量少地调用绘制界面的代码。因为 The actual drawing code of a view object is called as little as possible, and when the code is called, the results are cached by Core Animation and reused as much as possible later.

View 和 Subview的关系

• 只要子视图不透明，就能遮盖父视图的事件响应。 If the subview is totally opaque, then the area occupied by the subview completely obscures the corresponding area of the parent.
• Each superview stores its subviews in an ordered array .
• 改变父视图的大小会在子视图中引起连锁反应。Changing the size of a parent view has a ripple effect that can cause the size and position of any subviews to change too.

2.1.2 The View Drawing Cycle

• The UIView class uses an on-demand drawing model for presenting content. When a view first appears on the screen, the system asks it to draw its content. The system captures a snapshot of this content and uses that snapshot as the view’s visual representation.

2.1.3 Content Modes

• Each view has a content mode that controls how the view recycles its content in response to changes in the view’s geometry and whether it recycles its content at all.

Figure 1-2  Content mode comparisons

总结：所谓ContentMode，就是内容的显示方式，通过正确使用ContentMode可以非常方便地填充内容。尤其在使用UIimage的时候，可能就能省掉UIImageView这个过渡环节。直接在UIView中满屏填充。

2.1.4 Stretchable Views

• You can designate a portion of a view as stretchable/ so that /when the size of the view changes /only the content in the stretchable portion is affected.

2.1.5 Built-In Animation Support

• One of the benefits of having a layer object behind every view is that you can animate many view-related changes easily.

Among the properties you can animate on a UIView object are the following:

• frame—Use this to animate position and size changes for the view.

• bounds—Use this to animate changes to the size of the view.

• center—Use this to animate the position of the view.

• transform—Use this to rotate or scale the view.

• alpha—Use this to change the transparency of the view.

• backgroundColor—Use this to change the background color of the view.

• contentStretch—Use this to change how the view’s contents stretch.

• In addition to the animations you create using UIKit classes, you can also create animations using Core Animation layers. Dropping down to the layer level gives you much more control over the timing and properties of your animations.

2.2 View Geometry and Coordinate Systems

• The default coordinate system in UIKit has its origin in the top-left corner and has axes that extend down and to the right from the origin point.
• In addition to the screen coordinate system, windows and views define their own local coordinate systems that allow you to specify coordinates relative to the view or window origin instead of relative to the screen.

2.2.1 The Relationship of the Frame, Bounds, and Center Properties

A view object tracks its size and location using its frame, bounds, and center properties:

• The frame property contains the frame rectangle, which specifies the size and location of the view in its superview’s coordinate system.

• The bounds property contains the bounds rectangle, which specifies the size of the view (and its content origin) in the view’s own local coordinate system.

• The center property contains the known center point of the view in the superview’s coordinate system.

 

• By default, a view’s frame is not clipped to its superview’s frame. Thus, any subviews that lie outside of their superview’s frame are rendered in their entirety. In other words, touch events occurring in a part of a view that lies outside of its superview’s bounds rectangle are not delivered to that view.

2.2.2  Coordinate System Transformations

• Coordinate system transformations offer a way to alter your view (or its contents) quickly and easily. An affine transform is a mathematical matrix that specifies how points in one coordinate system map to points in a different coordinate system.

2.2.3 Points Versus Pixels

• In iOS, all coordinate values and distances are specified using floating-point values in units referred to as points.
• One point does not necessarily correspond to one pixel on the screen.

2.3 The Runtime Interaction Model for Views

2.4 Tips for Using Views Effectively

2.4.1 Views Do Not Always Have a Corresponding View Controller

• There is rarely a one-to-one relationship between individual views and view controllers in your application. The job of a view controller is to manage a view hierarchy, which often consists of more than one view used to implement some self-contained feature.
• As you design your application’s user interface, it is important to consider the role that view controllers will play. View controllers provide a lot of important behaviors, such as coordinating the presentation of views on the screen, coordinating the removal of those views from the screen, releasing memory in response to low-memory warnings, and rotating views in response to interface orientation changes. Circumventing these behaviors could cause your application to behave incorrectly or in unexpected ways.

For more information view controllers and their role in applications, see View Controller Programming Guide for iOS.

2.4.2 Minimize Custom Drawing

• Although custom drawing is necessary at times, it is also something you should avoid whenever possible. The only time you should truly do any custom drawing is when the existing system view classes do not provide the appearance or capabilities that you need. Any time your content can be assembled with a combination of existing views, your best bet is to combine those view objects into a custom view hierarchy.

2.4.3 Take Advantage of Content Modes

2.4.4 Declare Views as Opaque Whenever Possible

UIKit uses the opaque property of each view to determine whether the view can optimize compositing operations. Setting the value of this property to YES for a custom view tells UIKit that it does not need to render any content behind your view. Less rendering can lead to increased performance for your drawing code and is generally encouraged. Of course, if you set the opaque property to YES, your view must fill its bounds rectangle completely with fully opaque content.

2.4.5 Adjust Your View’s Drawing Behavior When Scrolling

Scrolling can incur numerous view updates in a short amount of time. If your view’s drawing code is not tuned appropriately, scrolling performance for your view could be sluggish. Rather than trying to ensure that your view’s content is pristine at all times, consider changing your view’s behavior when a scrolling operation begins. For example, you can reduce the quality of your rendered content temporarily or change the content mode while a scroll is in progress. When scrolling stops, you can then return your view to its previous state and update the contents as needed.

2.4.6 Do Not Customize Controls by Embedding Subviews

Although it is technically possible to add subviews to the standard system controls—objects that inherit from UIControl—you should never customize them in this way. Controls that support customizations do so through explicit and well-documented interfaces in the control class itself. For example, the UIButton class contains methods for setting the title and background images for the button. Using the defined customization points means that your code will always work correctly. Circumventing these methods, by embedding a custom image view or label inside the button, might cause your application to behave incorrectly now or at some point in the future if the button’s implementation changes.