大家好,关于探索视野与窗户设计:现代建筑美学解析很多朋友都还不太明白,今天小编就来为大家分享关于的知识,希望对各位有所帮助!
Views are responsible for
drawing contentDrawing involves using graphics technologies such as Core Graphics, OpenGL ES, or UIKit to draw shapes, images, and text inside a view’s rectangular areahandling multitouch eventsA view responds to touch events in its rectangular area either by using gesture recognizers or by handling touch events directlymanaging the layout of any subviews.In the view hierarchy, parent views are responsible for positioning and sizing their child views and can do so dynamically
view Architecture
Views work in conjunction with Core Animation layers to handle the rendering and animating of a view’s content. 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. Most operations you perform should be through the UIView interface. However, in situations where you need more control over the rendering or animation behavior of your view, you can perform operations through its layer instead.
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.) Behind those layer objects are Core Animation rendering objects and ultimately the hardware buffers used to manage the actual bits on the screen
view-layerThe use of Core Animation layer objects has important implications for performance. 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. Reusing already-rendered content eliminates the expensive drawing cycle usually needed to update views. Reuse of this content is especially important during animations, where the existing content can be manipulated. Such reuse is much less expensive than creating new content.
View Hierarchies and Subview Management
Each superview stores its subviews in an ordered array and the order in that array also affects the visibility of each subview.
The arrangement of views in a view hierarchy also determines how your application responds to events. When a touch occurs inside a specific view, the system sends an event object with the touch information directly to that view for handling. However, if the view does not handle a particular touch event, it can pass the event object along to its superview. If the superview does not handle the event, it passes the event object to its superview, and so on up the responder chain. Specific views can also pass the event object to an intervening responder object, such as a view controller. If no object handles the event, it eventually reaches the application object, which generally discards it.
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. If you never change the view’s content, the view’s drawing code may never be called again. The snapshot image is reused for most operations involving the view. If you do change the content, you notify the system that the view has changed. The view then repeats the process of drawing the view and capturing a snapshot of the new results.
When the contents of your view change, you do not redraw those changes directly. Instead, you invalidate the view using either the setNeedsDisplay or setNeedsDisplayInRect: method. These methods tell the system that the contents of the view changed and need to be redrawn at the next opportunity. The system waits until the end of the current run loop before initiating any drawing operations. This delay gives you a chance to invalidate multiple views, add or remove views from your hierarchy, hide views, resize views, and reposition views all at once. All of the changes you make are then reflected at the same time.
Changing a view’s geometry does not automatically cause the system to redraw the view’s content. The view’s contentMode property determines how changes to the view’s geometry are interpreted. Most content modes stretch or reposition the existing snapshot within the view’s boundaries and do not create a new one. For more information about how content modes affect the drawing cycle of your view
When the time comes to render your view’s content, the actual drawing process varies depending on the view and its configuration. System views typically implement private drawing methods to render their content. Those same system views often expose interfaces that you can use to configure the view’s actual appearance. For custom UIView subclasses, you typically override the drawRect: method of your view and use that method to draw your view’s content. There are also other ways to provide a view’s content, such as setting the contents of the underlying layer directly, but overriding the drawRect: method is the most common technique.
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. When a view is first displayed, it renders its content as usual and the results are captured in an underlying bitmap. After that, changes to the view’s geometry do not always cause the bitmap to be recreated. Instead, the value in the contentMode property determines whether the bitmap should be scaled to fit the new bounds or simply pinned to one corner or edge of the view.
scale_aspect.jpg
The content mode of a view is applied whenever you do the following:
Change the width or height of the view’s frame or bounds rectangles.Assign a transform that includes a scaling factor to the view’s transform property.By default, the contentMode property for most views is set to UIViewContentModeScaleToFill
you can also set the content mode to the UIViewContentModeRedraw value when you specifically want your custom views to redraw themselves during scaling and resizing operations. Setting your view’s content mode to this value forces the system to call your view’s drawRect: method in response to geometry changes. In general, you should avoid using this value whenever possible, and you should certainly not use it with the standard system views
Stretchable Views
button_scale.jpgYou specify the stretchable area of a view using the contentStretch property.
The view’s content mode also plays a role in determining how the view’s stretchable area is used.Stretchable areas are only used when the content mode would cause the view’s content to be scaled. This means that stretchable views are supported only with the UIViewContentModeScaleToFill, UIViewContentModeScaleAspectFit, and UIViewContentModeScaleAspectFill content modes. If you specify a content mode that pins the content to an edge or corner (and thus does not actually scale the content), the view ignores the stretchable area.
Note:The use of the contentStretch property is recommended over the creation of a stretchable UIImage object when specifying the background for a view. Stretchable views are handled entirely in the Core Animation layer, which typically offers better performance.
Built-In Animation Support
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.
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.
Important:Some iOS technologies define default coordinate systems whose origin point and orientation differ from those used by UIKit. For example, Core Graphics and OpenGL ES use a coordinate system whose origin lies in the lower-left corner of the view or window and whose y-axis points upward relative to the screen. Your code must take such differences into account when drawing or creating content and adjust coordinate values (or the default orientation of the coordinate system) as needed.
The Relationship of the 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.If you are changing only the position of the view (and not its size), the center property is the preferred way to do so. The value in the center property is always valid, even if scaling or rotation factors have been added to the view’s transform. The same is not true for the value in the frame property, which is considered invalid if the view’s transform is not equal to the identity transform.
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. You can change this behavior, though, by setting the superview’s clipsToBounds property to YES. Regardless of whether or not subviews are clipped visually, touch events always respect the bounds rectangle of the target view’s superview. 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.
Coordinate System Transformations
To modify your entire view, modify the affine transform in the transform property of your view.To modify specific pieces of content in your view’s drawRect: method, modify the affine transform associated with the active graphics context.You would not use this property to make permanent changes to your view, such as modifying its position or size a view within its superview’s coordinate space. For that type of change, you should modify the frame rectangle of your view instead.
Note:When modifying the transform property of your view, all transformations are performed relative to the center point of the view.
In your view’s drawRect: method, you use affine transforms to position and orient the items you plan to draw. Rather than fix the position of an object at some location in your view, it is simpler to create each object relative to a fixed point, typically (0, 0), and use a transform to position the object immediately prior to drawing. That way, if the position of the object changes in your view, all you have to do is modify the transform, which is much faster and less expensive than recreating the object at its new location. You can retrieve the affine transform associated with a graphics context using the CGContextGetCTM function and you can use the related Core Graphics functions to set or modify this transform during drawing.(i don"t quiet understand)
Important:If a view’s transform property is not the identity transform, the value of that view’s frame property is undefined and must be ignored. When applying transforms to a view, you must use the view’s bounds and center properties to get the size and position of the view. The frame rectangles of any subviews are still valid because they are relative to the view’s bounds.
Points Versus Pixels
One point does not necessarily correspond to one pixel on the screen.At the device level, all coordinates you specify in your view must be converted to pixels at some point. However, the mapping of points in the user coordinate space to pixels in the device coordinate space is normally handled by the system. Both UIKit and Core Graphics use a primarily vector-based drawing model where all coordinate values are specified using points. Thus, if you draw a curve using Core Graphics, you specify the curve using the same values, regardless of the resolution of the underlying screen.
The Runtime Interaction Model for Views
Any time a user interacts with your user interface, or any time your own code programmatically changes something, a complex sequence of events takes place inside of UIKit to handle that interaction. At specific points during that sequence, UIKit calls out to your view classes and gives them a chance to respond on behalf of your application.
UIKit interactions with your view objectsThe following steps break the event sequence in Figure 1-7 down even further and explain what happens at each stage and how you might want your application to react in response.
The user touches the screen.The hardware reports the touch event to the UIKit framework.The UIKit framework packages the touch into a UIEvent object and dispatches it to the appropriate view. (For a detailed explanation of how UIKit delivers events to your views, see Event Handling Guide for iOS.)The event-handling code of your view responds to the event. For example, your code might:Change the properties (frame, bounds, alpha, and so on) of the view or its subviews.Call the setNeedsLayout method to mark the view (or its subviews) as needing a layout update.Call the setNeedsDisplay or setNeedsDisplayInRect: method to mark the view (or its subviews) as needing to be redrawn.Notify a controller about changes to some piece of data.Of course, it is up to you to decide which of these things the view should do and which methods it should call.
If the geometry of a view changed for any reason, UIKit updates its subviews according to the following rules:
a. If you have configured autoresizing rules for your views, UIKit adjusts each view according to those rules. For more information about how autoresizing rules work, see Handling Layout Changes Automatically Using Autoresizing Rules.b. If the view implements the layoutSubviews method, UIKit calls it.You can override this method in your custom views and use it to adjust the position and size of any subviews. For example, a view that provides a large scrollable area would need to use several subviews as “tiles” rather than create one large view, which is not likely to fit in memory anyway. In its implementation of this method, the view would hide any subviews that are now offscreen or reposition them and use them to draw newly exposed content. As part of this process, the view’s layout code can also invalidate any views that need to be redrawn.
OK,关于探索视野与窗户设计:现代建筑美学解析和的内容到此结束了,希望对大家有所帮助。
【探索视野与窗户设计:现代建筑美学解析】相关文章:
2.米颠拜石
3.王羲之临池学书
8.郑板桥轶事十则
用户评论
这个 View 和 Window 架构听起来非常有用!
有17位网友表示赞同!
我一直在想办法改进应用程序的用户界面,这会不会是个很好的解决方案?
有13位网友表示赞同!
要构建复杂的多视图应用,这种架构看起来很适合。
有8位网友表示赞同!
感觉 View 和 Window 分离的设计更灵活和易于维护。
有7位网友表示赞同!
终于有人提到了在软件开发中将 UI 作为一个独立模块!
有7位网友表示赞同!
希望这个架构能有效提高开发效率。
有6位网友表示赞同!
我要详细了解一下如何实现这种 View 和 Window 的交互。
有13位网友表示赞同!
有没有示例代码可以参考?
有20位网友表示赞同!
学习新的架构方法 always a good thing!
有11位网友表示赞同!
View 和 Window 分离还能解决哪些问题呢?
有18位网友表示赞同!
这跟 MVC 架构有什么区别呢?
有20位网友表示赞同!
看名字就知道是针对 GUI 应用的呀。
有17位网友表示赞同!
对于桌面应用来说,这种架构确实很有帮助。
有14位网友表示赞同!
我之前用的架构方法不够灵活,看来可以考虑这个 View 和 Window 的方案了。
有19位网友表示赞同!
我有点迷茫,不知道哪些情况下更适合使用 View 和 Window 架构?
有13位网友表示赞同!
我想知道这个架构对应用程序性能有什么影响?
有14位网友表示赞同!
期待后续文章详细讲解这个 View 和 Window 架构的实现细节!
有19位网友表示赞同!
在学习新的架构之前必须先确认它是否适合我的项目需求。
有9位网友表示赞同!
这种架构听起来很有意思,我可以尝试在我的开发过程中应用一下。
有17位网友表示赞同!