1. Use ARC to manage memory
ARC (Automatic ReferenceCounting) is released together with iOS5, which avoids the most common memory leaks that are often caused by our forgetting to free memory. It automatically manages the retain and release process for you, so you don't have to manually intervene. Forgeting the release at the end of the code segment is as easy as remembering to eat. And ARC will automatically do these tasks for you at the bottom. In addition to helping you avoid memory leaks, ARC can also help you improve performance, which can ensure that the memory of objects you no longer need is released.
Now all iOS programs use ARC, this one can be ignored.
2. Use reuseIdentifier in the right place
A common mistake in development is that the correct reuseIdentifier is not set to UITableViewCells, UICollectionViewCells, and even UITableViewHeaderFooterViews.
For performance optimization, when table view is allocated with tableView:cellForRowAtIndexPath:, its data should be reused from UITableViewCell. A table view maintains a queue of data reusable UITableViewCell objects.
If you do not use reuseIdentifier, you have to set a brand new cell for each row of table view displayed. This has a considerable impact on performance, especially it will greatly reduce the scrolling experience of the app.
Since iOS6, in addition to UICollectionView's cells and supplementary views, you should also use reuseIdentifiers in header and footer views.
If you want to use reuseIdentifiers, add this method in the data source object when adding a new cell to a table view:
staticNSString *CellIdentifier = @"Cell"; UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier forIndexPath:indexPath];
This method excludes existing cells from the queue, or creates new cells using previously registered nibs or class if necessary. If there is no reusable cell and you do not register a class or nib, this method returns nil.
3. Try to set views to transparent
If you have transparent Views you should set their opaque property to YES.
The reason is that this will allow the system to render these views in an optimal way. This simple attribute can be set in IB or code.
Apple's documentation describes setting transparent properties for images:
(opaque) This property provides a prompt for the rendering system on how to handle this view. If set to YES, the rendering system considers this view to be completely opaque, which allows the rendering system to optimize some rendering processes and improve performance. If set to NO, the rendering system normally forms this View with other content. The default value is YES.
In relatively static screens, setting this property will not have much impact. However, when this view is embedded in the scroll view, or is part of a complex animation, if this property is not set, it will greatly affect the performance of the app.
You can use the Debug\Color Blended Layers option in the emulator to find out which views are not set to opaque. The goal is, if you can set it to opaque, you will set it to opaque!
There is one thing to note here. As long as it is a Label with Chinese characters, even if you set it to opaque, the Label in the emulator will still turn red. This guess is a problem when drawing characters. No good solution has been found at this moment.
4. Avoid excessively large XIB
Storyboards added to iOS5 are rapidly replacing XIB. However, XIB is still useful in some scenarios. For example, if your app needs to adapt to devices before iOS5, or if you have a custom reusable view, you will inevitably use them.
If you have to XIB, make them as simple as possible. Try configuring a separate XIB for each controller and spread the view hierarchy of a View Controller into a separate XIB as much as possible.
It should be noted that when you load an XIB, everything is placed in memory, including any pictures. If you have a view that won't be used immediately, you're wasting your valuable memory resources. Storyboards is another matter, storyboard only instantiates a view controller when needed.
When it comes to XIB, all pictures are chache, and if you are doing OS X development, the sound files are the same. Apple's description in related documents is:
When you load a nib that references an image or sound resource, the nib loading code will write the image and sound files into memory. In OS X, image and sound resources are cached in named cache for future use. In iOS, only image resources will be stored in named caches. Depending on your platform, use the imageNamed: method of NSImage or UIImage to get image resources.
I have a deep understanding of this problem. The loading speed of interfaces written in xib is much slower than that written directly in code.
5. Do not block the main thread
Never let the main thread bear too much. Because UIKit does all the work on the main thread, rendering, managing touch responses, responding to inputs, etc. need to be done on it.
The risk of using the main thread all the time is that if your code really blocks the main thread, your app will lose its response.
Most of the situations that hinder the main process are your app doing some I/O operations involving reading and writing external resources, such as storage or network.
You can use NSURLConnection to do network operations asynchronously:
+ (void)sendAsynchronousRequest:(NSURLRequest *)request queue:(NSOperationQueue*)queue completionHandler:(void (^)(NSURLResponse*, NSData*, NSError*))handler
Or use a framework like AFNetworking to do these operations asynchronously.
If you need to do other types of operations that require huge resources (such as time-sensitive computing or storage read and write), then use Grand Central Dispatch, or NSOperation and NSOperationQueues.
The following code is a template using GCD
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
// switch to a background thread and perform your expensive operation
dispatch_async(dispatch_get_main_queue(), ^{
// switch back to the main thread to update your UI
});
});
Have you found a nested dispatch_async in your code? This is because any UIKit-related code needs to be done on the main thread.
6. Resize the image in Image Views
If you want to display an image from a bundle in a UIImageView, you should ensure that the size of the image is the same as that of the UIImageView. Scaling images during operation is very resource-consuming, especially when the UIImageView is nested in a UIScrollView.
If the image is loaded from the remote service, you cannot control the image size, for example, if it is adjusted to the appropriate size before downloading, you can use the background thread after the download is completed, and then use the scaled image in the UIImageView.
7. Select the correct Collection
Learning to choose the most suitable class or object for business scenarios is the basis for writing energy-efficient code. This statement is especially true when dealing with collections.
Summary of some common collections:
- Arrays: an ordered set of values. Using index to lookup is fast, using value to lookup is slow, insertion/deletion is slow.
- Dictionaries: Store key-value pairs. Use keys to find it faster.
- Sets: An unordered set of values。 Use values to find them quickly，insert/Delete quickly。 Because Set uses hash, insertion and deletion search speed is much faster than Array
8. Turn on gzip compression
A large number of apps rely on remote resources and third-party APIs. You may develop an app that needs to download XML, JSON, HTML or other formats from the remote.
The problem is that we are targeting mobile devices, so you can't expect how good the network is. A user is still on the edge network and may switch to 3G in the next minute. No matter what scenario, you definitely don't want your users to wait too long.
One way to reduce the document is to open gzip on the server and in your app. This will have more significant effects on data such as text that can have higher compression rates.
The good news is that iOS already supports gzip compression by default in NSURLConnection, and of course, the same frameworks based on it are AFNetworking. Cloud service providers like Google App Engine have also supported compressed output.
9. Reuse and lazy load Views
More views mean more rendering, that is, more CPU and memory consumption, especially for apps that nest many views in UIScrollView.
The trick we use here is to imitate the operations of UITableView and UICollectionView: don't create all subviews at once, but create them when needed. When they complete their mission, put them into a reusable queue.
In this way, you just need to create your views when the scrolling occurs, avoiding unfavorable memory allocation.
The energy efficiency issues of creating views also apply to other aspects of your app. Imagine a scene where a user needs to present a view when clicking a button. There are two ways to implement it:
1. Create and hide this view when the screen is loaded, display it when needed;
2. Create and display when needed.
Each solution has its advantages and disadvantages. In the first solution, you need to create a view from the beginning and keep it until it is no longer used, which will consume more memory. However, this will also make your app operation more sensitive because when the user clicks a button, it only needs to change the visibility of the view.
The second solution is the opposite - consumes less memory, but it will be slightly stuttering when clicking the button.
10. Cache, Cache, or Cache! Pay attention to your cache
An excellent principle is that what caches require, that is, things that are unlikely to change but require frequent reading.
What can we cache? Some options are the responses of the remote server, pictures, and even calculation results, such as the row height of the UITableView.
NSURLConnection will cache resources in memory or storage based on the HTTP Headers it loads by default. You can even manually create an NSURLRequest and then make it load only the cached values.
Here is a available code snippet that you can use to create an NSURLRequest for an image that is basically unchanged and cache it:
+ (NSMutableURLRequest *)imageRequestWithURL:(NSURL *)url {
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url];
= NSURLRequestReturnCacheDataElseLoad;// this will make sure the request always returns the cached image
= NO;
= YES;
[request addValue:@"image/*"forHTTPHeaderField:@"Accept"];
return request;
}
Note that you can get a URL request through NSURLConnection, and the same is true for AFNetworking. This way you don't have to change all networking code to use this tip.
If you need to cache other things that are not HTTP Requests, you can use NSCache.
NSCache is similar to NSDictionary, the difference is that when the system recycles memory, it will automatically delete its contents.
11. Trade-off rendering method
There are many ways to make beautiful buttons in iOS. You can use the entire picture, the resized picture, or you can use CALayer, CoreGraphics or even OpenGL to draw them. Of course, each different solution has different levels of complexity and corresponding performance.
Simply put, it is faster to use pre-rendered images, because iOS eliminates the program that creates an image, draws things and displays them on the screen. The problem is that you need to put all the images you need into the app's bundle, which increases the volume – this is the better place to use variable sized images: you can save some unnecessary space and no longer need to make different images for different elements (such as buttons).
However, using images also means you lose the maneuverability of using code to adjust images, you need to rework them over and over again, which is a waste of time, and if you want to do an animation effect, although each image is just a few details, you need a lot of images to cause the bundle size to continue to grow.
In short, you need to weigh the pros and cons, whether to maintain performance or bundle size.
12. Handle memory warnings
Once the system memory is too low, iOS will notify all running apps. It is described in the official documentation:
If your app receives a memory warning, it needs to free up as much memory as possible. The best way is to remove strong references to cache, image objects and some other objects that can be recreated.
Fortunately, UIKit provides several ways to collect low memory warnings:
- Method of using applicationDidReceiveMemoryWarning: in app delegate
- Override didReceiveMemoryWarning in your custom UIViewController's subclass (subclass)
- Register and receive notifications from UIApplicationDidReceiveMemoryWarningNotification
Once you receive this kind of notification, you will need to free up any unnecessary memory usage.
For example, the default behavior of UIViewController is to remove some invisible views, and some subclasses of it can supplement this method and delete some additional data structures. An app with image cache can remove images that are not displayed on the screen.
This is necessary to handle memory alerts. If you do not pay attention to it, your app may be killed by the system.
However, when you must confirm that the object you selected is created to free memory. Be sure to use the memory reminder in the simulator to test it in development.
Of course, now that iOS devices are running memory is getting bigger and bigger, this is difficult to happen.
13. Reuse of large overhead objects
Some objects are slow to initialize, such as NSDateFormatter and NSCalendar. However, you inevitably need to use them, such as parsing data from JSON or XML.
To avoid the bottlenecks of using this object, you need to reuse them, which can be achieved by adding properties to your class or creating static variables.
Note that if you want to choose the second method, the object will always exist in memory while your app is running, which is very similar to a singleton.
The following code illustrates the use of a property to delay loading a date formatter. When it is called for the first time, it creates a new instance, and later calls will return the already created instance:
// in your .h or inside a class extension
@property (nonatomic, strong) NSDateFormatter *formatter;
// inside the implementation (.m)
// When you need, just use
- (NSDateFormatter *)formatter {
if(!_formatter) {
_formatter = [[NSDateFormatter alloc] init];
_formatter.dateFormat = @"EEE MMM dd HH:mm:ss Z yyyy";// twitter date format
}
return _formatter;
}
It should also be noted that setting up an NSDateFormatter is actually as slow as creating a new one! So if your app needs to process date format frequently, you will get a considerable performance improvement from this method.
14. Using Sprite Sheets
Sprite sheets can speed up rendering and even save memory than standard screen rendering methods.
15. Avoid repeated processing of data
Many applications require data that is often JSON or XML format required to load functions from the server. It is important to use the same data structure on the server side and on the client side. It is expensive to manipulate data in memory to make them satisfy your data structure.
For example, if you need data to display a table view, it is best to directly retrieve the data of the array structure from the server to avoid additional intermediate data structure changes.
Similarly, if you need to get data from a specific key, then use the dictionary of the key-value pair.
This is extremely important when processing large amounts of data, and the method of exchanging space for time may be excellent.
16. Select the correct data format
There are many solutions to transfer data from apps and network services, the most common of which are JSON and XML. You need to choose the one that is most suitable for your app.
Parse JSON is faster than XML, and JSON is usually smaller and easier to transfer. Since iOS5, it has become more convenient to use with the official built-in JSON deserialization.
But XML also has the benefits of XML. For example, using SAX to parse XML is like parsing local files. You don’t need to wait until the entire document is downloaded before starting parsing like parsing json. When you process large data, it greatly reduces memory consumption and increases performance.
Now it's basically JSON.
17. Set the background picture correctly
There are many ways to put background images in a View like many other iOS programming:
Use UIColor's colorWithPatternImage to set the background color;
Add a UIImageView as a child View in the view.
If you use a full frame background image, you must use UIImageView because UIColor's colorWithPatternImage is used to create small repeating images as background. In this case, using UIImageView can save a lot of memory:
// You could also achieve the same result in Interface Builder UIImageView *backgroundView = [[UIImageView alloc] initWithImage:[UIImage imageNamed:@"background"]]; [ addSubview:backgroundView];
If you use small picture tiling to create backgrounds, you need to use UIColor's colorWithPatternImage to do it, which renders faster and does not cost much memory:
= [UIColor colorWithPatternImage:[UIImage imageNamed:@"background"]];
18. Reduce the use of web features
UIWebView is very useful, and it is very simple to use it to display web content or create animation effects that are difficult to achieve in UIKit.
But you may have noticed that UIWebView is not as fast as it drives Safari. This is due to the limitations of Nitro Engine of Webkit featuring JIT compilation.
So if you want higher performance, you have to adjust your HTML. The first thing to do is remove unnecessary JavaScript as much as possible and avoid using too large frameworks. It would be even better if you could just use native js.
In addition, asynchronously load javascript such as user behavior statistics script that does not affect the expression of the page as much as possible.
Finally, always pay attention to the pictures you use to ensure that the pictures are in line with the size you use. Use Sprite sheet to increase loading speed and save memory.
19. Set Shadow Path
How to add a shadow to a View or a layer? The QuartzCore framework is the choice of many developers:
UIView *view = [[UIView alloc] init]; = CGSizeMake(-1.0f, 1.0f); = 5.0f; = 0.6;
It looks simple, right. However, the bad news is that using this method also has its problems... Core Animation had to first get your graphics in the background and add shadows before rendering it, which is a lot of overhead.
Using shadowPath avoids this problem:
= [[UIBezierPath bezierPathWithRect:] CGPath];
If you use shadow path, iOS does not have to calculate how to render every time, it uses a pre-computed path. But the problem is that calculating the path yourself may be more difficult in some Views, and whenever the frame of the view changes, you need to update shadow path.
I prefer to use CALayer to draw a shadow by myself, so that the shadow can be rasterized, saving a lot of CPU operations, the disadvantage is that it consumes more memory. Because if you set rasterization to the view layer, the entire view will become blurred.
20. Optimize Table View
Table view needs to have good scrolling performance, otherwise users will find flaws in the animation during scrolling.
In order to ensure smooth scrolling of the table view, make sure you take the following measures:
- Use reuseIdentifier correctly to reuse cells
- Try to make all view opaques, including the cell itself
- Avoid gradients, image scaling, and select people in the background
- cache line height
- If the actual content in the cell comes from the web, use asynchronous loading, cache the request result
- Use shadowPath to draw shadows
- Reduce the number of subviews
- Try not to use cellForRowAtIndexPath: If you need to use it, use it only once and cache the result.
- Use the correct data structure to store data
- Use rowHeight, sectionFooterHeight and sectionHeaderHeight to set a fixed height, do not request delegate
21. Select the correct data storage option
What do you do when storing large chunks of data?
You have many choices, such as:
- Use NSUerDefaults
- Use XML, JSON, or plist
- Use NSCoding to archive
- Use a local SQL database similar to SQLite
- Using Core Data
What is the problem with NSUserDefaults? Although it is nice and convenient, it is only suitable for small data, such as some simple Boolean setting options. If you are a little bigger, you have to consider other methods.
What about structured archives like XML? Overall, you need to read the entire file into memory to parse, which is very uneconomical. Using SAX is another troublesome thing.
NSCoding? Unfortunately, it also requires reading and writing files, so there are also the above problems.
In this application scenario, it is better to use SQLite or Core Data. Using these techniques you can load only the objects you need with specific query statements.
On the performance level, SQLite and Core Data are very similar. Their difference lies in the specific usage method. Core Data represents an object's graph model, but SQLite is a DBMS. Apple generally recommends using Core Data, but if you have a reason not to use it, then use the underlying SQLite.
If you use SQLite, you can use FMDB(/ccgus/fmdb) This library simplifies SQLite operations so that you don't have to spend a lot of experience understanding SQLite's C API.
23. Use Autorelease Pool
NSAutoreleasePool is responsible for releasing autoreleased objects in blocks. Generally, it will be automatically called by UIKit. But in some cases you also need to create it manually.
If you create many temporary objects, you will find that the memory is decreasing until these objects are released. This is because memory will be released only when the UIKit runs out of autorelease pool. The good news is that you can create temporary objects in your own @autoreleasepool to avoid this behavior:
NSArray *urls = <# An array of file URLs #>;
for(NSURL *url in urls) {
@autoreleasepool {
NSError *error;
NSString *fileContents = [NSString stringWithContentsOfURL:url encoding:NSUTF8StringEncoding error:&error];
/* Process the string, creating and autoreleasing more objects. */
}
}
This code releases all autorelease objects after each traversal
24. Choose whether to cache images
There are two common ways to load images from bundles. One is to use imageNamed, and the other is to use imageWithContentsOfFile. The first is more common.
Since there are two similar ways to achieve the same purpose, what is the difference between them?
The advantage of imageNamed is that it caches images when loaded. The imageNamed document says this: This method uses a specified name to look up an image object in the system cache if it exists. If no corresponding image is found in the cache, this method loads from the specified document and caches and returns the object.
Conversely, imageWithContentsOfFile only loads the image.
The following code illustrates the usage of these two methods:
UIImage *img = [UIImage imageNamed:@"myImage"];// caching // or UIImage *img = [UIImage imageWithContentsOfFile:@"myImage"];// no caching
So how should we choose?
If you want to load a large image and use it for one-time use, there is no need to cache the image. Using imageWithContentsOfFile is enough, so that you won't waste memory to cache it.
However, imageNamed is a much better choice in case of repeated reuse of images.
25. Avoid date format conversion
If you are using NSDateFormatter to handle many date formats, you should be careful. As mentioned earlier, reusing NSDateFormatters at any time is a good practice.
However, if you need more speed, it is a good solution to go straight to C.
Well, it looks good to use C directly, but do you believe it? We have a better solution!
If you can control the date format you are dealing with, try to choose Unix timestamps. You can easily convert from timestamp to NSDate:
- (NSDate*)dateFromUnixTimestamp:(NSTimeInterval)timestamp {
return[NSDate dateWithTimeIntervalSince1970:timestamp];
}
This will be faster than parsing date strings with C! It should be noted that many web APIs return timestamps in microseconds, because this format is more convenient to use in javascript. Remember to divide it by 1000 before using dateFromUnixTimestamp.
The above is all the content of this article. I hope it will be helpful to everyone's study and I hope everyone will support me more.