iOS图形学（一）：viewWillUnload和内存警告

vc的生命周期：

1. alloc init：程序员手动生成 VC；
2. loadView：创建 View；
   VC 本质上是 view 的管理者，VC 被创建之后只是和其他管理类建立了联系，比如 nav、TabVC，最经典的就是通过 childViewController 相关方法来自己实现一个 VC 的管理者进而管理多个 View。而 View 是懒加载，只有 View 将要被添加到 window 上时，且 VC.view = nil 时，才会调用该方法真正的创建 View；
3. viewDidLoad：view 被创建完成之后，该方法被调用，告知开发者对 View 进行一些额外的初始化操作。之所以这么设计，是因为 loadView 封装了 Xib 相关逻辑，这样设计完成了底层 Xib 方式创建 View 的逻辑封装，还做到了层级的分离，层次清晰，对开发者也比较友好；
4. 其他：之后就是 viewWillAppear -> DidAppear -> WillDisAppear -> didDisAppear；
5. willUnLoad：View 将要被卸载，不是销毁；
6. didUnLoad：View 已经被卸载；
7. 循环
8. dealloc

备注：
WWDC2012中提到：

The method viewWillUnload and viewDidUnload. We’re not going to call them anymore. I mean, there’s kind of a cost-benifit equation and analysis that we went through. In the early days, there was a real performance need for us to ensure that on memory warnings we unloaded views. There was all kinds of graphics and backing stores and so forth that would also get unloaded. We now unload those independently of the view, so it isn’t that big of a deal for us for those to be unloaded, and there were so many bugs where there would be pointers into。

这段话的具体内容可以延伸为：

1. iOS6之前，收到内存警告之后，确实需要卸载暂时不需要的 View 以节省内存，否则 APP 有被系统 kill 的风险；
2. 释放 View 的本质是要释放和 View 相关的 backing stores；
3. iOS6 之后，真正需要释放的对象和 view 实现了分离；
4. 真正需要释放的是 CALayer 对象中的 bitmap 位图对象，也就是 backing store；
5. 占内存的其实是一个 bitmap 图象类，CALayer 只占 48bytes, UIView 只占 96bytes。而一个 iPad 的全屏 UIView 的 bitmap 类会占到 12M 的大小！
6. 释放 View 会引发很多 Bug，加之 bitMap 已经可以独立释放，所以最终这两个方法被废弃；

总之：iOS6之后，一般情况下，不需要再对内存警告做出什么处理，更不需要把之前写在 didUnload 方法中的代码放到 receiveMemoryWarning 方法中，apple 在 iOS6 中实现了对位图的自动释放；

从上面可以知道，当前不需要再额外去处理内存警告，其主要原因是因为 Layer 中 bitmap 相关的优化，那么 bitMap 是什么呢？能深入了解一下吗？

延伸：iOS图形学（二）：bitmap位图详解