I am working on an android project with a few other developers and a bug was raised where Instance states were not being retained on garbage collection:
The actual bug reported:
The app has one activity with a bunch of fragments. If "don't keep activities" is checked in developer options and the user clicks on any button that changes the visible fragments, and then navigates away from the app and then back, it relaunches the app to its original state instead of the last state.
Another Dev on the project raised the following concern:
"The saving of instances will cause the apps in memory size to bloat. Already, because of the amount of drawables, the apps memory size is too high.
Its ok, if the app restarts after a while of non usage by the user."
My understanding was that the savedInstance Bundle actually gets written to physical memory, is that not correct? Is the above quote a valid concern?
I am interpreting "written to physical memory" as meaning "written to a file on a filesystem" (a.k.a., "persisted").
The instance state
Bundle
is not persisted. Android 5.0+ gives you a different hook for aPersistableBundle
that is persisted and therefore survives a reboot.However, the instance state
Bundle
is passed across process boundaries to a core OS process. That data can then be used if your process is terminated, but the user returns to your app while your task is still around (e.g., via the recent-tasks list).The only piece of that quote that could reasonably be evaluated by people here on SO is:
Saving one byte in the
Bundle
will consume more memory than will saving zero bytes in theBundle
. Hence, mathematically, the quote is accurate. The key is to keep theBundle
small. They can't get too big anyway for other reasons (1MB limit for IPC calls). Small instance stateBundles
should not be a problem.