如此一来，OkHttpClient的回调也被引导到我们的Callback上来，整个流程就已经走通了。
总结
终于到了总结的时候了，一般来说，这都是干货的时候，哈哈～
Volley对比优势
1.缓存处理；Volley自己就提供了一套完整的缓存处理方案，默认使用文件存储到磁盘中，并且提供了TTL SOFTTTL这么体贴入微的机制；一个Request可能存在两个Response,对于需要显示缓存，再显示网络数据的场景真是爽的不要不要的。而Retrofit中并没有提供任何和缓存相关的方案。
2.代码简单，可读性高。Volley的代码是写的如此的直接了当，让你看起代码来都不需要喝口茶，这样的好处是我们我们需要修改代码时不太容易引入bug....囧
同一个请求如果同时都在发送，那么实际上只会有一个请求真正发出去， 其它的请求会等待这个结果回来，算小小优化吧。实际上这种场景不是很多哈，如果有，可能是你代码有问题...
请求发送的时候提供了优先级的概念，但是是只保证顺序出去，不保证顺序回来，然并卵。
支持不同的Http客户端实现，默认提供了HttpClient和HttpUrlConnection的实现，而Retrofit在2.0版本之后，锁死在OkHttp上了。
3.支持请求取消
Retrofit
1.发送请求真简单，定义一个方法就可以了，这么简单的请求框架还有谁？Volley?
2.较好的可扩展性，Volley中每一个新建一个Request时都需要指定一个父类，告知序列化数据的方式，而Retrofit中只需要在配置时，指定各种转换器即可。CallAdapter的存在，可以使你随意代理调用的Call，不错不错。。。
3.OkHttpClient自带并发光环，而Volley中的工作线程是自己维护的，那么就有可能存在线程由于异常退出之后，没有下一个工作线程补充的风险(线程池可以弥补这个缺陷)，这在Retrofit中不存在，因为即使有问题，这个锅也会甩给OkHttp，嘿嘿
4.支持请求取消
再次说明的是，Retrofit没有对缓存提供任何额外支持，也就是说它只能通过HTTP的Cache control做文件存储，这样就会有一些问题：
1.需要Server通过Cache control头部来控制缓存，需要修改后台代码
2.有些地方比较适合使用数据库来存储，比如关系存储，此时，Retrofit就无能为力了
3.缓存不在我们的控制范围之内，而是完全通过OkHttp来管理，多少有些不便，比如我们要删除某一个指定的缓存，或者更新某一个指定缓存，代码写起来很别扭(自己hack请求头里面的cache contrl)
而在我们项目的实际使用过程中，缓存是一个比较重要的角色，Retrofit对缓存的支持度不是很好，真是让人伤心。。。
