当 Fragment 被替换并放入后堆栈(或删除)时，它是否留在内存中? [英] When a Fragment is replaced and put in the back stack (or removed) does it stay in memory?

问题描述

行为与活动的工作方式相似吗?例如对于活动，它的工作方式如下:

Activity A启动Activity B，当B出现在屏幕上时，系统可以移除A如果系统需要，则从内存中.按 BACK 后，A 将重新创建到内存中，就好像它从未离开过一样.

我一直在寻找关于 Fragments 内存明智发生的事情的清晰解释，但没有找到任何东西.它的工作方式相同吗?例如:

Activity C 在其布局中有 Fragment F.然后，在某些时候 F 被 Fragment G 替换，但 F 保留在它的后堆栈中.

F 会一直留在内存中直到 C 被杀死还是可以根据需要被系统删除?

我真正要问的是，如果我在单个 Activity 中有一堆复杂的 Fragment，我是否会面临内存不足的风险?

解决方案

看看这个:BackStackRecord.Op.fragment

这就是片段存储在返回堆栈中的方式.注意实时引用，WeakReference 和 SoftReference 都没有在那里使用.

现在这个:FragmentManagerImpl.mBackStack

那是管理器存储返回堆栈的地方.简单的 ArrayList，也没有 WR 或 SR.

最后这个:Activity.mFragments

这是对片段管理器的引用.

GC 只能收集没有活动引用的对象(无法从任何线程访问).这意味着，直到您的 Activity 被销毁(因此，FragmentManager 引用消失了)，GC 将无法收集返回堆栈中的任何 Fragment.

注意当Activity被销毁时保留状态(例如当您将设备转到横向模式时)，它不会保留实际的 堆栈中的 Fragment 对象，只有它们的状态 - Fragment.FragmentState 对象，即每次使用保留状态重新创建活动时，都会重新创建返回堆栈中的实际片段.>

希望这会有所帮助.

PS 所以，简而言之:是的，您可以通过将 Fragments 添加到后台堆栈 以及添加太多内存来耗尽内存许多视图可以查看层次结构.

UPD 考虑到您的示例，F 将保留在内存中，直到 C 被杀死.如果 C 被杀死然后以不同的配置复活 - F 也会被破坏并在不同的对象中转世.因此，F 的内存占用会一直持续到 C 失去状态或返回堆栈被清除.

Is the behavior similar to the way Activities work? For example with Activities it works like this:

Activity A starts Activity B, while B is on screen, the system is able to remove A from memory if it is needed by the system. Upon pressing BACK, A will be recreated into memory as if it never left in the first place.

I have looked for a clear explanation of what happens memory wise with Fragments and haven't found anything. Does it 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 kept in its back stack.

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

Really what I am asking is whether or not I run the risk of running out of memory if I have a back stack of complicated Fragments in a single Activity?

解决方案

Take a look at this: BackStackRecord.Op.fragment

That is how fragments are stored in the back stack. Note the live reference, neither WeakReference nor SoftReference are used there.

Now this: FragmentManagerImpl.mBackStack

That is where manager stores the back stack. Simple ArrayList, also, no WRs or SRs.

And finally this: Activity.mFragments

That is the reference to the fragment manager.

GC can only collect objects that have no live references (are not reachable from any thread). That means, until your Activity is destroyed (and so, FragmentManager reference is gone), GC will not be able to collect any of the Fragments in the back stack.

Note that when Activity is destroyed and retains state (like when you turn the device to landscape mode), it doesn't retain actual Fragment objects in the stack, only their states - Fragment.FragmentState objects, i.e. actual fragments in the back stack are re-created every time activity gets re-created with retained state.

Hope this helps.

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

UPD Considering your example, F will stay in memory until C is killed. If C is killed and then resurrected with different configuration - F will be destroyed and reincarnated in a different object as well. So, F's memory footprint is around until C loses state or back stack is cleared.

这篇关于当 Fragment 被替换并放入后堆栈(或删除)时，它是否留在内存中?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！