IOS development (48): close by init, loadView, viewDidLoad, viewDidUnload, and dealloc

For iphone developers, memory management is an extremely important skill. Even if the program functions more powerful and the design is more beautiful, if the memory is not well controlled, it will not escape the inexplicable exit of the program, this is totally different from web development.

There are many channels in the memory control. Here we will analyze the differences between viewDidUnload and dealloc. There are many articles about the differences between the two, but most of them are excerpted and translated official documents, some of them are just two simple sentences, but they do not elaborate on the specific differences between the two.

To understand the differences between the two, first of all, we need to know the view lifecycle. There are many articles in google. You can search for them first. I will not explain them here.

As the name suggests, lateral viewDidUnload is the statement executed after the view is detached. It matches viewDidLoad. Everyone knows that the official explanation is similar to the execution.

 

Self. myOutlet = nil;

 

But why? When will this method be called?

This method cannot be called manually. It is actually a method automatically called when the application receives the phone memory warning, the purpose is to clear some controls or data that are no longer used in the viewController that have been loaded except the current viewController, so as to prevent the application from being forcibly shut down due to excessive memory consumption. Remember that all viewcontrollers in the memory except the viewController to which the view is currently being displayed execute the viewDidUnload method, rather than the viewDidUnload method executed by the current viewController. Of course, these viewcontrollers will not be dealloc. Therefore, in viewDidUnload, IBOutlet variables are usually released and data that can be reconstructed in viewDidLoad, viewWillAppear, viewDidAppear, and other methods. Data transmitted from other pages or data that cannot be reconstructed by viewDidLoad, viewWillAppear, viewDidAppear, and other methods cannot be released, for example, if an image transmitted from the previous page in navigationController is released in viewDidUnload, the view cannot be restored when it is loaded again.

Why should we write it as self. myOutlet = nil; in fact, this syntax executes the setter method in property, rather than a simple variable assignment. It does two things: 1. release old data, 2. New data (nil) retain (when property is set to retain) is of course meaningless to nil retain. If myOutlet = nil is written, it simply points myOutlet to nil, so the memory will leak, because the old data has no release. However, if you only write it as [myOutlet release], the problem will also occur, because when the view is dealloc, it will be re-release, and the program will go wrong, but there is no problem with nil release.
 
When the current viewController is released, dealloc clears all objects and data in the current viewController to release the memory. This method is also automatically called without manual execution. For example, when modalView is returned to the previous page by dismissModalViewControllerAnimated or navigationController, this method is automatically called. Because this page is no longer used, you can release all objects and data (release.

In fact, the biggest difference between the two is: viewDidUnload is that all viewcontrollers except the current memory are executed simultaneously, while dealloc is only executed by the current viewController. This is not described on the Internet.

For personal notice, please correct the error!

PS: many friends have said that viewDidUnload cannot be debugged. The method is to select hardware> Simulate Memory warning in the menu of the iOS simulator. At this time, you can see NSLog in viewDidUnload, you can try NSLog in the opened viewController to check the effect. In dealloc, NSLog can be used directly.

 

 

 

Started from the relationship among init, loadView, viewDidLoad, viewDidUnload, and dealloc

Init Method

Instantiate necessary objects in the init method (following the LazyLoad idea)

Initialize ViewController in init Method

LoadView Method

When a view needs to be displayed but it is nil, viewController calls this method. Do not call this method directly.

If you manually maintain views, you must reload and override this method.

If you use IB to maintain views, you must not override this method by reload.

LoadView and IB build view

If you implement the loadView method in the controller, you may be called by the memory management control at some time when the application is running. If the device memory is insufficient, the view Controller receives the message didReceiveMemoryWarning. The default implementation is to check whether the current controller's view is in use. If its view is not in the current view hierarchy and your controller implements the loadView method, the view will be release, the loadView method is called again to create a new view.

 

ViewDidLoad Method

ViewDidLoad this method is called only when the view is initialized from the nib file.

Override this method to further customize the view

In iPhone OS 3.0 and later versions, you should also overload viewDidUnload to release any indexes on The view.

Call the data Model after viewDidLoad

ViewDidUnload Method

This method is called when the system memory is tight (Note: viewController is not dealloc)

When the memory is tight, didreceivemorywarning before iPhone OS 3.0 is the only way to release useless memory, but the viewDidUnload method is better in OS 3.0 and later versions.

In this method, set all IBOutlet (whether property or instance variables) to nil (the system release view has already been release)

Release other view-related objects in this method, and create others at runtime (but not required by the system) after you set the object to nil (IBOutlet only needs to set it to nil, the system release view has already been release)

ViewDidUnload is generally considered as the image of viewDidLoad, because when the view is requested again, viewDidLoad will be re-executed

Objects release in viewDidUnload must be easily re-created (for example, objects created in viewDidLoad or other methods ), do not release user data or other objects that are difficult to recreate

Dealloc Method

ViewDidUnload is not associated with the dealloc method, so dealloc continues to do what it should do.

See the following code

-(Void) viewDidUnload {

Self. detailViewController = nil;

Self. cyclagenames = nil;

Self. cyclagecodes = nil;

}

-(Void) dealloc {

[DetailViewController release];

[LanguageNames release];

[Deleagecodes release];

[Super dealloc];

}

If viewDidUnload is called first and then dealloc is called, then languageNames is already nil. What is the significance of dropping release?
The reason seems to be that for a viewcontroller, its data is initialized in init, And the view managed by it adopts the lazy load method, that is, it is loaded only when necessary, therefore, the view-related data can be initialized in viewDidLoad (that is, when the view is loaded. When the memory is tight, ios will destroy some views and call viewDidUnload (which generally only sets the view-related data to nil). However, viewcontroller is still in the process, therefore, its dealloc will not be called unless viewcontroller is destroyed.