很顯然，Context并不能通過new的方式提供，那么就通過構造函數傳參的方式提供。詳細代碼如下：
image.png
可見必要的提供Context的
context()的方法還是有的，而且用@Provides注解。至于這個ContextModule是什么時候被初始化的，通過什么樣的方式傳入到Dagger里面的，這個我們稍后再講。
那么通過這種注入方式，也可以提供Picasso。新建一個PicassoModule：
image.png
不難看出使用Dagger2會盡可能少的直接在需要依賴的地方new一個對象，而是通過Dagger去獲取一個對象。
那么會不會感到疑惑，Dagger究竟是怎樣幫助我們生成所需要的類呢？通過點擊下圖中的紅色方框部分可以看到Dagger為我們生成的代碼。
image.png
生成的代碼如下：
image.png
image.png
image.png
image.png
可以看到Dagger生成了提供各個類的Provider，在
initialize()中的初始化順序是按照正確的邏輯順序生成的，雖然我們并沒有指定它的順序，這一切都是Dagger自動完成的。為了使用Dagger為我們生成的類，我們就必須創建GithubApplicationComponent的實例。代碼如下：
image.png
看到了嗎，含有context的Module就是通過這樣的方式被初始化，并且傳入Dagger的。通過創建的component就可以獲取需要的githubService和picasso啦。但是大家有沒有發現一個問題，這里面每個Module都需要new一個傳進去，假如有個50個Module，這工作量也不少啊，而且容易漏。事實上Dagger只需要傳入一個ContextModule就行了，其余的Module都會自動幫你生成。就像下面這樣：
image.png
如果你會看上面Dagger幫我們生成的代碼時，里面
build()方法，你就會發現，Dagger會檢查需要的類，如果為空就幫我們生成所需要的類。唯一一個一旦為空就拋出異常的的Module就是ContextModule，因為Dagger并不知道如何創建這個類。
怎么樣，再對比剛開始Application中的類，是不是感覺少了很多代碼。接下來的文章將會介紹Scope的使用。
相關文章：
從實例出發理解Dagger2（一）
從實例出發理解Dagger2（二）
從實例出發理解Dagger2（三）
從實例出發理解Dagger2（四）
從實例出發理解Dagger2（五）
從實例出發理解Dagger2（六）
從實例出發理解Dagger2（七）
參考資料：https://www.youtube.com/watch?v=gg1zxoVStBM&list=PLuR1PJnGR-Ih-HXnGSpnqjdhdvqcwhfFU&index=3
