Retrofit配置及各情况处理

1、Retrofit创建

2、Retrofit实现Cookie自动化管理

3、Retrofit，Gson解析，请求返回的类型不统一，假如double返回的是null

4、请求参数日志打印

5、统一请求参数添加到请求头中

6、统一请求参数添加到请求body中

7、缓存的拦截器

8、BaseUrl动态切换

9、拦截指定接口，动态更改返回值便于测试

点击传送查看

点击传送查看

1第一种办法，依赖第三方库

配置信息如下

2第二种办法，拦截器拦截（个人推荐第二种，可控性高）

给大家推荐一个打印日志库，很漂亮的日志结构

然后在>

这里之所以叫Retrofit客户端。客户端提供的子系统有：

1serviceMethodCache(自定义的接口映射对象集合)

2baseUrl(请求地址)

3callFactory(默认为Ok>

retrofit中有什么注解 ，但是对于@body网上讲解不是很多，现在我们来分析下@body

首先我们要明白的是后台传参数的方式最常用的分为了get与post，get的参数是跟在url后面的，但是post的参数是放在请求体里面传给后台的，但是两种方式传表单数据的话，传给后台的参数字符串是一样的，只是get跟在url后，post放在请求体里面的，参数的形式都是以

这样的方式传参的，但是还有一种就是传json数据，get跟post都是把json放在body中传送给后台的。

retrofit一般传表单的数据是这样的：

底层自动封装成一个请求体，并通过这个注解来把这些参数封装成一个参数字符串传给后台！

如果是传json的话是这样的：

与上边的区别就是没得了@FormUrlEncoded来标志是表单数据，并且用的@body 里面的参数就是java中的bean对象！

这是最常用的两种方式，但是对于参数过多的表单数据按照第一种方式来写的话工程量有点大，有没得一种像post提交json这样的方式来提交表单数据呢？

别急，方法是这样的，也是使用@body：

注意这里照样没有@FormUrlEncoded，而且@body后面跟的是请求体，相当于我们直接给后端传一个我们自定义的请求体，而不用retrofit注解来用底层封装，但是这个传的RequestBody要进行自己封装，加上参数必须的=，&符号，像下边这样：

封装数据这样封装：

封装RequestBody这样封装，把上边的HashMap<String, String>包装的参数传进来：

再把返回的这个RequestBody传入到上边的方法中，这样就实现了传递post表单的方法！

其实get中的有 @GET("weather/index")

也可以通过@QueryMap 来提交大量数据，这里就不过多说了

以上就是关于Retrofit配置及各情况处理全部的内容，包括:Retrofit配置及各情况处理、Retrofit 进阶：Converter 的原理及使用【附 Retrofit 流程】、retrofit原理详解等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！