Say Hello to Retrofit

喜欢ヅ旅行 2022-07-16 09:22 143阅读 0赞

转载地址：http://blog.csdn.net/ghost\_programmer/article/details/52372065

在正式开始了解  Retrofit 的使用之前，我们有必要先了解一个概念，即  RESTful。这是因为 Retrofit 的初衷就是根据 RESTful风格的API 来进行封装的。

关于  RESTful 的学习，可以参考一下：

《RESTful API 设计指南》

> http://www.androidchina.net/3749.html

相信看完之后，就会对  Restful 有一个基本的认识和理解了。

但我们这里可以对 RESTful 的核心思想做一个最简练的总结，那就是：所谓”资源”，就是网络上的一个实体，或者说是网络上的一个具体信息。那么我们访问API的本质就是与网络上的某个资源进行互动而已。那么，因为我们实质是访问资源，所以 RESTful 设计思想的提出者Fielding认为：

URI 当中不应当出现  动词，因为”资源“表示一种  实体，所以应该用  名词 表示，而动词则应该放在HTTP协议当中。那么举个最简单的例子：

xxx.com/api/createUser
    xxx.com/api/getUser
    xxx.com/api/updateUser
    xxx.com/api/deleteUser

这样的API风格我们应该很熟悉，但如果要遵循 RESTful 的设计思想，那么它们就应该变为类似下面这样：

[POST]xxx.com/api/User [GET] xxx.com/api/User [PUT]xxx.com/api/User [DELETE]xxx.com/api/User

也就是说：因为这四个API都是访问服务器的 USER表，所以在 RESTfu l里URL是相同的，而是  通过HTTP不同的RequestMethod来区分增删改查的行为。

而有的时候，如果某个API的行为不好用请求方法描述呢？比如说，A向B转账500元。那么，可能会出现如下设计：

POST /accounts/1/transfer/500/to/2

在RESTful的理念里，如果某些动作是HTTP动词表示不了的，你就应该把动作做成一种资源。可以像下面这样使用它：

POST /transaction HTTP/1.1 Host: 127.0.0.1 from=1&to=2&amount=500.00

好了，当然实际来说RESTful肯定不是就这点内容。这里我们只是了解一下RESTful最基本和核心的设计理念。

#  #

从官方介绍初识Retrofit

当我们要去学习一样新的技术，还有什么是比官方的资料更好的了呢？所以，第一步我们打开网址：

> http://square.github.io/retrofit

然后开始阅读，我们发现官方的介绍非常简单粗暴，一上来就通过一个  Introduction 来展示了如何使用 Retrofit 来进行一个最基本的请求。下面我们就逐步的分析一下：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1][]

从上图中，我们首先注意到了一个关键的说明信息：Retrofit会将你的HTTP API转换为Java中的interface的形式。OK，接着看：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 1][]

这里我们读到的描述是：Retrofit类 可以针对之前 定义的interface 生成一个具体实现。我们发现官方对此解释的很言简意赅，但更通俗的来讲的话：

也就是说虽然我们之前将此次请求的API信息封装为了一个接口，但我们也知道Java中接口是不能产生对象的，这时Retrofit类就站出来扮演了这个角色。

我们可以将Retrofit类看作是一个“工厂类”的角色，我们在接口中提供了此次的“产品”的生产规格信息，而Retrofit则通过信息负责为我们生产。

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 2][]

这里我们看到了一个重要的东西“Call”：通过之前封装的请求接口对象创建的任一的Call都可以发起一个同步（或异步）的HTTP请求到远程服务器。

之后说了一些通过注解来描述request的好处，然后这个简单的Introduction就结束了。那么，现在我们来简单总结一下，目前为止我们的感受如何。

我觉得就仅从以上简单的介绍当中我们起码有两点直观感受：那就是解耦明确；使用简单。通过注解的方式描述request让人眼前一亮。但与此同时：

我们发现读完Introduction后，仅仅是这个基本的用例中，都仍然有很多小细节需要我们通过实际使用之后才能搞明白。这可能在一定程度上说明了：

为什么说Retrofit的使用门槛相对于其它库来说要更高一些。不过没关系，我们自己先来写一个比官方Introduction更简单的用例，再逐步深入。

#  #

写第一个Demo碰坑

已经阅读完了官方的用例介绍，乍看之下没什么，但实际用起来说不定就得碰坑。为方便测试，仍然通过 servlet 在本地简单的实现服务器。

我们现在的设想可能是这样的，我只是想要写一个demo来测试一下用 Retrofit 来成功发起一次最基本的 get请求，所以最初的 doGet 无比简单：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 3][]

完成了以上代码的编写，然后我们把该servlet的URL配置一下，言简意赅的，就配置为“/api/retrofitTesting”好了。这时服务器就准备完毕了。

很显然，下面我们就可以把焦点放在Android客户端的实现上来了。为了使用 Retrofit，所以我们的第一步工作自然就是在自己的项目中  设置依赖：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 4][]

配置好了依赖，接着我们就可以开始编码工作了。还记得官方用例的第一步吗？所以我们要做的显然是模仿它也把我们自己的HTTP API封装成interface。

public interface DemoService {
       
        @GET("api/retrofitTesting")
        Call<ResponseInfo> testHttpGet();
    }
    // GSON - BEAN class ResponseInfo {
       
        String describe;
    }

现在我们再来看这个所谓的API接口，可能就更加明确一点了。首先是通过  注解@GET 来声明本次请求方式为GET以及注明API-URL。

而就之后声明的方法来说：从其为 Call 的返回类型不难猜想多半与请求的发起有关，因为如果我们对 OkHttp 有所了解的话，一定就记得下面这样的代码：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 5][]

newCall方法 实际就是返回一个Call类型的实例。而  Retrofit 中的Call接口相对于  OkHttp 添加了一个泛型，该泛型用于说明本次请求响应的数据解析类型。

那么这里的泛型为什么是我们自己建立的一个实体类呢？其实回忆一下之前服务器在 response 中返回的内容(JSON)，就不难猜想到与GSON有关。

好的，我们继续按照官方用例中接下来的步骤去完善我们的demo。封装好了interface，接下来自然就是调用了，最终的代码如下：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 6][]

有了之前的说明并对照官方示例，现在会发现以上代码很容易理解。而我们发现官方没有给出的step4其实也很熟悉，因为它和OkHttp的使用是相同的。

这个时候看上去我们的准备工作就已经完成了，于是兴致勃勃的编译并运行demo来查看一下效果，却发现收到了如下的一个异常：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 7][]

为什么会出现这种情况呢？蛋疼啊！别急，通过异常信息的描述，我们得知这似乎与类型的转换相关，然后带着这个疑问再去查看官方文档，于是发现：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 8][]

从上述信息我们得知 Retrofit 默认只能将响应体转换为 OkHttp 中的 ResponseBody，而我们之前为 Call 设置的泛型类型是自定义的类型 ResponseInfo 。

将JSON格式的数据转换为 Java-BEAN，很自然就会想到GSON。而 Retrofit 如果要执行这种转换是要依赖于另一个库的，所以我们还得在项目中配置另一个依赖：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 9][]

之后，在构造Retrofit对象的时候加上一句代码就可以了：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 10][]

这个时候，当我们再次运行程序就没问题了，成功的得到如下的日志打印：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 11][]

现在，经过我们的一番摸索和折腾，关于Retrofit很基本的第一个demo就捣鼓出来了。

其实这是有意义的，因为回想一下会发现：现在我们对于Retrofit大致的使用套路，在心里已经有个一二三了。

#  #

回到官方文档继续学习

前面我们说到对于Retrofit的使用已经有了一个基本的认识和了解，接下来要做的自然就是深入和继续学习更多的使用细节。那么很显然，回到官方吧。

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 12][]

事实上前面我们已经使用到了  注解@GET，这里就是告诉我们这种注解其实对于HTTP其它常用的请求方式(GET,POST,PUT,DELETE等等)都封装了。

而对于  @GET 来说，我们知道HTTP-GET是可以将一些简单的参数信息直接通过URL进行上传的，所以URL又可以像下面那样使用：

@GET("api/retrofitTesting?param=value")

## replacement blocks与@path    ##

不知道大家注意到官方示例和我们刚才自己测试写的demo中有一个细小的差别没，就是下面这样的东西：

//官方的 @GET("users/{user}/repos")
    //我们的 @GET("api/retrofitTesting")

我们注意到官方的API的URL中有一个”\{user\}“这样的东西？它的作用是什么呢？我们也能在官方文档上找到答案：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 13][]

从上述介绍中，我们注意到一个叫做  replacement blocks 的东西。可以最简单的将其理解为路径替换块，用”\{\}”表示，与  注解@path 配合使用。

当然我们自己实际去使用一下能够对其有一个更加深刻的理解，所以我们将我们之前的demo修改一下，变成下面这样：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 14][]

使用的方式也会有所不同，我们在调用的使用需要将对应的值传给  responseInfo 方法。

Call<ResponseInfo> call = service.testHttpGet("retrofitTesting");

这样修改过后的实际效果实际上与我们之前的demo是一样的，那么这样做的好处是什么？显然是为了解耦。以官方的例子来说：

“https://api.github.com/users/\{user\}/repos”中的\{user\}就是为了针对不同的github用户解耦。因为这里假设代入我的github，URL就将变成：

“https://api.github.com/users/RawnHwang/repos”。而github的用户千千万万，如果使用我们之前的方式代码就会如下：

@GET("users/RawnHwang/repos")

这二者的优劣一目了然，我们肯定不会想要为了获取不同的user的repos去写N多个套路完全相同的API - interface吧。

## @Query ##

前面我们讲到：对于@GET来说，参数信息是可以直接放在url中上传的。那么你马上就反应过来了，这一样也存在严重的耦合！于是，就有了 @query。

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 15][]

同样，为了便于理解，我们仍然自己来实际的使用一下。就用我们之前的举到的例子好了，这里我们用 @query 来替换我们之前说到的如下代码：

@GET("api/retrofitTesting?param=value")

替换为：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 16][]

调用的时候改为：

Call<ResponseInfo> call = service.testHttpGet("value");

然后就可以在服务器查看是否成功接收到参数了：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 17][]

## @QueryMap ##

聪明的你现在肯定还不满足，因为可能有这样的疑问：假设我要在参数中上传10个参数呢？这意味着我要在方法中声明10个@Query参数？当然不是！

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 18][]

我们看到了，Retrofit也考虑到了这点，所以针对于复杂的参数上传，为我们准备了@QueryMap。现在来修改我们自己的demo：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 19][]

调用的时候自然也发生了变化：

Map<String,String> params = new HashMap<>();
    params.put("param1","value1");
    params.put("param2","value2");
    Call<ResponseInfo> call = service.testHttpGet(params);

## @POST ##

有了之前的基础，现在我们免不了要捣鼓一下 POST。相信有了 @GET 的使用经验，如果只是想发发简单的 POST请求 是没有多大的难度，我们关注下 POST的BODY，即请求体的使用技巧。

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 20][]

通过官方文档，我们发现出现了一个新的东西叫做“@Body”，顾名思义它就是用来封装请求体的。而同时通过后面的“User”参数类型，我们不难推断出：使用  @Body 时，是通过实体对象的形式来进行封装的。那么闲话少说，我们当然仍旧是自己动手来试一下：

首先，我们编写一下 servlet 的 doPost 方法，假设我们这里提供一个新建 User 的API。完成后为该POST-request配置一个新的API URL，我们这里配置为：“/api/users”。然后，在Android端编写一个新的interface，大致如下：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 21][]

这样其实就搞定了，是不是很简单。然后我们通过如下代码去调用测试就行了：

Call<ResponseInfo> call = service.uploadNewUser(new User("tsr","male",24));

这里唯一需要说明的就是，通过 @BODY 这种方式封装请求体，Retrofit 是通过JSON的形式来封装数据的。我们可以在服务器读取流中的数据打印：

{
       "name":"tsr","gender":"male","age":24}

我单独额外说明一下这个的初衷是因为：这种情况以servlet来说，通过如下的形式是读取不到的对应的参数值的（返回null），需要自己解析。

//输出为null System.out.println(request.getParameter("username"));

## @FormUrlEncoded ##

这时有的朋友就说了，那我要是就想要通过request.getParameter的方式直接读取参数信息呢？没关系，也是可以的，使用  @FormUrlEncoded 搞定。

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 22][]

其实通过这个注解的命名，我们就很容易联系到 HTTP Content-Type 中的 application/x-www-form-urlencoded：而其实在服务器打印Content-Type的话，会发现的确如此。也就是说，其实使用该注解过后，正是通过表单形式来上传参数的。

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 23][]

然后是依旧是调用，这时服务器就可以通过request.getParameter直接读取参数了：

Call<ResponseInfo> call = service.uploadNewUser("tsr","male",24);

当然，这个时候难免又会想起那个老梗：要写这么多的 @Field 参数？当然不是，也有@FieldMap 供我们使用，使用方法参照 @QueryMap

## @Headers与@Header ##

使用了 @FormUrlEncoded 之后，不知道你有没有好奇一下，假设我们的参数中含有中文信息，会不会出现乱码？让我们来验证一下：

Call<ResponseInfo> call = service.uploadNewUser("张德帅","male",24);

这里上传的 username 信息是中文，而在服务器读取后进行打印，其输出的是“?????·???”。没错，确实出现乱码了。

这个时候我们应该如何去解决呢？当然可以通过 URLEncode 对数据进行指定编码，然后服务器再进行对应的解码读取：

String name =  URLEncoder.encode("张德帅","UTF-8");
    Call<ResponseInfo> call = service.uploadNewUser(name,"male",24);

但如果了解一点 HTTP协议 的使用，我们知道还有另一种解决方式：在 Request-Header 中设置 charset 信息。于是，这个时候就涉及到添加请求头了：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 24][]

关于  @Headers 的使用看上去非常简单。那么，接下来我们就来修改一下我们之前的代码：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 25][]

通过 @Headers 我们在 Content-type 中同时指明了编码信息，再次运行程序测试，就会发现服务器正确读取到了中文的信息。

除了@Headers 之外，还有另一个注解叫做  @Header。它的不同在于是动态的来添加请求头信息，也就是说更加灵活一点。我们也可以使用一下：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 26][]

## 读取response header ##

通过上面的总结我们知道通过 @Header 可以在请求中 添加header，那么我们如何去读取响应中的 header 呢？我们会发现官方文档并没有相关介绍。

那么显然我们就只能自己看看了，一找发现对于 Retrofit2 来说 Response类 有一个方法叫做 headers()，通过它就获取了本次请求所有的响应头。

那么，我们记得在 OkHttp 里面，除了 headers()，还有用于获取单个指定头的 header() 方法。我们能不能在 Retrofit 里使用这种方式呢？答案是可以。

我们发现 Retrofit 的 Response 还有一个方法叫做 raw()，调用该方法就可以把 Retrofit 的Response 转换为原生的 OkHttp 当中的 Response。而现在我们就很容器实现 header 的读取了吧。

okhttp3.Response okResponse = response.raw();
    okResponse.header("Cache-Control");

进阶技巧

@Multipart 与文件上传

在官方文档中，实际上还有一个重要的注解，那就是  @Multipart。这个使用起来相对要复杂一点，所以放在这里。下面我们就来看一下这个东西的使用。

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 27][]

可以看到官方文档上对该注解使用的说明非常简单，但这个注解使用起来却不是那么简单，这就很烦人了。不过也没关系，我们由浅入深的来看一下。

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 28][]

这里对官方示例做了简化，因为我们在 @Part 参数中只使用了String类型，而没有声明 RequestBody 类型。接着就是调用它来进行测试：

Call<ResponseInfo> call = service.testMultipart("this is the part1","this is the part2");

为了一探究竟，我们现在在服务器打印一下 Content-Type 与 请求体(request-body) 分别是怎样的：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 29][]

现在我们来分析一下从打印的请求体中，我们能够得到哪些信息：

*  首先，本次请求的 Content-Type 是 multipart/form-data; 也就是代表通过2进制形式上传多部分的数据。
 *  boundary 故名思议就是分割线，它是用来对上传的不同部分的数据来进行分隔的，就像上图中体现的一样。
 *  通过 @Part 传入的参数信息都像上图中一样被组装，首先是相关的内容信息，然后间隔一个空行，之后是实际数据内容，最后接以 boundary。
 *  当使用 @Part 上传String参数信息时，我们可以看到其默认的参数类型application/json。（这代表如果你的服务器接不支持解析此类型的Content-Type，就需要自己修改为对应的类型）

现在我们注意到一个问题，那就是 multipart/form-data 将会以2进制形式来上传数据信息。那么，什么时候我们才需要2进制呢？显然就是文件的上传。

OK，那么我们继续修改代码，这次我们尝试通过@Part来上传一个文件会是什么情况？

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 30][]

这里可以发现，当要上传的数据是文件时，就要使用到 RequestBody 了。再次运行程序，然后截取服务器打印的请求体的部分进行查看：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 31][]

我们其实可以很直观的看到，大体的格式与之前都是一样的，而不同之处在于：

*  Content-Type 不再是 application/json，而是 image/png 了。
 *  空行之后的数据内容不再是之前直观的文本，而是二进制的图片内容。

这个时候就会出现一个问题，假设我们为了方便，打算通过一些公有的API去测试一下上传文件(图片)什么的，会发现上传不成功。这是为什么呢？

实际上如果我们完全自己动手来写服务器，完全根据之前的请求体打印信息的格式来写解析的方法，肯定是也能完成文件上传的。但问题在于：

我们说到 multipart/form-data 是支持多部分数据同时上传的，于是就出现了一个听上去很有逼格的梗，叫做“图文混传”。那么：

为了区别于同一个 request-body 中的文本或文件信息，所以通常实际开发来说，上传文件的时候，Content-Disposition 是这样的：

Content-Disposition: form-data; name="file"；filename="test.jpg"

而不是我们这里看到的：

Content-Disposition: form-data; name="file"

于是别人的api里读取不到这个关键的“filename”，自然也就无法完成上传了。所以如果想通过 Retrofit 实现文件上传，可以通过如下方式来改造一下：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 32][]

然后我们在servlet服务器中进行解析，完成文件的上传。这里当然就不自己去写解析body的代码了，可以使用现有的库 commons-fileupload。

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 33][]

再次运行程序，从代码中可以看到，我们希望将客户端上传的图片保存电脑的D盘根目录下，打开D盘看一下吧，已经成功上传了！

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 34][]

## 不同类型的Converter ##

相信我们还记得之前我们读取服务器返回的json数据时，依赖于 GsonConverterFactory 就成功完成了解析。那么问题来了：

假设有的时候我们服务器返回的就是一段简单的文本信息呢？这叫老夫如何是好，其实这在之前就已经有了答案了：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 35][]

我们看到除了基于GSON的 converter 之外，官方还提供了很多其它的 Converter。眼尖的马上就看到了 Scalars 后面有一个东西叫做 String。

于是接下来的工作就简单了，依然是配置依赖；然后将Call的泛型指定为String；最后记得将 Converter 改掉，像下面这样：

//... .addConverterFactory(ScalarsConverterFactory.create())

再次运行程序，查看日志打印信息，发现成功搞定：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 36][]

有了这个例子，对于同类型的需求我们就很容易举一反三了。但马上又想到：假设我们的数据类型官方没有提供现成的Converter呢？很简单，自己造！

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 37][]

从官方描述中，我们发现自定义Converter其实很简单。即创建一个继承自 Converter.Factory 的类，然后提供自己的 Converter实例 就行了。

那么假设，我们现在服务返回的数据格式是下面这样的。而我们的需求是希望在客户端对其解析后，将其放进一个Map里面。

username=张三&male=男性

根据这样的需求，我们可以像下面这样很容易的实现我们自己的 Converter：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 38][]

现在，我们就可以进行调用测试了：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 39][]

查看日志打印：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 40][]

使用Interceptor

之前在学习  @Headers 的用法的时候，其实官方文档中还有一个东西，我们没有总结。官方的描述是这样的：

> Headers that need to be added to every request can be specified using an OkHttp interceptor. 
> 
> 简单易懂，也就是说：如果你项目里的每一个请求需要加入某个header，那么就可以使用interceptor(interceptor本身是OkHttp里的东西)

interceptor 顾名思义就是拦截器，其具体使用方法可以参照：

> https://github.com/square/okhttp/wiki/Interceptors

这里我们看下官方的第一个例子：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 41][]

这里面的其它东西相信都很熟悉，一个新的关键叫做  Interceptor.chain。很明显，从命名我们可以猜想出它就是完成拦截的关键。

事实上，我们可以对以上的示例进行简化，最后其实我们需要学习的就两行代码：

Request request = chain.request();
    Response response = chain.proceed(request);

也就是说：

*  通过chain的request()方法，可以返回Request对象。
 *  通过chain的proceed()方法，可以返回此次请求的响应对象。

那么，以我们之前的需求来说：对所有的请求都添加某个请求头。实际就很容易实现了。

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 42][]

同理，如果我们想要在每个Response中都添加某个header值呢？做法是一样的：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 43][]

但是，到现在为止，我们说到的都是 interceptor 在 OkHttp 中的使用。那么对应在 Retrofit 呢，其实很简单，因为我们说了 Retrofit 就是基于 OkHttp 的。

那么，前面一切的步骤都可以按照在 OkHttp 里的使用方法按部就班。唯一额外要做的工作就是，构建好 OkHttpClient对象 后，记得把它设置给 Retrofit。

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 44][]

总结

到了这里，对Android中常用的网络请求库say hello系列的三篇博客总算是总结完毕了。而针对Retrofit的此文是写的最认真的一篇，一个是因为现在它的确是流行；其次是因为个人也比较感兴趣。如果您观看后有任何想法，望多多指正，给出宝贵意见。

[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1]: /images/20220716/064bc9ea9acd46159785e7eb093534ab.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 1]: /images/20220716/6d0e686e776242e196a084e79e3c8684.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 2]: /images/20220716/d5daf9853ade4a2880a78cf38dc108c3.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 3]: /images/20220716/ddd32c164ca2401aaeb5d35e35b0e0d0.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 4]: /images/20220716/fbfa7dcc77374b8a848c105fa69b50e6.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 5]: /images/20220716/b7061b2eb013406b80758e476542373e.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 6]: /images/20220716/8f265ec3624249b2952a5718dacc298f.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 7]: /images/20220716/dfbbf510e9434af3902a9b1fe40f9e11.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 8]: /images/20220716/ea22840317c141a4b12ccffb8e4d7eb7.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 9]: /images/20220716/1e219397e6e54480863e76e5830e85ed.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 10]: /images/20220716/adad6104d4da44329c5bdd4fc7700e0d.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 11]: /images/20220716/42cb66b3eeca404bbb829968a04dd466.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 12]: /images/20220716/4e7cff1a959345d28eaa2763a9e5a860.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 13]: /images/20220716/fe803a40cc864d4fa9d6e3ea461071af.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 14]: /images/20220716/7f7c437f47f64e399cbb4f29a3f972b1.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 15]: /images/20220716/cde57c6b3b934ce9b355f2bd47107d9c.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 16]: /images/20220716/f7b5001ffdfb4b84a34151e441df44fa.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 17]: /images/20220716/bd5901579160404a81da052465af1579.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 18]: /images/20220716/d89cf112f5b341b1894d31de57fbdf87.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 19]: /images/20220716/3a9c98e228ab48d7b695d8c28af1a2f4.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 20]: /images/20220716/d523d74a85a946da9d9ec8843acc0468.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 21]: /images/20220716/16f32da7e43843a49805285779c92bae.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 22]: /images/20220716/52aaa1145cc0482d9061581787a2094c.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 23]: /images/20220716/8fbf95a61a9941b2994e1e4c105fd4e1.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 24]: /images/20220716/05e00cc7bc454a2dbe9334d203a9cf3e.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 25]: /images/20220716/6bd234e96ec14abfa3e87835f2d9280a.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 26]: /images/20220716/8bd59d5f98fe4899b9bb96740cd828b8.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 27]: /images/20220716/d2bed2f609374c63b63b5ae1778ff770.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 28]: /images/20220716/d3eaf8a1c7ee4bc6b9d80f463fb21d6c.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 29]: /images/20220716/4c1fe514938f4d6bbcd4535f58bff883.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 30]: /images/20220716/ae07d7345b4d420589dc5f55ba331e9d.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 31]: /images/20220716/57f01e2056214acbb344f09183d40526.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 32]: /images/20220716/65a33bb5abec474db66bcaf005398b4c.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 33]: /images/20220716/ca4f8d384b10433795dd8241bec3595f.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 34]: /images/20220716/32e2c4fb9b80450db7c2c338b964fda1.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 35]: /images/20220716/ee079f10b1294ad1bc242eff68ec1cc2.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 36]: /images/20220716/4fc05d2048604c6d8b293baf4e9e4470.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 37]: /images/20220716/88450a7e469743b3b992788bcc4840ad.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 38]: /images/20220716/82abe7e3ca8c4e01b2aa01c8ef5a0d1b.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 39]: /images/20220716/8d56d4a03a7e4540a0be05b3110389d4.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 40]: /images/20220716/d264e7b32f2945f4b8936fd96066a2af.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 41]: /images/20220716/c6ef163dbae349f688d9941260ecec01.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 42]: /images/20220716/7157c2b9c0f44059838e3e40d23a31e5.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 43]: /images/20220716/62115a5f715e4d92a9f1ab12f8c625ae.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1 44]: /images/20220716/562f14e8a8a040adad7c249344f9d8ff.png