Memory usage higher in sim than real device?

Sorry if this has been covered before.

I'm on CIQ 3.0.5 (Windows), testing with a real 935.

I've got a complex data field which has 1592 or 1840 bytes free in the sim, under "idle conditions" (no FIT simulation, timer stopped). I don't know why the number is lower sometimes, unless it has to do with sending settings to the sim while the app is running.

On my real 935, with the same app config, the free memory is 2296. This is huge for me, and makes the difference between the app crashing or not for a certain edge case.

I obtained these numbers by printing System.getSystemStats().freeMemory on the screen.

While I tested my app over and over on the real device to make sure it doesn't crash, it really bothers me that it crashes in the sim. Is there something I'm missing or something I'm doing wrong? With a simple data field and SDK 2.4.7, I haven't seen this (crashing in sim yet running on real watch), although I've come close to the memory limits many times.

A couple of side questions which I think have been covered before:

When you send settings to an app while it is running on the sim...
- memory usage spikes and the app can crash.
Sometimes if the app survives the first settings change, the second one will make it crash. I'm not 100% sure, but it looks like the memory spike is permanent or at least lingering. I tried this a couple of times with my data field on a real device, and it doesn't crash (I didn't output the actual memory, because you can't send
settings with a sideloaded app afaik, and I haven't taken the time to do this exercise with a beta app or to do strategic System.println()'s).

- some properties can be read as null
This can cause crashes if you aren't checking for null (e.g. to save on code space, because you know those properties exist). Again I am curious if this would happen on the real device.

I want to implement onSettingsChanged() for a few cosmetic settings at least, but the combo of those questions makes me a little leery.

So I'm wondering if this is all expected behaviour or if I'm missing something.

Thanks!

Travis.ConnectIQ over 6 years ago

This sounds like an issue that was previously reported against the 3.0.3 SDK. We made a bug fix that forces a full reload of the settings that are sent to the app, and this increased memory/object usage a bit. This change may not appear to affect devices now, but it *should* affect them once they start integrating our virtual machine updates.

I recently made a small change that will reduce the amount of memory used when the app receives new settings, but it does not get things back to the pre 3.0.3 levels. This change should be released soon.

peterdedecker over 6 years ago

On apps with a lot of settings the increase is rather significant especially in the tight memory space in which a data field has to operate.

What is the reason that you need to reload the complete setting file where previously you did not have that need? Is it for covering adding new/removing settings?

FlowState over 6 years ago

Maybe we should be able to opt out of settings reload? Some data fields can't practically handle reloading settings anyway (other than cosmetics), because the settings involve things that have to be calculated from the beginning of the activity.