開天辟地

今天我們來講講一個有一點點冷門的庫Dagger吧。我做一個不負責任的猜測：做客戶端的同學可能比較少聽到一些名詞，比如面向切面編程、控制反轉(zhuǎn)、依賴注入，相信玩過Spring的同學肯定知道這些一開始讓人頭大后來卻很好玩的玩意兒。

今天我們來介紹這款依賴注入器 —— Dagger2，源自Square的Dagger，由Google開發(fā)，基于apt生成靜態(tài)編譯時的依賴注入工具，比動態(tài)注入的方式更加高性能，但是需要更多的約定。

官網(wǎng)：https://google.github.io/dagger/

組成

Dagger2(以下稱為Dagger) 主要由兩個部分組成：Component和Module。分別作為注入器和注入源存在于整個依賴圖中，然后有了源和工具，那么只用在我們需要注入的地方加上@Inject注解即可，它是屬于JSR-330的一部分，我們這里就直接引入一個最簡單的Demo。

Module

@Module 
public class AppModule { 
    Context mApplicationContext; 
 
    public AppModule(Context context) { 
        this.mApplicationContext = context; 
    } 
 
    @Provides 
    public Context provideContext(){ 
        return mApplicationContext; 
    } 
 
    @Provides 
    public Service provideService(Context context) { 
        return new Service(context, null); 
    } 
} 

這是世界的起源。

• @Module注解表示這個類是個Module，是一個“源”。
• @Provides注解告訴Dagger我們想要構造對象并提供這些依賴。

Component

@Component(modules=AppModule.class) 
public interface AppComponent { 
    void inject(App app); 
 
    Context context(); 
    Service service(); 
} 

Component是一個接口，具體的實現(xiàn)由Dagger經(jīng)過apt工具為你生成(是不是有了apt就特別爽)，我們給AppComponent這枚“針”指定了藥劑——AppModule，告訴它注入的時候，從AppModule里面拿到我們要的變量實例，只要給Component聲明一個無返回值，帶被注入類型形參的方法，Dagger 就會為這個類生成一個MemberInjector對象，用來給被注入類注入對象。

被注入對象

public class App extends Application { 
 
    @Inject Service mService; 
     
    private AppComponent mAppComponent; 
 
    /** 
     * 應用程序初始化 
     */ 
    @Override 
    public void onCreate() { 
        super.onCreate(); 
        mAppComponent = DaggerAppComponent.builder() 
                .appModule(new AppModule(this)) 
                .build(); 
 
        mAppComponent.inject(this); 
 
    } 
     
    public AppComponent getAppComponent() { 
        return mAppComponent; 
    } 
} 

這里的DaggerAppComponent是Dagger生成的，它的實現(xiàn)類會在所有Component接口類之前增加一個Dagger前綴，我們只用傳入它所需要的依賴即可，Component顯然是依賴Module的，所以需要在這里傳入AppModule，現(xiàn)在，只要用Context的地方，我們都可以拿到這個AppComponent實例，只要有這個實例，我們可以在任意地方注入被管理的類。

作用域

我們說依賴注入的時候，作用域(Scope)是經(jīng)常會出現(xiàn)在我們眼里的詞匯?？刂谱兞可芷冢瑢嵸|(zhì)就是控制它存在的作用域，服務端典型的作用域如單例(Singleton)，Request，Session，等等，它們的變量分別存在于不同的生命周期。

我們默認存在的是Singleton，也就是@Singleton注解。由它標注的Provider生成的對象會被緩存起來，用SingleCheck或者DoubleCheck進行包裝。我們Provider指定的作用域需要和Component的作用域一致。

比如Component這樣定義：

@Singleton 
@Component(modules=AppModule.class) 
public interface AppComponent { 
    void inject(App app); 
 
    Service service(); 
} 

而Module就是這個樣子

@Module 
public class AppModule { 
    Context mApplicationContext; 
 
    public AppModule(Context context) { 
        this.mApplicationContext = context; 
    } 
 
    @Singleton 
    @Provides 
    public Context provideService(){ 
        return new Service(); 
    } 
 
} 

限定符

Dagger還支持使用限定符(Qualifier)來指定注入的對象，比如內(nèi)置的@Named限定符，我們在需要特定限定名字的變量的時候，可以在@Inject上，指定@Named限定符，獲取指定對象。

//Module 
@Providers 
@Named("cache") 
public Service provideService(); 
 
// Injection 
@Inject 
@Named("cache") 
Service mService; 

這樣就給這個mService注入了名字為"cache"的實例了。

一個簡單場景的應用

當我們談論依賴注入的時候，我們在談論什么?

其實我們是在討論 作用域。

這是什么意思呢，我相信每一個程序員去實現(xiàn)一個單例是一件非常簡單的事情，makeInstance和getInstance嘛。但是，你們想過維護“雙例”嗎?我之前碰到了一個場景如下：

1. 用戶(User) 需要一張tag表，會增刪查改，并和用戶相關聯(lián)。
2. 問題(Question) 也需要一張tag表，也會增刪查改，和問題關聯(lián)。
3. 這兩張表的實體模型一模一樣。

那么我們采取的方案有兩種，雙表，或者雙庫。雙表的話，對ORM很不友好，因為ORM是根據(jù)類來確定表的，我們?yōu)榱舜a簡潔優(yōu)雅，不可能創(chuàng)建兩個一模一樣的類，不然取名都變成一件困難的事。這里，一個優(yōu)勢是，我使用的ORM庫首先是維護一個單例，單例進行CRUD操作，且一個單例和一個數(shù)據(jù)庫相關。于是我使用Qualifer的特性，生成了兩個實例(也就是對應了兩個數(shù)據(jù)庫)，分別注入到不同的業(yè)務模型中去，他們就可以使用同一個類，而且對tag的修改完全沒有影響。這件事要是我們自己去做的話，可能要寫很多骯臟不堪的代碼，但是Dagger只用2個注解就把我的需求解決了。

總結(jié)

好了，本文簡單的闡述了Dagger入門使用，總結(jié)起來，我們只要約定好Componenet、Module，搭配Inject使用，即可實現(xiàn)一個靜態(tài)的依賴注入流程。下一次我們詳細介紹Dagger生成的代碼結(jié)構。