我的团队正在研究依赖注入框架，并试图在使用Google-Guice和PicoContainer之间做出决定。
我们希望从框架中获得以下几点：
非常感谢对这两个框架根据列出的标准进行比较。任何有助于比较这两个框架的个人经验也将非常有帮助。
免责声明：我在依赖注入方面相对新手，请原谅我如果我问了一个与此讨论无关的问题。
您可能希望将Spring加入您考虑的依赖注入框架列表中。以下是一些问题的答案:
Pico - Pico倾向于不鼓励使用setter注入，但除此之外，您的类不需要了解Pico。只有需要了解装配的部分需要知道（对于所有DI框架都是如此）。
Guice - Guice现在支持标准JSR 330注释，因此您不再需要在代码中使用Guice特定的注释。Spring也支持这些标准注释。Guice的开发人员认为，如果没有运行Guice注释处理器，这些注释不应该对您决定使用其他框架产生影响。
Spring - Spring旨在允许您避免在代码中提到Spring框架。因为他们有很多其他的帮助程序/实用工具等等，所以依赖Spring代码的诱惑相当强烈。
Pico - 我不太熟悉Pico的速度特性。
Guice - Guice被设计成快速的，参考文献中提到了一些数字进行比较。如果速度是主要考虑因素之一，应该考虑使用Guice或手动装配。
Spring - Spring可能会比较慢。已经有工作来加快速度，使用JavaConfig库可以提高速度。
Pico - 简单易配置。Pico可以为您做一些自动装配的决策。不清楚它如何适用于非常大的项目。
Guice - 简单易配置，只需添加注释并从AbstractModule继承以将其绑定在一起。随着配置最小化，适用于大型项目的规模扩展良好。
Spring - 相对容易配置，但大多数示例使用Spring XML作为配置方法。Spring XML文件随着时间的推移可能变得非常庞大和复杂，并且需要加载时间。考虑使用Spring和手工制作的依赖注入的混合来克服这个问题。
Pico - 小型
Guice - 中等规模
Spring - 大型
Pico - 我没有太多关于Pico的经验，但它不是一个广泛使用的框架，因此很难找到资源。
Guice - Guice是一个流行的框架，当你在开发中频繁重启大型项目时，它的速度优势是受欢迎的。我担心配置的分布式性质，即很难看到我们整个应用程序是如何组合在一起的。在这方面有点像AOP。
Spring - Spring通常是我的默认选择。话虽如此，XML可能会变得繁琐，导致速度变慢让人感到烦恼。我经常使用手工制作的依赖注入和Spring的组合。当您真正需要基于XML的配置时，Spring XML非常好用。Spring还投入了大量精力使其他框架更具有依赖注入友好性，这可能很有用，因为它们在这样做时经常使用最佳实践（JMS、ORM、OXM、MVC等）。
jamie.mccrindle提供的答案实际上非常好，但我感到困惑的是，既然有更优秀的替代品（Pico和Guice），为什么Spring是默认选择。 我认为Spring的流行已经达到了巅峰，现在它只是凭借所产生的炒作（以及所有其他“跟风”的Spring子项目）存活下来。
Spring唯一的真正优势是社区规模（而且坦白地说，由于规模和复杂性，它是必需的），但是Pico和Guice不需要庞大的社区，因为他们的解决方案更清晰、更有组织、更优雅。 Pico似乎比Guice更灵活（你可以在Pico中使用注释，也可以不用-它非常高效）。 （编辑：想说的是非常灵活而不是非常高效。）
Pico的微小大小和缺少依赖项是一个重要的胜利，这不应该被低估。现在要使用Spring需要下载多少兆字节？ 它是一个笨拙混乱的巨型jar文件，并带有所有依赖项。 直觉认为，这样一个高效而“小”的解决方案应该比类似Spring的东西具有更好的可扩展性和性能。 Spring的膨胀真的会让它更好地扩展吗？这是个怪异的世界吗？ 在证明（并解释）之前，我不会假设Spring“更具可扩展性”。
有时候创建一个好的东西（Pico/Guice），然后不要去加任何臃肿和厨房水槽功能，通过推出无尽新版本来实现真的很奏效...
注：这更像是一条评论/牢骚，而不是一个答案
PicoContainer很棒。如果他们修复了他们的网站，我将会切换回来。现在它真的很混乱：
我现在正在使用Guice 2.x，即使它更大并且拥有的功能更少。找到文档很容易，而且它的用户组非常活跃。但是，如果Guice 3的方向任何迹象表明，它看起来像是开始变得臃肿，就像Spring在早期一样。
更新：我给Pico Container的人留了一个评论，他们对网站进行了一些改进。现在好多了！
这是一个老问题，但现在你可以考虑在你的Android应用项目中使用Dagger (https://github.com/square/dagger)。
Dagger在编译时进行代码生成，因此您可以获得更短的启动时间和更少的内存使用。
虽然我喜欢 PicoContainer 的简单性和缺乏依赖性，但我建议使用 CDI，因为它是 Java EE 标准的一部分，所以您没有供应商锁定。
就其侵入性而言，其主要问题是需要容器，并且使用一个相对空的 META-INF/beans.xml 文件（必须指示 jar 正在使用 CDI）和注释的使用（尽管它们是标准的）
我用于自己的项目的轻量级 CDI 容器是 Apache Open Web Beans。 尽管需要一些时间来弄清楚如何创建一个简单的应用程序（不像 Pico），但它看起来像这样。
public static void main(final String[] args) {
final ContainerLifecycle lifecycle = WebBeansContext.currentInstance()
.getService(ContainerLifecycle.class);
lifecycle.startApplication(null);
final BeanManager beanManager = lifecycle.getBeanManager();
// replace Tester with your start up class
final Bean<?> bean = beanManager.getBeans(Tester.class).iterator()
.next();
final Tester b = (Tester) lifecycle.getBeanManager().getReference(bean,
Tester.class, beanManager.createCreationalContext(bean));
b.doInit();
}