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