IOS UIKit框架之窗口和视图架构介绍

UIKit框架图

窗口和视图
窗口和视图是为iPhone应用程序构造用户界面的可视组件。窗口为内容显示提供背景平台，而视图负责绝大部分的内容描画，并负责响应用户的交互。虽然本章讨论的概念和窗口及视图都相关联，可是讨论过程更加关注视图，由于视图对系统更为重要。
什么是窗口和视图？

和Mac OS X同样，iPhone OS经过窗口和视图在屏幕上展示图形内容。虽然窗口和视图对象之间在两个平台上有不少类似性，可是具体到每一个平台上，它们的做用都有轻微的差异。

UIWindow的做用

和Mac OS X的应用程序有所不一样，iPhone应用程序一般只有一个窗口，表示为一个UIWindow类的实例。您的应用程序在启动时建立这个窗口（或者从nib文件进行装载），并往窗口中加入一或多个视图，而后将它显示出来。窗口显示出来以后，您不多须要再次引用它。

在iPhone OS中，窗口对象并无像关闭框或标题栏这样的视觉装饰，用户不能直接对其进行关闭或其它操做。全部对窗口的操做都须要经过其编程接口来实现。应用程序能够借助窗口对象来进行事件传递。窗口对象会持续跟踪当前的第一响应者对象，并在UIApplication对象提出请求时将事件传递它。

还有一件可能让有经验的Mac OS X开发者以为奇怪的事是UIWindow类的继承关系。在Mac OS X中，NSWindow的父类是NSResponder；而在iPhone OS中，UIWindow的父类是UIView。所以，窗口在iPhone OS中也是一个视图对象。无论其起源如何，您一般能够将iPhone OS上的窗口和Mac OS X的窗口一样对待。也就是说，您一般没必要直接操做UIWindow对象中与视图有关的属性变量。

在建立应用程序窗口时，您应该老是将其初始的边框尺寸设置为整个屏幕的大小。若是您的窗口是从nib文件装载获得，Interface Builder并不容许建立比屏幕尺寸小的窗口；然而，若是您的窗口是经过编程方式建立的，则必须在建立时传入指望的边框矩形。除了屏幕矩形以外，没有理由传入其它边框矩形。屏幕矩形能够经过UIScreen对象来取得，具体代码以下所示：

UIWindow* aWindow = [[[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]] autorelease];

虽然iPhone OS支持将一个窗口叠放在其它窗口的上方，可是您的应用程序永远不该建立多个窗口。系统自身使用额外的窗口来显示系统状态条、重要的警告、以及位于应用程序窗口上方的其它消息。若是您但愿在本身的内容上方显示警告，可使用UIKit提供的警告视图，而不该建立额外的窗口。

UIView是做用视图

是UIView类的实例，负责在屏幕上定义一个矩形区域。在iPhone的应用程序中，视图在展现用户界面及响应用户界面交互方面发挥关键做用。每一个视图对象都要负责渲染视图矩形区域中的内容，并响应该区域中发生的触碰事件。这一双重行为意味着视图是应用程序与用户交互的重要机制。在一个基于模型-视图-控制器的应用程序中，视图对象明显属于视图部分。

除了显示内容和处理事件以外，视图还能够用于管理一或多个子视图。子视图是指嵌入到另外一视图对象边框内部的视图对象，而被嵌入的视图则被称为父视图或超视图。视图的这种布局方式被称为视图层次，一个视图能够包含任意数量的子视图，经过为子视图添加子视图的方式，视图能够实现任意深度的嵌套。视图在视图层次中的组织方式决定了在屏幕上显示的内容，缘由是子视图老是被显示在其父视图的上方；这个组织方法还决定了视图如何响应事件和变化。每一个父视图都负责管理其直接的子视图，即根据须要调整它们的位置和尺寸，以及响应它们没有处理的事件。
因为视图对象是应用程序和用户交互的主要途径，因此须要在不少方面发挥做用，下面是其中的一小部分：
描画和动画
视图负责对其所属的矩形区域进行描画。
某些视图属性变量能够以动画的形式过渡到新的值。
布局和子视图管理
视图管理着一个子视图列表。
视图定义了自身相对于其父视图的尺寸调整行为。
必要时，视图能够经过代码调整其子视图的尺寸和位置。
视图能够将其坐标系统下的点转换为其它视图或窗口坐标系统下的点。
事件处理
视图能够接收触摸事件。
视图是响应者链的参与者。
在iPhone应用程序中，视图和视图控制器紧密协做，管理若干方面的视图行为。视图控制器的做用是处理视图的装载与卸载、处理因为设备旋转致使的界面旋转，以及和用于构建复杂用户界面的高级导航对象进行交互。更多这方面的信息请参见“视图控制器的做用”部分。
本章的大部份内容都着眼于解释视图的这些做用，以及说明如何将您本身的定制代码关联到现有的UIView行为中。

UIKit的视图类

UIView类定义了视图的基本行为，但并不定义其视觉表示。相反，UIKit经过其子类来为像文本框、按键、及工具条这样的标准界面元素定义具体的外观和行为。显示了全部UIKit视图类的层次框图。除了UIView和UIControl类是例外，这个框图中的大多数视图都设计为可直接使用，或者和委托对象结合使用。
视图的类层次
View class hierarchy

这个视图层次能够分为以下几个大类：

容器
容器视图用于加强其它视图的功能，或者为视图内容提供额外的视觉分隔。好比，UIScrollView类能够用于显示因内容太大而没法显示在一个屏幕上的视图。UITableView类是UIScrollView类的子类，用于管理数据列表。表格的行能够支持选择，因此一般也用于层次数据的导航—好比用于挖掘一组有层次结构的对象。
UIToolbar对象则是一个特殊类型的容器，用于为一或多个相似于按键的项提供视觉分组。工具条一般出如今屏幕的底部。Safari、Mail、和Photos程序都使用工具条来显示一些按键，这些按键表明常用的命令。工具条能够一直显示，也能够根据应用程序的须要进行显示。

控件
控件用于建立大多数应用程序的用户界面。控件是一种特殊类型的视图，继承自UIControl超类，一般用于显示一个具体的值，并处理修改这个值所须要的全部用户交互。控件一般使用标准的系统范式（好比目标-动做模式和委托模式）来通知应用程序发生了用户交互。控件包括按键、文本框、滑块、和切换开关。
显示视图
控件和不少其它类型的视图都提供了交互行为，而另一些视图则只是用于简单地显示信息。具备这种行为的UIKit类包括UIImageView、 UILabel（标签）、UIProgressView、UIActivityIndicatorView(界面活动指示器视图)。
文本和web视图
文本和web视图为应用程序提供更为高级的显示多行文本的方法。UITextView类支持在滚动区域内显示和编辑多行文本；而UIWebView类则提供了显示HTML内容的方法，经过这个类，您能够将图形和高级的文本格式选项集成到应用程序中，并以定制的方式对内容进行布局。
警告视图和动做表单
警告视图和动做表单用于即刻取得用户的注意。它们向用户显示一条消息，同时还有一或多个可选的按键，用户经过这些按键来响应消息。警告视图和动做表单的功能相似，可是外观和行为不一样。举例来讲，UIAlertView类在屏幕上弹出一个蓝色的警告框，而UIActionSheet类则从屏幕的底部滑出动做框。
导航视图
标签栏和导航条和视图控制器结合使用，为用户提供从一个屏幕到另外一个屏幕的导航工具。在使用时，您一般没必要直接建立UITabBar和UINavigationBar的项，而是经过恰当的控制器接口或Interface Builder来对其进行配置。
窗口
窗口提供一个描画内容的表面，是全部其它视图的根容器。每一个应用程序一般都只有一个窗口。更多信息请参见“UIWindow的做用”部分。除了视图以外，UIKit还提供了视图控制器，用于管理这些对象。更多信息请参见“视图控制器的做用”部分。

视图控制器的做用
运行在iPhone OS上的应用程序在如何组织内容和如何将内容呈现给用户方面有不少选择。含有不少内容的应用程序能够将内容分为多个屏幕。在运行时，每一个屏幕的背后都是一组视图对象，负责显示该屏幕的数据。一个屏幕的视图后面是一个视图控制器其做用是管理那些视图上显示的数据，并协调它们和应用程序其它部分的关系。

UIViewController类负责建立其管理的视图及在低内存时将它们从内容中移出。视图控制器还为某些标准的系统行为提供自动响应。好比，在响应设备方向变化时，若是应用程序支持该方向，视图控制器能够对其管理的视图进行尺寸调整，使其适应新的方向。您也能够经过视图控制器来将新的视图以模式框的方式显示在当前视图的上方。

除了基础的UIViewController类以外，UIKit还包含不少高级子类，用于处理平台共有的某些高级接口。特别须要提到的是，导航控制器用于显示多屏具备必定层次结构的内容；而标签栏控制器则支持用户在一组不一样的屏幕之间切换，每一个屏幕都表明应用程序的一种不一样的操做模式。

视图架构和几何属性
因为视图是iPhone应用程序的焦点对象，因此对视图与系统其它部分的交互机制有所了解是很重要的。UIKit中的标准视图类为应用程序免费提供至关数量的行为，还提供了一些定义良好的集成点，您能够经过这些集成点来对标准行为进行定制，完成应用程序须要作的工做。

本文的下面部分将解释视图的标准行为，并说明哪些地方能够集成您的定制代码。若是须要特定类的集成点信息，请参见该类的参考文档。您能够从UIKit框架参考中取得全部类参考文档的列表。

视图交互模型
任什么时候候，当用户和您的程序界面进行交互、或者您的代码以编码的方式进行某些修改时，UIKit内部都会发生一个复杂的事件序列。在事件序列的一些特定的点上，UIKit会调用您的视图类，使它们有机会表明应用程序进行事件响应。理解这些调用点是很重要的，有助于理解您的视图对象和系统在哪里进行结合。图2-2显示了从用户触击屏幕到图形系统更新屏幕内容这一过程的基本事件序列。以编程方式触发事件的基本步骤与此相同，只是没有最初的用户交互。
UIKit和您的视图对象之间的交互

UIKit interactions with your view objects

下面的步骤说明进一步刨析了图2-2中的事件序列，解释了序列的每一个阶段都发生了什么，以及应用程序可能如何进行响应。

用户触击屏幕。硬件将触击事件报告给UIKit框架。
UIKit框架将触击信息封装为一个UIEvent对象，并派发给恰当的视图（有关UIKit如何将事件递送给您的视图的详细解释，请参见“事件的传递”部分）。
视图的事件处理方法能够经过下面的方式来响应事件：
调整视图或其子视图的属性变量（边框、边界、透明度等）。
将视图（或其子视图）标识为须要修改布局。
将视图（或其子视图）标识为布局须要重画。
将数据发生的变化通报给控制器。
固然，上述的哪些事情须要作及调用什么方法来完成是由视图来决定的。
若是视图被标识为须要从新布局，UIKit就调用视图的layoutSubviews方法。
您能够在本身的定制视图中重载这个方法，以便调整子视图的尺寸和位置。举例来讲，若是一个视图具备很大的滚动区域，就须要使用几个子视图来“平铺”，而不是建立一个内存极可能装不下的大视图。在这个方法的实现中，视图能够隐藏全部不需显示在屏幕上的子视图，或者在从新定位以后将它们用于显示新的内容。做为这个过程的一部分，视图也能够将用于“平铺”的子视图标识为须要重画。
若是视图的任何部分被标识为须要重画，UIKit就调用该视图的drawRect:方法。
UIKit只对那些须要重画的视图调用这个方法。在这个方法的实现中，全部视图都应该尽量快地重画指定的区域，且都应该只重画本身的内容，不该该描画子视图的内容。在这个调用点上，视图不该该尝试进一步改变其属性或布局。
全部更新过的视图都和其它可视内容进行合成，而后发送给图形硬件进行显示。
图形硬件将渲染完成的内容转移到屏幕。

请注意：上述的更新模型主要适用于采纳内置视图和描画技术的应用程序。若是您的应用程序使用OpenGL ES来描画内容，则一般要配置一个全屏的视图，而后直接在OpenGL的图形上下文中进行描画。您的视图仍然须要处理触碰事件，但不须要对子视图进行布局或者实现drawRect:方法。有关OpenGL ES的更多信息，请参见“用OpenGL ES进行描画”部分。

基于上述的步骤说明能够看出，UIKit为您本身定制的视图提供以下主要的结合点：

下面这些事件处理方法：
touchesBegan:withEvent:
touchesMoved:withEvent:
touchesEnded:withEvent:
touchesCancelled:withEvent:
layoutSubviews方法
drawRect:方法

大多数定制视图经过实现这些方法来获得本身指望的行为。您可能不须要重载全部方法，举例来讲，若是您实现的视图是固定尺寸的，则可能不须要重载layoutSubviews方法。相似地，若是您实现的视图只是显示简单的内容，好比文本或图像，则一般能够经过简单地嵌入UIImageView和UILabel对象做为子视图来避免描画。

重要的是要记住，这些是主要的结合点，但不是所有。UIView类中有几个方法的设计目的就是让子类重载的。您能够经过查阅UIView类参考中的描述来了解哪些方法能够被重载。

视图渲染架构
虽然您经过视图来表示屏幕上的内容，可是UIView类自身的不少基础行为却严重依赖于另外一个对象。UIKit中每一个视图对象的背后都有一个Core Animation层对象，它是一个CALayer类的实例，该类为视图内容的布局和渲染、以及合成和动画提供基础性的支持。

和Mac OS X（在这个平台上Core Animation支持是可选的）不一样的是，iPhone OS将Core Animation集成到视图渲染实现的核心。虽然Core Animation发挥核心做用，可是UIKit在Core Animation上面提供一个透明的接口层，使编程体验更为流畅。这个透明的接口使开发者在大多数状况下没必要直接访问Core Animation的层，而是经过UIView的方法和属性声明取得相似的行为。然而，当UIView类没有提供您须要的接口时，Core Animation就变得重要了，在那种状况下，您能够深刻到Core Animation层，在应用程序中实现一些复杂的渲染。

文章来源：http://www.cnblogs.com/CHONGCHONG2008/archive/2012/08/02/2619366.html    此文本ID有部分修改