abstrakt：開天辟地今天我們來講講一個有一點點冷門的庫Dagger吧。我做一個不負責任的猜測：做客戶端的同學可能比較少聽到一些名詞，比如面向切面編程、控制反轉(zhuǎn)、依賴注入，相信玩過Spring的同學肯定知道這些一開始讓人頭大后來卻很好玩的玩意兒。今天我們來介紹這款依賴注入器 —— Dagger2，源自Square的Dagger，由Google開發(fā)，基于apt生成靜態(tài)編譯時的依賴注入工具，比動態(tài)注入的方式更加高性
開天辟地
今天我們來講講一個有一點點冷門的庫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嘛。但是，你們想過維護“雙例”嗎?我之前碰到了一個場景如下：
用戶(User) 需要一張tag表，會增刪查改，并和用戶相關聯(lián)。
問題(Question) 也需要一張tag表，也會增刪查改，和問題關聯(lián)。
這兩張表的實體模型一模一樣。
那么我們采取的方案有兩種，雙表，或者雙庫。雙表的話，對ORM很不友好，因為ORM是根據(jù)類來確定表的，我們?yōu)榱舜a簡潔優(yōu)雅，不可能創(chuàng)建兩個一模一樣的類，不然取名都變成一件困難的事。這里，一個優(yōu)勢是，我使用的ORM庫首先是維護一個單例，單例進行CRUD操作，且一個單例和一個數(shù)據(jù)庫相關。于是我使用Qualifer的特性，生成了兩個實例(也就是對應了兩個數(shù)據(jù)庫)，分別注入到不同的業(yè)務模型中去，他們就可以使用同一個類，而且對tag的修改完全沒有影響。這件事要是我們自己去做的話，可能要寫很多骯臟不堪的代碼，但是Dagger只用2個注解就把我的需求解決了。
總結
好了，本文簡單的闡述了Dagger入門使用，總結起來，我們只要約定好Componenet、Module，搭配Inject使用，即可實現(xiàn)一個靜態(tài)的依賴注入流程。下一次我們詳細介紹Dagger生成的代碼結構。