Wednesday 15 April 2015

android - savedInstanceState memory implications -



android - savedInstanceState memory implications -

i working on android project few other developers , bug raised instance states not beingness retained on garbage collection:

the actual bug reported:

the app has 1 activity bunch of fragments. if "don't maintain activities" checked in developer options , user clicks on button changes visible fragments, , navigates away app , back, relaunches app original state instead of lastly state.

another dev on project raised next concern:

"the saving of instances cause apps in memory size bloat. already, because of amount of drawables, apps memory size high.

its ok, if app restarts after while of non usage user."

my understanding savedinstance bundle gets written physical memory, not correct? above quote valid concern?

my understanding savedinstance bundle gets written physical memory, not correct?

i interpreting "written physical memory" meaning "written file on filesystem" (a.k.a., "persisted").

the instance state bundle not persisted. android 5.0+ gives different hook persistablebundle is persisted , hence survives reboot.

however, instance state bundle passed across process boundaries core os process. info can used if process terminated, user returns app while task still around (e.g., via recent-tasks list).

is above quote valid concern?

the piece of quote reasonably evaluated people here on is:

the saving of instances cause apps in memory size bloat

saving 1 byte in bundle consume more memory saving 0 bytes in bundle. hence, mathematically, quote accurate. key maintain bundle small. can't big anyway other reasons (1mb limit ipc calls). little instance state bundles should not problem.

android android-fragments android-lifecycle android-bundle

No comments:

Post a Comment