当我调用injectbaseActivity（this）时，它“告诉”匕首说所有@Inject注释都是我的类的依赖项，然后它在我的项目中搜索与该类型匹配的@Inject带注释的构造函数？
究竟。但这在您调用时还没有完成
injectbaseActivity，而是全部在编译时发生。这是 注释处理的 一种方式（另一种在运行时使用反射）。
在构建项目时，您在build.gradle文件中包含（作为依赖项）的dagger-annotation-
processor将被调用，并带有注释所
@Inject注释的所有字段，类等的列表，并以此构建依赖关系图。然后，它解析该图，生成提供该图上项目所有依赖项的源代码。
injectbaseActivity只需执行之前生成的代码，并将所有依赖项分配给您的对象。它是正确的源代码，您可以阅读和调试。
简而言之，这是编译步骤的原因是性能和验证。（例如，如果您有一些依赖周期，则会出现编译错误）
匕首如何知道我的AuthControllers是baseActivity的依赖项？
@InjectAuthController authController;
通过注释字段
@Inject匕首，您知道您想要一个
AuthController。到目前为止，一切都很好。现在，匕首将寻找一些提供控制器的方法，在组件，组件依赖项和组件模块中寻找它。它还将查看是否可以单独提供该类，因为它
知道 其构造函数。
如果您不将dagger包含在任何模块中，它将如何得知对象构造函数？
@Injectpublic AuthController(Context context) { }通过使用inject注释构造函数，您还告诉dagger有一个名为的类，
AuthController并且需要实例化它。它与将其添加到模块中基本相同。
@Provides如果您没有将
@Inject批注添加到构造函数的源代码，或者对象需要进一步的初始化，则应使用模块方法。或者就你而言…
[…]模块文件可用作我的依赖项树的“文档” […]
是的，您当然可以这样做。但是随着项目的增长，您将必须维护 许多 不必要的代码，因为在构造函数上使用简单的注释也可以完成相同的操作。
在构造函数中使用@Inject批注或在Modules文件中添加@Provides方法时，是否有最佳实践？
如果要为不同的上下文提供不同的版本（例如，以2种不同的方式实现接口），则还可以使用
@Binds注释来告诉dagger您希望提供哪个类作为实现。
除此之外，我相信您应该尽可能使用构造函数注入。如果有什么变化，您不必接触代码的任何其他部分，并且只需编写较少的代码，因此可以减少包含错误的位置。
此外，Dagger可以而且确实可以通过了解更多信息来进行很多优化，并且，如果您实现了不必要的代码，则它必须与您引入的开销一起工作。
当然，最终取决于您的最佳想法。毕竟， 您 必须使用 您的 代码;）
