UIViewController的生命周期及iOS程序执行顺序 和ios6 处理内存警告

当一个视图控制器被创建，并在屏幕上显示的时候。 代码的执行顺序
1、 alloc                                   创建对象，分配空间
2、init (initWithNibName) 初始化对象，初始化数据
3、loadView                          从nib载入视图 ，通常这一步不需要去干涉。除非你没有使用xib文件创建视图
4、viewDidLoad                   载入完成，可以进行自定义数据以及动态创建其他控件
5、viewWillAppear              视图将出现在屏幕之前，马上这个视图就会被展现在屏幕上了
6、viewDidAppear               视图已在屏幕上渲染完成

当一个视图被移除屏幕并且销毁的时候的执行顺序，这个顺序差不多和上面的相反
1、viewWillDisappear            视图将被从屏幕上移除之前执行
2、viewDidDisappear             视图已经被从屏幕上移除，用户看不到这个视图了
3、dealloc                                 视图被销毁，此处需要对你在init和viewDidLoad中创建的对象进行释放

关于viewDidUnload ：在发生内存警告的时候如果本视图不是当前屏幕上正在显示的视图的话， viewDidUnload将会被执行，本视图的所有子视图将被销毁，以释放内存,此时开发者需要手动对viewLoad、viewDidLoad中创建的对象释放内存。 因为当这个视图再次显示在屏幕上的时候，viewLoad、viewDidLoad 再次被调用，以便再次构造视图。

当我们创建一个UIViewController类的对象时，通常系统会生成几个默认的方法，这些方法大多与视图的调用有关，但是在视图调用时，这些方法的调用顺序如何，需要整理下。

通常上述方法包括如下几种，这些方法都是UIViewController类的方法：

- (void)viewDidLoad；

- (void)viewDidUnload；

- (void)viewWillAppear:(BOOL)animated；

- (void)viewDidAppear:(BOOL)animated；

- (void)viewWillDisappear:(BOOL)animated；

- (void)viewDidDisappear:(BOOL)animated；

下面介绍下APP在运行时的调用顺序。

1）- (void)viewDidLoad；

一个APP在载入时会先通过调用loadView方法或者载入IB中创建的初始界面的方法，将视图载入到内存中。然后会调用viewDidLoad方法来进行进一步的设置。通常，我们对于各种初始数据的载入，初始设定等很多内容，都会在这个方法中实现，所以这个方法是一个很常用，很重要的方法。

但是要注意，这个方法只会在APP刚开始加载的时候调用一次，以后都不会再调用它了，所以只能用来做初始设置。

2) - (void)viewDidUnload;

在内存足够的情况下，软件的视图通常会一直保存在内存中，但是如果内存不够，一些没有正在显示的viewcontroller就会收到内存不够的警告，然后就会释放自己拥有的视图，以达到释放内存的目的。但是系统只会释放内存，并不会释放对象的所有权，所以通常我们需要在这里将不需要在内存中保留的对象释放所有权，也就是将其指针置为nil。

这个方法通常并不会在视图变换的时候被调用，而只会在系统退出或者收到内存警告的时候才会被调用。但是由于我们需要保证在收到内存警告的时候能够对其作出反应，所以这个方法通常我们都需要去实现。

另外，即使在设备上按了Home键之后，系统也不一定会调用这个方法，因为IOS4之后，系统允许将APP在后台挂起，并将其继续滞留在内存中，因此，viewcontroller并不会调用这个方法来清除内存。

3）- (void)viewWillAppear:(BOOL)animated;

系统在载入所有数据后，将会在屏幕上显示视图，这时会先调用这个方法。通常我们会利用这个方法，对即将显示的视图做进一步的设置。例如，我们可以利用这个方法来设置设备不同方向时该如何显示。

另外一方面，当APP有多个视图时，在视图间切换时，并不会再次载入viewDidLoad方法，所以如果在调入视图时，需要对数据做更新，就只能在这个方法内实现了。所以这个方法也非常常用。

4) - (void)viewDidAppear:(BOOL)animated；

有时候，由于一些特殊的原因，我们不能在viewWillApper方法里，对视图进行更新。那么可以重写这个方法，在这里对正在显示的视图进行进一步的设置。

5) - (void)viewWillDisappear:(BOOL)animated；

在视图变换时，当前视图在即将被移除、或者被覆盖时，会调用这个方法进行一些善后的处理和设置。

由于在IOS4之后，系统允许将APP在后台挂起，所以在按了Home键之后，系统并不会调用这个方法，因为就这个APP本身而言，APP显示的view，仍是挂起时候的view，所以并不会调用这个方法。

6) - (void)viewDidDisappear:(BOOL)animated；

我们可以重写这个方法，对已经消失，或者被覆盖，或者已经隐藏了的视图做一些其他操作。

OS 开发init和 loadView 和 viewDidLoad 的区别

他们都可以用来在视图载入的时候，初始化一些内容。 但是他们有什么区别呢？

1.loadview里面必须为控制器的view赋值,要么继承要么实例化一个;主要作用是为了实例化view

2.执行顺序,init->load->viewDidLoad

3.如果设备内存不足的时候， view 控制器会收到didReceiveMemoryWarning的消息。默认的实现是检查当前控制器的view是否在使用。如果它的view不在当前正在使用的view hierarchy里面，且你的控制器实现了loadView方法，那么这个view将被release, loadView方法将被再次调用来创建一个新的view。所以不要再init中写任何和view相关的内容.

    func application(application: UIApplication!, didFinishLaunchingWithOptions launchOptions: NSDictionary!) -> Bool {
        // Override point for customization after application launch.

        self.window =  UIWindow(frame: UIScreen.mainScreen().bounds);
        self.window!.backgroundColor = UIColor.whiteColor();
        self.window!.makeKeyAndVisible();

        var rootController = ViewController(nibName: nil,bundle: nil);
        self.window!.rootViewController = rootController;
        return true
    }

class ViewController: UIViewController {

    var testView1:TestView?;
    var testView2:TestView?;

    override func loadView(){
        self.view = UIView();  //可自定义或者执行self.loadView();确保self.view被实例化
    }

    override func viewDidLoad() {
        super.viewDidLoad()

        var label = UILabel(frame: CGRect(x:,y:UIScreen.mainScreen().bounds.height/+,width:,height:));
        label.text = "aaaaa";
 }

iPhone下每个app可用的内存是被限制的，如果一个app使用的内存超过20M，则系统会向该app发送Memory Warning消息。收到此消息后，app必须正确处理，否则可能出错或者出现内存泄露。

app收到Memory Warning后会调用：UIApplication::didReceiveMemoryWarning -> UIApplicationDelegate::applicationDidReceiveMemoryWarning,然后调用当前所有的viewController进行处理。因此处理的主要工作是在viewController。

当我们的程序在第一次收到内存不足警告时，应该释放一些不用的资源，以节省部分内存。否则，当内存不足情形依然存在，iOS再次向我们程序发出内存不足的警告时，我们的程序将会被iOS kill掉。

iOS的UIViewController 类给我们提供了处理内存不足的接口。在iOS 3.0 之前，当系统的内存不足时，UIViewController的didReceiveMemoryWarining 方法会被调用，我们可以在didReceiveMemoryWarining 方法里释放掉部分暂时不用的资源。

从iOS3.0 开始，UIViewController增加了viewDidUnload方法。该方法和viewDIdLoad相配对。当系统内存不足时，首先UIViewController的didReceiveMemoryWarining 方法会被调用，而didReceiveMemoryWarining 会判断当前ViewController的view是否显示在window上，如果没有显示在window上，则didReceiveMemoryWarining 会自动将viewcontroller 的view以及其所有子view全部销毁，然后调用viewcontroller的viewdidunload方法。如果当前UIViewController的view显示在window上，则不销毁该viewcontroller的view，当然，viewDidunload也不会被调用了。但是到了ios6.0之后，这里又有所变化，ios6.0内存警告的viewDidUnload 被屏蔽，即又回到了ios3.0的时期的内存管理方式。

iOS3-iOS5.0以前版本收到内存警告：
调用didReceiveMemoryWarning内调用super的didReceiveMemoryWarning会将controller的view进行释放。所以我们不能将controller的view再次释放。
处理方法：

1. -(void)didReceiveMemoryWarning
2. {
3. [super didReceiveMemoryWarning];//如没有显示在window上，会自动将self.view释放。
4. // ios6.0以前，不用在此做处理，self.view释放之后，会调用下面的viewDidUnload函数，在viewDidUnload函数中做处理就可以了。
5. }
6. -(void)viewDidUnload
7. {
8. // Release any retained subviews of the main view.不包含self.view
9. //处理一些内存和资源问题。
10. [super viewDidUnload];
11. }

iOS6.0及以上版本的内存警告：
调用didReceiveMemoryWarning内调用super的didReceiveMemoryWarning调只是释放controller的resouse，不会释放view
处理方法：
    -(void)didReceiveMemoryWarning
    {
            [super didReceiveMemoryWarning];//即使没有显示在window上，也不会自动的将self.view释放。
            // Add code to clean up any of your own resources that are no longer necessary.

// 此处做兼容处理需要加上ios6.0的宏开关，保证是在6.0下使用的,6.0以前屏蔽以下代码，否则会在下面使用self.view时自动加载viewDidUnLoad

if ([[UIDevice currentDevice].systemVersion floatValue] >= 6.0) {

//需要注意的是self.isViewLoaded是必不可少的，其他方式访问视图会导致它加载 ，在WWDC视频也忽视这一点。

if (self.isViewLoaded && !self.view.window)// 是否是正在使用的视图
             {
                   // Add code to preserve data stored in the views that might be
                   // needed later.
        
                   // Add code to clean up other strong references to the view in
                   // the view hierarchy.
                   self.view = nil;// 目的是再次进入时能够重新加载调用viewDidLoad函数。
             }

}
    }

但是似乎这么写相对于以前并不省事。最终我们找到一篇文章，文章中说其实并不值得回收这部分的内存，原因如下：

1. UIView是UIResponder的子类，而UIResponder有一个CALayer的成员变量，CALayer是具体用于将自己画到屏幕上的。

2. CALayer是一个bitmap图象的包装类，当UIView调用自身的drawRect时，CALayer才会创建这个bitmap图象类。

3. 具体占内存的其实是一个bitmap图象类，CALayer只占48bytes, UIView只占96bytes。而一个iPad的全屏UIView的bitmap类会占到12M的大小！

4.在iOS6时，当系统发出MemoryWarning时，系统会自动回收bitmap类。但是不回收UIView和CALayer类。这样即回收了大部分内存，又能在需要bitmap类时，根据CALayer类重建。

所以，iOS6这么做的意思是：我们根本没有必要为了几十byte而费力回收内存。

--------------------------切糕分割线--------------

PS：

1、关于这个的官方文档：https://developer.apple.com/library/ios/#featuredarticles/ViewControllerPGforiPhoneOS/ViewLoadingandUnloading/ViewLoadingandUnloading.html

2、zon2012貌似都没有ios6的这个兼容（其实view是没问题的，关键是资源）

移动设备终端的内存极为有限，应用程序必须做好low-memory处理工作，才能避免程序因内存使用过大而崩溃。

low-memory 处理思路
通常一个应用程序会包含多个view controllers，当从view跳转到另一个view时，之前的view只是不可见状态，并不会立即被清理掉，而是保存在内存中，以便下一次的快速显现。但是如果应用程序接收到系统发出的low-memory warning，我们就不得不把当前不可见状态下的views清理掉，腾出更多的可使用内存；当前可见的view controller也要合理释放掉一些缓存数据，图片资源和一些不是正在使用的资源，以避免应用程序崩溃。

思路是这样，具体的实施根据系统版本不同而略有差异，本文将详细说明一下iOS 5与iOS 6的low-memory处理。

iOS 5 的处理
在iOS 6 之前，如果应用程序接收到了low-memory警告，当前不可见的view controllers会接收到viewDidUnload消息（也可以理解为自动调用viewDidUnload方法），所以我们需要在 viewDidUnload 方法中释放掉所有 outlets ，以及可再次创建的资源。当前可见的view controller 通过didReceiveMemoryWarning 合理释放资源，具体见代码注释。

举一个简单的例子,有这样一个view controller：
@interface MyViewController : UIViewController {  
    NSArray *dataArray;  
}  
@property (nonatomic, strong) IBOutlet UITableView *tableView;  
@end

对应的处理则为：
#pragma mark -
#pragma mark Memory management

- (void)didReceiveMemoryWarning {
    // Releases the view if it doesn't have a superview.
    [super didReceiveMemoryWarning];
    
    // Relinquish ownership any cached data, images, etc that aren't in use.
}

- (void)viewDidUnload {
    // Relinquish ownership of anything that can be recreated in viewDidLoad or on demand.
    // For example: self.myOutlet = nil;
    self.tableView = nil;
    dataArray = nil;
    
    [super viewDidUnload];
}

iOS 6 的处理
iOS 6 废弃了viewDidUnload方法，这就意味着一切需要我们自己在didReceiveMemoryWarning中操作。
具体应该怎么做呢？

1.将 outlets 置为 weak
当view dealloc时，没有人握着任何一个指向subviews的强引用，那么subviews实例变量将会自动置空。
@property (nonatomic, weak) IBOutlet UITableView *tableView;

2.在didReceiveMemoryWarning中将缓存数据置空
#pragma mark -   
#pragma mark Memory management   
  
  
- (void)didReceiveMemoryWarning  
{  
    [super didReceiveMemoryWarning];  
    // Dispose of any resources that can be recreated.   
    dataArray = nil;  
} 
不要忘记一点，每当tableview reload 的时候，需要判断一下 dataArray ，若为空则重新创建。

兼容iOS 5 与 iOS 6
好吧，重点来了，倘若希望程序兼容iOS 5 与 iOS 6怎么办呢？ 这里有一个小技巧，我们需要对didReceiveMemoryWarning 做一些手脚：
#pragma mark -
#pragma mark Memory management

- (void)didReceiveMemoryWarning
{
    [super didReceiveMemoryWarning];
    
    if ([self isViewLoaded] && self.view.window == nil) {
        self.view = nil;
    }
    
    dataArray = nil;
}

判断一下view是否是window的一部分，如果不是，那么可以放心的将self.view 置为空，以换取更多可用内存。

这样会是什么现象呢？假如，从view controller A 跳转到 view controller B ,然后模拟low-memory警告，此时，view controller A 将会执行self.view = nil ; 当我们从 B 退回 A 时， A 会重新调用一次 viewDidLoad ，此时数据全部重新创建，简单兼容无压力～～

Note:
如果你好奇Apple为什么废弃viewDidUnload，可以看看Apple 的解释：
Apple deprecated viewDidUnload for a good reason. The memory savings from setting a few outlets to nil just weren’t worth it and added a lot of complexity for little benefit. For iOS 6+ apps, you can simply forget about view unloading and only implement didReceiveMemoryWarning if the view controller can let go of cached data that you can recreate on demand later.