为什么 dagger 被认为比 Guice 更适合 AWS lambda 实现?

hat*_*lla 7 guice amazon-web-services aws-lambda dagger-2

我知道 dagger 通过生成代码在编译时创建注入,因此它的性能优于 Guice,后者在运行时进行注入。但特别是对于 lambda 的情况,我看到它在多个地方提到 Dagger 是首选。是因为冷启动问题吗?

由于 lambda 中的冷启动问题,当长时间收到请求时,lambda 会不断进行多次引导。那么,使用 dagger,与 Guice 相比,引导会快得多,因为它已经有了生成的代码?我是说与延迟加载相比,Guice 中的所有对象是否也在引导期间创建。

Mat*_*ope 17

正如您已经知道的那样,任何依赖注入框架在某些时候都需要为您的应用程序所需的对象构建某种依赖关系图。构建此图通常是 DI 框架中计算成本最高的部分。

Guice 通过在运行时使用反射来计算出这个图。Dagger 在编译时生成表示依赖图的代码。我不知道哪个更快,但我知道使用反射会导致不小的性能损失。

然而,最大的区别是 Dagger 在编译时完成所有繁重的工作(这意味着你只做一次工作,不管你运行多少次),而 Guice 必须在每次应用程序启动时做同样的工作。

现在,要回答您的问题,如果您的应用程序频繁启动和停止,则首选 Dagger。对于像移动应用程序这样的东西,较慢的启动时间通常只会降低用户体验。使用 Lambda,它不仅会减慢冷启动时间,而且由于您需要为代码运行的时间付费,因此不断重建依赖图实际上会花费更多的钱。

TLDR;Dagger 在 Lambda 上是首选(就冷启动时间和成本而言),因为它将 DI 框架中最昂贵的部分移到编译时而不是在运行时执行。