LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestras Condiciones de uso y nuestra Política de privacidad para más información.
LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestra Política de privacidad y nuestras Condiciones de uso para más información.
iOS App Performance
Things to Take Care
Gurpreet Singh Sachdeva
Engineering Manager @ Yahoo
Who should attend this session?
• If you are developing or planning to develop
iOS apps and looking for tips to make your
apps fast then you are right place.
• Pre-requisite: Basic Objective-C knowledge
Why performance is important?
• Faster apps provide a better user experience
• Users expect high performance
• If your app is slow or unresponsive it is bound
to get bad reviews and loose user base.
• Remember, mobile devices have less RAM.
• Use ARC
• In addition to helping you avoid memory leaks, ARC can
also improve your performance, by making sure that
objects are de-allocated as soon as they are no longer
• These days, you should always use ARC in your projects!
• Don’t block the main thread
• You should never do any heavy lifting on the main
thread. Remember, UIKit does all of its work on the
main thread, such as drawing, managing touches, and
responding to input.
• Most cases of blocking the main thread occur when your
app is performing an I/O operation which involves any
task that needs to read or write from an external
source, such as the disk or the network.
• You can perform network tasks asynchronously by using
this method on NSURLConnection
• Use a reuseIdentifier where appropriate
• A table view’s data source should generally reuse
UITableViewCell objects when it assigns cells to rows.
• Otherwise, table view will configure new cell each time
a row is displayed. This is an expensive operation and
will affect the scrolling performance of your app
• To use reuseIdentifiers, call this method from your data
source object when asked to provide a new cell for the
static NSString *CellIdentifier = @"Cell";
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier forIndexPath:indexPath];
• Avoid fat XIBs
• If you are still using XIB files for some reason (may be for
supporting pre iOS 5 devices) then make them as
uncomplicated as possible.
• Note that when you load a XIB into memory, all of its
contents are loaded into memory, including any images.
• If you have a view you’re not using immediately, then you’re
wasting precious memory.
• It’s worth noting that this won’t happen with storyboards,
since a storyboard will only instantiate a view controller when
• Size images to Image Views
• Scaling images on the fly can be expensive, especially if
your UIImageView is embedded in a UIScrollView.
• If the image is downloaded from a remote service,
sometimes you don’t have control over the size, or you
might not be able to scale it on the server prior to
• Choose the correct Collection
• Learning to use the most appropriate class or object for
the task at hand is fundamental to writing efficient
code. This is especially true when dealing with
• There is a document on Apple’s Developer Library that
explains in detail the differences between the available
classes, as well as which situations suit each class. It’s a
must read document for anyone looking to work with
• Enable GZIP compression
• Speed up the download of network-based resources by
enabling GZIP compression on both your server and on
• The good news is that iOS already supports GZIP
compression by default if you’re using
NSURLConnection, or a framework built on top of it such
• There is a great article about GZIP compression which
explains how to enable it on your Apache or IIS server.
• Reuse and lazy Load Views
• Create your views as you need them.
• More views means more drawing; which ultimately
means more CPU and memory overhead. This is
especially true if your app embeds many views inside of
• Cache what matters
• Cache things that are unlikely to change, but are
• What can you cache?
• Some candidates for caching are remote server responses,
• NSURLConnection already caches resources on disk or in
memory according to the HTTP headers it processes.
• Handle memory warnings
• iOS notifies all running apps when system memory is
• UIKit provides several ways to receive these low-memory
warnings, including the following:
• Implement the applicationDidReceiveMemoryWarning: method of your
• Override didReceiveMemoryWarning in your custom UIViewController
• Register to receive the
• Upon receiving any of these warnings, free up any unnecessary
• Purge unused data structures, release any images that are not
• Reuse expensive Objects
• Some objects are very slow to initialize —
NSDateFormatter and NSCalendar are two examples.
• To avoid performance bottlenecks when working with
these objects, try to reuse these objects if at all possible.
• You can do this by either adding a property to your class or
• Optimize Your Table Views
• Tips for optimizing Table Views
• Reuse cells by setting the correct reuseIdentifier.
• Make as many views opaque as possible, including the cell
• Avoid gradients, image scaling.
• If the cell shows content that comes from the web, be sure to
make those calls asynchronously and cache the responses.
• Reduce the number of subviews.
• Do as little work as possible in cellForRowAtIndexPath:. If you
need to do some work, do it only once and cache the results.
• Use the appropriate data structure to hold the information you
need. Different structures have different costs for different
• Speed up launch time
• Launching your app quickly is very important, especially
when the user launches for the first time. First
impressions mean a lot for an app!
• Ensure your app starts as quickly as possible is to
perform asynchronous tasks.
• You need to strike a balance between what to fetch before app
launch and what to fetch once the app is launched.
• Try to avoid fat XIBs, since they’re loaded on the main
thread. But recall that storyboards don’t have this
problem — so use them if you can!
• Cache Images (when?)
• There are two common ways to load a UIImage from an
• Using imageNamed and second using
• imageNamed has the advantage of caching the image as it’s loaded.
• Alternately, imageWithContentsOfFile simply loads the image with no
• When would you use one over the other?
• If you’re loading a large image that will be used only once,
there’s no need to cache the image.
• However, imageNamed is a much better choice for images that
you’re going to be reusing in your app.
• Reduce battery consumption
• Optimize use of the following features:
• The CPU
• Wi-Fi, Bluetooth, and baseband (EDGE, 3G) radios
• The Core Location framework
• The accelerometers
• The disk
• Consider the following guidelines:
• Avoid doing work that requires polling.
• Avoid accessing the disk too frequently.
• Do not draw to the screen faster than is needed.
• Connect to external network servers only when needed, and do
not poll those servers.
• Disable location updates as soon as you can.
• Reduce App’s memory footprint
• Actions to take
• Eliminate memory leaks.
• Make resource files as small as possible.
• Use Core Data or SQLite for large data sets.
• Load resources lazily.
• Use NSLog as sparingly as possible in production
• Messages written using NSLog are presented in the
debugger console and even to the device's console log
• NSLog() takes a non-negligible amount of time.
• The following are commonly used log definitions that
are used to selectively perform NSLog() in
// Only log when attached to the debugger
# define DLog(...) NSLog(__VA_ARGS__)
# define DLog(...) /* */
// Always log, even in production
#define ALog(...) NSLog(__VA_ARGS__)
• Be Lazy
• Defer memory allocations until you actually need the
• Defer reading the contents of a file until you actually
need the information.
• Take Advantage of Perceived Performance
• The perception of performance is just as effective as
actual performance in many cases.
• Many program tasks can be performed in the
background, using a dispatch queue, or at idle time.
• Doing this keeps the application’s main thread free to handle
user interactions and makes the program interface feel more
responsive to the user.
• If your program needs to scan a number of files or perform
lengthy calculations, do so using a dispatch queue.
• There is a good document available on apple’s site for
Analyzing the performance
• Using apple tools for analyzing performance