是否有必要在Android项目中使用IOC框架?
本来只是想找个注解库用一下
结果顺便看了看相关的库
首先是
butterknife https://github.com/JakeWharton/butterknife
在任何项目中使用butterknife都是正确且没有问题的. 非常轻量级的库.
可以缩减一部分代码.
其次是
Dagger https://github.com/square/dagger
Dagger其实和butterknife一样也是 JakeWharton 写的, 算是一家的产品吧.
View binding注解部分和butterknife几乎一致.可以认为没有区别.
Dagger额外提供了 IOC框架 功能
最后是
RoboGuice https://github.com/roboguice/roboguice 和
google guice https://github.com/google/guice
RoboGuice在View Binding上和以上2个库没有区别
也额外提供了 IOC框架功能
它和 Dagger 的区别是
RoboGuice 是 运行时 通过反射实现的IOC
Dagger 是通过 APT(Annotation Process Tool) 在运行时 生成辅助类 实现的 IOC
参考了一些分析资料
https://github.com/android-cn/android-open-project-analysis/tree/master/dagger
又翻了一下Spring中使用IOC的例子...
IOC的核心是解耦...
解耦的目的是 .... 修改耦合对象时不影响另外一个对象...降低模块之间的关联
在Spring中IOC更多的是依靠 xml的配置...
而以上Android上的IOC框架均不使用xml配置系统....而且也没有必要....
毕竟不是web要去考虑server/system/db/web容器的差异...
常见的例子..
public class MainActivity extends Activity {
@Inject Boss boss;
...
}
就看 扔物线 写的这个例子好了..
对于这个设计而言...谁被解耦了?
我认为MainActivity和Boss被解耦了.....更确切的讲....MainActivity和Boss的构造方法解耦了...
如果你下面需要使用Boss对象,仍然需要调用Boss中的方法...那么Boss和MainActivity依然存在依赖关系..
好处是,我修改Boss的构造方法不会影响MainActivity了...我可以修改Provider去自己获取参数..
Android中 Activity 一般不会参与复用..你不会去再写一个Activity继承MainActivity,也不会去生成多个MainActivity....即使同时存在多个MainActivity实例也是归系统管理..和你没有关系.... 所有通常我认为只有Boss是会复用的会变化的会被继承的...MainActivity的变化只和它自身有关系,不会影响系统中其它部分..
仔细思考,即使是在IOC框架中,耦合性也并没有消失,只是将耦合的部分从 Class之间转移到了 Class和IOC容器之间
回到上面这个部分...
你觉得 Activity 在 Android app中 处于 一个什么角色??
Activity不能充当容器角色么?
UI / 业务逻辑 / DB / Conection / Cache
所有组件都只和Activity产生依赖关系,互相之间互不影响....
在Activity外再嵌套一层IOC容器来解耦偶到底有无必要?
Activity为什么还需要解耦?
画一下2个模型图
我觉得本质上没有区别?
我构造一个场景
Activity需要做请求网络的操作,操作完成后写DB和Cache,IOC给你注入一个 HttpMananger / DBManager / CacheManager 又如何,你不要调用它们的方法吗? 耦合性并没有降低啊？
这么做也一方面是为了让代码写的更加优雅，可维护性更加好。
cache = container.get('cache')
至于这个cache的implementation是什么，你无需关心，这就是解耦
如果你没有container.get('cache')，cache init代码就在activity里面
如果你要修改cache implementation，如果没有container，你是不是要一个个activity改过去？
场景：服务器没开发完…
IHttp 接口
MockHttpImpl 随便实现一下，返回个值
HttpImpl 等服务器开发完了再实现
这样就不用等服务器开发了
Dagger等IOC框架一般配合MVP等设计模式使用。
IOC框架可以很好地解决大项目里，构造函数膨胀、依赖过于复杂等问题。
所以你举这例子不太妥当，建议看一下Dagger2作者做的那个演讲，有提到IOC解决什么问题和如何解决这些问题。