opening settings editor consumes app memory

FIRST
What happens when I change settings on device?
- go to IQ Connect
- run settings
- save
- something is transferred to device and saved somewhere
- system calls onSettingsChanged()
- now app can read new settings
So, where is my "work" to make peak - nowhere. How to manage memory if I don't have any control on huge object. System inject data and kills app.
SECOND
Settings - dictionary and it is in memory and consumes it from the app start (and for this reason you have less memory than totalMemory, so if you have 94kb totalMemory from the start is 92 because 2kB takes settings). There is no need to keep 2 dictionary settings in one time (another thing is that the data accessible by services - getProperty - should be in the service/system memory not application, the application can save data in storage and this is its data. All the luck that the data from the storage is not in memory). Apps settings are members, globals etc. Nobody read settings in loop but only after onSettingsChanged and now not in lowpower. So it's easy to chenge settings without any peak even in app memory.

But it means - everybody using setting have to remember to make free memory = 2xSizeSettings, so typically 4kB~5%... And of course - code ~40kB  and heap and data...

FIRST
What happens when I change settings on device?
- go to IQ Connect
- run settings
- save
- something is transferred to device and saved somewhere
- system calls onSettingsChanged()
- now app can read new settings
So, where is my "work" to make peak - nowhere. How to manage memory if I don't have any control on huge object. System inject data and kills app.
SECOND
Settings - dictionary and it is in memory and consumes it from the app start (and for this reason you have less memory than totalMemory, so if you have 94kb totalMemory from the start is 92 because 2kB takes settings). There is no need to keep 2 dictionary settings in one time (another thing is that the data accessible by services - getProperty - should be in the service/system memory not application, the application can save data in storage and this is its data. All the luck that the data from the storage is not in memory). Apps settings are members, globals etc. Nobody read settings in loop but only after onSettingsChanged and now not in lowpower. So it's easy to chenge settings without any peak even in app memory.

But it means - everybody using setting have to remember to make free memory = 2xSizeSettings, so typically 4kB~5%... And of course - code ~40kB  and heap and data...

I'm not new to settings but again surprised how it can be done this way... As I mentioned there is time to merge it outside app and call onSettingsChanged after this. If user change settings from app, ok it can be peak but not when system does.

> A few booleans is cheaper than a number of strings for example

It depends, if somebody nam key "very_long_property_key_id.................................." event bool may weigh in property and in code:)

But I understand, it's by design.

Yes.  You must be new to app settings.  When new settings are sent to a device, both the old and new settings are in memory at the same time while things are merged, and that's why there is a peak.

One thing that determines that is the number and type of settings involved.  A few booleans is cheaper than a number of strings for example