query.cachePolicy设置为CacheOnly,查询依然很慢。

查询的limit为20,不过有多个includeKey调用。

请教 2 个问题:

(1)SDK的cache机制是怎样的?disk only?还是disk & memory混合?

(2)SDK cache的是解析后的objects,还是每次读取cache时还需要去解析objects然后再给出最终结果?

我查到了Parse的相关资料: https://parse.com/questions/loading-from-disk-cache-is-slow

他们说可能是因为object解析花费时间,并建议将解析后的结果放到NSCache中。

我有空会去尝试一下的,不过还是希望 LeanCloud 的各位解释一下 SDK 的缓存机制。因为每次读cache很慢的话,是挺影响用户体验的。

你好,请问是 Android 还是 iOS ?

1) iOS SDK 不会将 AVQuery 的缓存放在内存中,原因是节省内存资源;
2) iOS SDK 会解析缓存中的 objects,对用户来说,接口返回的结果类型是一致的。

如果待查询的数据集很小,应该不会太慢。不清楚你说的慢是在毫秒级别,还是感觉与联网查询一样慢?如果是毫秒级别,建议将查询放在非主线程中去做,或者使用第三方 Cache 解决方案。如果是跟联网查询一样慢,看看是不是 SDK 的一个 bug。

感谢回复。

是ms级别的,0.6ms左右(query 的 limit 为 15,有 2 个 includeKey 调用)。

我已经放到非主线程中去做了,只不过在加载时页面会空白 0.6ms,用户会感知到。

我会去尝试第三方 Cache 解决方案的。

最后请问一下,Parse 目前是 memory & disk 混合的 cache 策略。( A while back we improved our query cache to be a hybrid disk and memory cache, which means finding the same query again should be faster. 见: https://parse.com/questions/loading-from-disk-cache-is-slow )。

想询问一下未来 LeanCloud 会不会考虑给 AVQuery 的缓存加上 memory 支持?因为对于追求极致 App 体验的 LeanCloud 用户来说,0.6ms 也算是比较长的一段时间了。

“原因是节省内存资源”,确实有这个问题,不过个人建议可以使用 NSCache,因为系统在低内存情况下会自动清除 NSCache 的内容,所以不用担心过多消耗内存资源。

以上,祝 LeanCloud 越办越好。

很好的建议,非常感谢你的建议!我们会在未来优化缓存策略,借鉴 Parse 和第三方的解决方案。