Low-memory processing for iOS 5 and iOS 6

Low-memory processing for iOS 5 and iOS 6

 

 

Mobile devices have extremely limited memory and applications.ProgramDo a Good Job of Low-memory processing to avoid program crash 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, seeCodeAnnotations.

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 didreceivemorywarning]; // 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 didreceivemorywarning]; 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.

When there are too many threads, there are too many threads, too many threads