我正在尝试了解 Dagger 2 中的范围，特别是范围图的生命周期。如何创建一个在您离开范围时将被清理的组件。
对于 Android 应用程序，使用 Dagger 1.x，您通常在应用程序级别拥有一个根作用域，您可以扩展该根作用域以在活动级别创建子作用域。
public class MyActivity {
private ObjectGraph mGraph;
public void onCreate() {
mGraph = ((MyApp) getApplicationContext())
.getObjectGraph()
.plus(new ActivityModule())
.inject(this);
}
public void onDestroy() {
mGraph = null;
}
}
只要您保留对子作用域的引用，子作用域就存在，在本例中就是 Activity 的生命周期。在 onDestroy 中删除引用可确保作用域图可以自由地被垃圾收集。
EDIT
杰西·威尔逊最近发布了认罪 https://publicobject.com/2014/11/15/dagger-2-has-components/
Dagger 1.0 严重搞砸了它的作用域名称... @Singleton 注释同时用于根图和自定义图，因此弄清楚事物的实际作用域是什么是很棘手的。
我读过/听到的所有其他内容都表明 Dagger 2 改进了瞄准镜的工作方式，但我很难理解其中的区别。根据@Kirill Boyarshinov 下面的评论，组件或依赖项的生命周期仍然像往常一样由具体引用确定。那么 Dagger 1.x 和 2.0 范围之间的区别纯粹是语义清晰度问题吗？
我的理解
匕首1.x
依赖关系是@Singleton或不。对于根图和子图中的依赖关系同样如此，导致依赖关系绑定到哪个图的模糊性（请参阅在 Dagger 中，子图中的单例是否会被缓存，或者在构造新的活动子图时它们是否总是会重新创建？ https://stackoverflow.com/questions/25953525/in-dagger-are-singletons-within-the-sub-graph-cached-or-will-they-always-be-recr)
匕首2.0
自定义作用域允许您创建语义清晰的作用域，但在功能上等同于应用@Singleton在 Dagger 1.x 中。
// Application level
@Singleton
@Component( modules = MyAppModule.class )
public interface MyAppComponent {
void inject(Application app);
}
@Module
public class MyAppModule {
@Singleton @Named("SingletonScope") @Provides
StringBuilder provideStringBuilderSingletonScope() {
return new StringBuilder("App");
}
}
// Our custom scope
@Scope public @interface PerActivity {}
// Activity level
@PerActivty
@Component(
dependencies = MyAppComponent.class,
modules = MyActivityModule.class
)
public interface MyActivityComponent {
void inject(Activity activity);
}
@Module
public class MyActivityModule {
@PerActivity @Named("ActivityScope") @Provides
StringBuilder provideStringBuilderActivityScope() {
return new StringBuilder("Activity");
}
@Name("Unscoped") @Provides
StringBuilder provideStringBuilderUnscoped() {
return new StringBuilder("Unscoped");
}
}
// Finally, a sample Activity which gets injected
public class MyActivity {
private MyActivityComponent component;
@Inject @Named("AppScope")
StringBuilder appScope
@Inject @Named("ActivityScope")
StringBuilder activityScope1
@Inject @Named("ActivityScope")
StringBuilder activityScope2
@Inject @Named("Unscoped")
StringBuilder unscoped1
@Inject @Named("Unscoped")
StringBuilder unscoped2
public void onCreate() {
component = Dagger_MyActivityComponent.builder()
.myApplicationComponent(App.getComponent())
.build()
.inject(this);
appScope.append(" > Activity")
appScope.build() // output matches "App (> Activity)+"
activityScope1.append("123")
activityScope1.build() // output: "Activity123"
activityScope2.append("456")
activityScope1.build() // output: "Activity123456"
unscoped1.append("123")
unscoped1.build() // output: "Unscoped123"
unscoped2.append("456")
unscoped2.build() // output: "Unscoped456"
}
public void onDestroy() {
component = null;
}
}
要点是使用@PerActivity传达你的意图关于该组件的生命周期，但最终您可以随时随地使用该组件。 Dagger 的唯一承诺是，对于给定的组件，范围注释方法将返回单个实例。我还假设 Dagger 2 使用组件上的范围注释来验证模块仅提供同一范围内或非范围内的依赖项。
总之
依赖关系仍然是单例或非单例，但是@Singleton现在适用于应用程序级单例实例，自定义范围是用较短的生命周期注释单例依赖项的首选方法。
开发人员负责通过删除不再需要的引用来管理组件/依赖项的生命周期，并负责确保组件仅在其预期范围内创建一次，但自定义范围注释可以更轻松地识别该范围。
价值 64,000 美元的问题*
我对 Dagger 2 范围和生命周期的理解正确吗？
* 实际上并不是一个价值 64'000 美元的问题。
