Question

To clarify the purpose of this question: I know HOW to create complicated views with both subviews and using drawRect. I’m trying to fully understand the when’s and why’s to use one over the other.

I also understand that it doesn’t make sense to optimize that much ahead of time, and do something the more difficult way before doing any profiling. Consider that I’m comfortable with both methods, and now really want a deeper understanding.

A lot of my confusion comes from learning how to make table view scroll performance really smooth and fast. Of course the original source of this method is from the author behind twitter for iPhone (formerly tweetie). Basically it says that to make table scrolling buttery smooth, the secret is to NOT use subviews, but instead do all the drawing in one custom uiview. Essentially it seems that using lots of subviews slows rendering down because they have lots of overhead, and are constantly re-composited over their parent views.

To be fair, this was written when the 3GS was pretty brand spankin new, and iDevices have gotten much faster since then. Still this method is regularly suggested on the interwebs and elsewhere for high performance tables. In fact it’s a suggested method in Apple’s Table Sample Code, has been suggested in several WWDC videos (Practical Drawing for iOS Developers), and many iOS programming books.

There are even awesome looking tools to design graphics and generate Core Graphics code for them.

So at first I’m lead to believe “there’s a reason why Core Graphics exists. It’s FAST!”

But as soon as I think I get the idea “Favor Core Graphics when possible”, I start seeing that drawRect is often responsible for poor responsiveness in an app, is extremely expensive memory wise, and really taxes the CPU. Basically, that I should “Avoid overriding drawRect” (WWDC 2012 iOS App Performance: Graphics and Animations)

So I guess, like everything, it’s complicated. Maybe you can help myself and others understand the When’s and Why’s for using drawRect?

I see a couple obvious situations to use Core Graphics:

1. You have dynamic data (Apple’s Stock Chart example)
2. You have a flexible UI element that can’t be executed with a simple resizable image
3. You are creating a dynamic graphic, that once rendered is used in multiple places

I see situations to avoid Core Graphics:

1. Properties of your view need to be animated separately
2. You have a relatively small view hierarchy, so any perceived extra effort using CG isn’t worth the gain
3. You want to update pieces of the view without redrawing the whole thing
4. The layout of your subviews needs to update when the parent view size changes

So bestow your knowledge. In what situations do you reach for drawRect/Core Graphics (that could also be accomplished with subviews)? What factors lead you to that decision? How/Why is drawing in one custom view recommended for buttery smooth table cell scrolling, yet Apple advises drawRect against for performance reasons in general? What about simple background images (when do you create them with CG vs using a resizable png image)?

A deep understanding of this subject may not be needed to make worthwhile apps, but I don’t love choosing between techniques without being able to explain why. My brain gets mad at me.

Question Update

Thanks for the information everyone. Some clarifying questions here:

1. If you are drawing something with core graphics, but can accomplish the same thing with UIImageViews and a pre-rendered png, should you always go that route?
2. A similar question: Especially with badass tools like this, when should you consider drawing interface elements in core graphics? (Probably when the display of your element is variable. e.g. a button with 20 different color variations. Any other cases?)
3. Given my understanding in my answer below, could the same performance gains for a table cell possibly be gained by effectively capturing a snapshot bitmap of your cell after your complex UIView render’s itself, and displaying that while scrolling and hiding your complex view? Obviously some pieces would have to be worked out. Just an interesting thought I had.

Answer 1

Stick to UIKit and subviews whenever you can. You can be more productive, and take advantage of all the OO mechanisms that should things easier to maintain. Use Core Graphics when you can’t get the performance you need out of UIKit, or you know trying to hack together drawing effects in UIKit would be more complicated.

The general workflow should be to build the tableviews with subviews. Use Instruments to measure the frame rate on the oldest hardware your app will support. If you can’t get 60fps, drop down to CoreGraphics. When you’ve done this for a while, you get a sense for when UIKit is probably a waste of time.

So, why is Core Graphics fast?

CoreGraphics isn’t really fast. If it’s being used all the time, you’re probably going slow. It’s a rich drawing API, which requires its work be done on the CPU, as opposed to a lot of UIKit work that is offloaded to the GPU. If you had to animate a ball moving across the screen, it would be a terrible idea to call setNeedsDisplay on a view 60 times per second. So, if you have sub-components of your view that need to be individually animated, each component should be a separate layer.

The other problem is that when you don’t do custom drawing with drawRect, UIKit can optimize stock views so drawRect is a no-op, or it can take shortcuts with compositing. When you override drawRect, UIKit has to take the slow path because it has no idea what you’re doing.

These two problems can be outweighed by benefits in the case of table view cells. After drawRect is called when a view first appears on screen, the contents are cached, and the scrolling is a simple translation performed by the GPU. Because you’re dealing with a single view, rather than a complex hierarchy, UIKit’s drawRect optimizations become less important. So the bottleneck becomes how much you can optimize your Core Graphics drawing.

Whenever you can, use UIKit. Do the simplest implementation that works. Profile. When there’s an incentive, optimize.