Android DI框架-Hilt

到底该如何理解<依赖注入>

模版代码：食之无味，弃之可惜

public class MainActivity extends Activity {@Overrideprotected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);TextView mTextView=(TextView) findViewById(R.id.mTextView);mTextView.setOnClickListener(new OnClickListener() {@Overridepublic void onClick(View v) {}});String params1= getIntent().getString("params1")String params2= getIntent().getString("params2")}
}

findViewById、getIntent().getXXX()这样的重复代码，即没有技术含量，还动不动就是几十行。

---

注解+APT+反射

为了解决上述的问题，越来越多的依赖注入框架应运而生，其中具有代表性的，当属：ButterKnife View注入，ARouter Intent 参数自动提取注入。

public class MainActivity extends Activity {@BindView(R.id.text)public TextView textView;@Autowiredpublic model model@Overrideprotected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);ButterKnife.inject(this);//运行时view注入Arouter.getInstance().inject(this)//运行时参数注入}@Click(R.id.text)void buttonClick() {}
}

---

ButterKnife原理：

1. 编译时按照命名规则生成相应实现类，编织好findViewById的代码
2. 运行时根据MainActivity的类名找到编译生成的实现类，反射构建实例，并调用inject方法触发findViewById

//ButterKnife自动findViewById
class ButterKnife_MainActivity<MainActivity> implements Inject{@Overridepublic void inject(MainActivity activity){activity.textView =activity.findViewById(R.id.text)}
}

ARouter原理：大致相同，详情参考：ARouter简明扼要原理分析 ：

//arouter的参数自动提取
public class MainActivity$$ARouter$$Autowired implements ISyringe {@Overridepublic void inject(Object target) {MainActivity substitute = (MainActivity)target;substitute.goodsId = substitute.getIntent().getStringExtra("id");substitute.goodsModel = substitute.getIntent().getParcelableExtra("model");}
}

---

IOC框架的类型

view注入: Xutils,ButterKnife

参数注入: Arouter

对象注入:koin,Dagger2，Hilt

---

IOC、DI、APT傻傻分不清楚

什么是IOC(Inversion of Control) 控制反转？

是一种思想，并不是特指一种技术实现，目的是要解决Java 开发领域，对象的创建以及管理的问题，是一种软件设计思想。

• 控制 ：指的是对象创建（实例化、管理）的权力。(在哪里创建，由‘’谁”创建)
• 反转 ：控制权交给外部环境（Spring 框架、IoC 容器）
• 传统的开发方式 ：当一个类里面需要用到很多个成员变量时。传统的写法，这些成员变量，都需要new出来！
• 使用 IOC 思想的开发方式 ：IOC的原则是：NO，我们不要new，这样耦合度太高(入参改变，所有引用都要改)，而是通过 IOC 容器(Hilt,Dagger2 框架) 来帮助我们实例化对象并赋值。

Java中常见IOC解决方案

• 解决方案一： 配置xml文件，里面标明哪个类，里面用了哪些成员变量，等待加载这个类的时候，我帮你注入（new）进去(Spring 服务器开发常用ioc方案)
• 解决方案二： 用注解在需要注入的成员变量上面加个注解，例如@Inject，编译时生成相关实现类，运行时动态注入。在android上常用的ioc实现案，就是annotition +abtractProcessor，简称APT(Annotation Processing Tool)

---

什么是DI（Dependency Injection）依赖注入?

其实它们是同一个概念的不同角度描述，IOC是一种软件设计思想，DI是这种软件设计思想的一个具体的实现，相比于控制反转，依赖注入更容易理解。

简单来说，依赖注入指的是对象是通过外部注入的方式完成创建。

---

IOC分析

IOC的优势

• 对象之间的耦合度或者说依赖程度降低

//1. 传统做法需要ILoginService = new LoginServiceImpl(),增加了对LoginServiceImpl的引用，
//倘若那天LoginServiceImpl不再是唯一实现类，那么所有引用的地方都需要相应改变//2. 如果有100个地方都直接new创建LoginServiceImpl对象，
//如果入参改变了,那么这100个地方都需要相应改变。//3.使用DI则没有这个问题,因为对象的创建将被统一管理了，统一实现了。
class MainActivty:AppcompatActivity{@Inject public ILoginService loginService;
}class LoginServiceImpl(): ILoginService{
}

• 对象实例的创建变的易于管理，很容易就可以实现一个全局，或局部共享单例

class CustomFragment:Fragment{//假如fragment需要访问Activity中的成员变量//共享对象的自动注入，在同一个作用域内(activity生命周期内，application生命周期内)，得到的都是同一个实例对象，不需要传来传去@Inject user:Userfun  display(){//传统做法  ×强转×，或者set 也就是在CustomFragment定义setUser，在Activity中把user塞进来((MainActivity)context).user.name((SecondActivity)context).user.name}
}

适合场景：模板代码创建实例对象，全局或局部对象共享

IOC的缺点

• 代码可读性差，不知道对象在哪里被创建？实例创建的时机在哪里？入参是什么？
• 增加新人学习成本（Dagger2很优秀，但仅仅是使用，就劝退了很多人）
• 加速触及65535方法数

是否有必要引入IOC？

不是必须。能发挥多大作用取决于你的项目体量复杂度，如果简单的小项目用它适得其反，学习成本和收益不匹配，出错不容易排查。

Hilt 救世主？

2019 dev submit大会，公开表示dagger2并没有真正解决大家真正遇到的问题，反而学习成本，入门门槛较高，现在已经停止开发新功能了。取而代之的是基于dagger2开发的Hilt组件，大大的降低了学习成本和上手复杂度。

• Jetpack推荐的DI库,降低 Android 开发者使用依赖注入框架的上手成本,减少了在项目中进行手动依赖(简化使用姿势，dagger2需要大量配置，Hilt不需要)
• Hilt内部有一套作用域的概念，只能在指定的作用域中使用这个对象，并且提供声明式对象生命周期的管理方式。原本dagger2是不能帮我们管理对象的使用范围，和生命周期，但是在hilt里面，这些问题都不存在了。

DI框架，在国内可能并不是很广泛，但在国外却很受欢迎。根据Google统计Google Play上架的应用，前10K的应用70%都是用到了DI框架，Google更是在自己的Youtube上使用了Hilt 数据来自2019-2020阶段

Hilt 基本用法

快速接入

项目根目录 build.gradle

plugins {id 'com.google.dagger.hilt.android' version '2.44.2' apply false
}
或 
buildscript {repositories {// other repositories...mavenCentral()}dependencies {// other plugins...classpath 'com.google.dagger:hilt-android-gradle-plugin:2.44.2'}
}

每个Module模块 build.gradle:

plugins {id 'com.android.application'id 'org.jetbrains.kotlin.android'//Hiltid 'kotlin-kapt'id 'com.google.dagger.hilt.android'
}android {compileOptions {sourceCompatibility JavaVersion.VERSION_1_8targetCompatibility JavaVersion.VERSION_1_8}kotlinOptions {jvmTarget = '1.8'}
}dependencies {implementation 'com.google.dagger:hilt-android:2.44.2'kapt 'com.google.dagger:hilt-compiler:2.44.2'
}

Step.1 配置应用程序

/** Hilt在编译阶段会生成顶层的components容器，* 提供全局的application context。* 为application提供对象注入的能力*/
@HiltAndroidApp
class HiltApplication : Application() {}

---

Step.2 配置需要依赖注入的类

/*
声明该类是一个可以注入的入口类。 仅支持在以下类型中进行依赖注入：
this supports appcompatActivity, androidx.fragment, views, services, and broadcast-receivers.
不支持Content Provider,不支持你自定义且不属于以上类型的类*/
@AndroidEntryPoint
class MainActivity : AppCompatActivity() {//声明该对象需要被动态注入@Injectlateinit var emptyView: EmptyViewoverride fun onCreate(savedInstanceState: Bundle?) {super.onCreate(savedInstanceState)setContentView(R.layout.activity_main)//Hilt.inject(this)不需要//编译时生成Hilt_HomeActivity，在super前面实例化该类，进行成员变量赋值}
}

@AndroidEntryPoint 声明该类是一个可以注入的入口类

仅支持在以下类型中进行依赖注入

不支持Content Provider,不支持你自定义且不属于以上类型的类

---

Step.3 创建注入对象

Step.3.1 @Providers 创建对象

// 声明该模块中创建的对象的生命周期 可以有多种生命周期
// doubt: 直接使用最高的不就行了？长生命周期的创建，势必会违反Hilt设计生命周期和作用范围的初衷
@InstallIn(value = [ActivityComponent::class])
@Module//声明这是一个模块，类似分组概念,里面的方法必须是public static
object HomeModule {//Kotlin 必须是单例/Java public static@Provides      //直接在方法给出具体的实现代码@ActivityScoped //声明该对象的作用域，在Activity生命周期内共享实例fun newEmptyView(@ActivityContext context: Context): EmptyView {//@ActivityContext//声明context的类型，此处声明为Activity类型的context,//除此之外还可使用@ApplicationContext，声明为Application contextval emptyView = EmptyView(context)emptyView.refresh()return emptyView}
}

Step.3.2 @binds接口注入

@InstallIn(FragmentComponent::class)//不可以在activity中使用
@Module
abstract class LoginServiceModule{//1. 函数返回类型告诉 Hilt 提供了哪个接口的实例//2. 函数参数告诉 Hilt 提供哪个实现//3. 没有指定作用域scope，则每次都会生成新的实例对象@Binds//@FragmentScoped //hint @FragmentScoped与FragmentComponent::class 必须一一对应abstract fun bindLoginService(impl:LoginServiceImpl):ILoginService?
}

• @InstallIn(value = [FragmentComponent::class]) 必须与@FragmentScoped对应
  
• @Binds：需要在方法参数里面明确写明接口的实现类。
• @Provides：不需要在方法参数里面明确指明接口的实现类，但需要给出具体的实现
• 两者不能同时出现在一个module里面，因为Provides需要定义在object修饰的类，而Binds需要定义在abstract修饰的类。

@Qualifier 限定符

自定义限定符@Qualifier，提供同一接口，不同的实现。更多参考：深入浅出，一篇文章让你学会Dagger2使用

@InstallIn(FragmentComponent::class)
@Module
object MainModule {@Qualifier@Retention(AnnotationRetention.RUNTIME)annotation class GeneralLoginServiceImpl@Qualifier@Retention(AnnotationRetention.RUNTIME)annotation class VipLoginServiceImpl@GeneralLoginServiceImpl@Providesfun provideGeneralLoginServiceImpl(): ILoginService {//note 这么写没问题，或是外界generalLoginService.password = 123456 用这种方式赋值属性//     但与在构造方法中传入参数相比，这样就少了 传入的强制性和直观性return LoginServiceImpl("General")}@VipLoginServiceImpl@Providesfun provideVipLoginServiceImpl2(): ILoginService {return LoginServiceImpl("Vip")// 这样写是不行的 会报错}//    @VipLoginServiceImpl
//    @Provides
//    fun provideVipLoginServiceImpl2(account:String): ILoginService {
//        return LoginServiceImpl(account)// 这样写是不行的 可以。但改如何注入这个参数呢？会不会过于复杂呢 hint:参数包装进方法里
//    }@Providesfun vipLoginServiceAccount():String{return "Default"//这个是给 iLoginService使用的}
}@AndroidEntryPoint
class EmptyFragment : Fragment() {@Inject@JvmField//note 需要外界重新赋值这个加上这个注解var iLoginService: ILoginService? = null@[e-mail]ateinit var generalLoginService: ILoginService@[e-mail]nit var vipLoginService: ILoginServiceoverride fun onCreateView(inflater: LayoutInflater, container: ViewGroup?,savedInstanceState: Bundle?): View? {iLoginService!!.login()generalLoginService.login()vipLoginService.login()return inflater.inflate(R.layout.fragment_empty, container, false)}}

作用域 scope

• 默认情况下，Hilt中的所有对象实例都是无作用域的。这意味着每次请求绑定时，Hilt都会创建一个新的绑定实例。@Scopes 的作用在指定作用域范围内(Application、Activity 等等) 提供相同的实例。
• 在@InstallIn模块中声明实例生命周期的范围时，作用域的范围必须与component的作用域匹配。例如，@InstallIn(ActivityComponent.class)模块内的绑定只能用限制作用域@ActivityScoped

@Module
@InstallIn(ActivityComponent.class)
object MainModule{@Providers@ActivityScoped  //在Activity生命周期内实例唯一fun providerLoginService():ILoginService=LoginServiceImpl
}

---

关键注解示意

Hint的局限性

Hilt 支持最常见的 Android 类 进行依赖注入

• Application、AppcompatActivity、androidx.Fragment、View、Service、BroadcastReceiver 等等，但是我们可能需要在 Hilt 不支持的类中执行依赖注入，在这种情况下可以使用 @EntryPoint 注解
• 比如Hilt 不支持 ContentProvider，如果想在 ContentProvider 中让Hilt 完成对象的注入，你可以定义一个接口，并添加 @EntryPoint 注解，然后添加 @InstallIn 注解指定 对象的生命周期边界，代码如下所示。

class WorkContentProvider : ContentProvider() {override fun onCreate(): Boolean {val service = InitializerEntryPoint.resolve(context!!).injectWorkService()service.work()return true}}
@EntryPoint
@InstallIn(SingletonComponent::class)//ApplicationComponent::class 已经被SingletonComponent取代
interface InitializerEntryPoint {fun injectWorkService(): WorkServicecompanion object {fun resolve(context: Context): InitializerEntryPoint {//如果该模块的生命周期是application，在创建实例时需要使用fromApplication//对应的还有fromActivity,fromFragment,fromView//具体使用哪个方法需要和InstallIn指定的组件类型匹配return EntryPointAccessors.fromApplication(context,InitializerEntryPoint::class.java)}}
}
class WorkService @Inject constructor() {fun work() {Log.e("TAG", "WorkService  -- work ")}
}   

---

源码分析

字节码分析

点击Android Studio -> Build->Build Bundles/Apks->Build APK -> 分析生成的Apk，找到对应的Application，MainActivity，分析字节码：

## HiltApplication:.class public final Lorg/ggxz/kotlin/hiltsourcecode/HiltApplication;
.super Lorg/ggxz/kotlin/hiltsourcecode/Hilt_HiltApplication;
.source "HiltApplication.kt"
...
# virtual methods
.method public onCreate()V.registers 1.line 10invoke-super {p0}, Lorg/ggxz/kotlin/hiltsourcecode/Hilt_HiltApplication;->onCreate()V.line 11return-void
.end method## MainActivity:.class public final Lorg/ggxz/kotlin/hiltsourcecode/MainActivity;
.super Lorg/ggxz/kotlin/hiltsourcecode/Hilt_MainActivity;
.source "MainActivity.kt"
...
.method protected onCreate(Landroid/os/Bundle;)V.registers 3.param p1, "savedInstanceState"    # Landroid/os/Bundle;.line 15invoke-super {p0, p1}, Lorg/ggxz/kotlin/hiltsourcecode/Hilt_MainActivity;->onCreate(Landroid/os/Bundle;)V
...

Application对象注入

//1. 编译时生成Hilt_HiApplication,称之为依赖注入的入口类//负责创建applicationComponet组件对象
//2. 编译时把父类替换成Hilt_HiApplication
@HiltAndroidApp
class HiApplication :(Hilt_HiApplication) Application {override fun onCreate() {super.onCreate()-->//3.执行父类Hilt_HiApplication.onCreate() //4.创建与Application生命周期关联的HiltComponents_ApplicationC组件,//并把application的Context对象与之关联//5.调用injectHiApplication为Application注入对象}
}

MainActivity对象注入

//1. 编译时生成Hilt_MainActivity,称之为对象注入的入口类，//创建ActivityComponent对象
//2. 编译时把父类替换成Hilt_MainActivity
@AndroidEntryPoint
class MainActivity :(Hilt_MainActivity) AppcomponentActivity {override fun onCreate() {super.onCreate()-->//3.执行父类Hilt_MainActivity.onCreate() //4.创建与Activity生命周期关联的HiltComponents_ActivityC组件//5.调用injectHiMainActivity为MainActivity注入对象}
}

共同点

• 都会创建以Hilt为前缀，类名（HiAppilication）为后缀的对象注入管理类
• 都会被替换掉父类为 Hilt_HiApplication ,Hilt_MainActivity
• 都会在onCreate()时创建对应的component组件HiltComponents_ApplicationC,HiltComponents_ActivityC
• 都会调用injectxxx(MainActivity instance)开始注入对象

知其然，知其所以然-Hilt 源码分析

Hilt_Application

@Generated("dagger.hilt.android.processor.internal.androidentrypoint.ApplicationGenerator")
public abstract class Hilt_HiltApplication extends Application implements GeneratedComponentManager<Object> {private final ApplicationComponentManager componentManager = new ApplicationComponentManager(new ComponentSupplier() {@Overridepublic Object get() {return DaggerHiltApplication_HiltComponents_ApplicationC.builder().applicationContextModule(new ApplicationContextModule(Hilt_HiltApplication.this)).build();}});protected final ApplicationComponentManager componentManager() {return componentManager;}@Overridepublic final Object generatedComponent() {return componentManager().generatedComponent();}@CallSuper@Overridepublic void onCreate() {// This is a known unsafe cast, but is safe in the only correct use case:// HiltApplication extends Hilt_HiltApplication((HiltApplication_GeneratedInjector) generatedComponent()).injectHiltApplication(UnsafeCasts.<HiltApplication>unsafeCast(this));super.onCreate();}
}

在super.onCreate()之前，调用injectHiltApplication为HiltApplication进行注入。通过Dagger2我们知道，对象的是通过Component。由上面代码所知，generatedComponent()最终会调用到
ApplicationComponentManager#get()。

private final ApplicationComponentManager componentManager = new ApplicationComponentManager(new ComponentSupplier() {@Overridepublic Object get() {return DaggerHiltApplication_HiltComponents_ApplicationC.builder().applicationContextModule(new ApplicationContextModule(Hilt_HiltApplication.this)).build();}});

1. ApplicationContextModule是Hilt自动生成的类，其本身也是@Module类型，用来保存和对外提供Application/Context，当被注入的对象标注@ApplicationContext注解，Hilt会为其自动注入ApplicationContext参数。
2. DaggerHiltApplication_HiltComponents_ApplicationC是ApplicationComponent类型。其本身是抽象类，.build()最终返回是它的子类DaggerHiltApplication_HiltComponents_ApplicationC。并将applicationContextModule作为参数传递了过去。

 public HiltApplication_HiltComponents.ApplicationC build() {Preconditions.checkBuilderRequirement(applicationContextModule, ApplicationContextModule.class);return new DaggerHiltApplication_HiltComponents_ApplicationC(applicationContextModule);}

DaggerHiltApplication_HiltComponents_ApplicationC

整体结构

public final class DaggerHiltApplication_HiltComponents_ApplicationC extends HiltApplication_HiltComponents.ApplicationC {}

DaggerHiltApplication_HiltComponents_ApplicationC继承自HiltApplication_HiltComponents.ApplicationC，结构如下：

  @Component(modules = {ApplicationContextModule.class,ActivityRetainedCBuilderModule.class,ServiceCBuilderModule.class,MainModule.class})@Singletonpublic abstract static class ApplicationC implements ApplicationComponent,HiltWrapper_ActivityRetainedComponentManager_LifecycleComponentBuilderEntryPoint,ServiceComponentManager.ServiceComponentBuilderEntryPoint,GeneratedComponent,HiltApplication_GeneratedInjector {}@Subcomponent(modules = {DefaultViewModelFactories.FragmentModule.class,ViewWithFragmentCBuilderModule.class,ViewModelFactoryModules.FragmentModule.class})

• ApplicationC是ApplicationComponent子类型
• 创建MainModule.class以注解参数的形式传递进来
• ApplicationC是abstract static class类型
  由上面可知DaggerHiltApplication_HiltComponents_ApplicationC在HiltApplication中创建。所以和Application的生命周期一样长，同时在@Module类中标记@InstallIn(ApplicationComponent::class)，@Component就就会和与之对应的ApplicationComponent相关联(同时也会关联一些默认Module)，从而使得MainModule中对象也可以和Application的生命周期一样长。

---

了解了Module的生命周期，我们再来看下对象是如何创建，已经如何生成单例的。再次之前我们先概括下结合核心类的关系：

单例创建

ublic final class DaggerHiltApplication_HiltComponents_ApplicationC extends HiltApplication_HiltComponents.ApplicationC {private final ApplicationContextModule applicationContextModule;private volatile Object iLoginService = new MemoizedSentinel();private DaggerHiltApplication_HiltComponents_ApplicationC(ApplicationContextModule applicationContextModuleParam) {this.applicationContextModule = applicationContextModuleParam;}public static Builder builder() {return new Builder();}private LoginServiceImpl getLoginServiceImpl() {return new LoginServiceImpl(ApplicationContextModule_ProvideContextFactory.provideContext(applicationContextModule));}private ILoginService getILoginService() {Object local = iLoginService;if (local instanceof MemoizedSentinel) {synchronized (local) {local = iLoginService;if (local instanceof MemoizedSentinel) {local = getLoginServiceImpl();iLoginService = DoubleCheck.reentrantCheck(iLoginService, local);}}}return (ILoginService) local;}...... 省略
}

• iLoginService对象，就是需要注入生成的对象。通过getILoginService()方法通过双重验证。利用getLoginServiceImpl()来new创建对象。
• 可以看到iLoginService是MemoizedSentinel()类型，这个类是final类，无法被继承，且内部无任何方法。作用就是用来创建单例对象。标记的作用
• 由于iLoginService是在DaggerHiltApplication_HiltComponents_ApplicationC中创建，而DaggerHiltApplication_HiltComponents_ApplicationC是在Application中创建。所以iLoginService生命周期和Application一样长，同时利用getILoginService()单例方法只会创建一次。从而达到全局单例的效果

private volatile Object iLoginService = new MemoizedSentinel();
通过volatile和synchronized我们不难看出。Hilt依赖注入是支持多线程的。但是有条件的，注入的定义和Module中具体的对象需要在同一线程，因为getLoginServiceImpl()会同步返回结果。

那么如何在主线程定义对象，Module中通过子线程创建：

class MainActivity{@Inject@jvmFiledvar data:List<City>?=null}@module@InstallIn(ActivityComponent::Class)object MainModule{@Providersfun loadData():List<City>?={DbHelp.execute(Runnable{//加载数据库数据 How to do？})}}

---

对象注入

上面讲到对象的创建，以及Hilt是如何完成单例的。下面就分析下，在MainActivity中，Hilt是如何完成注入的。

Hilt_MainActivity

public abstract class Hilt_MainActivity extends AppCompatActivity implements GeneratedComponentManager<Object> {private volatile ActivityComponentManager componentManager;private final Object componentManagerLock = new Object();...省略   @CallSuper@Overrideprotected void onCreate(@Nullable Bundle savedInstanceState) {inject();super.onCreate(savedInstanceState);}@Overridepublic final Object generatedComponent() {return componentManager().generatedComponent();}protected ActivityComponentManager createComponentManager() {return new ActivityComponentManager(this);}protected final ActivityComponentManager componentManager() {if (componentManager == null) {synchronized (componentManagerLock) {if (componentManager == null) {componentManager = createComponentManager();}}}return componentManager;}protected void inject() {((MainActivity_GeneratedInjector) generatedComponent()).injectMainActivity(UnsafeCasts.<MainActivity>unsafeCast(this));}@Overridepublic ViewModelProvider.Factory getDefaultViewModelProviderFactory() {...省略
}

Hilt_MainActivity的核心代码也不多。

1. 首先在上面我们分析过，Hilt会讲MainActivity的父类，动态替换成Hilt_MainActivity。此时在onCreate()内，super.onCreate(savedInstanceState)之前调用inject()进行注入，所以并不是不需要注入的代码，而是Hilt帮我们完成了。
2. 而要想完成注入，必须借助Component组件来完成injectMainActivity()。那么我们看下这个Component到底做了什么

generatedComponent()–>componentManager().generatedComponent()–>ActivityComponentManager#generatedComponent–>createComponent()
最终在createComponent()方法中调用.build();方法来创建对象。此时进入到：

@DefineComponent.Builder
public interface ActivityComponentBuilder {ActivityComponentBuilder activity(@BindsInstance Activity activity);ActivityComponent build();
}

这是个借口类，唯一的实现类就是ActivityCBuilder，在其内部的build()方法内返回ActivityCImpl对象。那么在ActivityCImpl中肯定存在injectMainActivity()方法:

@Overridepublic void injectMainActivity(MainActivity mainActivity) {injectMainActivity2(mainActivity);}private MainActivity injectMainActivity2(MainActivity instance) {MainActivity_MembersInjector.injectILoginService(instance, DaggerHiltApplication_HiltComponents_ApplicationC.this.getILoginService());return instance;}

内部两个参数分别为：MainActivity,ILoginService。MainActivity很好理解，我们要为这个类进行对象注入，ILoginService就是我们最终要依赖注入完成创建的对象。然后通过：MainActivity_MembersInjector#injectILoginService完成对MainActivity

public static void injectILoginService(MainActivity instance, ILoginService iLoginService) {
instance.iLoginService = iLoginService;
}
中定义iLoginService类型进行赋值。

而DaggerHiltApplication_HiltComponents_ApplicationC.this.getILoginService()用来创建注入对象。前面分析过，这是个单例创建对象的方法。所以iLoginService只会创建一次，且与Application生命周期一样长。

那么新的问题出现了。ActivityCImpl又是如何能访问的到DaggerHiltApplication_HiltComponents_ApplicationC#getILoginService()方法的呢？

层级嵌套

仔细观察DaggerHiltApplication_HiltComponents_ApplicationC的结构你会发现：

DaggerHiltApplication_HiltComponents_ApplicationC的结构是一层嵌套一层，长生命周期的Component，嵌套短生命周期的Component。长生命周期的Component称作短生命周期的父容器，这样设计的目的就是方便，短生命周期的Component可以调用长生命周期创建对象的方法，从而达到对象单例，方便的控制对象的生命周期。

---

@HiltApplication、@AndroidEntryPoint 注解

结果上面分析，可以更加深刻理解@HiltApplication的作用，理解为什么Application没有任何需要注入的对象，也需要添加@HiltApplication，不添加会报错原因：

• 创建ApplicationContextModule来保存ApplicationContext，当对象参数添加@ApplicationContext时自动为其注入
• 利用injectHiltApplication为Application进行对象注入
• 创建DaggerHiltApplication_HiltComponents_ApplicationC顶层容器

扩展

为了加深理解，现进行其他场景的分析，修改MainModule.class代码：

//ApplicationComponent 改成ActivityComponent
@InstallIn(/*ApplicationComponent::class*/ ActivityComponent::class)
@Module
abstract class MainModule {@Binds
//    @Singleton @ActivityScoped//@Singleton 改成 @ActivityScopedabstract fun bindService(impl: LoginServiceImpl): ILoginService
}interface ILoginService {fun login()
}class LoginServiceImpl @Inject constructor(@ApplicationContext val context: Context) : ILoginService {override fun login() {Toast.makeText(context, "LoginServiceImpl", Toast.LENGTH_SHORT).show()}}

生成后的代码：

private final class ActivityCImpl extends HiltApplication_HiltComponents.ActivityC {private final Activity activity;private volatile Object iLoginService = new MemoizedSentinel();.....省略private LoginServiceImpl getLoginServiceImpl() {return new LoginServiceImpl(ApplicationContextModule_ProvideContextFactory.provideContext(DaggerHiltApplication_HiltComponents_ApplicationC.this.applicationContextModule));}private ILoginService getILoginService() {Object local = iLoginService;if (local instanceof MemoizedSentinel) {synchronized (local) {local = iLoginService;if (local instanceof MemoizedSentinel) {local = getLoginServiceImpl();iLoginService = DoubleCheck.reentrantCheck(iLoginService, local);}}}return (ILoginService) local;}.....省略}

可以看到，此时getILoginService()单例方法定义在ActivityCImpl类中，那么此时iLoginService对象的生命周期就和Activity一样长，那么在子容器：View和Fragment中就和实现对象共享，达到单例的目的。

---

再来看另外一种场景：

@InstallIn(ApplicationComponent::class /*ActivityComponent::class*/)
@Module
abstract class MainModule {@Binds
//    @Singleton//去掉abstract fun bindService(impl: LoginServiceImpl): ILoginService
}interface ILoginService {fun login()
}class LoginServiceImpl @Inject constructor(@ApplicationContext val context: Context) : ILoginService {override fun login() {Toast.makeText(context, "LoginServiceImpl", Toast.LENGTH_SHORT).show()}}

生成后的代码：

DaggerHiltApplication_HiltComponents_ApplicationC.classprivate LoginServiceImpl getLoginServiceImpl() {return new LoginServiceImpl(ApplicationContextModule_ProvideContextFactory.provideContext(applicationContextModule));}

可以看到getLoginServiceImpl()虽然定义在DaggerHiltApplication_HiltComponents_ApplicationC类中，但每次创建不在是单例，而是会new一个新的，那么此时这个对象的生命周期和Application生命周期一样长吗？，答案是不是的，此时会和对象所在页面生命周期一样长。(对象不是单例，就和所在Acitvity/Fragment生命周期一样长，是单例，就和定义的Component一样长)

总结与疑问

至此整个Hilt的原理分析到此为止，源码分析不可能面面俱到。除了源码学习之前，还能学习到特别的单例创建，生命周期嵌套设计，构造器模式等等，可以在编写自己的代码时，起到借鉴的作用。
总结不如提出几个有意思的问题：

• 如何为主线程中的字段实现异步加载的依赖注入？
• @HiltApplication/@AndroidEntryPoint可以去掉吗？为什么？
• @Singleton和@ActivityScope能在同个Module共存吗？
• ARouter、Dagger2、Hilt对比依赖注入的实现方式的怎么样的，优缺点各是什么？如何选择？

以上问题可以通过网络，或是本文的理解，找出答案。分享会上会给我个人的见解