删除片段后内存未释放 [英] Memory not freeing after fragment is removed

问题描述

我有一个 Fragment，它有一个 RecyclerView.

I have a Fragment which has a RecyclerView.

在这个 RecyclerView 中，我可能偶尔会下载和显示图像(加载了 Glide 进入ImageView.

In this RecyclerView, I may occasionally download and display images (loaded with Glide into ImageView.

所以当我打开Fragment时，使用的内存有时可能会从30MB左右跳到100MB左右甚至更多.

So when I open the Fragment, used memory may sometimes jump from around 30MB to around 100MB or even more.

持有Fragment的Activity结束后，内存不会释放.和以前一样.

After the Activity that is holding the Fragment is finished, the memory does not free up. It stays the same as before.

我查看了 Glide 文档，显然我们不必担心释放 Bitmaps 在 RecyclerView 中.这是一个很大的问题，因为应用程序经常因为 OOM 而崩溃.

I checked Glide documentation and apparently we don't have to worry about freeing up Bitmaps in RecyclerView. This is a huge issue, because app often crashes due to OOM because of this.

当 Fragment 被删除时，我应该如何正确处理释放内存?

How should I correctly handle freeing up memory when Fragment is removed?

另一个观察

我注意到的另一件事是，如果我完成 Activity 然后再次启动相同的 Activity.内存会跳回一会然后又回升到 100MB，这让我相信在再次启动 Fragment 之前内存已被清除.

Another thing I noticed is that if I finish the Activity and then start the same Activity again. Memory will jump back down for a moment and then back up to 100MB, which leads me to believe that the memory is cleared before launching the Fragment again.

推荐答案

垃圾收集有时是 Android 中的一个痛苦问题.大多数开发人员没有考虑这个问题，只是在没有任何资源分配意识的情况下继续开发.

Garbage Collection is sometimes a painful issue in Android. Most developers fail to consider this issue and just keep developing without any sense of resource allocation.

这当然会导致内存泄漏、OOM 和不必要的资源绑定等内存问题.绝对没有自动释放内存的方法.在任何情况下，您都不能仅仅依赖垃圾收集器

This will of course cause memory problems such as leaks, OOM and unnecessary resource binding. There is absolutely no automatic way to free up memory. You can not, under any circumstances, rely solely on the Garbage Collector

每当您传递 Fragment 或 Activity 的 onDestroy() 方法时，您可以而且应该做的是删除应用程序中不再需要的任何构造.您可以执行以下操作:

Whenever you pass the Fragment's or Activity's onDestroy() method, what you can and should do is erase any construct that shall no longer be required in the application. You can do the following :

1. 避免匿名监听器实例.创建侦听器并在您不再需要它们时销毁它们.
2. 将所有侦听器(单击、长按等)设置为 null
3. 清除所有变量、数组.对包含在 Activity/Fragment 中的所有类和子类应用相同的过程
4. 每当您对给定的类执行任何前面的步骤时，将变量设置为 null(适用于所有变量)

我最终做的是创建一个类似的界面

What I ended up doing was creating an interface like

public interface clearMemory(){
    void clearMemory();
}

并在每个类上实现它，无论是 Activity、Fragment 还是普通类(包括适配器、自定义视图等).

and implementing it on every class, be it Activity, Fragment or a normal class (includes adapters, custom views, etc).

然后我会在类被销毁时调用该方法(因为应用程序正在被销毁或每当我觉得需要这样做.小心不要在正常运行时处理)

I would then call the method whenever the class was to be destroyed (because the app was being destroyed or whenever I felt need to do so. Careful not to dispose in normal runtime)

@Override
public void onDestroy(){
    clearMemory();
}

public void clearMemory(){
    normalButtonOnClickListener = null;
    normalButton.setOnClickListener(null);
    normalButton = null;
    myCustomClass.clearMemory(); // apply the interface to the class and clear it inside
    myCustomClass = null;
    simpleVariable = null;
    ...        
}

通过以系统的方式实现这一点，我的应用程序的内存管理变得更加容易和精简.然后就可以准确地知道/控制内存的处理方式和时间.

By implementing this in a systematic way, my applications' memory management has become easier and leaner. One can then then know/control exactly how and when the memory is disposed.

这篇关于删除片段后内存未释放的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！