实际清理

Question

是否可以对此进行范围化并在模块或其他位置提供释放方法以防止内存泄漏。防爆。我需要关闭onDestroy()中的数据库连接，但如果这可以由模块本身处理，那将会很好。

考虑以下示例*代码。

* 阅读容易出错的代码，风险自负

<击>

模块

@dagger.Module
@lombok.NoArgsConstructor
public class PersistenceModule {

    @Provides
    @Singleton
    DatabaseProvider providesDatabaseHelper(Context context) {
        return new DatabaseProvider(context);
    }
}

活动

public class SomeActivity extends Activity{

    @javax.inject.Inject DatabaseProvider provider;


    //..onCreate omitted where injection happens.

    @Override
    protected void onDestroy() {
        //Close database and cleanup.
        provider.release();
        provider = null;
        super.onDestroy();
    }
}

<击>

Answer 1

您的示例似乎容易出错，因为您使用DatabaseProvider范围限定了@Singleton，但在活动中使用并清理它。

Module只是帮助创建对象 - 特别是如果没有可注入的构造函数或者需要进一步初始化 - 并且不知道进一步的生命周期事件。它将对象提供给Component，它只保存并创建注入类所需的对象图。最后，两者都只是普通的旧java对象，组件上的作用域只不过是语法糖，有助于编译时验证。

在任何情况下，您都应该在提供依赖项的同一范围内处理清理。因此，应该在同样持有应用程序组件的应用程序对象中清除@Singleton范围。如果清理活动中的单例作用域对象，则访问它的下一个活动将是访问处于关闭状态的对象。

如果每个活动都应该有自己的访问者并在使用后进行清理，那么您应该切换到一些基于活动的范围。其他范围只是您可以自己创建的注释。

实际清理

所有这些说，我不会包括＆＃34;清理＆＃34;我的模块中的逻辑，因为大多数人不希望在那里找到它。

<强> @Module
注释有助于对象图的类。

Dagger是一个依赖注入框架，提供依赖关系，以便更容易地使用接口和更松散的类耦合。它是为了减少对象创建的样板代码以及对实际对象所做的操作，不应该属于创建它们的相同代码库。

虽然仍然可以保留对模块的引用，或者让它们实现一些接口（仍然是pojos！）并调用它们来清理自己onDestroy它可能会导致更多的混乱而不仅仅是做其他人期望的清理工作。

匕首2：确定和处理所提供注射的释放/清理

模块

活动

1 个答案:

实际清理