Fragment Transaction .add vs .replace optimum perspective?

Question

When using a fragment transaction we can do them using add and replace methods. If we use add, the previous fragment is not destroyed and kept in memory. And if we use replace the previous fragment is destroyed and recreated again when we go back. From an optimum (memory, cpu, etc) perspective what is more effective/better?

Answer 1

I've created a simple app that is capable of replace or add a fragment, you can find it here.

Following the android documentation I've used their tool to test the performace, those are the results:

By adding the fragment the usage of the cpu peaked was 17%

By replacing the fragment the usage of the cpu peaked was 23,3%

Answer 2

If you are talking about memory usage, then replace is better than add, because in add() the fragments's (which are in a stack of fragments) views are in memory, and all the images and views are taking memory, which is not released. Suppose you have 5 fragments A, B, C, D, E. You have added them one by one A->B->C->D->E Now E is at the top and all fragments A, B, C, D have their views and resources loaded in the memory, Suppose these fragments have a lot of heavy images, then there are chances your app may face out of memory. But If you use replace for each of them, their views are released so their resources are released (which is good, as these are no more visible to the screen, so should not hold resources, images and memory).

For more information, Google has introduced Jetpack navigation https://developer.android.com/guide/navigation In this when fragments navigate from one to another, replace is performed.

The only thing required in case of replacing, is you need to handle onCreateView() properly so when the user comes back to destroyed fragment, Its views are populated again.

Answer 3

It depends on your scenario. Replace seems as better option generally because creating a new hierarchy doesn't cause a performance downfall and it releases its view hierarchy without destroying fragment instance if you save it to your back stack. However, there is some cases you should be aware of for example: you create a view like map view. It takes much time to create a view from scratch so you should keep that view in memory to prevent creating the view again and again user backs to this fragment. However if your memory starts to reach it bounds you should take care of it like destroying the fragment by using memory callbacks. Most of the cases, replacing fragment is better option. You can see what happens when you add your fragment to a container without replacing previous one by not setting a background to your fragments. As summary if your fragments take so much time to create its view hierarchy, you keep the view hierarch by transactions of show and hide not adding each fragment top of another. But if the fragment has a lightweight view hierarchy to create replace it.