在使用nib文件做界面开发的过程中，加载nib文件后，由于设置了outlet和delegate，出现了一些未能及时释放的引用和retain循环，最后结果当然可想而知，dealloc没有走到，内存一路高歌走上去了。
所以在使用的时候应该需要注意一些地方，及时的释放不必要的引用等
官方文档Memory Management Programming Guide中 Memory Management of Nib Objects一节指出，通过nib文件加载的文件retaincount为1并且是autorelease的，但是又特别指出在内存警告的时候需要做这样的动作。
- (void)viewDidUnload {
}
并且在UIViewController的dealloc中也要处理
- (void)dealloc {
}
在mac桌面开发中是这样的情况：
The File’s Owner of a nib file缺省要去释放NIB资源及顶层的对象
NIB文件的全局拥有者是全局应用对象NSApp，但是当Cocoa应用终止时，nib中的顶层对象也没有自动获得dealloc消息，因为NSApp已经被析构了。换句话说，即使nib主文件中，你也不得不管理顶层对象的内存
实际上也不用担心，mac已经有两个特征可以帮助你了
NSWindow对象有一个isReleasedWhenClosed属性，设置为YES则关闭窗口对象时自动关闭相关对象
nib文件的拥有者是一个NSWindowController对象，那么他会调用NSDocument来管理一个NSWindowController的实例，会自动释放他管理的窗口的
所以现实情况就是虽然你要负责释放一个nib文件中的top-level对象，但是只要你的nib文件的owner是一个NSWindowController的实例，那么它会帮你释放的。如果你的一个对象加载了nib自身并且文件的拥有者并不是NSWindowController，那么你可以为nib中的对象定义outlets，这样你就可以在恰当的时候释放他们。如果你不想为每个对象都声明outlet，你也可以这样：
NSNib类的instantiateNibWithOwner:topLevelObjects: 方法来获得nib文件中的所有顶层对象。
可是IOS直到4.0以后的sdk才有和NSNib类似作用的类UINib，这个在官方的sample：AdvancedTableViewcells中就有使用的例子。
Cocoa 没有提供 nib unload的api，所以你要unload一个nib文件，基本上来说就是要关闭由nib文件创建的windows并释放top level的对象。
另外，
n 仔细设计对象的owner关系，避免retain循环。
n 我们常见的delegate往往是assign方式的属性而不是retain方式 的属性，赋值不会增加引用计数，就是为了防止delegation两端产生不必要的循环引用。如果一个UITableViewController 对象a通过retain获取了UITableView对象b的所有权，这个UITableView对象b的delegate又是a， 如果这个delegate是retain方式的，那基本上就没有机会释放这两个对象了。自己在设计使用delegate模式时，也要注意这点。
n 类似NSArray, NSDictionary, NSSet 等类，会在对象加入后引用计数加一获得所有权，在对象被移除或者整个容器对象被释放的时候释放容器内对象的所有权。类似的情况还有UIView对 subview的所有权关系，UINavigationController对其栈上的controller的所有权关系等等。
n 还有一些用法会让系统拥有对象的所有权。比如NSObject 的performSelector:withObject:afterDelay 。如果有必要，需要显示的调用cancelPreviousPerformRequestsWithTarget:selector:object: ，否则有可能产生内存泄露。因这种原因产生的泄露因为并不违反任何规则，是Intrument所无法发现的。
UINib的类结构也是比较简单的。
