Android上的Dagger 2.存储和访问@Singleton组件的不同方法

Mar*_*ano 11 java android dagger-2

这是关于如何存储@Singleton作用域Dagger 2组件的第N个问题,其寿命应该等于应用程序的生命周期.

在使用Dagger 2的Android应用程序中,通常至少有一个组件是@Singleton作用域,并且应该持续所有应用程序的生命周期:由于这些要求,它通常被初始化并存储在自定义Application类中.

由于我们的应用程序的所有部分都必须可以访问此Component的实例,因此我看到过这样的代码:

1.将组件存储在应用程序类内的公共静态变量中.

public class App extends Application {

    public static AppComponent appComponent;

    @Override
    public void onCreate() {
        super.onCreate();

        appComponent = DaggerAppComponent.builder()
                .appModule(new AppModule(this)).build();
    }
}
Run Code Online (Sandbox Code Playgroud)

这样它可以在任何其他地方访问:

App.appComponent.inject(this);
Run Code Online (Sandbox Code Playgroud)

2.将组件存储在应用程序实例内的私有变量中,并为其创建静态访问器.

public class App extends Application {

    private static AppComponent appComponent;

    @Override
    public void onCreate() {
        super.onCreate();

        appComponent = DaggerAppComponent.builder()
                .appModule(new AppModule(this)).build();
    }

    public static AppComponent getAppComponent() {
        return appComponent;
    }
}
Run Code Online (Sandbox Code Playgroud)

这样它可以在任何其他地方访问:

App.getAppComponent().inject(this);
Run Code Online (Sandbox Code Playgroud)

3.将组件存储在应用程序实例内的私有变量中,并为其创建非静态访问器.

public class App extends Application {

    private AppComponent appComponent;

    @Override
    public void onCreate() {
        super.onCreate();

        appComponent = DaggerAppComponent.builder()
                .appModule(new AppModule(this)).build();
    }

    public AppComponent getAppComponent() {
        return appComponent;
    }
}
Run Code Online (Sandbox Code Playgroud)

这样,它只能从包含对Context的引用的类实例访问:

// From within an Activity.
((App) getApplication()).getAppComponent().inject(this);

// From within a Fragment.
((App) getActivity().getApplication()).getAppComponent().inject(this);

// From within any other class which holds a reference to a Context. 
((App) context.getApplicationContext()).getAppComponent().inject(this);
Run Code Online (Sandbox Code Playgroud)

最后一种方法使得将Context引用传递给任何愿意访问Component的类是非常必要的(即使该类不需要该Context用于任何其他目的).

IMHO必须"手动注入"一个Context实例只是为了访问注入器本身听起来有点反直觉.

另一方面,许多建议不要使用静态变量,但是:为什么?如果对象必须在应用程序的生命周期内保留在内存中(这意味着在JVM实例的整个生命周期内),如果它存储在静态变量中会出现什么问题?

其他人说静态的东西不能在测试中被嘲笑而且它是真的,虽然我不确定我完全得到这个,因为它是DI模式,可以轻松进行模拟/测试,而不是注入器本身,所以我们为什么要这样做嘲笑注射器本身?

这些替代方案的优缺点是什么?除了已经提到的那些之外,还有其他可能的替代方案吗?

小智 5

对于1和2,您正在使用静态引用。这是关于为什么要避免使用它们的一个很好的思路

为什么静态变量被认为是邪恶的?

因此,剩下的唯一选择是第三。那就是我在项目中使用的东西。关于是否应该将上下文作为参数传递,取决于项目的体系结构以及Dagger依赖项的设计方式。就我个人而言,我没有这个问题,因为我只注入了活动/片段。您能否举个例子,说明您需要传递上下文以注入依赖项吗?