我有几个关于自定义范围的问题：
【问题讨论】：
完成您需要的最简单的方法是创建一个应用程序级组件，希望您提供每种类型的演示者。问题是您将在同一级别上拥有所有项目的所有类，这有点难看。 好的方法是为一个注入当前活动/片段的依赖项的活动创建一个模块
使用@ActivityScope 或任何其他方法只是表明模块的生命周期与@Singleton 不同，只要它不是单例，就认为您的模块将与创建它的活动相同。
【讨论】：
这是否意味着我必须为每个活动创建一个单独的模块/组件？
是的。没有。
至少如果你想提供活动范围的依赖项，你需要为每个活动创建一个新组件对象，比如Activity本身，@ 987654322@，或类似的东西，因为范围将与活动一样长。
您的每一项活动是否都需要一个模块和组件的问题在很大程度上取决于您的架构。您还可以创建一个通用的ActivityModule，提供您可以重复使用的模型、演示者和视图。
您也可以只使用一个Component，例如如果只需要活动的基本依赖项，例如LoaderManager 或Activity 本身，那么您可以编写一个ActivityModule 来提供这些基础对象。然后，您可以将此模块与您的组件一起使用来提供依赖项。
如果您的 Presenter（及其依赖项）可以通过构造函数注入创建，您可以使用单个组件和模块来处理所有活动。
如果您的演示者和视图是已实现的接口，则您需要创建一个提供实际实现的模块。
如果我仍然负责创建和释放这些依赖项，自定义范围注释的目的是什么？
作用域用于使管理这些依赖关系更容易。如前所述，活动范围随着活动被破坏而死亡。通过拥有这些范围依赖，您可以确保没有任何东西依赖于具有更高范围/生命周期并可能导致内存泄漏的活动。
另外，我喜欢将其视为可以热交换并“丢弃”的依赖包。一个很好的例子是@UserScope，它将保存用户数据、他的登录信息、会话数据……
如果我切换用户，我只需要在用户范围或更少的范围内丢弃所有内容（关闭活动，删除 UserComponent），并且与用户有关的所有内容都消失了。下一个可以登录，副作用风险低。
范围主要是编译时检查，帮助您将层次结构引入依赖项，因为编译器所做的只是检查其中没有循环，并且没有任何东西从它可以请求的范围请求依赖项'访问。
【讨论】：