之前学习很多的框架，我个人觉得学习框架的目的主要两点：
- 理解框架的原理，在实际开发中，才会得心应手，游刃有余。
- 学习框架的设计思想和技术亮点。我觉得这才是学习框架的最终目的，只有学到了东西，才算是对自己有提升。
今天，我写这篇文章主要是为了介绍我的第一个框架--Blade。Blade其实不是非常厉害的框架，就是基于APT技术开发的依赖注入框架，简称DI框架。
1. 概述
其实，熟悉Java开发的同学应该都知道，Google有一个非常著名的依赖注入框架--Dagger，那我为什么还要自己开发一个依赖注入的框架呢？俗话说，重复造轮子是对轮子最大的不尊重。
当然我也不是吃饱了撑的没事干(其实仔细想一想，还是有那么一点)，这里面是有一定的原因。最近，楼主做自己的毕业设计，想在自己的毕业设计中加上依赖注入的框架，使得写的代码更加简洁。介于这个原因，我去学习了Google爸爸的Dagger框架。在学习过程中，我发现Dagger的一个设计，就是它提供对象都是通过方法来实现的，这个与我的想法有点相悖(有可能还有其他方式可以实现，但是我不知道)。由于这个原因，我就狠下心，打算自己来写一个，自己想要什么都可以自己来实现，然后入坑了。。。
在这框架开发过程中，我借鉴了Dagger的部分思想。其实，我们可以从框架命名可以看出来，Dagger的中文意思是匕首，而Blade是剑的意思，看上去也是非常相似，以表示我对Dagger的尊重。
接下来，我将简单介绍一下Blade（其实就是将github的ReadMe拷贝过来）。
2. gradle 导入方式
(1). 项目的build.gradle
allprojects {
repositories {
// ······
maven { url 'https://jitpack.io' }
}
}
(2). app的build.gradle
dependencies {
// ······
implementation 'com.github.BeauteousJade.blade:inject:1.2.3'
annotationProcessor 'com.github.BeauteousJade.blade:processor:1.2.3'
}
3. 基本结构
在整个DI框架，有三个注解，分别是Module, Inject, Provides，先来解释这三个注解所表示的意思。
| 注解 | 含义 | 使用范围 |
|---|---|---|
| Module | 需要注入的对象所在类需要标记该类 | 比如A类内部有一个B类需要从外部(Context)注入进来，A类必须标记Module,其中Module注解带一个Class参数，表示从哪个Context对象注入。 |
| Inject | 如果一个变量需要注入，那么该变量会被标记Inject，表示注入的目标 |
比如上面的B类对象，必须标记Inject。该注解默认带一个String参数(可以不填)， 表示以此String字符串为id从注入源取得注入对象;不填表示默认以该对象的ClassName为id。因此，在同一个Module下，不能同时有两个相同类型的变量的Inject注解不填id。 |
| Provides | 如果一个变量需要被注入，该变量会标记Provides注解。需要被注入的变量必须放在一个Context（Object类型，也就是任意类型）里面；反之，如果一个类里面有一个变量标记了Provides注解，表示该类可以作为一个Context |
Provides默认带一个String参数，表示注入的id，跟Inject的参数相对应。 |
如果使用注解成功的标记我们想要被注入和注入的变量，我们可以在通过调用Blade的inject(Object target, Object source)方法进行注入操作的最后一步，也只有经过这一步，想要注入的变量才会成功赋值。如下是Blade的代码：
public class Blade {
public static void inject(Object target, Object source) {
String className = target.getClass().getName() + "_Inject";
try {
Object object = Class.forName(className).newInstance();
Class<?> clazz = object.getClass();
Method method = clazz.getMethod("inject", target.getClass(), source.getClass());
method.invoke(object, target, source);
} catch (ClassNotFoundException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
} catch (InstantiationException e) {
e.printStackTrace();
} catch (NoSuchMethodException e) {
e.printStackTrace();
} catch (InvocationTargetException e) {
e.printStackTrace();
}
}
}
这也是本框架唯一通过反射方式来实现的地方。
在编译器时期，APT会扫面每个被Module标记的类，然后对应着会生成一个Java类，上面代码的作用就是调用生成的Java类的inject方法进行赋值。下面是一个Demo代码：
public class MainActivity_Inject {
public void inject(MainActivity target, MainActivity.Context source) {
target.string = source.string;
target.a = source.a;
}
}
4. 基本使用
首先我们有一个类的有一些变量注入，比如MainActivity
@Module(MainActivity.Context.class)
public class MainActivity extends AppCompatActivity {
@Inject
String string;
@Inject
int a;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
Blade.inject(this, new Context());
}
// ······
}
这里需要注意两点：
MainActivity必须标记Module注解，同时Module注解必须传入注入源的Class对象。- 注入的变量需要标记
Inject
然后我们定义一个Context对象：
@Module(MainActivity.Context.class)
public class MainActivity extends AppCompatActivity {
// ······
public static class Context {
@Provides
String string = "string";
@Provides
int a = 1;
}
}
最后在调用Blade的inject方法。
Blade.inject(this, new Context());
整个注入过程就完成了。
5. 1.2.x新特性
(1).注入源传递
Provides注解新增一个deepProvides属性，默认为false。当deepProvides为true，表示当前注入的对象所在类的所注入对象可以作为当前注入对象所在Context的注入对象。形象的说，假设A类有一个里面B类对象被Provides注解标记，同时B类也是Context，如果deepProvides为true，B类的注入源可以通过A类找到，也就是，一个Module被标记在A类取得注入源，此时可以通过A类从B类中需要注入源。简而言之，就是深搜(广搜)思想。
例如，Context01的代码：
public class Context01 {
@Provides(deepProvides = true)
public Context02 context02;
@Provides("string")
public String string;
}
Context01内部有一个Context02对象，请注意我们将deepProvides为true。
然后我们来看看Context02的代码：
public class Context02 {
@Provides("string1")
public String string;
}
最后我们来看看注入部分：
@Module(Context01.class)
public class MainActivity extends AppCompatActivity {
@Inject("string1")
String string;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
Blade.inject(this, new Context01());
}
}
虽然我们的Module设置是从Context01里面获取注入源，但是Context01并没有id为string1的注入源，所以得从deepProvides为true的类里面去找，所以这里会在Context02里面找到。
我们可以将Context01称为父Context，Context02称为子Context。
注意点：
- 理论上来说，不同Context里面可以存在相同id的注入源。但是需要注意的是，由于框架遍历Context树采用的是广搜算法，所以在搜索时，找到的第一个相匹配id的注入源就会停止搜索。为了保证结果的正确性，在同一个Context树里面，id最好是具有唯一性，当然如果你能保证匹配正确，可以使用多id。
- 在构建Context树时，千万不要构成环路。也就是说，一个
子Context将父Context作为自己的注入源。这种情况是必须避免的。
(2). 类型向下转型
考虑到一种情况，就是在Java中，父类类型的引用可以引用子类的对象。在这种情况，注入源有可能是父类类型，但是注入目标是子类类型，如果不进行强转，会导致编译失败。所以从1.2.4开始，Blade支持类型向下转型。如下是使用例子。
首先定义一个Context类，里面有一个注入源，我们这里用Object引用：
public class Context {
@Provides(value = "string")
Object string = "pby";
}
然后有一个Module需要注入：
@Module(Context.class)
public class MainActivity extends AppCompatActivity {
@Inject("string")
String string;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
Blade.inject(this, new Context());
}
}
在Blade 1.2.4版本中，上面的代码是可以成功注入的，因为Blade会自动进行类型强转。
注意点：
- 如果想要支持类型强转，必须通过手动设置id来实现。因为APT在扫描注入源时，如果不提供id，默认会使用
className作为id，而注入源和注入目标的className在编译时期是不一样的，所以会导致注入失败。
6. github地址
github:blade