gpt4 book ai didi

android - AsyncTaskLoader 是如何缓存数据的?

转载 作者:搜寻专家 更新时间:2023-11-01 09:06:08 25 4
gpt4 key购买 nike

我有一个 Activity 实现了所有这些代码所在的 fragment 。由于代码是 secret 的,因此最好通过示例对此进行解释。这个例子反射(reflect)了正在尝试做的事情以及我通过测试观察到的事情

ex.) 我有一个 rss 阅读器 fragment ,它从两个具有加载器 ID(加载器 1、加载器 2)的唯一加载器中获取两个唯一对象(A、B)

Object A: 

int[] fullArticleIdList;
List<ArticlePreview> partialArcticlePreviewList;

Object B:

List<ArticlePreview> partialArcticlePreviewList;

在创建时,我在加载器 1 上调用“initloader”,它获取对象 A。在滚动浏览可用文章后,它到达从对象 A 返回的 partialArcticlePreviewList 的底部,并在加载器 2 上使用“restartloader”获取更多文章,它获取对象 B 和允许用户阅读它们并继续对所有文章执行此操作。

在用户旋转设备从而调用 onCreate 之前,此方法工作正常。现在,当在 Loader 1 上调用 initloader 时,它会在连接到 loader 1 后立即跳转到 onLoadFinished 并返回一个 Loader 1。虽然正确返回了 articleId,但返回的 partialArcticlePreviewList 是从 Loader 2 获取对象 B 的那个。

加载器管理器是否只在缓存中保留对象的一个​​实例并在多个加载器之间共享?从广泛的测试(5 个多小时试图找到问题并查看 Eclipse 调试器中的加载器 ID/缓存/地址)来看,它似乎用加载器 2 的 partialArcticlePreviewList 中收到的数据覆盖了加载器 1 的 partialArcticlePreviewList。虽然这种情况对于单个加载器来说是理想的,但我认为每个加载器的缓存都是独立的。显然,加载器的优势之一是它们易于使用,并且通过屏幕旋转和数据缓存实现持久化,但它似乎并没有像暗示的那样工作。我们通过保留 fragment 的一个实例并在 onCreateView 和 onDestroyView 中编写适当的代码来避免内存泄漏来规避这个问题,但这是一个好的解决方案吗?

编辑:忘记添加了,我们正在使用兼容性库 v4。此外,查看加载程序的 android 源代码似乎并没有说明加载程序为何返回错误数据的情况,因为它是“mId”。

最佳答案

用于规避此问题的最终解决方案是简单地自己管理数据而不依赖加载程序。

当加载器只为屏幕加载一个东西时,加载器可以很好地保留数据,但对于分页,它们会造成所有这些麻烦,而且它们的操作方式仍未得到很好的理解;结论是它们没有按预期运行,或者我们的实现有问题,这只有在更高级的用例中才会变得明显。

为了自己管理数据,我们使用了 bundle/retaining fragments 的组合,同时小心地在 onDestroyView 中正确清理所有内容。我们还让加载程序在旋转后执行回调时检查我们的数据集是否已经有数据,因此我们不会将分页数据两次添加到我们的数据集中。另一种选择是使用单例对象。

希望这对以后的其他人有帮助。

关于android - AsyncTaskLoader 是如何缓存数据的?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/11787031/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com