之前写了几篇关于dagger2的基础介绍,使用方式以及源码分析，最后准备写一篇关于dagger2的使用扩展.
dagger2提供了很多修饰符
@scope（作用域）
在这里记录我的源码分析结果验证结果,按照上一篇案例我在
@Singleton
public class DemoPresenter
Presenter类上加上Singleton修饰，然后我们跑一下代码可以看到Inject注入的二个对象的地址一模一样！
QQ截图20170612180852.png
现在去掉这个修饰符再跑下看看结果
QQ截图20170612181028.png
可以看到Singleton是完全有创建单例能力的啊,并且我的Component是在MainActicity中初始化的,现在再创建一个SecondActivity生成对象试试,
public class SecondActivity extends AppCompatActivity implements BaseView {
@Inject
DemoPresenter mDemoPresenter;
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.second_layout);
DaggerCompnoent.builder().module(new Module(this)).build().inject(this);
Log.e("wwwSecondDemoPresenter2",mDemoPresenter.toString());
}
@Override
public void setXxx(Person p) {
}
}
简单写下代码
QQ截图20170612182849.png
现在MainActivity中二个注入的对象地址一模一样的我们跳转到SecondActivity看下生成对象地址
QQ截图20170612183105.png
咦?我特么以为地址会一模一样怎么跳一下界面地址就变了,带着大大的疑问我决定去看看源码？所谓知己知彼百战不殆嘛
@SuppressWarnings("unchecked")
private void initialize(final Builder builder) {
this.getBaseViewProvider = Module_GetBaseViewFactory.create(builder.module);
this.demoPresenterProvider =
DoubleCheck.provider(DemoPresenter_Factory.create(getBaseViewProvider));
this.mainActivityMembersInjector = MainActivity_MembersInjector.create(demoPresenterProvider);
this.secondActivityMembersInjector =
SecondActivity_MembersInjector.create(demoPresenterProvider);
}
这里之前看过源码分析的已经很清楚了就不多说了,
MainActivity_MembersInjector
SecondActivity_MembersInjector
都是一个工厂类里面创建对象,然后inject会调用对象中的injectMembers然后把demoPresenterProvider.get生成的presenter对象注入进去
DoubleCheck.provider(DemoPresenter_Factory.create(getBaseViewProvider));
之前分析的时候好像没有DoubleCheck这个玩意,貌似加了个Singleton就多出个这DoubleCheck.provider( );
点进去看看是什么
/** Returns a {@link Provider} that caches the value from the given delegate provider. */
public static <T> Provider<T> provider(Provider<T> delegate) {
checkNotNull(delegate);
if (delegate instanceof DoubleCheck) {
/* This should be a rare case, but if we have a scoped @Bind that delegates to a scoped
* binding, we shouldn't cache the value again. */
return delegate;
}
return new DoubleCheck<T>(delegate);
}
里面接收DemoPresenter_Factory对象,把DemoPresenter_Factory传到DoubleCheck构造参数中,然后返回这个对象，我们看看DoubleCheck的get方法做了什么
@SuppressWarnings("unchecked") // cast only happens when result comes from the provider
@Override
public T get() {
Object result = instance;
if (result == UNINITIALIZED) {
synchronized (this) {
result = instance;
if (result == UNINITIALIZED) {
instance = result = provider.get();
/* Null out the reference to the provider. We are never going to need it again, so we
* can make it eligible for GC. */
provider = null;
}
}
}
return (T) result;
}
其实DoubleCheck就是个代理类,它进行一系列判断后调用DemoPresenter_Factory的get方法生成p对象,
我们前面MainActivity生成的对象一模一样就是因为在MainActivity中
Compnoent只生成一次,而注入对象时调用的就是我们上面分析的代理类DoubleCheck的get()方法,通过分析代码可以知道只要Compnoent对象不变,那么它永远只调用一次get()方法生成一次对象.这里可以解释之前MainActivity生成单例的错觉了,因为我们Compnoent只生成过一次！！！
@Override
public void injectMembers(MainActivity instance) {
if (instance == null) {
throw new NullPointerException("Cannot inject members into a null reference");
}
instance.mDemoPresenter1 = mDemoPresenter1AndMDemoPresenter2Provider.get();
instance.mDemoPresenter2 = mDemoPresenter1AndMDemoPresenter2Provider.get();
}
至于为什么SecondActivity生成的又不一样了，SecondActivity跟MainActivity完全是二个不同对象,生成的Compnoent成员变量自然在二个对象的堆地址中,所以生成的p对象当然不相同了~
这也是Singleton最坑的地方,让我们误以为加上这个注释就具有单例的能力
QQ截图20170612191006.png
我在MainActivity中再生成一次compnoent，前面分析如果
compnoent不变那么compnoent生成的对象就会一直不变,如果它的地址改变了,那么生成的对象地址也会改变。我们看看是不是这样
QQ截图20170612191245.png
可以看到第一次注入的二个对象都是第一个compnoent生成的对象是相同的跟我们前面分析的也一致，下一步我们看看第二个compnoent生成的对象
QQ截图20170612191355.png
由结果可以看到确实跟我们分析的一样compnoent变了生成的对象地址同样变了！
所以我们加上Singleton注解生成的那段代码我的理解是在compnoent不变的情况下保证compnoent生成的对象永远一样！所以compnoent单例还是需要我们自己做的, Singleton同样需要添加的！
@Qualifier （限定符）
这个注解作用与当我们@provide提供了多个返回相同对象的方法时,dagger懵比了,它并不知道选择哪一个进行返回,这个时候我们用@inject注解就会编译错误
QQ截图20170612201335.png
那怎么办呢？？？这个时候Qualifier就派上用场了
@Provides
@Named("name1")
public DemoPresenter provideDemoPresenter1(){
return new DemoPresenter(mBaseView);
}
@Provides
@Named("name2")
public DemoPresenter provideDemoPresenter2(){
return new DemoPresenter(mBaseView);
}
比如这段代码中,我提供了二个都返回DemoPresenter对象的方法,我们这个时候需要使用限定符进行标识，@Named是Qualifier 默认实现的一个注解,这里把方法一表示为name1，方法二标识为name2，我们在需要依赖的地方使用
@Inject
@Named("name1")
DemoPresenter mDemoPresenter2;
这样就依赖上方法一返回的对象了~当然你也可以自己自定义一个Qualifier
@Qualifier
@Documented
@Retention(RUNTIME)
public @interface Named {
/** The name. */
String value() default "";
}
我们看Named怎么定义的，自定义只需要改变Named命名就可以了
接下来看看Lazy用法,
@Inject
Lazy<DemoPresenter> mDemoPresenterLazy;
使用Lazy这个接口注入我们的对象,泛型中存放我们的presenter对象类型,然后运行代码,dagger会帮我们module中生成的p对象存放到我们上面提到过的DoubleCheck类中我们翻下源码
@Override
public void injectMembers(MainActivity instance) {
if (instance == null) {
throw new NullPointerException("Cannot inject members into a null reference");
}
instance.mDemoPresenterLazy = DoubleCheck.lazy(mDemoPresenterLazyProvider);
}
继续看看DoubleCheck中lazy方法
/** Returns a {@link Lazy} that caches the value from the given provider. */
public static <T> Lazy<T> lazy(Provider<T> provider) {
if (provider instanceof Lazy) {
@SuppressWarnings("unchecked")
final Lazy<T> lazy = (Lazy<T>) provider;
// Avoids memoizing a value that is already memoized.
// NOTE: There is a pathological case where Provider<P> may implement Lazy<L>, but P and L
// are different types using covariant return on get(). Right now this is used with
// DoubleCheck<T> exclusively, which is implemented such that P and L are always
// the same, so it will be fine for that case.
return lazy;
}
return new DoubleCheck<T>(checkNotNull(provider));
}
可以看到返回了一个DoubleCheck对象,
public final class DoubleCheck<T> implements Provider<T>, Lazy<T>
它实现了Lazy接口,这个时候我们如果调用get方法就会返回p对象,这个过程在上面已经分析了源码过程。
最后再看一个Provider用法
@Inject
Provider<DemoPresenter> mDemoPresenterProvider;
这玩意也非常简单,就是把生成p的工厂类对象直接给我们,我们调用get就会调用工厂类的get方法生成p对象
@Override
public DemoPresenter get() {
return Preconditions.checkNotNull(
module.provideDemoPresenter1(), "Cannot return null from a non-@Nullable @Provides method");
}
好了dagger的扩展使用全部介绍完毕,整个系列算是告一段落~~~
网友评论