點贊關注，不再迷路，你的支持對我意義重大！

?? Hi，我是丑丑。本文 「Android 路線」| 導讀 —— 從零到無窮大 已收錄，這里有 Android 進階成長路線筆記 & 博客，歡迎跟著彭丑丑一起成長。（聯系方式在 GitHub）

前言

• 依賴注入是項目組件解耦中非常重要的一個手段，Dagger2 和 Hilt 是在 Android 中最主要的依賴注入框架；
• 在這篇文章里，我將總結 Dagger2 的使用方法，如果能幫上忙，請務必點贊加關注，這真的對我非常重要。

目錄

前置知識

這篇文章的內容會涉及以下前置 / 相關知識，貼心的我都幫你準備好了，請享用~

• APT 【點贊催更】
• Java | 注解（含 Kotlin）

1. 為什么要進行依賴注入

依賴注入（Dependency Injection，簡稱 DI）其實并不是一個很神秘的概念，往往在不經意地間我們就使用了依賴注入。依賴注入應用了 “控制反轉（IoC）” 的原理，簡單來說就是在類的外部構造依賴項，使用構造器或者 setter 注入。

提示： 你往往在不經意間使用了依賴注入的思想。

使用依賴注入可以為我們帶來什么好處呢？

• 重用組件： 因為我們在類外部構造依賴項；
• 組件解耦： 當我們需要修改某個組件的實現時，不需要在項目中進行大量變更；
• 易測試： 我們可以向依賴方注入依賴項的模擬實現，這使得依賴方的測試更加容易；
• 生命周期透明： 依賴方不感知依賴項創建 / 銷毀的生命周期，這些可以交給依賴注入框架管理。

2. Android 依賴注入框架

當只有一個依賴項時，手動進行依賴注入很簡單，但隨著項目規模變大，手動注入會變得越來越復雜。而使用依賴注入框架，可以讓依賴注入的過程更加簡便，另外，依賴注入框架往往還提供了管理依賴項的生命周期的功能。從實現上，依賴注入框架可以歸為兩類：

• 1、基于反射的動態方案： Guice、Dagger；
• 2、基于編譯時注解的靜態方案（性能更高）： Dagger2、Hilt、ButterKnife。

提示：依賴注入框架本質上不是提供了依賴注入的能力，而是采用了注解等方式讓依賴注入變得更加簡易。

在這里面，Dagger2 和 Hilt 是我們今天討論的主題。

• Dagger2： Dagger 的名字取自有向無環圖（DAG，Directed acyclic graph），最初由 Square 組織開發，而后來的 Dagger2 和 Hilt 框架則由 Square 和 Google 共同開發維護。

• Hilt： Hilt 是 Dagger2 的二次封裝，Hilt 本質上是對 Dagger 進行場景化。它為 Android 平臺制定了一系列規則，大大簡化了 Dagger2 的使用。在 Dagger2 里，你需要手動獲取依賴圖和執行注入操作，而在 Hilt 里，注入會自動完成，因為 Hilt 會自動找到 Android 系統組件中那些最佳的注入位置。

下面，我們分別來討論 Dagger2 和 Hilt 兩個框架。原本我不打算介紹太多 Dagger2 的內容（因為在 Android 里我們是直接使用 Hilt），考慮到兩者的關系還是覺得還是有必要把 Dagger2 講清楚，才能真正理解 Hilt 幫我們做了什么。

3. Dagger2 使用教程

提示： 我在學習 Dagger2 時，也閱讀了很多文章和官方文檔。有些作者會列舉出所有注解的用法，有些作者只介紹用法而忽略解釋自動生成的代碼。我也在尋求一種易于理解 / 接受的講法，最后我覺得先「基礎注解」再「復雜注解」，邊介紹用法邊解釋自動生成代碼的方式，或許是更容易理解的方式。期待得到你的反饋~

在討論的過程中，我們通過一個簡單的例子來展開：假設我們有一個用戶數據模塊，它依賴于兩個依賴項：

public class UserRepository {
    private final UserLocalDataSource userLocalDataSource;
    private final UserRemoteDataSource userRemoteDataSource;

    public UserRepository(UserLocalDataSource userLocalDataSource, UserRemoteDataSource userRemoteDataSource) {
        this.userLocalDataSource = userLocalDataSource;
        this.userRemoteDataSource = userRemoteDataSource;
    }
}

首先，你可以選擇不使用依賴注入，那么你可能就會在項目多處重復構建，缺點我們在第一節都討論過了。

new UserRepository(new UserLocalDataSource(), new UserRemoveDataSource());

后來，有追求的你已經開始使用依賴注入，你寫了一個全局的工具方法：

public static UserRepository get() {
    return new UserRepository(new UserLocalDataSource(), new UserRemoveDataSource());
}

這確實能滿足需求，然而在真實項目中，模塊之間的依賴關系往往比這個例子要復雜得多。此時，如果經常手動編寫依賴注入的模板代碼，不僅耗時耗力，也容易出錯。下面，我們開始使用 Dagger2 這個幫手來替我們編寫模板代碼。

3.1 @Component + @Inject

@Component 和 @Inject 是 Dagger2 最基礎的兩個注解，僅使用這兩個注解就可以實現最簡單的依賴注入。

• @Component：創建一個 Dagger 容器，作為獲取依賴項的入口

@Component
public interface ApplicationComponent {
    UserRepository userRepository();
}

• @Inject：指示 Dagger 如何實例化一個對象

public class UserRepository {

    private final UserLocalDataSource userLocalDataSource;
    private final UserRemoteDataSource userRemoteDataSource;

    @Inject
    public UserRepository(UserLocalDataSource userLocalDataSource, UserRemoteDataSource userRemoteDataSource) {
        this.userLocalDataSource = userLocalDataSource;
        this.userRemoteDataSource = userRemoteDataSource;
    }
}
--------------------------------------------
public class UserLocalDataSource {
    @Inject
    public UserLocalDataSource() {
    }
}
--------------------------------------------
public class UserRemoveDataSource {
    @Inject
    public UserRemoveDataSource() {
    }
}

你需要用 @Inject 注解修飾依賴項的構造方法，同時，它的依賴項 UserLocalDataSource 和 UserRemoteDataSource 也需要增加 @Inject 注解。

以上代碼在構建后會自動生成代碼：

DaggerApplicationComponent.java

1、實現 ApplicationComponent 接口
public final class DaggerApplicationComponent implements ApplicationComponent {
    private DaggerApplicationComponent() {
    }
    
    2、創建依賴項實例
    @Override
    public UserRepository userRepository() {
        return new UserRepository(new UserLocalDataSource(), new UserRemoteDataSource());
    }

    3、構建者模式
    public static Builder builder() {
        return new Builder();
    }

    public static ApplicationComponent create() {
        return new Builder().build();
    }

    public static final class Builder {
        private Builder() {
        }

        public ApplicationComponent build() {
            return new DaggerApplicationComponent();
        }
    }
}

可以看到，最簡單的依賴注入模板代碼已經自動生成了。使用時，你只需要通過 ApplicationComponent 這個入口就可以獲得 UserReopsitory 實例：

ApplicationComponent component = DaggerApplicationComponent.create();

UserRepository userRepository = component.userRepository();

3.2 @Inject 字段注入

有些類不是使用構造器初始化的，例如 Android 框架類 Activity 和 Fragment 由系統實例化，此時就不能再使用 3.1 節 中使用的構造器注入，可以改為字段注入，并手動調用方法請求注入。

構造器注入：（X）
public class MyActivity {
    @Inject
    public MyActivity(LoginViewModel viewModel){
        ...
    }
}
--------------------------------------------
字段注入：
class MainActivity : AppCompatActivity() {
    @Inject
    lateinit var viewModel: LoginViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        DaggerApplicationComponent.create().inject001(this)
        super.onCreate(savedInstanceState)
        ...
    }
}
public class LoginViewModel {
    private final UserRepository userRepository;

    @Inject
    public LoginViewModel(UserRepository userRepository) {
        this.userRepository = userRepository;
    }
}

在 Activity 或 Fragment 中使用時，需要注意組件的生命周期：

• 在 super.onCreate() 中的恢復階段，Activity 會附加綁定的 Fragment，這些 Fragment 可能需要訪問 Activity。為保證數據一致性，應在調用 super.onCreate() 之前在 Activity 的 onCreate() 方法中注入 Dagger。

• 在使用 Fragment 時，應在 Fragment 的 onAttach() 方法中注入 Dagger，此操作可以在調用 super.onAttach() 之前或之后完成。

3.3 @Singleton / @Scope

• @Singleton / @Scope：聲明作用域，可以約束依賴項的作用域周期

@Singleton
public class UserRepository {
    ...
}
--------------------------------------------
@Component
@Singleton
public interface ApplicationComponent {
    ...
}

在 ApplicationComponent 和 UserRepository 上使用相同的作用域注解，表明兩者處于同一個作用域周期。這意味著，同一個 Component 多次提供該依賴項都是同一個實例。你可以直接使用內置的 @Singleton，也可以使用自定義注解：

@Scope
@Documented
@Retention(RUNTIME)
public @interface Singleton {}
--------------------------------------------
@Scope
@Retention(RetentionPolicy.RUNTIME)
public @interface MyCustomScope {}

提示： 使用 @Singleton 或 @MyCustomScope，效果是完全一樣的。

以上代碼在構建后會自動生成代碼：

public final class DaggerApplicationComponent implements ApplicationComponent {
    private Provider<UserRepository> userRepositoryProvider;

    private DaggerApplicationComponent() {
        initialize();
    }

    private void initialize() {
        this.userRepositoryProvider = DoubleCheck.provider(UserRepository_Factory.create(UserLocalDataSource_Factory.create(), UserRemoteDataSource_Factory.create()));
    }

    @Override
    public UserRepository userRepository() {
        return userRepositoryProvider.get();
    }
    ...
}

作用域注解約束

有幾個關于作用域注解的約束，你需要注意下：

• 如果某個組件有作用域注解，那么該組件只能給提供帶有該注解的類或者不帶任何作用域注解的類；
• 子組件不能使用和某個父組件的相同的作用域注解。

提示： 關于子組件的概念，你可以看 第 3.5 節。

作用域注解規范

只要你滿足上面提到的約束規則，Dagger2 框架并不嚴格限制你定義的作用域語義。你可以按照業務劃分作用域，也可以按照生命周期劃分作用域。例如：

按照業務劃分：
@Singleton
@LoginScope
@RegisterScope
--------------------------------------------
按聲明周期劃分：
@Singleton
@ActivityScope
@ModuleScope
@FeatureScope

不過，按照生命周期劃分作用域是更加理想的做法，作用域不應該明確指明其實現目的。

3.4 @Module + @Providers

• @Module + @Providers：指示 Dagger 如何實例化一個對象，但不是以構造器的方式

public class UserRemoteDataSource {
    private final LoginRetrofitService loginRetrofitService;
    @Inject
    public UserRemoteDataSource(LoginRetrofitService loginRetrofitService) {
        this.loginRetrofitService = loginRetrofitService;
    }
}
--------------------------------------------
@Module
public class NetworkModule {
    @Provides
    public LoginRetrofitService provide001(OkHttpClient client) {
        return new Retrofit.Builder()
                .baseUrl("https://example.com")
                .build()
                .create(LoginService.class);
    }
}
--------------------------------------------
@Singleton
@Component(modules = NetworkModule.class)
public interface ApplicationComponent {

    UserRepository userRepository();

    void inject001(MainActivity activity);
}

@Module 模塊提供了一種與 @Inject 不同的提供對象實例的方式。在 @Module 里，@Provides 方法的返回值是依賴項實例，而參數是進一步依賴的對象。另外，你還需要在 @Component 參數中應用該模塊。

目前為止，我們構造的依賴關系圖如下所示：

3.5 @Subcomponent

• @Subcomponent：聲明子組件，使用子組件的概念可以定義更加細致的作用域

子組件是繼承并擴展父組件的對象圖的組件，子組件中的對象就可以依賴于父組件中提供的對象，但是父組件不能依賴于子組件依賴的對象（簡單的包含關系，對吧？）。

我們繼續通過一個簡單的例子來展開：假設我們有一個登錄模塊 LoginActivity，它依賴于 LoginModel。我們的需求是定義一個子組件，它的聲明周期只在一次登錄流程中存在。在 第 3.2 節 提過，Activity 無法使用構造器注入，所以 LoginActivity 我們采用的是 @Inject 字段注入的語法：

@Subcomponent
public interface LoginComponent {
    void inject(LoginActivity activity);
}

但是這樣定義的 LoginComponent 還不能真正稱為某個組件的子組件，需要增加額外聲明：

@Module(subcomponents = LoginComponent.class)
public class SubComponentsModule {
}
--------------------------------------------
@Component(modules = {NetworkModule.class,SubComponentsModule.class})
@Singleton
public interface ApplicationComponent {
    UserRepository userRepository();
    LoginComponent.Factory loginComponent();
}
--------------------------------------------
@Subcomponent
public interface LoginComponent {
    @Subcomponent.Factory
    interface Factory{
        LoginComponent create();
    }
    void inject001(LoginActivity activity);
}

在這里，我們需要定義一個新模塊 SubcomponentModule，同時需要在 LoginComponent 中定義子組件 Factory，以便 ApplicationComponent 知道如何創建 LoginComponent 的示例。

現在，LoginComponent 就算聲明完成了。為了讓 LoginComponent 保持和 LoginActivity 相同的生命周期，你應該在 LoginActivity 內部創建 LoginComponent 實例，并持有引用：

public class LoginActivity extends Activity {
    1、持有子組件引用，保證相同生命周期
    LoginComponent loginComponent;

    2、@Inject 字段注入
    @Inject
    LoginViewModel loginViewModel;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        3、創建子組件實例
        loginComponent = ((MyApplication) getApplicationContext())
                                .appComponent.loginComponent().create();
        4、注入
        loginComponent.inject(this);
        ...
    }
}

執行到步驟 4 ，loginViewModel 字段就初始化完成了。這里有一個需要特別注意的點，你思考這個問題：如果你在 LoginActivity 中的一個 Fragment 重復注入 LoginViewModel，它是一個對象嗎？

@Subcomponent
public interface LoginComponent {

    @Subcomponent.Factory
    interface Factory {
        LoginComponent create();
    }

    void inject001(LoginActivity loginActivity);
    void inject002(LoginUsernameFragment fragment);
}

肯定是不同對象的，因為我們還沒有使用 第 3.3 節 提到的 @Singleton / @Scope 作用域注解。現在我們增加作用域注解：

@Scope
@Retention(RetentionPolicy.RUNTIME)
public @interface ActivityScope {}

@ActivityScope
@Subcomponent
public interface LoginComponent { ... }

@ActivityScope
public class LoginViewModel {
    private final UserRepository userRepository;

    @Inject
    public LoginViewModel(UserRepository userRepository) {
        this.userRepository = userRepository;
    }
}

目前為止，我們構造的依賴關系圖如下所示：

4. 在 Dagger2 的基礎上進行單元測試

當一個項目應用了 Dagger2 或者其它依賴注入框架，那么在一定程度上它的各個組件之間是處于一種松耦合的狀態，此時進行單元測試顯得游刃有余。

在 Dagger2 項目上你可以選擇在不同級別上注入模擬依賴項：

4.1 對象級別：

你可以定義一個 FakeLoginViewModel，然后替換到 LoginActivity：

public class LoginActivity extends Activity {
    1、持有子組件引用，保證相同生命周期
    LoginComponent loginComponent;

    2、@Inject 字段注入
    @Inject
    FakeLoginViewModel loginViewModel;
}

4.2 組件級別

你可為為正式版和測試版定義兩個組件：ApplicationComponent 和 TestApplicationComponent：

@Singleton
@Component(modules = {FakeNetworkModule.class, SubcomponentsModule.class})
public interface TestApplicationComponent extends ApplicationComponent {
}

5. 總結

總結一下我們提到的注解：

參考資料

• 【Dagger · 官網】【Hilt · 官網】【Dagger2 · Github】
• 《Android 中的依賴項注入》系列文檔 —— Android Developers（必看）
• 《Tasting Dagger 2 on Android.》 —— Fernando Cejas 著
• 《從 Dagger 到 Hilt，谷歌為何執著于讓我們用依賴注入？》 —— 扔物線 著
• 《Jetpack 新成員，一篇文章帶你玩轉 Hilt 和依賴注入》 —— 郭霖 著
• 《Android Studio 4.1 的 Dagger 導航更新》 —— Android Developers
• 《在 Kotlin 中使用 Dagger 會遇到的陷阱和優化方法》 —— Android Developers

創作不易，你的「三連」是丑丑最大的動力，我們下次見！