When a fragment is replaced and pushed onto the back stack (or removed), does it remain in memory?

Question

Is the behavior similar to how actions work? For example, using "Actions", it works as follows:

Activity A starts Activity B , and B starts on the screen, the system can delete A from memory if the system needs it. By pressing BACK, A will be recreated in memory, as if it never remained in the first place.

I was looking for a clear explanation of what is happening with the Fragments memory and found nothing. Does this work the same way? For example:

Activity C has Fragment F in its layout. Then, at some point, F is replaced by Fragment G , but F is saved on its stack.

Will F remain in memory until C is killed or can it be deleted by the system as needed?

Indeed, I ask if I have a risk of running out of memory if I have a back stack of complex fragments in one action?

Answer 1

Take a look at this: BackStackRecord.Op.fragment

Thus, fragments are stored in the background stack. Pay attention to the live link, WeakReference and SoftReference are not used SoftReference .

Now this is: FragmentManagerImpl.mBackStack

This is where the manager stores the back stack. A simple ArrayList is also not WR or SRs.

And finally, this: Activity.mFragments

This is a link to the fragment manager.

GC can only collect objects that do not have live links (inaccessible from any stream). This means that until your activity is destroyed (and therefore the FragmentManager link has disappeared), the GC will not be able to collect any of the fragments on the stack .

Please note that when activity is destroyed and saves state (for example, when you turn on the device in landscape mode), it does not save the actual Fragment objects on the stack, only their states are Fragment.FragmentState objects , that is, the actual fragments in the reverse stack are restored every time when an action occurs recreated with a saved state.

Hope this helps.

PS So, in short: Yes, you can run out of memory by adding Fragments to the back stack , and also adding too many views to view the hierarchy.

UPD Given your example, F will remain in memory until C is killed. If C is killed and then resurrected with a different configuration, F will be destroyed and reincarnated in another object. Thus, memory size F is maintained until C loses state or back stack.

Answer 2

I apologize for not being able to provide you with some kind of official source of information, but I was also curious to find out what would happen, and decided to check it out. And, according to my tests, yes, you run the risk of running out of memory.

I had to add an incredible amount of fragments (over a hundred) to the for loop for OutOfMemoryError , but this happened. And while checking my logs, I saw that the onCreate() and onCreateView() methods were called many times, but onSaveInstance() , onPause() and onDestroy were not called at all.

For reference, this is how I added snippets to the backstack:

 getSupportFragmentManager().beginTransaction().add(R.id.scene_fragment_container, mSceneFragment).addToBackStack("FOOBAR").commit(); 

And the added snippets were somewhat simple: ImageView , EditText , a pair of TextViews , SeekBar and ListView .

But if you do not store a huge amount of data in memory, this should not be a problem.

Later, I tried adding only 50 to the stack, killing the application and restarting it. And, as I hoped / guessed, all the fragments were restored (and the onSaveInstance() and onPause() methods were onSaveInstance() ), so my lifecycle implementation was not the problem that caused OutOfMemoryError .

Answer 3

From developer.android.com/guide/topics/fundamentals/fragments.html

A fragment must always be embedded in the action, and the fragment life cycle directly depends on the host life cycle. For example, when an action is paused, that is, all fragments in it, and when the action is destroyed, as well as all fragments. However, while the action is being performed (it is in the state of a renewed life cycle), you can independently control each fragment, for example, add or delete them. When you perform such a fragment transaction, you can also add it to the back stack, which is controlled by activity - each entry in the previous stack in the activity is a record of the fragment transaction that occurred. The back stack allows the user to cancel the fragment transaction (move backward) by pressing the BACK button.

Answer 4

Yes, you can run out of memory by creating too many fragments in one action. Fragments will be destroyed only if it contains an asset.