Ios system handles memory warnings and ios system memory warnings

Ios system handles memory warnings and ios system memory warnings

The Memory available for each app in the iPhone is limited. If the Memory used by an app exceeds 20 mb, the system will send a Memory Warning message to the app. After receiving this message, the app must handle it correctly. Otherwise, an error may occur or memory leakage may occur.

After receiving Memory Warning, the app calls: UIApplication: didReceiveMemoryWarning-> UIApplicationDelegate: applicationDidReceiveMemoryWarning and calls all the current viewcontrollers for processing. Therefore, the main task of processing is in viewController.

When our program receives a warning of insufficient memory for the first time, it should release unnecessary resources to save some memory. Otherwise, when the memory shortage still exists and iOS sends a warning of memory insufficiency to our program again, our program will be killed by iOS.

 

The iOS UIViewController class provides an interface to handle insufficient memory. Before iOS 3.0, when the system memory is insufficient, the didReceiveMemoryWarining method of UIViewController will be called. We can release some resources temporarily unused in the didreceivemorywarining method.

The viewDidUnload method has been added to UIViewController since iOS3.0. This method is paired with viewDIdLoad. When the system memory is insufficient, the didReceiveMemoryWarining method of UIViewController is called first, and didreceivemorywarining checks whether the view of the current ViewController is displayed on the window. If the view is not displayed on the window, didReceiveMemoryWarining will automatically destroy the viewcontroller view and all its sub-views, and then call the viewdidunload method of viewcontroller. If the current view of UIViewController is displayed on the window, the view of the viewcontroller will not be destroyed. Of course, viewDidunload will not be called. However, after ios6.0, The ios6.0 memory warning viewDidUnload is blocked, Which is back to the memory management mode of ios3.0.

Earlier versions of the iOS3-iOS5.0 receive a memory warning that calling didreceivemorywarning within didreceivemorywarning of super will release the view of the controller. Therefore, we cannot release the controller view again. Solution:

Java code

1. -(Void) didReceiveMemoryWarning
2. {
3. [Super didReceiveMemoryWarning]; // if it is not displayed on the window, the self. view is automatically released.
4. // Before ios6.0, you do not need to process it here. After self. view is released, the following viewDidUnload function will be called to process it in the viewDidUnload function.
5. }
6. -(Void) viewDidUnload
7. {
8. // Release any retained subviews of the main view. does not contain self. view
9. // Handle some memory and resource problems.
10. [Super viewDidUnload];
12. }

-(Void) didReceiveMemoryWarning {[super didreceivemorywarning]; // if not displayed on the window, the self. view is automatically released. // Before ios6.0, you do not need to process it here. After self. view is released, the following viewDidUnload function will be called to process it in the viewDidUnload function. }-(Void) viewDidUnload {// Release any retained subviews of the main view. does not contain self. view // handles some memory and resource problems. [Super viewDidUnload];}

 

 

Memory warning for iOS6.0 and later versions: calling the super callback call in didReceiveMemoryWarning only releases the resouse of the controller and does not release the view processing method:-(void) didreceivemorywarning {[super didreceivemorywarning]; // The self. release view. // Add code to clean up any of your own resources that are no longer necessary.
// The ios6.0 macro switch must be added for compatibility processing to ensure that it is used under 6.0. The following code is blocked before 6.0. Otherwise, viewDidUnLoad will be automatically loaded when self. view is used below.

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

//Note that self. isViewLoaded is indispensable. Access to the view in other ways will cause it to load, which is also ignored in the WWDC video.

If (self. isViewLoaded &&! Self. view. window) // whether the view is in use {// 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; // The purpose is to reload and call the viewDidLoad function when you enter the page again.}

}}

 

However, it seems that writing like this is not easy. In the end, we found an article, which says it is not worthwhile to recycle this part of memory, for the following reasons:

1. UIView is a subclass of UIResponder, and UIResponder has a member variable of CALayer. CALayer is used to draw itself to the screen.

2. CALayer is a bitmap image packaging class. When UIView calls its own drawRect, CALayer will create this bitmap image class.

3. The memory is actually a bitmap image class. CALayer only occupies 48 bytes, and UIView only occupies 96 bytes. The bitmap class of an iPad full screen UIView accounts for 12 Mb!

4. During iOS6, when the system sends out MemoryWarning, the system automatically recycles the bitmap class. However, the UIView and CALayer classes are not recycled. In this way, most of the memory is recycled, and the bitmap class can be rebuilt based on the CALayer class when the bitmap class is required.

Therefore, iOS6 means that we do not have to reclaim memory for dozens of bytes at all.

 

-------------------------- Cut cake cut line --------------

PS:

1. About this official document: https://developer.apple.com/library/ios/#featuredarticles/ViewControllerPGforiPhoneOS/ViewLoadingandUnloading/ViewLoadingandUnloading.html

2. zon2012 does not seem to be compatible with ios6 (in fact, view is okay, and the key is resource)