Android技术栈(三)依赖注入技术的探讨与实现

//一个简单的工厂类,包含一个工厂方法test
public class Factory
{
public static Bean test(String text)
{
Log.d(“test”,text);
return new Bean();
}
}

public class Bean
{
public float field;

public String string;

Object object;

public void setObject(Object object)
{
this.object = object;
}

@Override
public String toString()
{
return super.toString() + “\n” + field + “\n” + object + “\n” + string;
}
}

• 使用JavaBean

代码还是上面的代码,只不过这次加了点东西,factory,builder,new定义了对象的构造方式,我们还可以用field和property标签在对象生成后为对象赋值,通过name属性指定要赋值给哪个字段或属性,property所指定的name应该是一个方法,它的命名应该符合Java的setter标准,比如name="abc",对应void setAbc(YourType)方法

• 将val转换为var

我知道每次重复写字面值很蠢,所以提供了val转换为var的方法,让字面值可以像var一样被ref使用

复制代码

• 完整的xml

最后在这里提一点无论是factory还是builder都不允许返回null值,默认导入的null只是为了兼容某些特殊情况而设计的,factory和builder返回null是没有意义的.

<?xml version="1.0" encoding="utf-8"?>

6.生命周期和对象所有权

如果说Android开发中影响范围最广泛的概念是什么，我想那一定就是生命周期了。

因为你会发现几乎什么东西都能跟生命周期扯上关系，在组件创建的时候订阅或请求数据，并一定要记得在组件销毁的时候取消订阅和清理数据，要不然你就等着内存泄漏和迷之报错吧。

还有一个和生命周期有关联的词，那就是对象所有权.

如果Activity或者Service引用了Application的资源，这很合理，因为Application的生命周期比Activity要长，不必担心内存泄漏，但如果Application引用了Activity的资源，这就有点不合理了，因为Activity可能随时被杀掉，而Application的生命周期又比Activity长，这就容易造成本该在Activity中释放的资源一直被Application持有，进而造成内存泄漏,所以Application不应该有Activity或者Service上资源的对象所有权。

所以Liteproj从一开始就设计成和组件的生命周期绑定在一起,并制定了合理的对象所有权。

Liteproj支持对5组件进行依赖注入:

• Application,无特殊要求,会在attachBaseContext之后与onCreate之前执行依赖注入
• Activity,至少是FragmentActivity(AppCompatActivity继承了FragmentActivity)
• Service,需要继承Liteproj的org.kexie.android.liteproj.LiteService
• Fragment,继承appcompat的Fragment即可
• ViewModel,需要继承Liteproj的org.kexie.android.liteproj.LiteViewModel

可以看到Liteproj的倾入性还是很低的,除了Service和ViewModel需要强制继承基类,其他组件的基本上都无需代码改动.

图是用ProcessOn画的:

Service和Activity可以使用Application的xml配置文件,因为Application的生命周期比Service和Activity都长,同理Fragment可以使用Activity的xml配置文件,而ViewModel由于不能违背MVVM的设计原则(ViewModel不应该知道他是与哪一个View进行交互的),所以除了自己能使用自己的xml配置文件之外只允许它使用Application的xml配置文件.

在Liteproj中各种组件的依赖都由DependencyManager进行管理,可以通过DependencyManager.from(owner)获得该实例的DependencyManager.

可以通过DependencyManager#get(String name)主动获取xml中定义的依赖,也可以使用隐式装配(下面马上介绍).

当一个依赖的名字在本组件的DependencyManager找不到的时候,DependencyManager就会把请求转发到上层的DependencyManager中,比如在Activity中找不到某个依赖时,就跑到Application上去找(但前提是你的Activity的@Using注解中引用了Application的依赖配置文件).

DependencyManager与组件的生命周期绑定,在组件生命周期结束时,会释放自己占有的所有资源.

7.隐式装配

在继续对比Dagger和Spring两者依赖注入的行为中，我发现Spring有一个Dagger没有的优点，那就是在依赖注入中的一个设计原则,即一个对象不应该知道自己的依赖是何时、怎样被注入的。

为了实现这个功能,我编写了一个ContentProvider作为框架的初始化器(仿照Android Jetpack Lifecycle包的做法),ContentProvider可以在Application的attachBaseContext之后与onCreate之前对框架进行初始化,并对Application进行依赖注入,自此,Liteproj终于大功告成.

现在,你只需要使用@Reference注解,然后填入名字就可以就可以给自己的组件进行依赖注入了,@Reference注解与xml中的ref作用基本一致,但是你将value留空的时候,它可以使用属性名或字段名进行自动装配.

@Retention(RUNTIME)
@Target({FIELD, METHOD})
public @interface Reference
{
String value() default “”;
}

就好比这样(所有代码都来自Github的Demo中):

@Using({R.xml.all_test})
public class MainActivity extends AppCompatActivity
{
private static final String TAG = “MainActivity”;

@Reference(“request”)
Request request;

@Reference(“bean”)
Bean bean;

@Reference(“holder”)
AppHolderTest holderTest;

@Override
protected void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
Logger.d(request + “\n” + bean + “\n” + holderTest.context);
}
}

直接运行你的APP,就可以看到这些对象居然都被自动设置好了,对的,不需要自定义的Application类,也不需要你去调用奇怪的init方法再传入一个Context实例.

与JSR-330相比,Liteproj只有@Using和@Reference这两个注解,这样是不是简单多了?

8.发布到jitpack.io

一切代码都编写完成后最后一步当然就是把它发布到在线的maven仓库了,这里我选择了jitpack.io,因为它实在是太方便了有木有,它与Github高度集成,发布一个自己的类库甚至都不需要你登录账号.

在根项目的build.gradle中添加

buildscript {

repositories {
google()
jcenter()
}
dependencies {
classpath ‘com.android.tools.build:gradle:3.2.0’
// ↓↓↓↓↓↓↓↓↓↓↓↓ 加这行! 加这行! ↓↓↓↓↓↓↓↓↓↓↓↓
classpath ‘com.github.dcendents:android-maven-gradle-plugin:2.1’

// NOTE: Do not place your application dependencies here; they belong
// in the individual module build.gradle files
}
}

然后继续在你要发布的模块的build.gradle的头部添加

apply plugin: ‘com.android.library’
//↓↓↓↓↓↓↓↓↓↓↓↓ 加这行! 加这行! ↓↓↓↓↓↓↓↓↓↓↓↓
apply plugin: ‘com.github.dcendents.android-maven’
//↓↓↓↓↓↓↓↓↓↓↓↓ 加这行! 加这行!并且group改成你想要的 ↓↓↓↓↓↓↓↓↓↓↓↓
group=‘org.kexie.android’

然后Look up

在log中查看编译log,点击get it即可开始在jitpack上编译你的项目

如果成功

allprojects {
repositories {
…
maven { url ‘https://www.jitpack.io’ }
}
}
dependencies {
implementation ‘com.github.LukeXeon:Liteproj:+’
}

你就可以用gradle远程依赖了.

如果失败,你就得注意一下classpath 'com.github.dcendents:android-maven-gradle-plugin:2.1'这个插件了,不同的gradle版本有对应不同的插件版本,笔者的gradle是4.10.1,具体版本对应可以在这里查看.

9.Liteproj的缺点

我每次写文章,我总会在写便了xxx的好处后的倒数第二个标题总结xxx的缺点，当然我也不会放过我自己写的库。（我认真起来连我自己都盘，盘我！）

如你所见Liteproj还是一个很年轻的依赖注入框架，如果你要将它用到商业项目中,可能需要辛苦你测试一下它有没有一些坑之类的(逃…不过好在咱是开源的对吧,代码其实也就1-2k也不多)。

其次，Liteproj没有使用注解处理器来在编译时处理注解，而是依赖纯反射，而且它还需要解析xml,虽然只会解析一次,之后xml文件中的依赖信息就会转换为内存中的数据结构,下次再使用这个xml配置文件就是直接使用内存中已经加载好的数据了,且在xml解析时也使用了多线程来进行优化,尽最大的可能减少了主线程的等待时间,但这依然可能会带来一些微小的效率问题。

10.结语

写这篇文章时，Liteproj基本上已经稳定，欢迎到我的github去star或fork，如果你在使用的过程中发现了问题，可以给我issue，或者直接给我发一个pull request。

【附】相关架构及资料

资料及源码领取

点赞+加群免费获取 Android IOC架构设计

领取获取往期Android高级架构资料、源码、笔记、视频。高级UI、性能优化、架构师课程、NDK、混合式开发（ReactNative+Weex）微信小程序、Flutter全方面的Android进阶实践技术

结语

• 现在随着短视频，抖音，快手的流行NDK模块开发也显得越发重要，需要这块人才的企业也越来越多，随之学习这块的人也变多了，音视频的开发，往往是比较难的，而这个比较难的技术就是NDK里面的技术。
• 音视频/高清大图片/人工智能/直播/抖音等等这年与用户最紧密，与我们生活最相关的技术一直都在寻找最终的技术落地平台，以前是windows系统，而现在则是移动系统了，移动系统中又是以Android占比绝大部分为前提，所以AndroidNDK技术已经是我们必备技能了。
• 要学习好NDK，其中的关于C/C++，jni，Linux基础都是需要学习的，除此之外，音视频的编解码技术，流媒体协议，ffmpeg这些都是音视频开发必备技能，而且
• OpenCV/OpenGl/这些又是图像处理必备知识，下面这些我都是当年自己搜集的资料和做的一些图，因为当年我就感觉视频这块会是一个大的趋势。所以提前做了一些准备。现在拿出来分享给大家。

加入社区》https://bbs.csdn.net/forums/4304bb5a486d4c3ab8389e65ecb71ac0
都是需要学习的，除此之外，音视频的编解码技术，流媒体协议，ffmpeg这些都是音视频开发必备技能，而且

• OpenCV/OpenGl/这些又是图像处理必备知识，下面这些我都是当年自己搜集的资料和做的一些图，因为当年我就感觉视频这块会是一个大的趋势。所以提前做了一些准备。现在拿出来分享给大家。

[外链图片转存中…(img-rjGuQidM-1725734792767)]

[外链图片转存中…(img-9UNhV9ET-1725734792768)]

加入社区》https://bbs.csdn.net/forums/4304bb5a486d4c3ab8389e65ecb71ac0