Java 为每个活动创建子组件-良好实践？

我刚开始学习Dagger，我想将其融入我的应用程序中，在阅读了大量文章后，我开始以以下方式使用Dagger：

@ApplicationScope
@Component(modules = [ApplicationModule::class])
interface ApplicationComponent {
    fun addMainActivitySubComponent() : MainActivitySubComponent
}

@Module
class ApplicationModule {
    @ApplicationScope
    @Provides
    fun provideBigClass() = BigClass()
}

对于每项活动：

@ActivityScope                                         
@Subcomponent(modules = [SomeModule::class])      
interface MainActivitySubComponent {                   
    fun inject(activity: MainActivity)                 
    fun inject(activity: HomeFragment)                 
}  

---

为每个活动创建一个子组件是一种良好的做法，还是我做错了什么？

为每个活动声明单独的组件根本不是一个好主意。这背后的原因很简单——你并不真的需要所有这些模块/组件（正如你自己已经看到的）

但是，只有一个组件与

应用程序的生命周期相关联，并将其注入所有
活动中也不是最佳解决方案（这是您朋友的方法）。它不是最优的，因为：

它仅将您限制在一个范围内（
@Singleton
或自定义范围）
您被限制的唯一作用域使注入的对象成为“应用程序单例”，因此作用域中的错误或作用域对象的不正确使用很容易导致全局内存泄漏
您可能也希望使用Dagger2来注入
服务
，但是
服务
可能需要与
活动
不同的对象（例如
服务
不需要演示者，没有
碎片管理器
，等等）。通过使用单个组件，您失去了为不同组件定义不同对象图的灵活性
因此，每个
活动的一个组件是一种过分的杀伤力，但是整个应用程序的单个组件不够灵活。最佳解决方案介于这两个极端之间（通常是这样）

我采用以下方法：

提供“全局”对象的单个“应用程序”组件（例如，持有全局状态的对象，在应用程序中的所有组件之间共享）。在
应用程序中实例化

“应用程序”组件的“控制器”子组件，提供面向所有用户的“控制器”所需的对象（在我的体系结构中，这些对象是
活动
和
片段
）。在每个
活动
和
片段
中实例化

“应用程序”组件的“服务”子组件，提供所有
服务所需的对象。在每个
服务中实例化