CODEWITHSUNDEEP
ioscocos2d-iphone
anon_dev1234
anon_dev1234

Reputation: 2153

iOS - Apple App Sandbox Doesn't Apply?

While doing some testing, I noticed that my Cocos2D app was struggling pretty badly. This was weird because the app itself is not doing intense calculations, doesn't have items scheduled every update, and is generally simple.

Aside from the fact that I have not optimized images using TexturePacker or the like, I could not think of any reason why this might be happening.

Upon further testing using the Memory profiler in Instruments, I discovered that regardless of what state the device was currently in (running an app, sitting at the home screen, etc.), Maps was using 20-30MB of device memory. The App Store and Springboard were likewise using the same amount. I understand why the Springboard needs to stay running in memory, but why on earth are Maps and the App Store running in my app's sandbox?

I thought that once an app was exited, it was no longer in main memory. It has been my belief this whole time that any app can run in its sandbox, and that's about it - and that you were not required to double-tap the home screen and 'force quit' the app from the quick menu. However, force quitting Maps and the App Store was the only way to free up the necessary memory. Have my assumptions been wrong all this time? Is this just an Apple thing that I am forced to work around for memory intense applications?

Upvotes: 0

Views: 238

Answers (1)

tc.
tc.

Reputation: 33592

The apps are not running "in your sandbox"; they're either running in their own sandbox, or they're the lucky Apple apps which are not sandboxed (I suspect built-in ones are and App Store-installed ones aren't).

The aim of iOS's "sandboxing" is to prevent apps from accessing data they're not supposed to (both reading and overwriting), not to prevent "exited" apps from using RAM. Since iOS 4 (on 3GS+), "exited" apps stay loaded in the background by default, and additionally Apple has allowed Safari to stay loaded in the background since at least iOS 3 (and I suspect since iOS 1 — reloading the page every time you switched into the browser is pretty terrible).

Non-critical background apps also cannot prevent your app from using "necessary memory" — the OS will kill background apps to free memory as necessary. Unlike a typical desktop, iOS does not use swap — memory "in use" by background apps should not inherently slow your app down.

There are a couple of things I can think of:

  • Backgrounded apps can still use CPU (Instruments will tell you if they are). This really shouldn't be a problem; I believe they run with lower priority than the foreground app.
  • The new Maps uses OpenGL. If iOS isn't handling background GL contexts efficiently, it might cause a problem. This would be a pretty serious bug.
  • Your app loads just enough textures to trigger a memory warning and handles the memory warning by throwing away all textures (add a NSLog() to -applicationDidReceiveMemoryWarning: to find out). If your app is in the foreground, don't throw away textures that will be needed the next frame. This might be a Cocos2D bug.

If it's not memory warnings, I'd try profiling the app to figure out which bits are slow.

p.s. There are also different "levels" of memory warning, but I'm not sure if you can access this (maybe it's in the userInfo dict of UIApplicationDidReceiveMemoryWarningNotification). In this case, it shouldn't matter — it's simply counter-productive to free memory if you'll it use again in the next second.

Upvotes: 4

Related Questions