StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Many things affect render performance, here are some items you can check:</p> <ul> <li><p>Profile - You said you already did this, so great job! Unfortunately profiling is often overlooked, even though it can reveal unexpected problems. In one app I was working on a calendar with different cells representing dates. At first scrolling between cells slow, which was unexpected. I thought maybe it was drawing a few cells too many. After profiling I found that <code>[NSCalender currentCalender]</code> was using 85% of my CPU time! After fixing that everything scrolled great!</p></li> <li><p>Images - Large images put a lot of load in CoreGraphics. Scrolling especially requires a lot of draw operations to move them around. One tip is to scale images on the device as little as you can, that makes CoreGraphics' job a lot easier. If an image is twice as large as the view displaying it, resize the UIImage before displaying it in the view. iOS devices handle PNGs best. They are compressed by a tool (pngcrush) at compile time and iOS has special hardware for rendering them.</p></li> </ul> <p><strong>Edit</strong>: JPGs are probably a better option for photos. iOS devices have dedicated JPG decoders as well.</p> <ul> <li><p>Custom Drawing - If possible, cutback on the amount of custom CGContext drawing you do. Lots of custom drawing has negative effects on animation speed. I would considering using an image over complex custom drawing, if possible.</p></li> <li><p>Cull - Only draw things you need to. <code>UITableView</code> automatically unloads and loads cells as they appear, so this is done for you, but any custom CGContext drawing should only be done when that part is visible. Also automatic view shadows can be very slow in my experience.</p></li> <li><p>Reuse - Use the reuse identifier on <code>UITableView</code>, this will allow <code>UITableView</code> to reuse cell objects rather than reallocating as it scrolls - look at the answer to this <a href="https://stackoverflow.com/questions/2152180/iphone-what-are-reuseidentifiers-uitableviewcell">question</a>. Also reuse <code>UIImages</code> rather than allocating multiple for the same file. <code>imageNamed</code> caches images automatically but <code>imageFromContents</code> of file does not.</p></li> <li><p>Create your own - You could create your own grid view class that culls it's subviews views hidden off screen, and scrolls with lazy content loading. By writing a custom solution you can fully control the process and create a design optimized for the usage context. For most use cases you will have a hard time building something better than the Apple standard, but I have seen it done in specific cases. </p></li> <li><p>Last resort - Reduce the size of the offending view (improves filtrate), break content into multiple pages, downsize images, cut out older devices that don't perform as well. I would settle for 30 FPS before sacrificing most of that stuff. Devices will continue to get faster, older devices will be eliminated, and your app will gradually get faster.</p></li> </ul>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload