前言
如果您對dagger2的概念，整個依賴注入框架還不清楚，可以先了解下我的前2篇文章：
Android：dagger2讓你愛不釋手-基礎依賴注入框架篇
Android：dagger2讓你愛不釋手-重點概念講解、融合篇
這2篇文章也收到好多網友的好評和提問，謝謝大家的支持。我大概總結了下提的問題：
- dagger2到底能帶來哪些好處？
- dagger2怎麼使用？
因此我將結合這2點來進行本文的講解。並且會有具體的sample。
dagger2到底有哪些好處？
咱們直奔主題：
增加開發效率、省去重複的簡單體力勞動
首先new一個實例的過程是一個重複的簡單體力勞動，dagger2完全可以把new一個實例的工作做了，因此我們把主要精力集中在關鍵業務上、同時也能增加開發效率上。
省去寫單例的方法，並且也不需要擔心自己寫的單例方法是否線程安全，自己寫的單例是懶漢模式還是餓漢模式。因爲dagger2都可以把這些工作做了。
更好的管理類實例
每個app中的ApplicationComponent管理整個app的全局類實例，所有的全局類實例都統一交給ApplicationComponent管理，並且它們的生命週期與app的生命週期一樣。
每個頁面對應自己的Component，頁面Component管理着自己頁面所依賴的所有類實例。
因爲Component，Module，整個app的類實例結構變的很清晰。
解耦
假如不用dagger2的話，一個類的new代碼是非常可能充斥在app的多個類中的，假如該類的構造函數發生變化，那這些涉及到的類都得進行修改。設計模式中提倡把容易變化的部分封裝起來。
我們用了dagger2後。
假如是通過用Inject註解標註的構造函數創建類實例，則即使構造函數變的天花亂墜，我們基本上都不需要修改任何代碼。
假如是通過工廠模式Module創建類實例，Module其實就是把new類實例的代碼封裝起來，這樣即使類的構造函數發生變化，只需要修改Module即可。
有個網友問過一個這樣的問題，Module的構造函數也會發生變化，發生變化後，相應的new Module的類也發生變化，這就沒有達到解耦的效果。首先解耦不是說讓類之間或模塊之間真的一點關係都沒有了，解耦達到的目的是讓一個類或一個模塊對與自己有關聯的類或模塊的影響降到最低，不是說這種影響就完全沒有了，這是不可能的。
解耦還有個好處，就是方便測試，若需要替換爲網絡測試類，只需要修改相應的Module即可。
項目中使用dagger2注意點
具體的代碼就不講了，dagger2 sample地址，大家自行下載。這裏重點說下dagger2對目標類進行依賴注入的過程，現在假設要初始化目標類中的其中一個依賴類的實例，那具體步驟就在下面：
步驟1：查找Module中是否存在創建該類的方法。
步驟2：若存在創建類方法，查看該方法是否存在參數
步驟2.1：若存在參數，則按從**步驟1**開始依次初始化每個參數
步驟2.2：若不存在參數，則直接初始化該類實例，一次依賴注入到此結束
步驟3：若不存在創建類方法，則查找Inject註解的構造函數，
看構造函數是否存在參數
步驟3.1：若存在參數，則從**步驟1**開始依次初始化每個參數
步驟3.2：若不存在參數，則直接初始化該類實例，一次依賴注入到此結束以上是dagger2進行的一次依賴注入的步驟，其實這個步驟是一個遞歸的過程，並且在查找類的實例的過程中Module的級別要高於Inject，這概念在上一篇講過。
下面在說下注意的幾點
- 一個app必須要有一個Component（名字可以是ApplicationComponent）用來管理app的整個全局類實例
- 多個頁面可以共享一個Component
- 不是說Component就一定要對應一個或多個Module，Component也可以不包含Module
- 自定義Scope註解最好使用上，雖然不使用也是可以讓項目運行起來的，但是加上好處多多。
總結
好了關於dagger2的所有的概念知識點到此終於結束了，希望能幫助大家，與大家共勉，有問題可以隨時與我溝通。