Volley CacheDispatcher

最新推荐文章于 2022-02-12 13:01:47 发布

原创最新推荐文章于 2022-02-12 13:01:47 发布 · 331 阅读

0 ·

CC 4.0 BY-SA版权

焦虑同时被 3 个专栏收录

12 篇文章

订阅专栏

volley源码

10 篇文章

订阅专栏

犯困

1 篇文章

订阅专栏

本文探讨了一种请求处理机制，该机制通过缓存队列和网络队列的协调工作来提升用户体验。当请求到达时，系统首先尝试从缓存中获取数据；若缓存未命中，则将请求放入网络队列等待进一步处理。文章还讨论了为何采用这种复杂的流程而非直接进行网络请求的原因，旨在避免显示过期数据。

不断地从mCacheQueue中取出请求，然后到cache中区找，如果不命中则加入到mNetworkQueue队列中让另一个去处理，如果命中，那么分两种情况，不需要刷新就直接 mDelivery.postResponse(request, response);如果需要刷新就

 mDelivery.postResponse(request, response, new Runnable() {
                        @Override
                        public void run() {
                            try {
                                mNetworkQueue.put(request);
                            } catch (InterruptedException e) {
                                // Not much we can do about this.
                            }
                        }
                    });

不明白为什么要这么麻烦不直接 mNetworkQueue.put(request);大概是为了防止网络请求先执行，返回了新的response delivery之后，旧的response又delivery将新的覆盖，结果显示的还是过期的数据，不过，经过网络请求后又delivery得数据会比直接delivery的数据块吗？，除非线程被堵塞了而网络请求有特别快的完成了，我觉得这种情况出现的几率应该很小