The thing that struck me most while working on the iPhone was how limited the resources actually are, something that isn’t (and shouldn’t be) obvious to the user. Going from the simulator to the actual device can be really jarring, because animations that seemed butter-smooth suddenly become a slideshow.

It can be very frustrating to go back to the code and try to figure out just what the issue is, so here are a few things to keep in mind while coding, performance-wise:

• Transparencies are expensive; wherever possible, set views to be opaque, so there won’t be any wasted cycles refreshing the views underneath.
• Always reuse cells; the docs seem to suggest that it’s simply a “good practice”, but it’s practically required. If you have a small table you might think it won’t matter to just allocate new cells, but once you start to scroll, the performance hit becomes obvious.
• It’s better to customize cells by subclassing UITableViewCell rather than add subviews to the content view, especially if transparency is involved. I’m not entirely sure why this is the case, just that subclassing eked out a few extra frames during scrolling.
• With normal-sized scroll views, loading subviews on-demand is actually worse. What is normal-sized? In my case, I tried up to 3200-by-460 and preloading the subviews yielded much smoother animations than any of the several load-on-demand methods I tried.

With most performance concerns, the common underlying issue is object allocation. Preloading definitely helps, but go too far and you start to bump your head against the memory ceiling. In the end, you want to balance object allocation and definitely use didReceiveMemoryWarning to clear out unused objects.

Overall however, I really liked working on the iPhone: it forces you to go back to the basics and come up with creative solutions: elegant coding is always better than the sledgehammer approach!

Posted on Saturday, January 10th, 18:11. Filed under: Cocoa, iPhone