我正在Android中使用Dagger 2和Repository模式，并且因为存储库的依赖关系以及使用它们的权衡，我应该使用哪个范围来绊倒。
通常我会为每个功能创建一个存储库。因此，如果我们谈论注册功能，那么我将创建一个RegistrationRepository。 RegistrationRepository将有3个不同的数据源，RegistrationNetworkSource，RegistrationDiscSource和RegistrationMemorySource。当我的Activity向RegistrationRepository发出请求时，repo将创建一个RxJava observable并将其返回给activity。然后，活动可以订阅observable并等待结果。如果在observable返回结果之前活动恰好经历了配置更改，那么可以将observable缓存在一个作用于应用程序生命周期的单独类中，并且在重新创建活动之后，它可以获取此缓存的observable并重新订阅它。这就是我的困惑开始的地方。如果我的observable被缓存在一个范围为应用程序范围的类中，那么这意味着还需要将3个存储库数据源限定在应用程序范围内吗？
我的直觉告诉我，我应该将它们范围扩展到应用程序范围。这样做将允许每个源执行长时间运行的数据获取任务，即使请求来自的Activity经历配置更改，该任务也可以继续。每个应用程序都有一个实例，它们始终可供使用。听起来不错，但这最终会浪费资源吗？如果注册是我的应用程序的第一个屏幕，并且用户将剩余的时间花在HomeActivity或其他地方，那么为什么3个注册数据源仍然存在呢？
答案 0 :(得分：1)
这个问题与你的previous question非常相似，但似乎有一些未解决的疑问。
首先，我建议您阅读范围在this question的答案中的工作原理。总而言之，范围没有任何神奇之处，它们可以帮助您推断从组件创建的对象的生命周期。您从组件生成的依赖项的实例将存在于您维护对它们的引用的位置。通常，您将维护对单个活动中@PerActivity组件注入的依赖项的引用。例如，如果您的@PerActivity CoffeeComponent有CoffeeModule：
@Provides
@PerActivity
public CoffeeMaker coffeeMaker(HotWater hotWater, Beans beans) {
return new DefaultCoffeeMaker(hotWater, beans);
}
然后，您通常希望您获得的CoffeeMaker实例遵循单个活动的生命周期。但是，如果您使用其中一个CoffeeMaker实例并在Application类中维护对它的引用，那么该实例将一直存在，直到应用程序被销毁。
让我们尝试将此问题应用于您的问题：
如果我的observable被缓存在一个范围为应用程序范围的类中，那么这意味着还需要将3个存储库数据源限定在应用程序范围内吗？
不，存储库数据源可以作为范围@PerActivity，您可以维护对Observables @PerApplication处@Singleton的引用范围。此处的其他Dagger 2答案已经讨论过使用Holder模式。简而言之，您可以创建一个单例类，它能够在应用程序范围级别存储Observables的结果。使用RegistrationNetworkSource发出请求时，可以使Holder订阅，接收和缓存结果。您的活动可以从Holder获取待处理结果，而不是直接订阅Observable中的RegistrationRepository。
需要考虑的其他一些问题：
长期运行的网络请求在配置更改后需要多长时间？考虑使用类似DownloadManager
{4}不是比Dagger 2和Rx-Java Observable更适合您的用例吗？请注意以下装载机的文档：
加载程序会在配置更改中保持并缓存结果，以防止重复查询。