1239 Views 4 Replies Latest reply: Jun 30, 2008 3:17 PM by gkstuart
The academic answer is: It shouldn't matter how much memory you leak in your app after the app has been closed. I can't speak to how the device functions cause I can't test on one yet! But it's UNIX under the hood and that means each process is assigned it's own address space. Any memory allocated to a process is completely reclaimed when the process exits.
I'm not sure what changes Apple made to the VM kernel subsystem for the iPhone. Unix is already tried and tested in this arena -- so if it's the default Darwin VM I would be very surprised if this is a bug. But since this is embedded they may have added some "shortcuts" for performance and efficiency... hard to say. Since you have the device, are you able to do any system level diagnostics? does the device lose free memory the more your start/stop your app?
Also -- the device has 128MB of RAM. The 8 or 16GB is storage, which isn't used for RAM. The specs are hard to find, but I think I found the answer through Google on the amount of RAM in the iPhone and iPod Touch.
I'm not sure about the 3G. But the iPod Touch and first gen iPhone both have 128MB of RAM.
As for loading large datasets, you are correct to worry about memory limitations. You'll likely have to load only immediately useful data. The SQLite Books example has a neat implementation of hydrate/dehydrate methods to read/store data to the backing store as needed in order to keep as much memory free as possible. And you'll also likely want to only load a certain number of records at a time, especially if the user has the ability to add records. You can't control how many records they will add and if they breach the memory limit, then your "load all on application start" will turn into a "my application will not run at all" . I'm dealing with this myself in my design.