到底该如何理解<依赖注入>
模版代码:食之无味,弃之可惜
public class MainActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
TextView mTextView=(TextView) findViewById(R.id.mTextView);
mTextView.setOnClickListener(new OnClickListener() {
@Override
public 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;
@Autowired
public model model
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
ButterKnife.inject(this);//运行时view注入
Arouter.getInstance().inject(this)//运行时参数注入
}
@Click(R.id.text)
void buttonClick() {
}
}
ButterKnife原理:
- 编译时按照命名规则生成相应实现类,编织好findViewById的代码
- 运行时根据MainActivity的类名找到编译生成的实现类,反射构建实例,并调用inject方法触发findViewById
//ButterKnife自动findViewById
class ButterKnife_MainActivity<MainActivity> implements Inject{
@Override
public void inject(MainActivity activity){
activity.textView =activity.findViewById(R.id.text)
}
}
ARouter原理:大致相同,详情参考:ARouter简明扼要原理分析 :
//arouter的参数自动提取
public class MainActivity$$ARouter$$Autowired implements ISyringe {
@Override
public 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
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:User
fun 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'
//Hilt
id 'kotlin-kapt'
id 'com.google.dagger.hilt.android'
}
android {
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility 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() {
//声明该对象需要被动态注入
@Inject
lateinit var emptyView: EmptyView
override 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 context
val 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
@Provides
fun provideGeneralLoginServiceImpl(): ILoginService {
//note 这么写没问题,或是外界generalLoginService.password = 123456 用这种方式赋值属性
// 但与在构造方法中传入参数相比,这样就少了 传入的强制性和直观性
return LoginServiceImpl("General")
}
@VipLoginServiceImpl
@Provides
fun provideVipLoginServiceImpl2(): ILoginService {
return LoginServiceImpl("Vip")// 这样写是不行的 会报错
}
// @VipLoginServiceImpl
// @Provides
// fun provideVipLoginServiceImpl2(account:String): ILoginService {
// return LoginServiceImpl(account)// 这样写是不行的 可以。但改如何注入这个参数呢?会不会过于复杂呢 hint:参数包装进方法里
// }
@Provides
fun vipLoginServiceAccount():String{
return "Default"//这个是给 iLoginService使用的
}
}
@AndroidEntryPoint
class EmptyFragment : Fragment() {
@Inject
@JvmField//note 需要外界重新赋值这个加上这个注解
var iLoginService: ILoginService? = null
@Inject
@MainModule.GeneralLoginServiceImpl
lateinit var generalLoginService: ILoginService
@Inject
@MainModule.VipLoginServiceImpl
lateinit var vipLoginService: ILoginService
override 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(): WorkService
companion 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 10
invoke-super {p0}, Lorg/ggxz/kotlin/hiltsourcecode/Hilt_HiltApplication;->onCreate()V
.line 11
return-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 15
invoke-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() {
@Override
public Object get() {
return DaggerHiltApplication_HiltComponents_ApplicationC.builder()
.applicationContextModule(new ApplicationContextModule(Hilt_HiltApplication.this))
.build();
}
});
protected final ApplicationComponentManager componentManager() {
return componentManager;
}
@Override
public final Object generatedComponent() {
return componentManager().generatedComponent();
}
@CallSuper
@Override
public 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() {
@Override
public Object get() {
return DaggerHiltApplication_HiltComponents_ApplicationC.builder()
.applicationContextModule(new ApplicationContextModule(Hilt_HiltApplication.this))
.build();
}
});
- ApplicationContextModule是Hilt自动生成的类,其本身也是@Module类型,用来保存和对外提供Application/Context,当被注入的对象标注@ApplicationContext注解,Hilt会为其自动注入ApplicationContext参数。
- 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
}
)
@Singleton
public 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
@jvmFiled
var data:List<City>?=null
}
@module
@InstallIn(ActivityComponent::Class)
object MainModule{
@Providers
fun 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
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
inject();
super.onCreate(savedInstanceState);
}
@Override
public 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));
}
@Override
public ViewModelProvider.Factory getDefaultViewModelProviderFactory() {
...省略
}
Hilt_MainActivity的核心代码也不多。
- 首先在上面我们分析过,Hilt会讲MainActivity的父类,动态替换成Hilt_MainActivity。此时在onCreate()内,super.onCreate(savedInstanceState)之前调用inject()进行注入,所以并不是不需要注入的代码,而是Hilt帮我们完成了。
- 而要想完成注入,必须借助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()方法:
@Override
public 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 改成 @ActivityScoped
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()
}
}
生成后的代码:
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.class
private 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对比依赖注入的实现方式的怎么样的,优缺点各是什么?如何选择?
以上问题可以通过网络,或是本文的理解,找出答案。分享会上会给我个人的见解