1 . Window 和View
1.1概述
每个应用至少含有一个window和一个view用来展示应用的内容。
window本身并没有可视的内容，为应用中的view提供了基础的容器（container）展示整个应用的用户界面。在大多数情况下，应用的window不会改变，改变的是在其上呈现的view。view实现window中某一部分的视图。（define a portion of a window that you want to fill with some content）
view主要负责：
1.绘图，使用例如OpenGl ES或UIKit等图形工具绘制内容；
2.响应点击事件；
3.管理子试图（subview），其中父试图（parent view）负责他的子试图（child view）的自动定位和适应大小。
我们用过的IB（interface builder）在此扮演的角色是：我们借助IB，将多个view放置到一个nib文件中，这个nib文件是一种资源文件，存放了“被冻住的”（freeze-dried）view对象和其他一些对象。当我们在运行时加载nib文件时，nib文件中的对象解冻，解冻后我们就可以是用代码控制他们了。（when you load a nib file at runtime, the objects inside it are reconstituted into actual objects that your code can then manipulate programmatically.）
1.2 view的基本结构
view与Core Animation layers控制了view 上内容的渲染和动画。每个在UIKit框架下的view底层都有一个层对象（layer object，通常是CALayer 类），这个层对象负责存储view内容以及控制与这个view相关的对象。
下图用以说明view结构以及view与其下层Core Animation Layer的关系。
如上图所示，每个view都对应了一个layer对象，我们可以通过view的 layer属性来访问其layer对象。UIBarButtonItem 对应的layer为灰色代表他并不是一个view，所以我们不能像访问view的layer属性那样直接获得其layer对象。
Core Animation Layer对应用的性能表现有很大的影响。实际上，一个view的绘图代码（drawing code）应该在程序运行过程中尽可能少的被调用，并且当绘图代码被调用时，这段代码执行的结果会被Core Animation Layer缓存起来，并在之后被重用。重用渲染结果可以减少因更新试图而带来的绘图开销（expenive drawing cycle）
1.3 分层的view以及子试图管理
从view的功能角度重看子试图管理：
a. 绘图、展示内容：
子试图覆盖在其父试图上，如果子试图的透明度设置为不透明，则子试图会完全遮住响应位置的父试图的内容。对于同级的试图，后添加的试图在先添加的试图之上。（If two subviews overlap each o other,the one that was added last or was moved to the end of the subview array）appears on top of the other）
b. 响应事件：
当在view上发生了点击事件，系统会将这个点击时间直接发送给这个view，如果这个view不能处理这个事件，可能是没有声明这个事件的处理方法，那么这个view就会把事件传递给其父试图（superview）因为子试图在父试图之上。如果父试图仍没有响应，则会响应的根据响应链（responder chain）向上传递。有些view如果声明了响应的通知，也会将此事件传递给其他对象，比如view controllor。如果始终没有对象响应这个事件，最终会被传递给应用对象（application object）被丢弃（discard）。
1.4 view的绘制周期
contentMode
1.5 Stretchable View
例：对话气泡实现