Introduction to Low-memory Processing for iOS 5 and iOS 6

Mobile device terminals have very limited memory, and applications must do low-memory processing to avoid crashes due to excessive memory usage.

The thought of low-memory treatment

Usually an application contains multiple view controllers, and when you jump from view to another view, the previous view is only invisible and not immediately cleared, but is saved in memory for the next quick appearance. But if the application receives the Low-memory warning from the system, we will have to clean out the views that are not currently visible, freeing up more available memory, and the currently visible view controller to reasonably release some cached data. Picture resources and some resources that are not in use to avoid application crashes.

The idea is that specific implementations vary slightly depending on the system version, and this article will detail the low-memory processing of iOS 5 and iOS 6.

Processing of IOS 5

Prior to iOS 6, if the application received the Low-memory warning, the currently invisible view controllers would receive the Viewdidunload message (also understood as an automatic call to the Viewdidunload method), so we need to The Viewdidunload method frees all outlets and the resources that can be created again. The view controller currently visible is didreceivememorywarning to reasonably release resources, as specified in code comments.

To give 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 doe SN ' 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 is 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 that everything needs to be done in didreceivememorywarning.

What exactly should be done?

1. Placing outlets as weak

When view Dealloc, no one holds any strong references to Subviews, the subviews instance variable is automatically empty.

@property (nonatomic, weak) Iboutlet UITableView *tableview;

2. Empty cached data in didreceivememorywarning

#pragma mark-    
#pragma mark Memory management    
        
        
-(void) didreceivememorywarning    
{    
    [super Didreceivememorywarning];    
    Dispose of any of the can is recreated.    
    DataArray = nil;    
}

See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/OS/extra/

Do not forget that, whenever tableview reload, you need to judge the DataArray, if empty then recreate.

Compatible with iOS 5 and iOS 6

Well, the point is, what if you want the program to be compatible with iOS 5 and iOS 6?

Here's a little trick, we need to do something to didreceivememorywarning:

#pragma mark-    
#pragma mark Memory management    
        
        
-(void) didreceivememorywarning    
{    
    [super Didreceivememorywarning];    
            
    if ([self isviewloaded] && Self.view.window = = nil) {    
        self.view = nil;    
    }    
            
    DataArray = nil;    
}

Determine if view is part of window, and if not, you can safely place the Self.view in exchange for more available memory.

What would be the phenomenon? If, from view controller a jumps to view controller B, and then simulates the low-memory warning, view controller A will execute Self.view = nil; When we return a from B, a will call again Viewdidload, the data is all recreated, simple compatible without pressure ~ ~

UPDATE-2013.5.21

1. In the commentary, a man offered his solution:

In the Didreceivememorywarning method, if the current version >= 6.F, use Performselectoronmainthread call Viewdidunload, can be reused for compatibility 5 write Viewdidunload method.

The idea is very good, but I think it is not necessary, because in the iOS6, before the viewdidunload implementation of the things have been completely hosted, not without doing related processing, do not need to call the viewdidunload manually.

2. Also some people do not recommend the use of the Qing Self.view this article mentioned in this lazy compatibility method, specific to see: Goodbye, Viewdidunload method

I think this is really worth everyone's thinking, and also welcome to talk about their own ideas.

Note:

If you're curious about why Apple abandoned viewdidunload, look at 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 T. For IOS 6+ apps, your can simply forget about view unloading and only implement didreceivememorywarning if the view cont Roller can let go of cached data this can recreate on demand later.

Author: csdn