这章是展示使用Dagger 2在Android端实现依赖注入的系列中的一部分。今天我会花点时间在自定义Scope（作用域）上面 - 它是很实用，但是对于刚接触依赖注入的人会有一点困难。

Scope - 它给我们带来了什么？

几乎所有的项目都会用到单例 - 比如API clients，database helpers，analytics managers等。因为我们不需要去关心实例化（由于依赖注入），我们不应该在我们的代码中考虑关于怎么得到这些对象。取而代之的是@Inject注解应该提供给我们适合的实例。

在Dagger 2中，Scope机制可以使得在scope存在时保持类的单例。在实践中，这意味着被限定范围为@ApplicationScope的实例与Applicaiton对象的生命周期一致。@ActivityScope保证引用与Activity的生命周期一致（举个例子我们可以在这个Activity中持有的所有fragment之间分享一个任何类的单例）。

简单来说 - scope给我们带来了“局部单例”，生命周期取决于scope自己。

但是需要弄清楚的是 - Dagger 2默认并不提供@ActivityScope或者/并且@ApplicationScope这些注解。这些只是最常用的自定义Scope。只有@Singletonscope是默认提供的（由Java自己提供）。

Scope - 实践案例

为了更好地去理解Dagger 2中的scope，我们直接进入实践案例。我们将要去实现比Application/Activity scope更加复杂一点的scope。为此我们将使用上一文章中的GithubClient例子。我们的app应需要三种scope：

• __@Sigleton__ - application scope
• __@UserScope__ - 用于与被选中的用户联系起来的类实例的scope（在真实的app中可以是当前登录的用户）。
• __@ActivityScope__ - 生命周期与Activity（在我们例子中的呈现者）一致的实例的scope

讲解的@UserScope是今天方案与以前文章之间的主要的不同之处。从用户体验的角度来说它没有带给我们任何东西，但是从架构的观点来说它帮助我们在不传入任何意图参数的情况下提供了User实例。使用方法参数获取用户数据的类（在我们的例子中是RepositoriesManager）中我们可以通过构造参数（它将通过依赖图表提供）的方式来获取User实例并在需要的时候被初始化，而不是在app启动的时候创建它。这意味着RepositoriesManager可以在我们从Github API获取到用户信息（在RepositoriesListActivity呈现之前）之后被创建。

这里有个我们app中scopes和components呈现的简单图表。

单例（Application scope）是最长的scope（在实践中是与application一样长）。UserScope作为Application scope的一个子集scope，它可以访问它的对象（我们可以从父scope中得到对象）。ActivityScope（生命周期与Activity一致）也是如此 - 它可以从UserScope和ApplicationScope中得到对象。

Scope生命周期的例子

这里有一个我们app中scope生命周期的案例：

单例的生命周期是从app启动后的所有的时期，当我们从Github API（在真实app中是用户登录之后）得到了User实例时UserScope被创建了，然后当我们回退到SplashActivity（在真实app中是用户退出之后）时被销毁。

实现

在Dagger 2中，Scope的实现归结于对Components的一个正确的设置。一般情况下我们有两种方式 - 使用Subcomponent注解或者使用Components依赖。它们两者最大的区别就是对象图表的共享。Subcomponents可以访问它们parent的所有对象图表，而Component依赖只能访问通过Component接口暴露的对象。

我选择第一种使用@Subcomponent注解，如果你之前使用过Dagger 1，它几乎与从ObjectGraph创建一个subgraphs（子图表）是一样的。此外，对于创建一个subgraphs的方法我们会使用类似的命名法则（但这不是强制性的）。

我们从AppComponent的实现开始：

@Singleton
@Component(
        modules = {
                AppModule.class,GithubApiModule.class
        }
)
public interface AppComponent {

    UserComponent plus(UserModule userModule);

    SplashActivityComponent plus(SplashActivityModule splashActivityModule);

}

它将会是其它subcomponents的根Components：UserComponent和Activities Components。正如你注意到的那样（尤其如果你在前面的文章中看过的AppComponent 实现）所有的返回依赖图表对象的公开方法全部消失了。因为我们有subcomponents了，我们不需要去公开去暴露依赖了 - 无论如何subgraphs都可以访问它们全部了。

作为替代，我们新增了两个方法：

• UserComponent plus(UserModule userModule);
• SplashActivityComponent plus(SplashActivityModule splashActivityModule);

这表示，我们可以从AppComponent创建两个子Components（subcomponents）：UserComponent和SplashActivityComponent。因为它们都是AppComponent的subcomponents，所以它们两者都可以访问AppModule和GithubApiModule创建的实例。

这些方法的命名法则是：返回类型是subcomponent类，方法名字随意，参数是这个subcomponent需要的modules。

如你所见，UserComponent需要另一个module（它通过plus()方法的参数传入）。这样，我们通过增加一个新的用于生成对象的module，继承AppComponent图表。UserComponent类看起来这样：

当然@UserScope注解是我们自己创建的：

我们可以从UserComponent创建另外两个subcomponents：RepositoriesListActivityComponent和RepositoryDetailsActivityComponent。

UserComponent appComponent = appComponent.plus(new UserModule(user))

class GithubClientApplication extends Application {

    private AppComponent appComponent;
    private UserComponent userComponent;

    //...

    public UserComponent createUserComponent(User user) {
        userComponent = appComponent.plus(new UserModule(user));
        return userComponent;
    }

    public void releaseUserComponent() {
        userComponent = null;
    }

    //...
}

• 上一篇：data pipeline 中充斥着惊人的浪费下一篇：UML中关联（Association）、聚合（