Android依赖注入框架选型

ゞ浴缸里的玫瑰 2022-10-01 06:50 128阅读 0赞

说到Android依赖注入框架，网上比较推崇的是google维护的Dagger2框架，使用依赖注入可以带来以下好处： 1、依赖的注入和配置独立于组件之外。2、因为对象是在一个独立、不耦合的地方初始化，所以当注入抽象方法的时候，我们只需要修改对象的实现方法，而不用大改代码库。3、依赖可以注入到一个组件中：我们可以注入这些依赖的模拟实现，这样使得测试更加简单。Dagger2可以免去在每个使用类的地方都使用构造函数构造一个实例，使用@Inject注解可实现类实例的依赖注入，依赖的构建分别支持@Provide、@module注解，用于构建自定义的类和第三方类，并使用@Scope注解来声明依赖的作用域，可以跟acitvity的声明周期绑定在一起，在需要的地方自动实现单例模式。写到此处可见Dagger2框架提供的功能很强大，可以帮助我们的代码进行很好的解耦，但是如果把他实施到具体的项目当中，你会发现事情并没有想象中那么便利，而且我们的工作量增加了：

应用中每个页面的需要依赖注入的地方都需要写一份模板代码来实现，比较繁琐。而且如果我们的项目是多module工程，需要创建很多Component类，不能放到library中去实现，因为这会涉及到module工程循环引用的问题。我们平时开发的工作量主要来源于业务需求，需要创建很多新的页面，这时候不仅仅要考虑代码怎么做到低耦合，代码的高内聚也是很重要的，这有助于减少代码量和测试的工作量。由此想到是否可以把依赖注入的过程放到Activity或者Fragment的基类中去实现，比如将MVP代码框架里面的presenter放到基类中去注入，我们去实现每个具体的页面的时候去扩展这个基类即可，不需要再在每个扩展类中去写这些模板代码。 RoboGuice是一种比Dagger使用更简易的依赖注入框架，他不需要定义各种Component注射器，直接通过 RoboGuice.getInjector()就可以拿到注射器，支持视图、资源、系统服务、对象等注入，并且可以通过注解来实现单例模式，基本能实现dagger提供的功能，非常适合MVP框架，可以在Activity或者Fragment的基类去实现presenter的注入：

笔者非常推荐大家使用这套框架！ 如果项目使用kotlin语言则有更多的选择，kodein框架是一个不错的选择：

只要在你的Module中绑定需要的实例构造方法，在需要用到该实例的页面通过by instance()的调用去实现依赖的检索：

更多用法可以上 [官网][Link 1]查看： [github demo][]

转载于:https://juejin.im/post/5cd7b55cf265da036902b54e

[Link 1]: https://link.juejin.im?target=http%3A%2F%2Fkodein.org%2FKodein-DI%2F%3F5.2%2Fandroid%23_being_kodeinaware
[github demo]: https://link.juejin.im?target=https%3A%2F%2Fgithub.com%2FKodein-Framework%2FKodein-DI%2Ftree%2F5.2%2Fdemo%2Fdemo-android