Jetpack 系列(10)—— 从 Dagger2 到 Hilt 玩转依赖注入(一)

简介: Jetpack 系列(10)—— 从 Dagger2 到 Hilt 玩转依赖注入(一)

前言


  • 依赖注入是项目组件解耦中非常重要的一个手段,Dagger2 和 Hilt 是在 Android 中最主要的依赖注入框架;
  • 在这篇文章里,我将总结 Dagger2 的使用方法,如果能帮上忙,请务必点赞加关注,这真的对我非常重要。


这篇文章是 Jetpack 系列文章第 10 篇,专栏文章列表:



二、其他:


  • 1、AppStartup:轻量级初始化框架
  • 2、DataStore:新一代键值对存储方案
  • 3、Room:ORM 数据库访问框架
  • 4、WindowManager:加强对多窗口模式的支持
  • 5、WorkManager:加强对后台任务的支持
  • 6、Compose:新一代视图开发方案


目录


image.png

前置知识


这篇文章的内容会涉及以下前置 / 相关知识,贴心的我都帮你准备好了,请享用~



1. 为什么要进行依赖注入


依赖注入(Dependency Injection,简称 DI)其实并不是一个很神秘的概念,往往在不经意地间我们就使用了依赖注入。依赖注入应用了 “控制反转(IoC)” 的原理,简单来说就是在类的外部构造依赖项,使用构造器或者 setter 注入。


提示: 你往往在不经意间使用了依赖注入的思想。


image.png

使用依赖注入可以为我们带来什么好处呢?


  • 重用组件: 因为我们在类外部构造依赖项;
  • 组件解耦: 当我们需要修改某个组件的实现时,不需要在项目中进行大量变更;
  • 易测试: 我们可以向依赖方注入依赖项的模拟实现,这使得依赖方的测试更加容易;
  • 生命周期透明: 依赖方不感知依赖项创建 / 销毁的生命周期,这些可以交给依赖注入框架管理。


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;
    }
}
复制代码


image.png

首先,你可以选择不使用依赖注入,那么你可能就会在项目多处重复构建,缺点我们在第一节都讨论过了。


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 参数中应用该模块。


目前为止,我们构造的依赖关系图如下所示:

image.png


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;
    }
}
复制代码


目前为止,我们构造的依赖关系图如下所示:

image.png

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. 总结


总结一下我们提到的注解:


注解 描述
@Component 创建一个 Dagger 容器,作为获取依赖项的入口
@Inject 指示 Dagger 如何实例化一个对象
@Singleton / @Scope 作用域,可以约束依赖项的作用域周期
@Module + @Providers 指示 Dagger 如何实例化一个对象,但不是以构造器的方式
@Subcomponent 声明子组件,使用子组件的概念可以定义更加细致的作用域


目录
相关文章
Jetpack Compose中ViewModel、Flow、Hilt、Coil的使用
Jetpack Compose中ViewModel、Flow、Hilt、Coil的使用
1082 0
Jetpack Compose中ViewModel、Flow、Hilt、Coil的使用
|
Android开发 开发者 容器
上手指南 | Jetpack Hilt 依赖注入框架
上手指南 | Jetpack Hilt 依赖注入框架
上手指南 | Jetpack Hilt 依赖注入框架
|
测试技术 数据库 Android开发
Android Jetpack 浅析Hilt依赖注入
首先,某个类的成员变量称为依赖,如若此变量想要实例化引用其类的方法,可以通过构造函数传参或者通过某个方法获取对象,此等通过外部方法获取对象实例的称为依赖注入;而依赖注入又可以简单分为`手动注入`和`自动注入`两种方式;`Hilt`就是基于Dagger进行`场景化优化`的一个依赖注入库,Hilt是Google专门为Android平台打造的一个依赖注入库,在使用上极大程度进行啦简化(与dagger相比)
318 1
|
Java API 调度
Jetpack Hilt有哪些改善又有哪些限制?
Jetpack Hilt有哪些改善又有哪些限制?
Jetpack Hilt有哪些改善又有哪些限制?
DHL
|
算法 安全 Java
Jetpack 新成员 Hilt 与 Dagger 大不同(三)落地篇
在 Google 的 Hilt 文档中 Dependency injection with Hilt 只是简单的告诉我们 Hilt 是 Android 的依赖注入库,它减少了在项目中进行手动依赖,Hilt 是基于 Dagger 基础上进行开发的,为常见的 Android 类提供容器并自动管理它们的生命周期等等。
DHL
469 0
Jetpack 新成员 Hilt 与 Dagger 大不同(三)落地篇
DHL
|
存储 算法 安全
Jetpack 新成员 Hilt 实践之 App Startup(二)进阶篇
Hilt 是基于 Dagger 基础上进行开发的,如果了解 Dagger 朋友们,应该会感觉它们很像,但是与 Dagger 不同的是, Hilt 集成了 Jetpack 库和 Android 框架类,并删除了大部分模板代码,让开发者只需要关注如何进行绑定,而不需要管理所有 Dagger 配置的问题。
DHL
368 0
Jetpack 新成员 Hilt 实践之 App Startup(二)进阶篇
DHL
|
算法 安全 Java
Jetpack 新成员 Hilt 实践(一)启程过坑记
这篇文章主要来分析一下 Hilt,花了好几天时间梳理了一下 官方 Hilt 文档,Hilt 的知识点有点多,将会分为三篇文章结合实际案例来完成,每篇文章都会有详细的使用的案例。
DHL
351 0
Jetpack 新成员 Hilt 实践(一)启程过坑记
|
4天前
|
存储 设计模式 数据库
构建高效的安卓应用:探究Android Jetpack架构组件
【4月更文挑战第20天】 在移动开发的世界中,构建一个既高效又可维护的安卓应用是每个开发者追求的目标。随着Android Jetpack的推出,Google为开发者提供了一套高质量的库、工具和指南,以简化应用程序开发流程。本文将深入探讨Jetpack的核心组件之一——架构组件,并展示如何将其应用于实际项目中,以提升应用的响应性和稳定性。我们将通过分析这些组件的设计原则,以及它们如何协同工作,来揭示它们对于构建现代化安卓应用的重要性。
|
4天前
|
Android开发 开发者
什么是Android Jetpack,它包括哪些组件?
什么是Android Jetpack,它包括哪些组件?
45 0
|
4天前
|
IDE API 开发工具
Google I/O :Android Jetpack 最新变化(四)Compose
Google I/O :Android Jetpack 最新变化(四)Compose
119 0