是否可以确定范围并在模块或其他地方提供释放方法以防止内存泄漏。前任。我需要关闭一个数据库连接,onDestroy()但如果这可以由模块本身处理,那就太好了。
考虑以下示例*代码。
*阅读容易出错的代码,风险自负
@dagger.Module
@lombok.NoArgsConstructor
public class PersistenceModule {
@Provides
@Singleton
DatabaseProvider providesDatabaseHelper(Context context) {
return new DatabaseProvider(context);
}
}
Run Code Online (Sandbox Code Playgroud)
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();
}
}
Run Code Online (Sandbox Code Playgroud)
您的示例似乎很容易出错,因为您正在使用范围DatabaseProvider来确定@Singleton范围,但在活动中使用并清理它。
AModule只是帮助创建对象\xe2\x80\x94,特别是如果没有可注入构造函数或者需要进一步初始化\xe2\x80\x94 并且不知道进一步的生命周期事件。它将其对象提供给Component,后者仅保存并创建注入类所需的对象图。最后,两者都只是普通的旧 java 对象,组件上的作用域只不过是帮助编译时验证的语法糖。
无论如何,您应该在提供依赖项的同一范围内处理清理工作。@Singleton因此,应该在也包含应用程序组件的应用程序对象中清理作用域。如果您清理活动中的单例作用域对象,则访问该对象的下一个活动将访问处于关闭状态的对象。
如果每个活动都应该有自己的访问器并在使用后清理它,那么您应该切换到一些基于活动的范围。附加范围只是您可以自己创建的注释。
\n综上所述,我不会在我的模块中包含“清理”逻辑,因为大多数人不会期望在那里找到它。
\n\n\n@模块
\n
\n注释一个有助于对象图的类。
Dagger 是一个依赖注入框架,提供依赖关系,以便更轻松地使用接口和松散地耦合类。它是为了减少对象创建的样板代码,并且一旦拥有实际对象,您对它们所做的操作就不应该属于创建它们的相同代码库。
\n虽然仍然可以保留对模块的引用,或者让它们实现一些接口(仍然是 pojo!)并调用它们来清理自己,但这onDestroy可能会导致比仅仅在其他人期望的地方进行清理更混乱。
| 归档时间: |
|
| 查看次数: |
2219 次 |
| 最近记录: |