我假设
LoginComponent和
MenuComponent分别使用，例如
LoginActivity和中
MenuActivity。每个组件都是内置的
Activity.onCreate。如果是这样，则每次创建新活动，模块和依赖项时，都会重新创建组件，而与它们绑定的范围无关。因此，你得到的新情况
MainProvider和
AccountManager每一次。
MenuActivity并且
LoginActivity具有单独的生命周期，因此
MailModule两者的依赖关系不能都是单例的。你需要的是申报根组件与
@Singleton范围（例如，在应用程序子类），化妆
MenuComponent和
LoginComponent依赖于它。活动级别组件不能@Singleton范围，最好使用
@Scope注释创建自己的范围，例如：
@Retention(RetentionPolicy.RUNTIME)@Scopepublic @interface MenuScope {}或者，您可以不加限制。
关于范围，以下是最初Dagger 2提案的简要说明：
@Singleton@Component(modules = {…})public interface ApplicationComponent {}该声明使dagger可以执行以下约束：
- 给定的组件只能具有未限制范围或声明的作用域的绑定（包括类的作用域注释）。即，一个组件不能代表两个范围。如果未列出作用域，则绑定只能是无作用域的。
*范围内的组件只能具有一个范围内的依赖项。这是强制两个组件不要各自声明自己的作用域绑定的机制。例如，每个都有自己的@Singleton缓存的两个Singleton组件将被破坏。- 组件的范围不得出现在其任何传递依赖项中。例如：SessionScoped-> RequestScoped->
SessionScoped没有任何意义，是一个错误。- @Singleton被特别对待，因为它不能具有任何范围内的依赖项。每个人都希望Singleton是“根”。
这种规则组合的目的是要强制实施范围时，组件的结构与我们以前使用Dagger 1.0
plus（）的ObjectGraphs所具有的结构相同，但具有对所有对象的静态知识的能力。绑定及其范围。换句话说，当应用范围时，这将图的可构建范围限制为仅可正确构建的图。
根据我自己的实践，很明显根本不使用
@Singleton。取而代之的是，我使用
@ApplicationScope。它用于在整个应用程序上定义单例，并且没有其他限制
@Singleton。
希望对您有帮助:)。快速理解是很棘手的，需要时间，至少对我来说是这样。
