Dagger-匕首，鼎鼎大名的Square公司旗下又一把利刃（沒錯！還有一把黃油刀，喚作ButterKnife）；故此給本篇取名神兵利器Dagger2。
Dagger2起源於Dagger，是一款基於Java註解來實現的完全在編譯階段完成依賴注入的開源庫，主要用於模組間解耦、提高程式碼的健壯性和可維護性。Dagger2在編譯階段通過apt利用Java註解自動生成Java程式碼，然後結合手寫的程式碼來自動幫我們完成依賴注入的工作。
起初Square公司受到Guice的啟發而開發了Dagger，但是Dagger這種半靜態半執行時的框架還是有些效能問題（雖說依賴注入是完全靜態的，但是其有向無環圖(Directed Acyclic Graph)還是基於反射來生成的，這無論在大型的服務端應用還是在Android應用上都不是最優方案）。因此Google工程師Fork了Dagger專案，對它進行了改造。於是變演變出了今天我們要討論的Dagger2，所以說Dagger2其實就是高配版的Dagger。
依賴注入（Dependency Injection）
那麼什麼是依賴注入呢？在解釋這個概念前我們先看一小段程式碼：
public class Car{
private Engine engine;
public Car(){
engine = new Engine();
}
}複製程式碼這段Java程式碼中Car類持有了對Engine例項的引用，我們稱之為Car類對Engine類有一個依賴。而依賴注入則是指通過注入的方式實現類與類之間的依賴，下面是常見的三種依賴注入的方式：
1、構造注入：通過建構函式傳參給依賴的成員變數賦值，從而實現注入。
public class Car{
private Engine engine;
public Car(Engine engine){
this.engine = engine;
}
}複製程式碼2、介面注入：實現介面方法，同樣以傳參的方式實現注入。
public interface Injection<T>{
void inject(T t);
}
public class Car implements Injection<Engine>{
private Engine engine;
public Car(){}
public void inject(Engine engine){
this.engine = engine;
}
}複製程式碼3、註解注入：使用Java註解在編譯階段生成程式碼實現注入或者是在執行階段通過反射實現注入。
public class Car{
@Inject
Engine engine;
public Car(){}
}複製程式碼前兩種注入方式需要我們編寫大量的模板程式碼，而機智的Dagger2則是通過Java註解在編譯期來實現依賴注入的。
為什麼需要依賴注入
我們之所是要依賴注入，最重要的就是為了解耦，達到高內聚低耦合的目的，保證程式碼的健壯性、靈活性和可維護性。
下面我們看看同一個業務的兩種實現方案：
1、方案A
public class Car{
private Engine engine;
private List<Wheel> wheels;
public Car(){
engine = new Engine();
wheels = new ArrayList<>();
for(int i = 0; i < 4; i++){
wheels.add(new Wheel());
}
}
public void start{
System.out.println("啟動汽車");
}
}
public class CarTest{
public static void main(String[] args){
Car car = new Car();
car.start();
}
}複製程式碼2、方案B
public class Car{
private Engine engine;
private List<Wheel> wheels;
public Car(Engine engine, List<Wheel> wheels){
this.engine = engine;
this.wheels = wheels;
}
public void start{
System.out.println("啟動汽車");
}
}
public class CarTest{
public static void main(String[] args){
Engine engine = new Engine();
List<Wheel> wheels = new ArrayList<>();
for(int i = 0; i < 4; i++){
wheels.add(new Wheel());
}
Car car = new Car(engine, wheels);
car.start();
}
}複製程式碼方案A：由於沒有依賴注入，因此需要我們自己是在Car的建構函式中建立Engine和Wheel物件。
方案B：我們手動以建構函式的方式注入依賴，將engine和wheels作為引數傳入而不是在Car的建構函式中去顯示的建立。
方案A明顯喪失了靈活性，一切依賴都是在Car類的內部建立，Car與Engine和Wheel嚴重耦合。一旦Engine或者Wheel的建立方式發生了改變，我們就必須要去修改Car類的建構函式（比如說現在建立Wheel例項的建構函式改變了，需要傳入Rubber（橡膠）了）；另外我們也沒辦法替換動態的替換依賴例項（比如我們想把Car的Wheel（輪胎）從鄧祿普（輪胎品牌）換成米其林（輪胎品牌）的）。這類問題在大型的商業專案中則更加嚴重，往往A依賴B、B依賴C、C依賴D、D依賴E；一旦稍有改動便牽一髮而動全身，想想都可怕！而依賴注入則很好的幫我們解決了這一問題。
為什麼是Dagger2
無論是建構函式注入還是介面注入，都避免不了要編寫大量的模板程式碼。機智的猿猿們當然不開心做這些重複性的工作，於是各種依賴注入框架應用而生。但是這麼多的依賴注入框架為什麼我們卻偏愛Dagger2呢？我們先從Spring中的控制反轉（IOC）說起。
談起依賴注入，做過J2EE開發的同學一定會想起Spring IOC，那通過迷之XML來配置依賴的方式真的很讓人討厭；而且XML與Java程式碼分離也導致程式碼鏈難以追蹤。之後更加先進的Guice（Android端也有個RoboGuice）出現了，我們不再需要通過XML來配置依賴，但其執行時實現注入的方式讓我們在追蹤和定位錯誤的時候卻又萬分痛苦。開篇提到過Dagger就是受Guice的啟發而開發出來的；Dagger繼承了前輩的思想，在效能又碾壓了它的前輩Guice，可謂是長江後浪推前浪，前浪死在沙灘上。
又如開篇我在簡介中說到的，Dagger是一種半靜態半執行時的DI框架，雖說依賴注入是完全靜態的，但是生成有向無環圖(DAG)還是基於反射來實現，這無論在大型的服務端應用還是在Android應用上都不是最優方案。升級版的Dagger2解決了這一問題，從半靜態變為完全靜態，從Map式的API變成申明式API（@Module），生成的程式碼更優雅高效；而且一旦出錯我們在編譯期間就能發現。所以Dagger2對開發者的更加友好了，當然Dagger2也因此喪失了一些靈活性，但總體來說利還是遠遠大於弊的。
前面提到這種A B C D E連續依賴的問題，一旦E的建立方式發生了改變就會引發連鎖反應，可能會導致A B C D都需要做針對性的修改；但是騷年，你以為為這僅僅是工作量的問題嗎？更可怕的是我們建立A時需要按順序先建立E D C B四個物件，而且必須保證順序上是正確的。Dagger2就很好的解決了這一問題（不只是Dagger2，在其他DI框架中開發者同樣不需要關注這些問題）。
Dagger2註解
開篇我們就提到Dagger2是基於Java註解來實現依賴注入的，那麼在正式使用之前我們需要先了解下Dagger2中的註解。Dagger2使用過程中我們通常接觸到的註解主要包括：@Inject, @Module, @Provides, @Component, @Qulifier, @Scope, @Singleten。
@Inject：@Inject有兩個作用，一是用來標記需要依賴的變數，以此告訴Dagger2為它提供依賴；二是用來標記建構函式，Dagger2通過@Inject註解可以在需要這個類例項的時候來找到這個建構函式並把相關例項構造出來，以此來為被@Inject標記了的變數提供依賴；
@Module：@Module用於標註提供依賴的類。你可能會有點困惑，上面不是提到用@Inject標記建構函式就可以提供依賴了麼，為什麼還需要@Module？很多時候我們需要提供依賴的建構函式是第三方庫的，我們沒法給它加上@Inject註解，又比如說提供以來的建構函式是帶引數的，如果我們之所簡單的使用@Inject標記它，那麼他的引數又怎麼來呢？@Module正是幫我們解決這些問題的。
@Provides：@Provides用於標註Module所標註的類中的方法，該方法在需要提供依賴時被呼叫，從而把預先提供好的物件當做依賴給標註了@Inject的變數賦值；
@Component：@Component用於標註介面，是依賴需求方和依賴提供方之間的橋樑。被Component標註的介面在編譯時會生成該介面的實現類（如果@Component標註的介面為CarComponent，則編譯期生成的實現類為DaggerCarComponent）,我們通過呼叫這個實現類的方法完成注入；
@Qulifier：@Qulifier用於自定義註解，也就是說@Qulifier就如同Java提供的幾種基本元註解一樣用來標記註解類。我們在使用@Module來標註提供依賴的方法時，方法名我們是可以隨便定義的（雖然我們定義方法名一般以provide開頭，但這並不是強制的，只是為了增加可讀性而已）。那麼Dagger2怎麼知道這個方法是為誰提供依賴呢？答案就是返回值的型別，Dagger2根據返回值的型別來決定為哪個被@Inject標記了的變數賦值。但是問題來了，一旦有多個一樣的返回型別Dagger2就懵逼了。@Qulifier的存在正式為了解決這個問題，我們使用@Qulifier來定義自己的註解，然後通過自定義的註解去標註提供依賴的方法和依賴需求方（也就是被@Inject標註的變數），這樣Dagger2就知道為誰提供依賴了。----一個更為精簡的定義：當型別不足以鑑別一個依賴的時候，我們就可以使用這個註解標示；
@Scope：@Scope同樣用於自定義註解，我能可以通過@Scope自定義的註解來限定註解作用域，實現區域性的單例；
@Singleton：@Singleton其實就是一個通過@Scope定義的註解，我們一般通過它來實現全域性單例。但實際上它並不能提前全域性單例，是否能提供全域性單例還要取決於對應的Component是否為一個全域性物件。
我們提到@Inject和@Module都可以提供依賴，那如果我們即在建構函式上通過標記@Inject提供依賴，有通過@Module提供依賴Dagger2會如何選擇呢？具體規則如下：
- 步驟1：首先查詢@Module標註的類中是否存在提供依賴的方法。
- 步驟2：若存在提供依賴的方法，檢視該方法是否存在引數。
- a：若存在引數，則按從步驟1開始依次初始化每個引數；
- b：若不存在，則直接初始化該類例項，完成一次依賴注入。
- 步驟3：若不存在提供依賴的方法，則查詢@Inject標註的建構函式，看建構函式是否存在引數。
- a：若存在引數，則從步驟1開始依次初始化每一個引數
- b：若不存在，則直接初始化該類例項，完成一次依賴注入。
Dagger2使用入門
前面長篇大論的基本都在介紹概念，下面我們看看Dagger2的基本應用。關於Dagger2的依賴配置就不在這裡佔用篇幅去描述了，大家可以到它的github主頁下去檢視官方教程github.com/google/dagg…。接下來我們還是拿前面的Car和Engine來舉例。
1、案例A
Car類是需求依賴方，依賴了Engine類；因此我們需要在類變數Engine上新增@Inject來告訴Dagger2來為自己提供依賴。
public class Car {
@Inject
Engine engine;
public Car() {
DaggerCarComponent.builder().build().inject(this);
}
public Engine getEngine() {
return this.engine;
}
}複製程式碼Engine類是依賴提供方，因此我們需要在它的建構函式上新增@Inject
public class Engine {
@Inject
Engine(){}
public void run(){
System.out.println("引擎轉起來了~~~");
}
}複製程式碼接下來我們需要建立一個用@Component標註的介面CarComponent，這個CarComponent其實就是一個注入器，這裡用來將Engine注入到Car中。
@Component
public interface CarComponent {
void inject(Car car);
}複製程式碼完成這些之後我們需要Build下專案，讓Dagger2幫我們生成相關的Java類。接著我們就可以在Car的建構函式中呼叫Dagger2生成的DaggerCarComponent來實現注入（這其實在前面Car類的程式碼中已經有了體現）
public Car() {
DaggerCarComponent.builder().build().inject(this);
}複製程式碼2、案例B
如果建立Engine的建構函式是帶引數的呢？比如說製造一臺引擎是需要齒輪(Gear)的。或者Eggine類是我們無法修改的呢？這時候就需要@Module和@Provide上場了。
同樣我們需要在Car類的成員變數Engine上加上@Inject表示自己需要Dagger2為自己提供依賴；Engine類的建構函式上的@Inject也需要去掉，應為現在不需要通過建構函式上的@Inject來提供依賴了。
public class Car {
@Inject
Engine engine;
public Car() {
DaggerCarComponent.builder().markCarModule(new MarkCarModule())
.build().inject(this);
}
public Engine getEngine() {
return this.engine;
}
}複製程式碼接著我們需要一個Module類來生成依賴物件。前面介紹的@Module就是用來標準這個類的，而@Provide則是用來標註具體提供依賴物件的方法（這裡有個不成文的規定，被@Provide標註的方法命名我們一般以provide開頭，這並不是強制的但有益於提升程式碼的可讀性）。
@Module
public class MarkCarModule {
public MarkCarModule(){ }
@Provides Engine provideEngine(){
return new Engine("gear");
}
}複製程式碼接下來我們還需要對CarComponent進行一點點修改，之前的@Component註解是不帶引數的，現在我們需要加上modules = {MarkCarModule.class}，用來告訴Dagger2提供依賴的是MarkCarModule這個類。
@Component(modules = {MarkCarModule.class})
public interface CarComponent {
void inject(Car car);
}複製程式碼Car類的建構函式我們也需要修改，相比之前多了個markCarModule(new MarkCarModule())方法，這就相當於告訴了注入器DaggerCarComponent把MarkCarModule提供的依賴注入到了Car類中。
public Car() {
DaggerCarComponent.builder()
.markCarModule(new MarkCarModule())
.build().inject(this);
}複製程式碼這樣一個最最基本的依賴注入就完成了，接下來我們測試下我們的程式碼。
public static void main(String[] args){
Car car = new Car();
car.getEngine().run();
}複製程式碼輸出
引擎轉起來了~~~複製程式碼3、案例C
那麼如果一臺汽車有兩個引擎（也就是說Car類中有兩個Engine變數）怎麼辦呢？沒關係，我們還有@Qulifier！首先我們需要使用Qulifier定義兩個註解：
@Qualifier
@Retention(RetentionPolicy.RUNTIME)
public @interface QualifierA { }複製程式碼@Qualifier
@Retention(RetentionPolicy.RUNTIME)
public @interface QualifierB { }複製程式碼同時我們需要對依賴提供方做出修改
@Module
public class MarkCarModule {
public MarkCarModule(){ }
@QualifierA
@Provides
Engine provideEngineA(){
return new Engine("gearA");
}
@QualifierB
@Provides
Engine provideEngineB(){
return new Engine("gearB");
}
}複製程式碼接下來依賴需求方Car類同樣需要修改
public class Car {
@QualifierA @Inject Engine engineA;
@QualifierB @Inject Engine engineB;
public Car() {
DaggerCarComponent.builder().markCarModule(new MarkCarModule())
.build().inject(this);
}
public Engine getEngineA() {
return this.engineA;
}
public Engine getEngineB() {
return this.engineB;
}
}複製程式碼最後我們再對Engine類做些調整方便測試
public class Engine {
private String gear;
public Engine(String gear){
this.gear = gear;
}
public void printGearName(){
System.out.println("GearName:" + gear);
}
}複製程式碼測試程式碼
public static void main(String[] args) {
Car car = new Car();
car.getEngineA().printGearName();
car.getEngineB().printGearName();
}複製程式碼執行結果：
GearName:gearA
GearName:gearB複製程式碼4、案例D
接下來我們看看@Scope是如何限定作用域，實現區域性單例的。
首先我們需要通過@Scope定義一個CarScope註解：
@Scope
@Retention(RetentionPolicy.RUNTIME)
public @interface CarScope {
}複製程式碼接著我們需要用這個@CarScope去標記依賴提供方MarkCarModule。
@Module
public class MarkCarModule {
public MarkCarModule() {
}
@Provides
@CarScope
Engine provideEngine() {
return new Engine("gear");
}
}複製程式碼同時還需要使用@Scope去標註注入器Compoent
@CarScope
@Component(modules = {MarkCarModule.class})
public interface CarComponent {
void inject(Car car);
}複製程式碼為了便於測試我們對Car和Engine類做了一些改造：
public class Car {
@Inject Engine engineA;
@Inject Engine engineB;
public Car() {
DaggerCarComponent.builder()
.markCarModule(new MarkCarModule())
.build().inject(this);
}
}複製程式碼public class Engine {
private String gear;
public Engine(String gear){
System.out.println("Create Engine");
this.gear = gear;
}
}複製程式碼如果我們不適用@Scope,上面的程式碼會例項化兩次Engine類，因此會有兩次\"Create Engine\"輸出。現在我們在有@Scope的情況測試下勞動成果：
public static void main(String[] args) {
Car car = new Car();
System.out.println(car.engineA.hashCode());
System.out.println(car.engineB.hashCode());
}複製程式碼輸出
Create Engine複製程式碼bingo！我們確實通過@Scope實現了區域性的單例。
Dagger2原理分析
前面囉裡囉嗦的介紹了Dagger2的基本使用，接下來我們再分析分析實現原理。這裡不會分析Dagger2根據註解生成各種程式碼的原理，關於Java註解以後有機會再寫一篇文章來介紹。後面主要分析的是Dagger2生成的各種類如何幫我們實現依賴注入，為了便於理解我這裡選了前面相對簡單的案例B來做分析。
Dagger2編譯期生成的程式碼位於build/generated/source/apt/debug/your package name/下面:
首先我們看看Dagger2依據依賴提供方MarkCarModule生成的對應工廠類MarkCarModule_ProvideEngineFactory。為了方便大家理解對比，後面我一律會把自己寫的類和Dagger2生成的類一併放出來。
/**
* 我們自己的類
*/
@Module
public class MarkCarModule {
public MarkCarModule(){ }
@Provides Engine provideEngine(){
return new Engine("gear");
}
}
/**
* Dagger2生成的工廠類
*/
public final class MarkCarModule_ProvideEngineFactory implements Factory<Engine> {
private final MarkCarModule module;
public MarkCarModule_ProvideEngineFactory(MarkCarModule module) {
assert module != null;
this.module = module;
}
@Override
public Engine get() {
return Preconditions.checkNotNull(
module.provideEngine(), "Cannot return null from a non-@Nullable @Provides method");
}
public static Factory<Engine> create(MarkCarModule module) {
return new MarkCarModule_ProvideEngineFactory(module);
}
/** Proxies {@link MarkCarModule#provideEngine()}. */
public static Engine proxyProvideEngine(MarkCarModule instance) {
return instance.provideEngine();
}
}複製程式碼我們可以看到MarkCarModule_ProvideEngineFactory中的get()呼叫了MarkCarModule的provideEngine()方法來獲取我們需要的依賴Engine，MarkCarModule_ProvideEngineFactory的例項化有crate()建立，並且MarkCarModule的例項也是通過create()方法傳進來的。那麼這個create()一定會在哪裡呼叫的，我們接著往下看。
前面提到@Component是依賴提供方(MarkCarModule)和依賴需求方(Car)之前的橋樑，那我看看Dagger2是如何通過CarComponent將兩者聯絡起來的。
/**
* 我們自己的類
*/
@Component(modules = {MarkCarModule.class})
public interface CarComponent {
void inject(Car car);
}
/**
* Dagger2生成的CarComponent實現類
*/
public final class DaggerCarComponent implements CarComponent {
private Provider<Engine> provideEngineProvider;
private MembersInjector<Car> carMembersInjector;
private DaggerCarComponent(Builder builder) {
assert builder != null;
initialize(builder);
}
public static Builder builder() {
return new Builder();
}
public static CarComponent create() {
return builder().build();
}
@SuppressWarnings("unchecked")
private void initialize(final Builder builder) {
this.provideEngineProvider = MarkCarModule_ProvideEngineFactory.create(builder.markCarModule);
this.carMembersInjector = Car_MembersInjector.create(provideEngineProvider);
}
@Override
public void inject(Car car) {
carMembersInjector.injectMembers(car);
}
public static final class Builder {
private MarkCarModule markCarModule;
private Builder() {}
public CarComponent build() {
if (markCarModule == null) {
this.markCarModule = new MarkCarModule();
}
return new DaggerCarComponent(this);
}
public Builder markCarModule(MarkCarModule markCarModule) {
this.markCarModule = Preconditions.checkNotNull(markCarModule);
return this;
}
}
}複製程式碼通過上面的程式碼我們看到Dagger2依據CarComponent介面生成了實現類DaggerCarComponent（沒錯這正是我們在Car的建構函式中使用DaggerCarComponent）。DaggerCarComponent在build的時候例項化了DaggerCarComponent物件，並首先呼叫MarkCarModule_ProvideEngineFactory.create(builder.markCarModule)始化了provideEngineProvider變數，接著呼叫Car_MembersInjector.create(provideEngineProvider)初始化了carMembersInjector變數。當我們手動在Car類的建構函式中呼叫inject(Car car)方法時會執行carMembersInjector.injectMembers(car)。所以接下來我們要看看Car_MembersInjector的實現。
public final class Car_MembersInjector implements MembersInjector<Car> {
private final Provider<Engine> engineProvider;
public Car_MembersInjector(Provider<Engine> engineProvider) {
assert engineProvider != null;
this.engineProvider = engineProvider;
}
public static MembersInjector<Car> create(Provider<Engine> engineProvider) {
return new Car_MembersInjector(engineProvider);
}
@Override
public void injectMembers(Car instance) {
if (instance == null) {
throw new NullPointerException("Cannot inject members into a null reference");
}
instance.engine = engineProvider.get();
}
public static void injectEngine(Car instance, Provider<Engine> engineProvider) {
instance.engine = engineProvider.get();
}
}複製程式碼Car_MembersInjector中的create()用於例項化自己，這個方法前面我們看到是在DaggerCarComponent中呼叫的。injectMembers(Car instance)將engineProvider.get()的返回值賦給了依賴需求方Car的engine變數，而engineProvider.get()正是本節一開始我們提到的MarkCarModule_ProvideEngineFactory中的get()方法。至此整個依賴注入的流程就完成了。更復雜的應用場景會生成更加複雜的程式碼，但原理都和前面分析的大同小異。
總結
這篇文章只是通過一些簡單的例子介紹了Dagger2的相關概念及使用，實際專案中的應用遠比這裡的例子要複雜。關於Dagger2在實際專案中的應用可以參照這個開源專案 github.com/BaronZ88/Mi…（專案採用MVP架構，其中View層和Presenter層的解耦就是通過Dagger2來實現的）。
MinimalistWeather是一款開源天氣App，開發此專案主要是為展示各種開源庫的使用方式以及Android專案的架構方案，並作為團隊開發規範的一部分。專案中每一個字母、每一個命名、每一行程式碼都是經過仔細考究的；但是由於時間精力有限，專案UI未做嚴格要求。本著精益求精、提供更好開源專案和更美天氣應用的原則，因此期望有興趣的開發和UED同學可以一起來完成這個專案。
本次掘金徵文活動連結gold.xitu.io/post/58522d…