Dagger 文档显示了使用 aProvider<Filter>来获取Filter实例，这似乎很有意义。
我正在编写一个ListAdapter实例化视图，我希望 Dagger 注入它。我很想将 aProvider<ViewType>注入我的ListAdapter, 并调用mViewProvider.get()实例化视图。
但是，Dagger 文档说：
注入
Provider<T>可能会创建令人困惑的代码，并且可能是图形中范围错误或结构错误的对象的设计气味。通常你会想要使用 aFactory<T>或 aLazy<T>或者重新组织代码的生命周期和结构，以便能够只注入 aT
我可以看到如何以与使用辅助注射时所需的方式类似的方式使用工厂。
但是，考虑到我必须自己编写前者，使用我自己Factory<T>的比使用 Dagger's 有什么优势？Provider<T>
Provider<T>在系统中有非常具体的含义。它是 Graph 管理对象的委托构造函数。 Provider<T>有特定的保证/行为，我通常建议不要注入Provider<T>，除非你支持一些需要它的遗留情况。
Factory<T>是一个例子 - FooFactory 更准确，因为这样做的目的是您不使用手动工厂，而是使用AutoFactory（http://github.com/google/auto）之类的东西来生成创建对象的工厂。然后您不必编写自己的文档，但AutoFactory在编写这些文档时尚未构建。
归根结底，原因主要是代码清晰和长期维护。使用 dagger 的实例管理作为事实上的实例工厂是可能的，但受到限制，因为它只能与注入依赖项的实例一起使用。如果不添加另一个范围或图形层，就无法支持调用堆栈依赖项。在 Guice 中，这一事实经常导致人们使用额外的范围来将调用堆栈依赖关系塞入对象实例（供应）依赖关系中，方法是玩自定义范围的游戏并复杂化他们的对象图和分层以获得一些免费代码。
为了解决这个问题，创建了（在 guice 中）Assisted-Injection 和（在 Dagger 中）AutoFactory - 这样您就可以做更语义更清晰的事情，而不依赖于框架内部，而是自动为您完成。
不使用Provider<T>是一种意见。如果您愿意，您可以自由地这样做，但不建议这样做。相反，我们推荐一种解决方案，例如AutoFactory获得更好的命名类型，在您的系统中具有更清晰的含义，可以支持更灵活地处理调用堆栈状态。