【问题标题】:How to avoid memory leak here?如何避免这里的内存泄漏?
【发布时间】:2020-04-08 04:07:18
【问题描述】:

我正在创建一个模块(一组执行功能的类),我需要上下文对象来执行一些操作,例如安全设置读取等。

我不喜欢为我的类创建多个对象,这在我的情况下是不需要的,即使我正在做这样的事情,

class MyModuleFactory {

    private static final String TAG = MyModuleFactory.class.getSimpleName();
    public Context mContext;
    private static HashMap<Context, MyModuleFactory> myInstance = new HashMap<>();

    private MyModuleFactory(Context context) {
        mContext = context;
    }

    public static synchronized MyModuleFactory getInstance(Context mContext) {
        if(mContext == null) {
            Log.i(TAG, "Context cannot be null");
            return null;
        }
        if(myInstance.get(mContext.getApplicationContext()) != null) {
            return myInstance.get(mContext.getApplicationContext());
        } else {
            MyModuleFactory myModuleFactory = new MyModuleFactory(mContext);
            myInstance.put(mContext.getApplicationContext(), myModuleFactory);
        }
    }
}

我担心的是,因为我在这里持有应用程序的上下文,我担心我会导致内存泄漏 - 原因是因为 Android 可以随时清除应用程序对象并重新创建它。因此,在应用程序的生命周期后面保留上下文并且不允许在此处清除上下文可能会导致内存泄漏。

在此处为我的模块强制单例并避免内存泄漏的更好方法是什么。

【问题讨论】:

    标签: android memory-leaks singleton android-context


    【解决方案1】:

    如果您持有对应用程序上下文的引用,则不会有任何内存泄漏。只要应用程序正在运行,应用程序上下文就存在。当应用程序被杀死时,它会被销毁。在这种情况下,即使你的单例也会被销毁,因此不会发生内存泄漏。

    只需确保您仅在单例中持有对 Application 上下文的引用,而不是 Activity 上下文。

    查看this post了解详细信息:

    如果您必须为您的应用程序创建一个单例对象,并且 对象需要上下文,始终传递应用程序上下文。

    如果在这里传递活动上下文,会导致内存泄漏 因为它将保留对活动的引用,而活动将不会 垃圾收集。

    【讨论】:

    • system_server 进程的上下文会存活多久?它会一直保持到重新启动吗?
    • 我之前没听说过system_server进程。看起来设备在设备启动时启动了该过程。因此,它根本与您的应用程序无关,只要设备打开,它就可能存在。不过我不确定。
    • 因为这是一个不同的问题,我想你可以将它作为一个新问题发布。
    • 谢谢鲍勃的回答。我怀疑发生内存泄漏的原因是在阅读了这篇文章(github.com/codepath/android_guides/wiki/…)之后,他们说android可以清除应用程序对象并重新创建它?即使在那种情况下,上下文是否仍然保持不变?如果是这样,这是怎么回事?
    • 如果应用程序对象正在被系统杀死,则意味着系统已经杀死了应用程序本身,可能是设备内存不足,系统不得不杀死后台运行的应用程序。同样在这种情况下,由于应用程序本身被杀死,您的单例也会从内存中删除。例如,当用户从最近的应用程序中再次打开应用程序时,系统将重新创建应用程序对象,将有一个新的上下文,它甚至会再次创建单例。系统会重启用户之前离开的Activity。所以不会有任何内存泄漏。
    猜你喜欢
    • 2016-08-14
    • 1970-01-01
    • 2020-05-13
    • 1970-01-01
    • 2015-08-27
    • 1970-01-01
    • 2018-04-08
    相关资源
    最近更新 更多