Ios6 memory warning and ios6 memory warning

Ios6 memory warning and ios6 memory warning

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.

Previous iOS3-iOS5.0 versions receive memory Warnings:
Calling didReceiveMemoryWarning to call didReceiveMemoryWarning of super will release the controller view. Therefore, we cannot release the controller view again.
Solution:

JavaCode

 

 

Memory warning for iOS6.0 and later versions:
Call didReceiveMemoryWarning to call didReceiveMemoryWarning of super. The call only releases the resouse of the controller and does not release the view.
Solution:
-(Void) didReceiveMemoryWarning
{
[Super didReceiveMemoryWarning]; // The self. view is not automatically released even if it is not displayed on the window.
// 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)

 

Share:

Xcode4.5 (iOS 6) Development and previous differences | IOS Email sending Method

• Browse 4798
• Comment (1)
• Category: mobile development
• Related Recommendations

Comment

Xiaoxiaotian, 1st floor

The memory of mobile devices is extremely limited. Applications must handle low-memory to avoid program crashes due to memory usage.

How to handle low-memory
An application usually contains multiple view controllers. When you jump from view to another view, the previous view is only invisible and will not be cleared immediately, but saved in memory, so that the next quick appearance can be made. However, if the application receives the low-memory warning from the system, we have to clear the views in the invisible state to free up more memory; currently, the visible view controller also needs to reasonably release some cached data, image resources and resources that are not in use to avoid application crash.

The idea is that the specific implementation varies slightly according to the system version. This article will detail the low-memory processing for iOS 5 and iOS 6.

Handling of iOS 5
Before iOS 6, if the application receives the low-memory warning, the currently invisible view controllers will receive the viewDidUnload message (or automatically call the viewDidUnload method ), therefore, we need to release all outlets and the resources that can be created again in the viewDidUnload method. The currently visible view controller uses didReceiveMemoryWarning to reasonably release resources. For details, see the code annotations.

For a simple example, there is a view controller:
@ Interface MyViewController: UIViewController {
NSArray * dataArray;
}
@ Property (nonatomic, strong) IBOutlet UITableView * tableView;
@ End

The corresponding processing is:
# 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];
}

Processing of iOS 6
IOS 6 discards the viewDidUnload method, which means we need to operate everything on our own in didReceiveMemoryWarning.
What should I do?

1. Set outlets to weak
When view dealloc, no one holds any strong reference pointing to subviews, The subviews instance variable will be automatically empty.
@ Property (nonatomic, weak) IBOutlet UITableView * tableView;

2. Set the cache data to null in didReceiveMemoryWarning.
# Pragma mark-
# Pragma mark Memory management


-(Void) didReceiveMemoryWarning
{
[Super didReceiveMemoryWarning];
// Dispose of any resources that can be recreated.
DataArray = nil;
}
Do not forget that every time tableview reload is performed, You need to judge dataArray. If it is empty, create a new one.

Compatible with iOS 5 and iOS 6
Well, the point is, what if I want the program to be compatible with iOS 5 and iOS 6? Here is a tip. We need to do something about didReceiveMemoryWarning:
# Pragma mark-
# Pragma mark Memory management

-(Void) didReceiveMemoryWarning
{
[Super didReceiveMemoryWarning];

If ([self isViewLoaded] & self. view. window = nil ){
Self. view = nil;
}

DataArray = nil;
}

Determine whether the view is part of the window. If not, you can safely leave self. view empty in exchange for more available memory.

What will this happen? If you switch from view controller A to view controller B and simulate the low-memory warning, view controller A will execute self. view = nil; when we return A from B, A will call viewDidLoad again. At this time, all the data is re-created, which is simple and compatible with no pressure ~~

Note:
If you are curious about why Apple abandoned viewDidUnload, you can refer to Apple's explanation:
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.

Why does the same program simulate a memory warning on the ios6 simulator trying to control the release of the view?

You should be clear about the principle of viewDidUnload. When the memory is warned, all viewcontrollers in the memory will execute the viewDidUnload method (except the viewController of the currently displayed view ).
As you said, iOS6 viewDidUnload is already Deprecated.
One of the previous viewDidUnload functions will automatically release the viewDidLoad cache data, so that data that you do not want to release will be lost when you reload the viewcontroller.

Therefore, at present, iOS6 and so on, in didReceiveMemoryWarning, you decide to safely release the useless memory that you think can be released, rather than automatically releasing all view-related items by the system.
In this case, after viewDidUnload occurs in iOS3, this method is gradually considered unreliable, which is equal to the state in which iOS6 is restored to iOS3, that is, it can only be released in didReceiveMemoryWarning.
In this case, if the code runs in iOS6, you need to add the view you created in didReceivMemoryWarning to release it. Without viewDidUnload, your didReceivMemoryWarning will not do anything.
The above is my personal analysis comprehension, which is not officially explained. If you have any objection, please discuss it with me in the comments.

How does ios6 clean up memory?

There should be software that can be used, and Android is used. Do not be surprised when something wrong is reported.