In iPhone in Action we talk about some about using the iPhone Simulator as a testing & debugging facility for your iPhone programs. It's certainly an easy and convenient way to work on your programs. You hit command-r and with no additional work on your part, your program compiles, the Simulator starts up, and everything runs.
However, in iPhone in Action, we also talk a bit about the places where the iPhone Simulator comes up short. It includes: using the accelerometers, using the location manager (though you can do simple tests as the Simulator reports back Apple's Silicon Valley headquarters), and downloading streaming audio.
In the last two months I've been working on a card game, which I expect to write about more here when we're ready to release. It's shown me another pretty grave short-coming in the Simulator: performance. The issue? It's too good.
I mean, we all know that the iPhone is a mobile platform, and that by nature it'll ultimately be limited in its CPU capabilities. But, it's easy to forget that with all of the sexy animations and graphics that Apple pushes back and forth around the screen. Indeed, if you're just making simple use of Apple's more front-facing frameworks, you may not hit performance problems at all.
The problem arises when you start using more in-depth frameworks like Core Data and Core Graphics. You may end up with programs which work great on the Simulator but which seriously bog down when you put it out to a real iPhone or iPod Touch device.
Here were the top two performance problems that I hit when working on my card game:
- Rounded Corners. My cards are laid out as CALayers. When I used the new 3.0 property, cornerRadius, to round the corners of my cards, I discovered that a real iPhone got dragged to a blinking, laggy halt. I thought I was just going to need to square my corners as long as I used CALayers, but eventually discovered that if I rounded the corners myself, using a clipping area on the CALayer's context, everything worked pretty good.
- Too Much Core Data Writing. At one point, I accidentally set my program to rewrite the Core Data ordering property for my cards any time a deck was touched, rather than only when they were actually reordered. Until I resolved the inefficiency, my game felt like it was moving through molasses.
The important fact that I intend to convey here is: these problems did not show up in the Simulator, only on an actual device. This was particularly frustrating for the second problem, which I discovered after a half-day or so of programming lots of different changes.
So the moral? If you're using simple frameworks, don't worry about it, But, if you're doing more complex work, every couple of compiles, send one over to an actual hardware device. The first time you hit a performance problem that didn't show up in the Simulator, you'll be happy you did.
Next Up: I'll be back after the Thanksgiving holiday, probably talking about NSSets: how they work, why you'd want to use them, and how they integrate with Core Data.
Comments