Handle memory warnings by apps after ios6.0

The IOS version has reached 6.0.1. This article says that 60% of iPhone users have upgraded to ios6. Are there any preparations for our applications. Debugging today Code When I used the simulator to simulate the memory warning, I found that my viewcontroller did not respond to the viewdidunload function, Nima. This is a big problem. Query documentation. After IOS is upgraded to 6.0, viewdidunload is no longer supported. The official document explains that the system will automatically control the memory occupied by large views. The memory occupied by other small views is extremely small, it is not worth cleaning and re-creating to save memory. If you need to release business data or perform other specific processing during memory warning, you can implement the didreceivememorywarning function. In Apple's official documents, please click here to summarize: viewdidunload and didreceivememorywarning will be called before ios6. IOS 6 and later versions. Viewdidunload will not be called didreceivememorywarning and is still called. The system automatically processes view-related memory. Apple officially explained that the related solutions always look wonderful, but the reality is often cruel. 1. Our project is from arc. 2. We will hold the member variable (strong) of the large quantum view in viewcontroller 3. We have implemented a large number of viewdidunload functions to release the child view held in (2. Let's see what will happen after our code reaches ios6. Because all the sub-views are held by strong, this will lead to timely system memory warnings leading to the collection of views, and they will not be truly released. So, our Program It may be killed frequently by the system in the background. After the analysis, the solution is clear, so I won't bother. The solution Code provided by Apple.

 
1-(void) didreceivememorywarning 2 {3 [Super didreceivememorywarning]; 4 // Add code to clean up any of your own resources that are no longer necessary. 5 If ([self. view window] = nil) 6 {7 // Add code to preserve data stored in the views that might be 8 // needed later. 9 // Add code to clean up other strong references to the view in 10 // The View hierarchy. 11 self. view = nil; 12} 
 

So with the above Code, is it over? No. The following describes the problem of this solution. (Example)

An app has three tabs, A, B, and C. (Both are inherited from viewcontroller and all are implemented Didreceivememorywarning ). When the program starts, Tab A is displayed by default. At this time, the viewdidload of A is called and the loaded data is displayed to the user. Then we switch to tab B, and B repeats the loading process of. At this time, the system generates a memory warning. All objects A, B, and C are warned. Object A: because it is no longer displayed on the current UI [Self. View window] = nil. The related view is released. Object B: displaying, all Didreceivememorywarning does nothing. C object: the most miserable, never shown, viewdidload never called, never shown. Then there is a self. view. this call will result in a result that the viewdidload of the c object will be called once, so his logic is to create it before release and then release himself. Is it a tragedy. (The solutions provided by Apple are not necessarily reliable)   The story here also tells us how to deal with this problem in ios6 and later.   1. Do not use subview as a member variable. Use tags. (In fact, no matter which version is used in the end) 2. You do not need to implement viewdidunload. The system controls the memory release. 3. Implemented as needed Didreceivememorywarning to release some business data to reduce memory usage. Do not operate uiview. You may have an error. please correct me or not.