Performance is especially important for iOS App development, and if your App is unresponsive or slow, frustrated users will write their frustration all over the App Store reviews. However, due to the limitations of iOS devices, it can sometimes be difficult to get performance right. There are a lot of things to be aware of during development, and it’s easy to forget to consider performance implications when making choices.

That’s why I’m writing this article. This article incorporates 25 tips and tricks you can use to improve your app’s performance in the form of a handy checklist.

Note: Every time you optimize your code, you should be aware of a problem. Don’t make the mistake of “pre-optimizing” your code. Always use Instruments to profile your code to find areas that need improvement. Matt Galloway wrote a great article on how to use Instruments to optimize code.

Also note that some of the suggestions listed here come at a cost. Suggested ways can speed up your app or make it more efficient, but can also take a lot of work to implement or make the code more complex, so choose carefully.

directory

The advice I’m going to give will fall into three different levels: entry-level, intermediate, and advanced:

Entry-level (Here are some tips you’ll definitely use in your app development)

1. Use ARC to manage memory

  1. Use reuseIdentifier in the right place

  2. Make Views as opaque as possible

  3. Avoid large XIBs

  4. Do not block the main thread

  5. Resize the Image in Image Views

  6. Select the correct Collection

  7. Open gzip compression

Intermediate (these are the ones you might use in relatively complex situations)

  1. Reuse and lazy loading Views

  2. Cache, Cache, Cache!

  3. Tradeoff rendering methods

  4. Handling memory warnings

  5. Reuse expensive objects

  6. Use the Sprite Sheets

  7. Avoid reprocessing data

  8. Choose the correct data format

  9. Set Background Images correctly

  10. Reduce the use of Web features

  11. Set the Shadow Path

  12. Optimize your Table View

  13. Select the correct data storage options

Advancement (These tips should only be used if you are confident that they are problem-solvable and handy)

  1. Acceleration start time

  2. Using Autorelease Pool

  3. Select whether to cache images

  4. Avoid date format conversions as much as possible

Beginner performance boost

This section focuses on some basic changes that can improve performance. But developers at all levels are likely to get a boost from this little performance memo documenting some neglected projects

  1. Manage memory with ARC

ARC(Automatic Reference Counting) comes with iOS5, which avoids the most common memory leak that often happens when we forget to free memory. It automatically manages the retain and release process for you, so you don’t have to manually intervene.

Here’s a code snippet you’ll often use to create a View:

2 / /… 3 [self.view addSubview:view]; 4[view release]; Forgetting the release at the end of the code snippet is as easy as remembering to eat. And ARC will automatically do that for you at the bottom.

In addition to helping you avoid memory leaks, ARC can also help you improve performance by ensuring that you free up memory for objects no longer needed. In this day and age, you should use ARC in all your projects!

Here are some resources to learn more about ARC:

Apple’s official documentation

Matthijs Hollemans’ Beginning ARC in iOS Tutorial

Tony Dahbura’s How To Enable ARC in a Cocos2D 2.X Project

If you still aren’t convinced of the benefits of ARC, check out this article on eight myths about ARC to really convince you why you should be using it!

ARC certainly can’t rule out all memory leaks for you. Memory leaks can still occur due to blocking, retain cycles, poorly managed CoreFoundation Objects (and C structures), or simply bad code.

There is a great ARC can’t do and what should we do articles at http://conradstoll.com/blog/2013/1/19/blocks-operations-and-retain-cycles.html.

2 Use reuseIdentifier in the right place

Image. The PNG in developing a common mistake is not to UITableViewCells UICollectionViewCells, even UITableViewHeaderFooterViews reuseIdentifier set up correctly.

For performance optimization, the table view with a tableView: cellForRowAtIndexPath: for the distribution of rows cells, its data should reuse self UITableViewCell. A table view maintains a queue of data reusable UITableViewCell objects.

Without the reuseIdentifier, a new cell would have to be set every time a table view is displayed. This can have a significant impact on performance, especially the scrolling experience of the app.

As of iOS6, in addition to UICollectionView cells and supplementary views, you should also use reuseIdentifiers in header and footer views.

To use reuseIdentifiers, add this method to your Data Source Object when adding a new cell to a table view:

1static NSString *CellIdentifier = @”Cell”; 2UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier forIndexPath:indexPath]; · This method removes existing cells from the queue or creates new cells using previously registered NIBs or classes if necessary. This method returns nil if there are no reusable cells and you haven’t registered a class or NIB.

3. Try to set views as opaque **

If you have opaque Views, you should set their opaque property to YES.

The reason is that this allows the system to render these views in an optimal way. This simple property can be set either in IB or in code.

Apple’s documentation for setting opacity for images reads:

The image.png (opaque) property gives the rendering system an indication of what to do with the view. If set to YES, the rendering system considers the view to be completely opaque, which allows the rendering system to optimize some of the rendering process and improve performance. If set to NO, the rendering system normally makes up the View with other content. The default value is YES.

On relatively still screens, setting this property does not have much effect. However, if the view is embedded in the Scroll View or is part of a complex animation, not setting this property 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. And the goal is, if you can make it opaque, make it opaque!

  1. Avoid xiBs that are too large

Storyboards added to iOS5 are rapidly replacing XIB. However, XIBs can still be useful in some scenarios. For example, if your app needs to adapt to pre-ios5 devices, or if you have a custom reusable view, you will inevitably use them.

If you have to xiBS, keep them as simple as possible. Try to configure a separate XIB for each Controller, splitting the View hierarchy of a View Controller into a separate XIB as much as possible.

PNG note that when you load a XIB everything is stored in memory, including any images. If you have a view that you don’t need right away, you’re wasting precious memory. Storyboards are another story, Storyboards only instantiate a View Controller when needed.

In XIB, all images are chache, as are sound files if you’re doing OS X development. Apple notes in the relevant documentation:

When you load an NIB that references an image or sound resource, the NIB load code writes the image and sound file into memory. In OS X, image and sound resources are cached in named cache for future use. In iOS, only image resources are stored in named Caches. Depending on your platform, use the imageNamed: method of NSImage or UIImage to get the image resource.

Obviously the same thing happens in Storyboards, but I can’t find any documentation that supports this conclusion. If you know about this operation, write to me!

To learn more about storyboards you can check out Matthijs Hollemans Beginning Storyboards in iOS 5 Part 1 and Part 2

  1. Do not block the main thread

Image.png should never overload the main thread. Because UIKit does all the work on the main thread, rendering, managing touch responses, responding to input, all that stuff needs to be done on it.

The risk of using the main thread all the time is that if your code actually blocks the main thread, your app will become unresponsive. This is… The shortest way to get a star in the App Store :]

Most of the cases that block the main process are when your app is doing I/O operations that involve reading or writing to external resources, such as storage or networking.

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 this asynchronously.

If you need to do other types of costly operations (such as time-sensitive calculations or storage reads and writes) use Grand Central Dispatches, or NSOperation and NSOperationQueues.

The following code is a template that uses GCD

1dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{ 2 // switch to a background thread and perform your expensive operation 3 4 dispatch_async(dispatch_get_main_queue(), ^{ 5 // switch back to the main thread to update your UI 6 7 }); 8}); Found a nested dispatch_async in your code? This is because any UIKit related code needs to be done on the main thread.

If you’re interested in NSOperation or GCD details, check out Ray Wenderlich’s Multithreading and Grand Central Dispatch on iOS for Beginners, And Soheil Azarpour’s How To Use NSOperations and NSOperationQueues tutorial.

  1. Resize the Image in Image Views

PNG If you want to display an image from a bundle in a UIImageView, you should make sure that the image is the same size as the UIImageView. Zooming in and out of images on the fly is expensive, especially if UIImageView is nested in a UIScrollView.

If the image is loaded from a remote service and you don’t have any control over the size of the image, for example, before downloading it, you can scale it once after downloading it, preferably with a Background thread, and then use the scaled image in the UIImageView.

Learning to select the classes or objects that are most appropriate for your business scenario is the foundation for writing efficient code. This is especially true when dealing with collections.

Apple has a documentation for Collections Programming Topics that details the differences between available classes and which scenarios you should use them in. This is a must-read document for anyone who uses Collections.

Hehe, I knew you missed it for too long… Here’s a summary of some common collections:

Arrays: an ordered set of values. Index lookup is fast, value lookup is slow, and insert/delete is slow.

Dictionaries: Store key-value pairs. It’s faster to look it up by keys.

Sets: an unordered set of values. Quick to find by value, quick to insert/delete.

8. Enable gzip compression

Many apps rely on remote resources and third-party apis, and you may develop an app that requires downloading XML, JSON, HTML, or other formats from remote sources.

The problem is that we’re targeting mobile devices, so you can’t expect the network to be good. A user may be on edge one minute and switch to 3G the next. Whatever the scenario, you don’t want to keep your users waiting too long.

One way to reduce documentation is to open Gzip on the server and in your app. This is especially useful for text, which has a higher compression rate.

The good news is that iOS already supports gzip compression by default in NSURLConnection, as do frameworks like AFNetworking based on it. Cloud service providers like Google App Engine already support compressed output.

If you don’t know how to open Gzip using Apache or IIS, read this article.

Intermediate performance improvement

Are you sure you’ve mastered the basics? But the reality is that sometimes some solutions aren’t as obvious as those, and they often depend heavily on how you structure and write your app. The following tips are for these scenarios.

  1. Reuse and lazy load Views

More views means more rendering, which means more CPU and memory consumption, especially for apps that have a lot of views nested inside UIScrollView.

The trick here is to mimic the actions of UITableView and UICollectionView: Instead of creating all subViews at once, create them as needed, and put them in a reusable queue when they’re done.

This way you only need to create your views when scrolling occurs, avoiding uneconomical memory allocation.

The energy efficiency issue of creating views also applies to other aspects of your app. Imagine a scenario where a user clicks a button and needs to present a view. There are two ways to do this:

1. Create and hide the view when the screen is loaded and display it when needed;

2. Create and present as needed.

Each scheme has its advantages and disadvantages.

In the first case, because you need to create a view at the beginning and keep it until you don’t use it anymore, it will consume more memory. However, it also makes your app more sensitive because when the user clicks on a button it just needs to change the visibility of the view.

The second option is the opposite – consuming less memory, but running slightly slower when the button is clicked.

  1. Cache, Cache, Cache!

A good rule of thumb is that the cache needs things that are not likely to change but need to be read frequently.

What can we cache? Some options are the response from the remote server, images, and even computed results, such as the row height of a UITableView.

By default, NSURLConnection caches the HTTP Headers loaded by the resource in memory or storage. You can even create an NSURLRequest manually and have it load only cached values.

2 NSMutableURLRequest request = [NSMutableURLRequest requestWithURL:url]; 3 4 request.cachePolicy = NSURLRequestReturnCacheDataElseLoad; //// this will make sure the request always returns the cached image 5 request.HTTPShouldHandleCookies = NO; 6 request.HTTPShouldUsePipelining = YES; 7 [request addValue:@”image/” forHTTPHeaderField:@”Accept”]; 8 9 return request; 10} Note that you can get a URL request via NSURLConnection, as well as AFNetworking. This way you don’t have to change all your networking code to adopt this tip.

If you want to learn more about HTTP Caching, NSURLCache, and NSURLConnection, read this article.

If you need to cache something other than an HTTP Request, you can use NSCache.

NSCache is similar to NSDictionary, except that when the system reclaims memory, it automatically deletes its contents. Mattt Thompson has an article on the great about it: : http://nshipster.com/nscache/

If you are interested in HTTP, you can read Google’s Best-practices Document on HTTP Caching.

  1. Tradeoff rendering methods

There are a lot of ways to make nice buttons in iOS. You can use whole images, resizable images, and uozhe can draw them using CALayer, CoreGraphics or even OpenGL.

Of course, each solution has different levels of complexity and corresponding performance. A great post on graphic performance recommended by Andy Matuschak, a member of the Apple UIKit team, is well worth reading.

Simply put, it’s faster to use pre-rendered images because it eliminates the need for iOS to create an image and draw something on it and then display it on the screen. The problem is that you need to put all the images you need into your app’s bundle, which increases the volume — and that’s where using variable-sized images is even better: you can save unnecessary space, and you don’t have to make different images for different elements (like buttons).

Use images, however, also means that you lost the adjust the picture mobile use code, you need to constantly redo them again and again, and it is a waste of time, and if you want to do an animation effects, although each image is just some of the detail of the changes you need a lot of pictures of increasing the size of the bundle.

In general, you need to balance performance against keeping the bundle at the right size.

  1. Handling memory warnings

IOS notifies all running apps when system memory runs low. The official document describes it as follows:

If your app gets a memory warning, it needs to free as much memory as possible. The best way to do this is to remove strong references for caches, image objects, and other objects that can be recreated.

Fortunately, UIKit provides several ways to collect low memory warnings:

Used in the app delegate applicationDidReceiveMemoryWarning: method

Override didReceiveMemoryWarning in your custom UIViewController subclass

Register and receive UIApplicationDidReceiveMemoryWarningNotification notification

Once you receive such notifications, you need to free up any unnecessary memory usage.

For example, UIViewController’s default behavior is to remove invisible views, and some of its subclasses can supplement this method by removing additional data structures. An app with an image cache can remove images that are not displayed on the screen.

Handling memory alerts in this way is essential, because if not, your app could be killed by the system.

However, you must make sure that the object you select can be recreated to free up memory. Be sure to test out the memory reminder emulation in the emulator during development.

  1. Reuse large overhead objects

PNG Some objects are slow to initialize, such as NSDateFormatter and NSCalendar. However, you will inevitably need to use them, such as parsing data from JSON or XML.

To avoid the bottleneck of using these objects, you need to reuse them, either by adding properties to your class or by creating static variables.

Note that if you choose the second method, the object will remain in memory for as long as your app runs, much like a singleton.

The following code shows using an attribute to lazily load a date formatter. The first call creates a new instance, and subsequent calls return the already created instance:

1// in your .h or inside a class extension 2@property (nonatomic, strong) NSDateFormatter *formatter; 3 4// inside the implementation (.m) 5// When you need, just use self.formatter 6- (NSDateFormatter *)formatter { 7 if (! _formatter) { 8 _formatter = [[NSDateFormatter alloc] init]; 9 _formatter.dateFormat = @”EEE MMM dd HH:mm:ss Z yyyy”; //twitter date format 10 } 11 return _formatter; Note also that setting an NSDateFormatter is almost as slow as creating a new one! So if your app does a lot of date formatting, you’ll get a significant performance boost from this approach.

  1. Use the Sprite Sheets

If you’re a game developer, Sprite Sheets must be one of your best friends. Sprite Sheet makes rendering faster and even less memory efficient than standard screen rendering methods.

We have two great tutorials for Sprite:

  1. How To Use Animations and Sprite Sheets in Cocos2D

  2. How to Create and Optimize Sprite Sheets in Cocos2D with Texture Packer and Pixel Formats

The second tutorial covers the details of the Pixel format that can greatly affect the performance of your game.

If you’re not familiar with Spirte Sheet, check out these two (YouTube) SpriteSheets — The Movie, Part 1 and Part 2. The video was written by Andreas Low, author of Texture Packer, one of the popular tools for creating Sprite Sheet.

In addition to using Sprite Sheets, the other tips written here can of course be applied to game development. For example, if you need a lot of Sprite Sheets, action essentials like enemies, missiles, etc., you can reuse these sprites without having to recreate them every time.

  1. Avoid reprocessing data

Many applications need to load data, often in JSON or XML format, from the server for functionality. It is important to use the same data structure on both the server and client sides. Manipulating data in memory to fit your data structure is expensive.

For example, if you need data to display a table view, it’s best to get the array structure data directly from the server to avoid additional intermediate data structure changes.

Similarly, if you need to fetch data from a particular key, a key-value pair dictionary is used.

  1. Choose the correct data format

There are many options for transferring data between apps and web services, the most common being JSON and XML. You need to choose the one that works best for your app.

Parsing JSON is faster than XML, and JSON is usually smaller and easier to transport. JSON deserialization is easy to use since iOS5 with official built-in JSON deserialization.

But XML also has XML benefits. For example, parsing XML with SAX is like parsing local files; you don’t have to wait until the entire document has been downloaded to start parsing, as you do with JSON. When you deal with very large amounts of data, you can dramatically reduce memory consumption and increase performance.

  1. Set the background image correctly

To put a background image in a View, just like many other iOS programs, there are several ways to do this:

Use UIColor’s colorWithPatternImage to set the background color;

Add a UIImageView to the view as a child view.

If you are using a full-frame background, you must use UIImageView because UIColor’s colorWithPatternImage is used to create small repeating images as backgrounds. Using UIImageView in this case can save a lot of memory:

1 // You could also achieve the same result in Interface Builder 2 UIImageView *backgroundView = [[UIImageView alloc] initWithImage:[UIImage imageNamed:@”background”]]; 3 [self.view addSubview:backgroundView]; If you use small tiling to create the background, you’ll need to do it with UIColor’s colorWithPatternImage, which renders faster and doesn’t cost much memory:

1 self.view.backgroundColor = [UIColor colorWithPatternImage:[UIImage imageNamed:@”background”]]; 18. Reduce the use of Web features

UIWebView is useful, it’s really easy to use it to display web content or create animations that UIKit can’t do.

But you might have noticed that UIWebView isn’t as fast as driving Safari. This is due to limitations of Webkit’s Nitro Engine, which features JIT compilation.

So for higher performance you need to tweak your HTML. The first thing to do is to remove unnecessary javascript whenever possible and avoid using overly large frameworks. It would be nice to just use native JS.

Also, load javascript that doesn’t affect page presentation, such as user behavior statistics scripts, asynchronously whenever possible.

Finally, always pay attention to the images you use and make sure they fit the size you use. Use Sprite Sheet for faster loading and memory savings.

For more information, see WWDC 2012 Session #601 — Optimizing Web Content in UIWebViews and Websites on iOS

  1. Set the Shadow Path

1 #import 2 #import 3 UIView *view = [[UIView alloc] init]; 4 5 // Setup the shadow … 6 view.layer.shadowOffset = CGSizeMake(-1.0f, 1.0f); 7 view. Layer. ShadowRadius = 5.0 f; 8 the view. The layer. ShadowOpacity = 0.6; Seems pretty simple, right?

However, the bad news is that using this method also has its problems… Core Animation has to draw and shadow your graphics in the background before rendering, which is expensive.

Using shadowPath avoids this problem:

view.layer.shadowPath = [[UIBezierPath bezierPathWithRect:view.bounds] CGPath];

With Shadow Path, iOS doesn’t have to calculate how to render every time, it uses a pre-calculated path. The problem is that calculating the path yourself can be difficult in some views, and you need to update the shadow path every time the View’s frame changes.

Read more on this post by Mark Pospesel.

  1. Optimization of the Table View

The Table view needs to have good scrolling performance, otherwise the user will find flaws in the animation during scrolling.

To keep the table View scrolling smoothly, make sure you do the following:

Use reuseIdentifier correctly to reuse cells

Try to make all view Opaque, including the cell itself

Avoid gradients, zoom, and background selection

Cache line height

If the actual content in the cell comes from the Web, use asynchronous loading and cache the request results

Use shadowPath to draw shadows

Reduce the number of subviews

Try not to use cellForRowAtIndexPath: if you need to use it, just use it once and then cache the result

Use the right data structure to store data

Use rowHeight, sectionFooterHeight, and sectionHeaderHeight to set fixed heights, and do not request a delegate

  1. Select the correct data storage options

What do you do when storing large chunks of data?

You have many options, such as:

Using NSUerDefaults

Use XML, JSON, or PList

Archive using NSCoding

Use a local SQL database like SQLite

Using the Core Data,

What’s the problem with NSUserDefaults? While it’s nice and convenient, it only works with small data, such as simple Booleans, and beyond that you need to consider other options

What about structured files like XML? In general, you need to read the entire file into memory to parse, which is very uneconomical. Using SAX is another hassle.

NSCoding? Unfortunately, it also needs to read and write files, so it has the same problems.

In this scenario, SQLite or Core Data is preferable. With these techniques you can load only the objects you need with specific queries.

SQLite and Core Data are very similar in terms of performance. They differ in how they are used. Core Data represents a Graph Model of an object, but SQLite is a DBMS. Apple recommends using Core Data in general, but if you have a reason not to use it, go for the lower-level SQLite.

If you use the SQLite, you can use the FMDB (https://github.com/ccgus/fmdb) this library to simplify the operation of the SQLite, so you don’t have to spend a lot of experience to understand the SQLite C API.

Advanced performance hints

Want some elite tips on how to become a ninja of the programmed ape? Here are some tips to help you optimize your app to the hilt!

  1. Acceleration start time

It’s important to open your app quickly, especially when you’re opening it for the first time. First impressions are so important to your app.

What you can do is make it do as many asynchronous tasks as possible, such as loading remote or database data and parsing data.

Again, avoid xiBs that are too large because they are loaded on the main thread. Try to use Storyboards that don’t have this problem!

Note that watchdog does not run with Xcode debug, be sure to disconnect the device from Xcode to test startup speed

  1. Using Autorelease Pool

NSAutoreleasePool is responsible for releasing the Autoreleased objects in the block. Normally it’s automatically called by UIKit. But in some cases you need to create it manually.

If you create a lot of temporary objects, you’ll find that memory will continue to decrease until the objects are released. This is because memory is only freed when UIKit runs out of autoRelease pools.

The good news is that you can avoid this behavior by creating temporary objects in your own @Autoreleasepool:

1 NSArray *urls = ; 2 for (NSURL *url in urls) { 3 @autoreleasepool { 4 NSError *error; 5 NSString fileContents = [NSString stringWithContentsOfURL:url 6 encoding:NSUTF8StringEncoding error:&error]; 7 / Process the string, creating and autoreleasing more objects. */ 8

See the official documentation for more information about NSAutoreleasePool.

  1. Select whether to cache images

There are two common ways to load an image from a bundle, one is imageNamed, the other is image with content file, the first one is a little bit more common.

Since there are two similar approaches to achieving the same goal, what is the difference between them?

The advantage of imageNamed is that it caches images when they are loaded. ImageNamed’s documentation says this:

This method looks up a picture object in the system cache with a specified name and returns it if it exists. If no corresponding image is found in the cache, this method loads the object from the specified document and then caches and returns the object.

In contrast, imageWithContentsOfFile only loads images.

The following code illustrates the use of both methods:

1 UIImage *img = [UIImage imageNamed:@”myImage”]; // caching 2 // or 3 UIImage *img = [UIImage imageWithContentsOfFile:@”myImage”]; // No caching So how do we choose?

If you’re loading a large image and you’re using it once, there’s no need to cache the image, just use image with Content file so you don’t waste memory caching it.

However, imageNamed is a much better choice in cases where images are reused repeatedly.

  1. Avoid date format conversions

If you’re going to use NSDateFormatter to handle a lot of date formats, be careful. As mentioned earlier, it’s a good practice to reuse NSDateFormatters anytime.

However, if you need more speed, going straight to C is a good solution. Sam Soffes has a great post (http://soff.es/how-to-drastically-improve-your-app-with-an-afternoon-and-instruments) with some that can be used to parse ISO-8601 Period string code, simple rewrite can be used to use.

Well, it looks good to do it in C, but can you believe we have a better solution?

If you can control the date format you work with, try to use Unix timestamps. You can easily convert from timestamp to NSDate:

1 – (NSDate*)dateFromUnixTimestamp:(NSTimeInterval)timestamp { 2 return [NSDate dateWithTimeIntervalSince1970:timestamp]; 3} This will be faster than parsing date strings in C!

Note that many Web apis return timestamps in microseconds, because this format is easier to use in javascript. Remember to divide by 1000 before dateFromUnixTimestamp.

Read more

The following WWDC videos are highly recommended for developers looking to improve the performance of their apps. You first need to make sure that you have registered your Apple ID as a developer to view WWDC 2012 videos here.

406: Adopting Automatic Reference Counting

238: iOS App Performance: Graphics and Animations

242: iOS App Performance: Memory

235: iOS App Performance: Responsiveness

409: Learning Instruments

706: Networking Best Practices

514: OpenGL ES Tools and Techniques

506: Optimizing 2D Graphics and Animation Performance

601: Optimizing Web Content in UIWebViews and Websites on iOS

225: Up and Running: Making a Great Impression with Every Launch

Some WWDC videos from 2001 are also valuable:

308: Blocks and Grand Central Dispatch in Practice

323: Introducing Automatic Reference Counting

312: iOS Performance and Power Optimization with Instruments

105: Polishing Your App: Tips and tricks to improve the responsiveness and performance

121: Understanding UIKit Rendering

Some other videos worth watching, mostly from iOS 5 Tech Talks:

Your iOS App Performance Hitlist

Optimizing App Performance with Instruments

Understanding iOS View Compositing

Ole Begemann wrote a text summary based on Michael Jurewitz’s video Your iOS App Performance Hitlist.

Apple provides a very useful is called “Performance Tuning | Performance Tuning” resources.

There are steps to explain the video and materials. Because there’s nowhere to put it. You can add my group to get it. Discuss audio and video technology in the group. QQ group number: 814636845