又是一年中秋佳节，祝各位中秋节快乐。
今天我们来聊聊这个最近很火的网络请求库retrofit，在此基础上会延伸出一些列的知识点。现在关于retrofit的文章很多，我之所以写这篇文章的原因在于：8月份负责假设新客户端底层的过程中首次尝试使用该库，并取得非常不错的效果，不到20天的时间内实现新产品的快速开发。
另外因为个人的原因，在写完基础框架及发布两个基础版本之后，我也选择的离职。现在，留给自己10天的时间，用来对2016年做个简短的总结，也希望能帮助各位。首先简单的说说会总结哪方面的，觉得感兴趣的同学可以关注下：
- 网络请求及优化，以retrofit作为出发点，其中穿插源码分析
- ANR原理及实现对ANR的监控
- App省点开发技巧
- apk混淆与逆向部分，其中拿一些市面上的app做示例。
- App快速开发框架部分，其中夹杂这一些从后端到移动端设计的敏感点，也会去整理出一个基本的app开发框架做演示
- 最后，就是一些杂七杂八点吧。对插件化之类的，目前市面上的文章已经非常不错了。
暂时的计划是这样。话不多说，这就开始。
Retrofit是什么？
Retrofit就是一个Http请求库，和其它Http库最大区别在于通过大范围使用注解简化Http请求。目前Retrofit 2.0底层是依赖OkHttp实现的，也就是说Retrofit本质上就是对OkHttp的更进一步封装。那么我们一定要使用它么？当然不，目前Android领域内的各种网络请求库多不胜数，随便哪一个都可以满足你大部分的需求，所以没必要纠结。不过从我个人的经验来看，如果你的服务端是restful风格，并且你希望后面使用rxjava相关的技术，那么Retrofit是你最好的选择。
Retrofit实战
添加依赖
要想使用retrofit，首先需要添加相关的依赖：
compile 'com.squareup.retrofit2:retrofit:2.0.2'
为什么要说这个呢？主要目的是告诉大家我们这里是基于此版本的。接下来，我们正式开始讲解。
常用注解
前面我们说道，retrofit通过使用注解来简化请求，这里我们先来认识一下常用的注解。retrofit中的注解大体分为以下基类：用于标注请求方式的注解，用于标记请求头的注解以及用于标记请求参数的注解。其实，任何一种Http库都提供了相关的支持，无非在retrofit中是用注解来简化。
请求方法注解
该类型的注解用于标注不同的http请求方式，主要有以下几种：
| 注解 | 说明 |
|---|---|
| @GET | 表明这是get请求 |
| @POST | 表明这是post请求 |
| @PUT | 表明这是put请求 |
| @DELETE | 表明这是delete请求 |
| @PATCH | 表明这是一个patch请求，该请求是对put请求的补充，用于更新局部资源 |
| @HEAD | 表明这是一个head请求 |
| @OPTIONS | 表明这是一个option请求 |
| @HTTP | 通用注解,可以替换以上所有的注解，其拥有三个属性：method，path，hasBody |
我并不准备对其使用做什么说明，官网的示例已经写的非常不错。但是我看国内的很多开发者只用get和post，这是件很悲伤的事情，实际上这些请求方法各自有各自的使用场景。
最容易混淆的是put，post，patch这三者，简单的说，post表示新增，put可以理解为完整替换，而patch则是更新资源。顺便来看看官方定义：
- POST to create a new resource when the client cannot predict the identity on the origin server (think a new order)
- PUT to override the definition of a specified resource with what is passed in from the client
- PATCH to override a portion of a specified resource in a predictable and effectively transactional way (if the entire patch cannot be performed, the server should not do any part of it)
接下来我们来重点说说@HTTP：
@HTTP注解我个人很少用，这里用个简单的例子来说明下：我们当前存在获取验证码的请求：
@GET("mobile/capture")
Call<ResponseBody> getCapture(@Query("phone") String phone);
用@HTTP代替后：
@HTTP(method = "get", path = "mobile/capture", hasBody = false)
Call<ResponseBody> getCapture(@Query("phone") String phone);
请求头注解
该类型的注解用于为请求添加请求头。
| 注解 | 说明 |
|---|---|
| @Headers | 用于添加固定请求头，可以同时添加多个。通过该注解添加的请求头不会相互覆盖，而是共同存在 |
| @Header | 作为方法的参数传入，用于添加不固定值的Header，该注解会更新已有的请求头 |
首先来看@Headers的示例：
//使用@Headers添加单个请求头
@Headers("Cache-Control:public,max-age=120")
@GET("mobile/active")
Call<ResponseBody> getActive(@Query("id") int activeId);
//使用@Headers添加多个请求头
@Headers({
"User-Agent:android"
"Cache-Control:public,max-age=120",
})
@GET("mobile/active")
Call<ResponseBody> getActive(@Query("id") int activeId);
接下来来看@Header的示例：
@GET("mobile/active")
Call<ResponseBody> getActive(@Header("token") String token,@Query("id") int activeId);
可以看出@Header是以方法参数形势传入的，想必你现在能理解@Headers和@Header之间的区别了。
请求和响应格式注解
该类型的注解用于标注请求和响应的格式。
| 名称 | 说明 |
|---|---|
| @FormUrlEncoded | 表示请求发送编码表单数据，每个键值对需要使用@Field注解 |
| @Multipart | 表示请求发送multipart数据，需要配合使用@Part |
| @Streaming | 表示响应用字节流的形式返回.如果没使用该注解,默认会把数据全部载入到内存中.该注解在在下载大文件的特别有用 |
请求参数类注解
该类型的注解用来标注请求参数的格式，有些需要结合上面请求和响应格式的注解一起使用。
| 名称 | 说明 |
|---|---|
| @Body | 多用于post请求发送非表单数据,比如想要以post方式传递json格式数据 |
| @Filed | 多用于post请求中表单字段,Filed和FieldMap需要FormUrlEncoded结合使用 |
| @FiledMap | 和@Filed作用一致，用于不确定表单参数 |
| @Part | 用于表单字段,Part和PartMap与Multipart注解结合使用,适合文件上传的情况 |
| @PartMap | 用于表单字段,默认接受的类型是Map<String,REquestBody>，可用于实现多文件上传 |
| @Path | 用于url中的占位符 |
| @Query | 用于Get中指定参数 |
| @QueryMap | 和Query使用类似 |
| @Url | 指定请求路径 |
我们依次对着注解进行举例说明。
@Headers
@Headers("Cache-Control: max-age=64000")
@GET("active/list")
Call<List<Active>> ActiveList();
当然@Header也支持同时设置多个：
@Headers({
"version:1.0.0"
"Cache-Control: max-age=64000"
})
@GET("active/list")
Call<List<Active>> ActiveList();
@Header
@GET("user")
Call<User> getUserInfo(@Header("token") token)
@Body
根据转换方式将实例对象转换为相应的字符串作为请求参数传递。比如在很多情况下，你可能需要以post的方式上传json格式的数据。那么该怎么来做呢？
我们以一个登录接口为例，该接口接受以下格式的json数据：
{"password":"abc123456","username":"18611990521"}
首先建立请求实体，为了区别其他实体，通常来说约定以Post为后缀.
public class LoginPost {
private String username;
private String password;
public LoginPost(String username, String password) {
this.username = username;
this.password = password;
}
}
然后定义该请求api：
@POST("mobile/login")
Call<ResponseBody> login(@Body LoginPost post);
retrofit默认采用json转化器，因此在我们发送数据的时候会将LogintPost对象映射成json数据，这样发送出的数据就是json格式的。另外，如果你不确定这种转化行为，可以强制指定retrofit使用Gson转换器：
Retrofit retrofit = new Retrofit.Builder()
.baseUrl("https://www.test.com/")
.addConverterFactory(GsonConverterFactory.create())
.build();
更详细的内容参照retrofit官网，另外关于retrofit的转换器我会在另一节中进行详细的分析。
@Filed & @FiledMap
@Filed通常多用于Post请求中以表单的形势上传数据,这对任何开发者来说应该都是很常见的。
@POST("mobile/register")
Call<ResponseBody> registerDevice(@Field("id") String registerid);
@FileMap和@Filed的用途相似，但是它用于不确定表单参数个数的情况下。
@Part & @PartMap
多用于Post请求实现文件上传功能。关于这两者的具体使用参考下文的文件上传。
在这里我们来解释一下@Filed和@Part的区别。
两者都可以用于Post提交，但是最大的不同在于@Part标志上文的内容可以是富媒体形势，比如上传一张图片，上传一段音乐，即它多用于字节流传输。而@Filed则相对简单些，通常是字符串键值对。
@Path
关于@Path没什么好说，官网解释已经足够清楚了。这里着重提示：
{占位符}和PATH只用在URL的path部分，url中的参数使用Query和QueryMap 代替，保证接口定义的简洁
异步VS同步
任何一个任务都可以被分为异步任务或者同步任务，和其它大多数的请求框架一样，retrofit也分为同步请求和异步请求。在retrofit是实现这两者非常简单：
同步调用
同步请求需要借助retrofit提供的execute()方法实现。
public void get() throws IOException {
Retrofit retrofit = new Retrofit.Builder().baseUrl("https://api.github.com/").build();
GitHubApi api = retrofit.create(GitHubApi.class);
Call<ResponseBody> call = api.contributorsBySimpleGetCall(mUserName, mRepo);
Response<ResponseBody> response = call.execute();
if (response.isSuccessful()) {
ResponseBody responseBody = response.body();
//处理成功请求
}else{
//处理失败请求
}
}
异步调用
异步请求需要借助retrofit提供的enqueue()方法实现。（从这个方法名中你可以看出之该方法实现的是将请求加入请求队列）。想async-http一样，同样你需要在enqueue(()方法中为其最终结果提供相应的回调，以实现结果的处理。
public void get() {
Retrofit retrofit = new Retrofit.Builder().baseUrl("https://api.github.com/").build();
GitHubApi api = retrofit.create(GitHubApi.class);
Call<ResponseBody> call = api.contributorsBySimpleGetCall(mUserName, mRepo);
call.enqueue(new Callback<ResponseBody>() {
@Override
public void onResponse(Call<ResponseBody> call, Response<ResponseBody> response) {
//处理请求成功
}
@Override
public void onFailure(Call<ResponseBody> call, Throwable t) {
//处理请求失败
}
});
}
不难发现retrofit中实现同步和异步是如此的方便，仅仅通过提供请求的不同执行方法（execute()和enqueue()）便成功的实现的请求执行方式和请求类型的解耦，实在是棒极了。
到目前为止，使用retrofit的多是在Android上，此时我们关注多事异步请求，毕竟Android中并不允许你在主线程去做一些耗时任务。
无论是同步请求还是异步请求，我们都希望这两种请求是可控的，通常来说是分为三个方面：开始请求，结束请求以及查询请求的执行状态。上面的同步请求和异步请求属于开始请求这方面，那么结束请求和查询请求呢?
我们发现无论是同步请求还是异步请求，返回给我们的都是Call接口的实例。我们稍微看一下该接口：
public interface Call<T> extends Cloneable {
//执行同步请求
Response<T> execute() throws IOException;
//执行异步请求
void enqueue(Callback<T> callback);
//该请求是否在执行过程中
boolean isExecuted();
//取消当前执行的请求
void cancel();
//该请求是否被执行
boolean isCanceled();
//和java中的clone()方法含义一样，通常利用该请求实现重复请求
Call<T> clone();
//获取原始请求
Request request();
}
通过上面的代码不难看出，Call接口提供了我们上面所说的执行请求，查询请求状态以及结束请求。
移除请求
看完上面的Call对象之后，我们知道要想取消一个请求(无论异步还是同步)，则只需要在响应的Call对象上调用其cancel（）对象即可。
public void cancle(){
Retrofit retrofit = new Retrofit.Builder().baseUrl("https://api.github.com/").build();
GitHubApi api = retrofit.create(GitHubApi.class);
Call<ResponseBody> call = api.contributorsBySimpleGetCall(mUserName, mRepo);
Response<ResponseBody> response = call.execute();
if (response.isSuccessful()) {
ResponseBody responseBody = response.body();
//处理成功请求
}else{
//处理失败请求
}
...
//取消相关请求
call.cancel();
}
多次请求
个别情况下我们可能需要一个请求执行多次。但是我们在retrofit中，call对象只能被调用一次，这时候该怎么办？
这时候我们可以利用Call接口中提供的clone()方法实现多次请求。
public void multi_async_get() {
Retrofit retrofit = new Retrofit.Builder().baseUrl("https://api.github.com/").build();
GitHubApi api = retrofit.create(GitHubApi.class);
Call<ResponseBody> call = api.contributorsBySimpleGetCall(mUserName, mRepo);
call.enqueue(new Callback<ResponseBody>() {
@Override
public void onResponse(Call<ResponseBody> call, Response<ResponseBody> response) {
//请求成功
}
@Override
public void onFailure(Call<ResponseBody> call, Throwable t) {
//请求失败
}
});
call.clone().enqueue(new Callback<ResponseBody>() {
@Override
public void onResponse(Call<ResponseBody> call, Response<ResponseBody> response) {
//请求成功
}
@Override
public void onFailure(Call<ResponseBody> call, Throwable t) {
//请求失败
}
});
}
关于请求
上面我们简单的介绍了retrofit中注解，但是我并不准备像入门教程一样去举例说明。这里我们只对大家经常有困惑的两点做说明：
提交json格式数据
很多情况下，我们需要上传json格式的数据。比如当我们注册新用户的时候，因为用户注册时的数据相对较多，并可能以后会变化，这时候，服务端可能要求我们上传json格式的数据。此时就要@Body注解来实现。
首先定义请求实体RegisterPost:
public class RegisterPost {
private String username;
private int age;
...
}
接下来定义请求方法:
@POST("mobile/register")
Call register1(@Body RegisterPost post);
这样我们就能够上传json格式的数据了。
上传文件
retrofit中的实现文件上传也是非常简单的。这里我们以图片上传为例。
单张图片上传
retrofit 2.0的上传和以前略有不同，需要借助@Multipart注解、@Part和MultipartBody实现。
首先定义上传接口
@Multipart
@POST("mobile/upload")
Call<ResponseBody> upload(@Part MultipartBody.Part file);
然后来看看如何调用该方法。和调用其他请求稍有不同，这里我们需要构建MultipartBody对象：
File file = new File(url);
//构建requestbody
RequestBody requestFile = RequestBody.create(MediaType.parse("multipart/form-data"), file);
//将resquestbody封装为MultipartBody.Part对象
MultipartBody.Part body = MultipartBody.Part.createFormData("file", file.getName(), requestFile);
这样，我们就可以方便的进行上传图片了。
多张图片上传
如果有很多张图片要上传，我们总不能一张一张的来吧？好吧，我们来看看如果进行多文件（图片）上传。
在retrofit中提供了@PartMap注解，借助该对象，我们可以实现多文件的上传。同样我们来看看具体文件的定义
@Multipart
@POST("upload/upload")
Call<ResponseBody> upload(@PartMap Map<String, MultipartBody.Part> map);
和单文件上传的唯一区别就是将@Part注解换成了@PartMap注解。这意味我们可以以Map的形式进行多文件上传。具体如何调用相信你已经明白。
图文混传
无论是多文件上传还是单文件上传，本质上个都是借助@Multipart注解和MultipartBody来实现的。
这和其他网络请求框架的实现原理并无本质区别，但retrofit在图文上传方面得天独厚的优势。比如我们在注册时候既要传用户文本信息又要上传图片,结合上面的用户注册来做说明：
@Multipart
@POST("")
Call<ResponseBody> register(@Body RegisterPost post,@Part MultipartBody.Part image);
该注册接口实现了用户注册信息和用户头像的同时上传，其调用无非就是结合我们上文提到的json数据上传以及单张图上传。
文件下载
很多时候，我们可能需要暂时下载文件，但是又不希望引入其他的下载库，那么如何retrofit实现下载呢？同样，我们还是以下载图片为例
首先定义api接口如下：
@GET
Call<ResponseBody> downloadPicture(@Url String fileUrl);
关键就是获取到ResponseBody对象。我们来看获取到ResponseBody之后的处理：
InputStream is = responseBody.byteStream();
String[] urlArr = url.split("/");
File filesDir = Environment.getExternalStorageDirectory();
File file = new File(filesDir, urlArr[urlArr.length - 1]);
if (file.exists()) file.delete();
不难发现这里的关键就是通过ResponseBody对象获取字节流，最后将其保存下来即可。实现下载就是这么简单。
这里需要注意的是如果下载的文件较大，比如在10m以上，那么强烈建议你使用@Streaming进行注解，否则将会出现IO异常.
@Streaming
@GET
Observable<ResponseBody> downloadPicture(@Url String fileUrl);
拦截器Interceptors使用
熟悉OkHttp的童鞋对Interceptors一定不会陌生。而Retrofit 2.0 底层强制依赖okHttp，所以可以使用okHttp的拦截器Interceptors 来对所有请求进行再处理。同样来说，我们经常使用拦截器实现以下功能：
- 设置通用Header
- 设置通用请求参数
- 拦截响应
- 统一输出日志
- 实现缓存
下面我们以上各自使用的场景给出相应的代码说明：
设置通用Header
在app api接口设计中，我们往往需要客户端在请求方法时，携带appid，appkey，timestamp，signature及version等header。你可能会问前边不提到的@Headers不也同样可以做到这事情么？在方法很少的情况下，或者个别请求方法需要的情况下使用@Headers来添加当然可以，但是如果要为所有请求方法都添加还是借助拦截器使用更为方便。直接看代码：
public static Interceptor getRequestHeader() {
Interceptor headerInterceptor = new Interceptor() {
@Override
public Response intercept(Chain chain) throws IOException {
Request originalRequest = chain.request();
Request.Builder builder = originalRequest.newBuilder();
builder.header("appid", "1");
builder.header("timestamp", System.currentTimeMillis() + "");
builder.header("appkey", "zRc9bBpQvZYmpqkwOo");
builder.header("signature", "dsljdljflajsnxdsd");
Request.Builder requestBuilder =builder.method(originalRequest.method(), originalRequest.body());
Request request = requestBuilder.build();
return chain.proceed(request);
}
};
return headerInterceptor;
}
你会发现在设置header的时候，我们有两种方法可选择：addHeader()和header()。切莫混淆两者之间的区别：
使用addHeader()不会覆盖之前设置的header,若使用header()则会覆盖之前的header
统一输出请求日志
在早期开发调试阶段，我们希望看到每个请求的详细信息，在发布时关闭这些消息。
得益于retrofit和okhttp的良好设计，可以方便的通过添加Log拦截器来实现，这里我们使用到OkHttp中的HttpLoggingInterceptor拦截器。
在retrofit 2.0中要使用日志拦截器，首先添加依赖：
compile 'com.squareup.okhttp3:logging-interceptor:3.1.2'
然后创建日志拦截器
public static HttpLoggingInterceptor getHttpLoggingInterceptor() {
HttpLoggingInterceptor loggingInterceptor = new HttpLoggingInterceptor();
loggingInterceptor.setLevel(HttpLoggingInterceptor.Level.BODY);
return loggingInterceptor;
}
拦截服务器响应
通常来说，我们多利用拦截器来实现对请求的拦截。但是在很多的情况下我们需要从响应中获取响应的Headers中获取指定的header，比如在有些功能中我们需要服务端会给出我们某个活动的起始时间，需要我们客户端来判断当然活动是否可以执行。这时候，我们显然不能利用客户端本地的时间（有条原则叫做永远不要相信客户端的时间），这时候就需要服务端在将服务器的时间传给我们。为了方便，通常时间服务器的时间戳放在每个响应Header当中。
那么我们该怎么拿到这个时间戳呢？拦截器可以非常容易的帮助我们解决这个问题。这里我们假设服务器在任何一个响应的Header中都添加了time，我们要做的就是通过拦截器来获取到Header，具体见代码：
public static Interceptor getResponseHeader() {
Interceptor interceptor = new Interceptor() {
@Override
public Response intercept(Chain chain) throws IOException {
Response response = chain.proceed(chain.request());
String timestamp = response.header("time");
if (timestamp != null) {
//获取到响应header中的time
}
return response;
}
};
return interceptor;
}
通过上面的响应拦截器实现了从响应中获取服务器返回的time，就是这么简单。
设置通用请求参数
在实际项目中，各个客户端往往需要向服务端传送一些固定的参数，通常来说有两种方案：
- 可以将这个公共的请求参数放到请求Header中
- 也可以将其放在请求参数中
如何添加到header中我们已经介绍过了，现在来看看如何添加公共请求参数。添加公共请求参数和添加公共Header实现原理一致，都是借助拦截器来实现，这里我们同样直接来看代码：
private void commonParamsInterceptor() {
Interceptor commonParams = new Interceptor() {
@Override
public okhttp3.Response intercept(Chain chain) throws IOException {
Request originRequest = chain.request();
Request request;
// String method = originRequest.method();
// Headers headers = originRequest.headers();
HttpUrl httpUrl = originRequest.url().newBuilder().addQueryParameter("paltform", "android").addQueryParameter("version", "1.0.0").build();
request = originRequest.newBuilder().url(httpUrl).build();
return chain.proceed(request);
}
};
return commonParams;
}
我个人强烈建议：如果需要添加统一的请求参数，最好将其放在请求头当中。
使用拦截器
上面我们介绍在实际开发中4中常用的拦截器，可以发现有了这些拦截器，我们可以很容易处理公共聚焦点。至于拦截器的使用，就是直接将响应的拦截器设置给OkHttpClient客户端即可,以添加日志拦截器为例：
HttpLoggingInterceptor logging = getHttpLoggingInterceptor();
//设置日志拦截器
OkHttpClient httpClient = new OkHttpClient.Builder().addInterceptor(logging).build();
Retrofit retofit=new Retrofit.Builder().baseUrl("http://www.demo.com").client(httpClient).build();
客户端请求策略
任何一个Http请求库都少不了失败重试及请求超时的设置。来看一下retrofit中如何设置：
失败重试
retrofit通过okHttpClient来设置失败时自动重试，其使用也非常简单：
public void setRetry(OkHttpClient.Builder builder) {
builder.retryOnConnectionFailure(true);
}
设置请求超时
当然，retrofit作为一个完善的网络请求框架也少不了这方面的设置。
public void setConnecTimeout(OkHttpClient.Builder builder) {
builder.connectTimeout(10, TimeUnit.SECONDS);
builder.readTimeout(20, TimeUnit.SECONDS);
builder.writeTimeout(20, TimeUnit.SECONDS);
}
添加缓存支持
在上面拦截器的使用中，我i门已经介绍了4中拦截器的使用，现在我们来介绍如何使用拦截器来实现HTTP缓存。Http缓存原理在本文中并不做重点解释。
ok，现在来看看Retrofit中如何配置使用缓存。
设置缓存的的两种方式
在retrofit中可以通过两种方式设置缓存：
- 通过添加 @Headers("Cache-Control: max-age=120") 进行设置。添加了Cache-Control 的请求，retrofit 会默认缓存该请求的返回数据。
- 通过Interceptors实现缓存。
这两者实现原理一致，但是适用场景不同。通常是使用Interceptors来设置通用缓存策略，而通过@Header针对某个请求单独设置缓存策略。另外，一定要记住，retrofit 2.0底层依赖OkHttp实现，这也就意味着retrofit缓存的实现同样是借助OkHttp来的。另外，无论你是决定使用那种形势的缓存，首先要为OkHttpClient设置Cache，否则缓存不会生效（retrofit并为设置默认缓存目录），Cache的设置你将在下文看到。
下面我们来具体看看，如何通过@Headers为某个方法设置缓存时间
@Headers("Cache-Control:public,max-age=120")
@GET("mobile/active")
Call<ResponseBody> getActive(@Query("id") int activeId);
这样我们就通过@Headers快速的为该api添加了缓存控制。120s内，缓存都是生效状态，即无论有网无网都读取缓存。
现在我们再来看一下如何利用拦截器来实现缓存：
首先创建缓存拦截器：
public static Interceptor getCacheInterceptor() {
return new Interceptor() {
@Override
public Response intercept(Chain chain) throws IOException {
Request request = chain.request();
Response response = chain.proceed(request);
return response.newBuilder().header("Cache-Control","public,max-age=120").build();
}
};
}
和其它的拦截器使用一样，将其设置到OkHttpClient即可，但此时设置缓存拦截器使用的addNetworkInterceptor()方法。凡是使用该设置了该缓存拦截器的OkHttpClient都具备了缓存功能，具体代码如下：
//创建Cache
Cache cache = new Cache(AppContext.context().getCacheDir(), 10 * 1024 * 1024);
//设置拦截器和Cache
OkHttpClient httpClient = new OkHttpClient.Builder().addNetworkInterceptor(getCacheInterceptor()).cache(cache).build();
//设置OkHttpClient
Retrofit retofit=new Retrofit.Builder().baseUrl("http://www.demo.com").client(httpClient).build();
实际开发中往往要求，有网的情况下直接从网络中获取数据，无网络的情况下才走缓存，那么此时上面的缓存拦截器就不是适用了，那这该怎么做呢？
在解决这个问题之前首先我们解决大家的一个疑惑：通过addNetworkInterceptor()和通过addInterceptor()添加的拦截器有什么不同呢？
简单来说，addNetworkInterfacetor()添加的是网络拦截器（Network Interfacetor），它会在request和response时分别被调用一次；addInterceptor（）添加的是应用拦截器（Application Interceptor），他只会在response被调用一次。OkHttp中对此做了更加详细的解释[OkHttp拦截器详解][2]
我们将上面的缓存问题再明确一下：在无网络的情况下读取缓存，有网络的情况下根据缓存的过期时间重新请求,根据需求，我们创建以下拦截器：
public static Interceptor getCacheInterceptor() {
return new Interceptor() {
@Override
public Response intercept(Chain chain) throws IOException {
Request request = chain.request();
if (!TDevice.hasInternet()) {
//无网络下强制使用缓存，无论缓存是否过期,此时该请求实际上不会被发送出去。
request=request.newBuilder().cacheControl(CacheControl.FORCE_CACHE)
.build();
}
Response response = chain.proceed(request);
if (TDevice.hasInternet()) {//有网络情况下，根据请求接口的设置，配置缓存。
//这样在下次请求时，根据缓存决定是否真正发出请求。
String cacheControl = request.cacheControl().toString();
//当然如果你想在有网络的情况下都直接走网络，那么只需要
//将其超时时间这是为0即可:String cacheControl="Cache-Control:public,max-age=0"
return response.newBuilder().header("Cache-Control", cacheControl)
.removeHeader("Pragma")
.build();
}else{//无网络
return response.newBuilder().header("Cache-Control", "public,only-if-cached,max-stale=360000")
.removeHeader("Pragma")
.build();
}
}
};
}
接下来，将该请求设置到OkHttpClient,此时我们的网络拦截器和应用拦截器都添加的是上面同一个拦截器：
//创建Cache
Cache cache = new Cache(AppContext.context().getCacheDir(), 10 * 1024 * 1024);
//设置拦截器和Cache
OkHttpClient httpClient = new OkHttpClient.Builder().addNetworkInterceptor(getCacheInterceptor()).cache(cache).addInterceptor(getCacheInterceptor()).build();
//设置OkHttpClient
Retrofit retofit=new Retrofit.Builder().baseUrl("http://www.demo.com").client(httpClient).build();
实际上，缓存策略应该由服务器指定，但是在有些情况下服务器并不支持缓存策略，这就要求我们客户端自行设置缓存策略。以上的代码假设服务端不支持缓存策略，因此器缓存策略完全由客户端通过重写request和response来实现。
不出意外，在进行一些网络请求后，我们就可以在缓存目前下看到许多的缓存文件。每一个请求的缓存文件都分为两部分，非别是以.0结尾的请求和以.1结尾的响应数据。到这里，关于缓存的部门我们就说完了。我们可能会问，必须要基于retrofit来实现缓存么？如果，以后我更换网络框架（尽管可能性非常小），这岂不是要出大问题？如果你此顾虑，完全可以自行实现一套缓存框架，其原理本质上也非常相似：基于LRU算法。你可能不了解LRU算法，但是LRUCache和LRUDiskCache想必是耳熟能详的，对此我不画蛇添足了。
设置cookie
retrofit 2.0依赖OkHttp 3.0.而在OkHttp 3.0中，为了方便开发者自定义cookie的管理策略，新增了Cookiejar和Cookie两个类。
持久化cookie和非持久化cookie
cookie的管理又分为持久化cookie和非持久化cookie。非持久化cookie存储在内存中，也就意味着，其生命周期基本和app保持一致（如果你的Retrofit是单例），app关闭后，cookie丢失。而持久化cookie则是存储在本地磁盘中，app关闭后不丢失。
首先来看非持久化cookie。对于OkHttp 3来说，要实现非持久化我们有两种方案，一种是像以前一样，利用传统的JavaNetCookieJar来实现，另一种则是利用OkHttp 3给我们提供的CookieJar自实行实现。
非持久化cookie——利用JavaNetCookieJar
首先我们还是利用JavaNetCookieJar来实现非持久化cookie，它和以前的实现一样，首先添加依赖
compile 'com.squareup.okhttp3:okhttp-urlconnection:3.2.0'
接下来在代码中设置cookie
public void setCookies(OkHttpClient.Builder builder) {
CookieManager cookieManager = new CookieManager();
cookieManager.setCookiePolicy(CookiePolicy.ACCEPT_ALL);
builder.cookieJar(new JavaNetCookieJar(cookieManager));
}
不难发现，它的使用非常简单，主要依靠CookieManager和JavaNetCookieJar两个类即可，关于其原理部分我们放在另外一文中进行解释。
非持久化cookie——自定义CookieJar
通过CookieJar来实现非持久化cookie显得更为简单，其代码如下：
builder.cookieJar(new CookieJar() {
final HashMap<HttpUrl, List<Cookie>> cookieStore = new HashMap<HttpUrl, List<Cookie>>()
@Override
public void saveFromResponse(HttpUrl url, List<Cookie> cookies) {
cookieStore.put(url, cookies);//保存cookie
}
@Override
public List<Cookie> loadForRequest(HttpUrl url) {
List<Cookie> cookies = cookieStore.get(url);//取出cookie
return cookies!=null?cookies:new ArrayList<Cookie>();
}
});
这样，我们就实现了一个非常简单的非持久化cookie。这这种方案都非常简单，你可以选择自己喜欢的方案。
持久化cookie
上面的代码中实现对cookie的管理并不是持久化在本地，而是在内存当中。如果想要实现cookie的持久化应该怎么做呢？
很显然，我们会考虑从response中取出cookie取出cookie保存在本地，在request的时候，从本地取出cookie添加到请求中即可.有了大体的思路之后，如何持久化cookie也就不成问题了，此时想必你的脑海中已经有了以下2种解决方案：
- 通过响应拦截器从response取出cookie并保存到本地，通过请求拦截器从本地取出cookie并添加到请求中
- 自定义CookieJar，在saveFromResponse()中保存cookie到本地，在loadForRequest()从本地取出cookie。
以上两种思路都能解决我们的问题。但是现在我并不急于向你展示如何持久化cookie。而是希望通过JavaNetCookieJar背后的原理来向大家展示另一种思路，也就是第三种思路。关于这方面，我会在另外一文中进行深入的分析。
如果你喜欢，也可以关注博客代码之道，编程之法
