Ⅰ rxjava+retrofit 请求网络为什么抛出数组越界异常
rxjava+retrofit 请求网络为什么抛出数组越界异常主线程默认有Runloop。当自己启动一个线程，如果只是用于处理单一的事件，则该线程在执行完之后就退出了。所以当我们需要让该线程监听某项事务时，就得让线程一直不退出，runloop就是这么一个循环，没有事件的时候，一直卡着，有事件来临了，执行其对应的函数。RunLoop,正如其名所示,是线程进入和被线程用来相应事件以及调用事件处理函数的地方.需要在代码中使用控制语句实现RunLoop的循环,也就是说,需要代码提供while或者for循环来驱动RunLoop.在这个循环中,使用一个runLoop对象[NSRunloop currentRunloop]执行接收消息,调用对应的处理函数.rxjava+retrofit 请求网络为什么抛出数组越界异常
Ⅱ retrofit + okhttp 怎么拦截服务器返回的error信息
"解决方法：
1，如果安装密码保护系统需要找维护人员开启
2，服务器负载需要等服务器正常时才能登陆
3，网络不稳定需要重启电脑
4，代理出现问题，先找到电脑中的工具选项(ie浏览器上)。
点击Ieternet选项。
选中高级选项。
将“通过代理连接使用 HTTP 1.1”前面的勾勾去掉，然后重新登录游戏即可。
出现的原因：
1，如果是在网吧，有可能是网吧安装密码保护系统
2，服务器负载
3，网络不稳定
4，代理出现问题
"
Ⅲ OkHTTP、Retrofit 中文乱码解决方法
出现乱码的根本原因是客户端、服务端两端编码格式不一致导致的。
客户端：多数情况下，客户端的编码格式是 UTF-8。
服务端：服务端会根据不同的请求方法使用不同的编码格式。如：请求方法为 POST 时，编码格式为 UTF-8；请求方法为 GET 时，编码格式为 ISO8859-1。
当请求方法为 POST 时，客户端和服务端两边的编码格式一致，所以不存在乱码问题。因此此处着重看下如何解决当请求方法为 GET 时的乱码问题。
解决方法倒也简单，只不过需要客户端和服务端配合：
在向 URL 添加参数之前，先对目标参数进行两次 encode，如 UTF-8：
服务器在收到数据之后，只需将数据进行一次跟客户端编码格式一样的 decode，如 UTF-8：
这样处理之后，两边就不会再出现乱码了。
通过上面的分析可知，乱码产生的主要原因是客户端、服务器两边编码不一致造成的，即发送 GET 请求时，客户端使用的是 UTF-8 编码格式对 URL 中的参数进行编码，而服务器在接收数据的时候，使用的是 ISO8859-1（解析 POST 请求时，服务器使用的编码格式是 UTF-8 编码格式）编码格式对 URL 中的参数进行解码。
ISO8859-1 跟 ASCII 码一样，都是单字节编码，ISO8859-1 是从 ASCII 扩展而来的。ISO8859-1 将 ASCII 一个字节中剩余的最后一位用了起来，也就是说，它比 ASCII 多了 128 个字符。另外，因为 ISO8859-1 是从 ASCII 扩展而来的，所以，ISO8859-1 兼容 ASCII。
原数据：
客户端第一次编码，URLDecoder.decode(username, "UTF-8") 编码之后：
客户端第二次编码，URLDecoder.decode(username, "UTF-8") 编码之后：
客户端发出的 URL：
服务器接收的 URL：
服务器第一次解码，服务器接收到 GET 请求之后，默认会用 ISO8859-1 编码格式解码，解码之后得到：
需要注意的是，服务器用 ISO8859-1 编码格式解码 URL 中的参数是自动完成的。
因为客户端第一次用 URLDecoder.decode(username, "UTF-8") 编码 URL 中参数之后，得到的是 ASCII 码，且 UTF-8 和 ISO8859-1 对 ASCII 的编码结果是一致的，所以，客户端第二次用 URLDecoder.decode(username, "UTF-8") 之后的结果可以直接用 ISO8859-1 编码格式解码。
由于服务器解码之后的 URL 中的参数是用 UTF-8 编码格式编码的，所以，此时需要服务器再用 UTF-8 编码格式解码一次。
服务器第二次解码，服务器用 UTF-8 编码格式解码之后得到：
如果客户端程序员没有显式用 UTF-8 编码格式编码 URL 中的参数，服务端要如何处理才能获取到原数据？
首先，分析下如果客户端没有用 UTF-8 编码格式编码 URL 中的参数，程序是如何执行的：
网络请求框架会对 URL 中的参数进行一次 UTF-8 编码：
服务器会对 URL 中的参数进行一次 ISO8859-1 编码：
明白了执行流程之后，如何解决自然也就显而易见了：
先转回 ISO8859-1 解码（decode）之前的结果，再转会 UTF-8 编码（encode）之前的结果。
具体操作步骤：
因为 URL 中的参数经 UTF-8 编码格式编码之后得到的结果在 ISO8859-1 字符集可能一样也可能根本表示不了，这也是为什么 ASCII 码经 UTF-8 编码格式编码之后的结果可以用 ISO8859-1 编码格式解码。如，在 Unicode 字符集中，第 20013 个字符是“中”，而在 ISO8859-1 字符集中，一共才有 256 个字符。字符“中”经 UTF-8 编码之后的结果再经 ISO8859-1 解码，无论如何也得不到正确答案的。
Ⅳ Android Okhttp/Retrofit网络请求加解密实现方案
比较安全的方案应该是AES+RSA的加密方式。具体如下图所示。
为什么要这样做呢？
1、RSA是非对称加密，公钥和私钥分开，且公钥可以公开，很适合网络数据传输场景。但RSA加密比较慢，据说比AES慢100倍，且对加密的数据长度也有限制。
2、AES是对称加密，加密速度快，安全性高，但密钥的保存是个问题，在网络数据传输的场景就很容易由于密钥泄露造成安全隐患
3、所以，AES+RSA结合才更好，AES加密数据，且密钥随机生成，RSA用对方（服务器）的公钥加密随机生成的AES密钥。传输时要把密文，加密的AES密钥和自己的公钥传给对方（服务器）。对方（服务器）接到数据后，用自己的私钥解密AES密钥，再拿AES密钥解密数据得到明文。这样就综合了两种加密体系的优点。
4、除上面说的外，还可以加签名，即对传输的数据（加密前）先做个哈希，然后用自己的RSA私钥对哈希签名（对方拿到自己的公钥可以验签），这样可以验证传输内容有没有被修改过。
就java来说，加密的输入和输出都是字节数组类型的，也就是二进制数据，网络传输或本地保存都需要重新编码为字符串。推荐使用Base64。Android 有自带的Base64实现，flag要选Base64.NO_WRAP，不然末尾会有换行影响服务端解码。
Android中Base64加密
总而言之，这些不同语言都有实现库，调用即可，关键是参数要一致，具体还需要和后台联调一下。
rsa加解密的内容超长的问题解决
现在说到网络框架，应该毫无疑问是Retrofit了。上面说的加密方案说到底还是要在网络请求框架内加上，怎么做入侵最小，怎么做最方便才是重点。
1、坑定不能直接在接口调用层做加密，加参数，这样每个接口都要修改，这是不可能的。
2、ConverterFactory处理，这也是网上可以搜到的很多文章的写法，但我觉得还是有入侵。而且有点麻烦。
3、OkHttp添加拦截器，这种方法入侵最小（可以说没有），实现呢也非常优雅。
下面的实现，网上也找不到多少可以参考的文章，但不得不说，OkHttp的封装和设计真的很好用，所见即所得。看下源码，就知道该怎么用了，连文档都不用查。
主要注意点：
0、和接口无关的新加的数据放在请求头里。
1、该close的要close，不然会内存泄漏。
2、新旧Request和Response要区分好，新的要替换旧的去传递或返回。
3、要对response.code()做处理，只有在和后台约定好的返回码下才走解密的逻辑，具体看自己的需求，不一定都是200。
Ⅳ Retrofit的浅析 —— 针对面试
1.近两年Retrofit非常热门，特别是结合Rxjava运用到项目中。Retrofit一个RESTful的Http网络请求框架的封装，内部封装了Okhttp网络请求框架，对网络请求做了大量优化。Retrofit其最大特点就是解耦，要解耦就需要大量的设计模式，内部使用了外观模式、构建模式、观察者模式、动态代理模式、策略模式、适配器模式和装饰模式等等；
实际上分析Retrofit需要熟悉Okhttp才能深入分析Retrofit，Retrofit不止使用okhttp的内核，它还封装了CallAdapter-请求适配器：可以实现多种请求响应形式：同步方式、异步回调方式、RxJava方式；封装了Converter-数据转换器：可以自己定义responseBodyConverter和requestBodyConverter,实现加密功能和各种数据格式的解析；
retrofit 结合 okhttp 的原因就是retrofit使用了代理模式,默认代理走的就是okhttp,okhttp 负责网络请求, retrofit 负责对网络的处理,包括gson解析都是封装在retrofit里面的,如果哪天okttp不流行了是可以切换到别的网络框架的
Retrofit(改良)框架是Square公司出品的目前非常流行的网络框架,效率高,实现简单,运用注解和动态代理设计模式,极大的简化了网络请求的繁琐步骤,非常适合处理REST ful(一种风格)网络请求.目前Retrofit版本是2(可以说是Square公司之前出品okhttp的升级版)
性能好,处理快,使用简单.(速度比Volley更快)
使用REST API非常方便
支持NIO(新的IO API，可以替代标准的Java IO API)
Retrofit默认使用okhttp处理网络请求；
默认使用Gson解析
1.在项目的build.gradle中添加依赖后一个依赖比前一个多了个Gson解析的功能,看需求,二者依赖一个即可, 一 般依赖带Gson解析的依赖
compile 'com.squareup.retrofit2:retrofit:2.0.0-beta4'
compile 'com.squareup.retrofit2:converter-gson:2.0.0-beta4'
<uses-permission android:name="android.permission.INTERNET" />
@GET GET网络请求方式
@POST POST网络请求方式
@Headers 头信息参数
@Path 路径参数.替换url地址中 "{" 和 "}"所包括的部分
@Query 查询参数.将在url地址中追加类似"page = 1"的字符串,形成提交给服务器端的请求参数
@QueryMap 查询参数集合.在url地址中追加类似"type = text & count = 30 & page = 1 " 的字符串
@FormUrlEncoded 对表单域中填写内存进行编码处理,避免乱码
@Field 指定from表单域中每个控件的name及相应数值
@FieldMap 表单域集合
@Multipart Post提交分块请求.如果上传文件,必须指定Multipart
@Part Post提交分块请求
@Body Post提交分块请求
1.设置请求方式是注解的形式
2.接口拼接字符串更灵活
3.异步响应回调方法在主线程
/**
* 作用：GET请求最简单的写法,无Path参数和Query参数
* article/list/latest?page=%d实际是Constant下的URL_LATEST地址
* @GET()里的东西是要拼接的网址,注意直接把page=1了
*/
@GET("article/list/latest?page=1")
Call<ResponseBody> getLatestJsonString();
/**
* 其中注解中的变量用{ 变量名自定义 } 在方法参数中
* 格式:@Path("上面定义的变量名") 类型 定义的变量名 作用:替换url地址中"{"和"}"所包括的部分
* 格式:@Query("参数名") 类型 定义的参数名 作用:会拼接在URL的最后部分,类似追加了"page = 1"的字符串,最后提交给服务器
*/
@GET("article/list/{type}?")
Call<QiushiModel> getInfoList(@Path("type") String type, @Query("page") int page);
/**
* @QueryMap参数将在url地址中追加类似"type = text & count = 30 & page = 1 " 的字符串
*/
@GET("web/LoginServlet")
Call<ResponseBody> getRegInfo(@QueryMap Map<String, String> map);
/**
* 静态的URL地址
*/
@GET("http://img.265g.com/userup/1201/201201071126534773.jpg")
Call<ResponseBody> getNetworkData();
/////////////////////////////////////////////////// Post ////////////////////////////////////////////////
/**
* 作用：post网络请求，向服务器提交表单域数据
* @FormUrlEncoded:解决编码乱码问题,
*/
@FormUrlEncoded
@POST("web/LoginServlet")
Call<ResponseBody> postFormFields(@Field("username") String username,@Field("password") String password);
/**
* 作用：post网络请求，向服务器提交表单域数据
* @FormUrlEncoded:解决编码乱码问题,
*/
@FormUrlEncoded
@POST("web/LoginServlet")
Call<ResponseBody> postFormFieldMap(@FieldMap Map<String , String> map);
/**
* 上传单个文件,必须加上 @Multipart 注解
*/
@Multipart
@POST("web/UploadServlet")
Call<ResponseBody> postUploadFile(@Part("uploadfile\";filename=\"myuploadimg.png") RequestBody requestBody);
Retrofit2中Base Url与@Url不是简单的组合,而是和<a href = "...">的处理方式一样
提示:Base URL: 以"/"结尾 @Url:不要以"/"开头
Ⅵ Retrofit 源码分析
现代Android开发中，Retrofit是主流的网络请求框架，内部封装OkHttp发起请求，也是声明式Http客户端，使用接口 + 注解的方式在接口中编写请求方法。
先看下常规Retrofit的使用吧，也是通过入口API来看源码的一种好方法。
我们先来看不添加Convert转换器的方式，这种方式只能设置返回值中的泛型为ResponseBody，拿到的数据只能是Json字符串，而转换模型的操作需要我们自己做，当然如果是添加了转换器，则可以直接写模型的泛型了
从简单使用来看，我们发现以下几点
简单来讲，就是把Retrofit的构造方法私有，只能通过内部的Builder内部类的实例创建，所以我们对Retrofit的配置，都是配置到Retrofit内的Builder类后，再通过它的build方法，创建Retrofit实例。
在Builder的构造方法中，调用了Platform类的get方法，这个类是适配调用平台的，因为Retrofit的接口请求在子线程请求，而接口响应的回调方法，是可以在Android的主线程中回调的，这就肯定会涉及到Handler，而Retrofit也支持在鸿蒙上使用，这时就需要拓展Platfrom类来实现
可以看到，如果在Android平台运行，则返回的是Android实现类，该类复写了 defaultCallbackExecutor() 方法，返回 MainThreadExecutor 实例，这个Executor其实是线程池接口，只有一个 execute() 方法， MainThreadExecutor 类复写了 execute() 方法，通过Handler把传进来的Runnable转发到主线程进行回调
Http接口的实现，是通过 create() 方法创建的，内部使用的是JDK的动态代理，当我们调用代理类的方法时，会回调 InvocationHandler 的 invoke() 方法
在 InvocationHandler 类的 invoke() 方法中，如果调用的是Object类的方法，直接调用，如果是Java8的默认方法，直接调用。最后就是普通的API方法，则调用 loadServiceMethod() ，这个方法的作用是解析API方法，并缓存到一个Map中，下次调用是直接复用的，最终是需要返回一个不为null的 ServiceMethod 实例，再调用它的 invoke() 执行方法调用
loadServiceMethod () 中，如果没有命中缓存，则通过 ServiceMethod.parseAnnotations() ，解析方法注解，返回 ServiceMethod 实例，再缓存起来
其中， ServiceMethod 是一个抽象类
RequestFactory 类也是一个Builder建造者模式，只是它是通过 Builder 类拆解 Method 对象，再通过 build 方法开始解析方法上的注解
注解分2种，分别是： 方法级的注解 和 方法形参上的注解 ， 方法级的注解 是 @GET 、 @POST 这种作用于方法上的注解，而 方法形参上的注解 则是 @Path 、 @Field 这种作用于形参上的注解
最后返回 RequestFactory 实例，最后调用 HttpServiceMethod.parseAnnotations() ，进行返回值适配和转换器
ServiceMethod 是一个抽象类，通过 ServiceMethod.parseAnnotations() 静态方法，会返回其子类 HttpServiceMethod ，子类的创建则是通过 HttpServiceMethod.parseAnnotations() 创建
通过解析方法的返回值，调用 createCallAdapter() ，查找能适配返回值的 CallAdapter ，再调用 createResponseConverter() 查找对应的 Converter 转换器
发现， HttpServiceMethod 也是一个抽象类，它在 ServiceMethod 的 invoke() 基础上，调用了一个 adapt() 抽象方法，其子类 CallAdapted ，复写了该方法，最终 invoke() 方法是通过 CallAdapter 来进行处理
查找适配器的工作，发现是通过 Retrofit 实例 callAdapter() 方法，for循环查找注册的适配器，如果没有找到则抛异常，这实际上是策略模式的应用
CallAdapter.Factory 是 CallAdapter 的工厂类，每次发起请求，都是通过 CallAdapter.Factory 创建一个 CallAdapter 进行适配工作
主要方法是 Factory.get() ，创建 CallAdapter ，而 CallAdapter 的主要方法是 adapt ，该方法对Call类进行适配，以及 responseType() ，该方法返回该适配器能处理的返回值类型中的泛型Type
在 Retrofit 构建时，就添加了一个默认的 CallAdapter.Factory 实例，它就是 DefaultCallAdapterFactory ，所以就是我们什么都不配置，默认找到的 CallAdapter.Factory 就是 DefaultCallAdapterFactory
发现这个工厂类，在 get() 方法中，创建了一个 CallAdapter 的匿名内部类， responseType() 返回了Call中的泛型Type，然后 adapt() 方法创建了一个 ExecutorCallbackCall 类，该类实现了 Call 接口
它其实是一个装饰器，包装了当前请求的 Call 类实例，并把 enqueue() 方法中的回调通过 callbackExecutor 做了调用包装，这个 callbackExecutor 就是 Platform 类中的 MainThreadExecutor 实例，所以就是这里来做回调的主线程回调的！
CallAdapter 查找完后，再查找 Converter 转换器，它的逻辑和上面查找 CallAdapter 很类似，都是在 Retrofit 的实例上找， Converter 也有一个 Factory 工厂类
同样，每次请求则创建都通过 Factory 创建一个 Converter 实例， Converter 有2种
responseBodyConverter() ，把ResponseBody转换为Type类型的模型（请求响应回来时调用），就是负责把接口响应的json数据，转换为对应的模型类
requestBodyConverter() ，把Type模型转换为RequestBody，就是application/json这种类型的请求，把模型类转换为Json字符串，然后把Json字符串设置到RequestBody中
在 Retrofit实例 创建中，也默认添加了一个转换器工厂，它就是 BuiltInConverters
Ⅶ android 网络请求Retrofit+Rxjava报错
检查项目依赖的retrofit和rxjava版本是否一致，大多数java.lang.IllegalStateException: Fatal Exception thrown on Scheler.Worker thread.都是由于这个问题造成的
2. compile 'com.squareup.retrofit2:adapter-rxjava:2.1.0'
compile 'com.squareup.retrofit2:retrofit:2.1.0'
把版本调成一样的，重新gradle一下应该就阔以了
Ⅷ retrofit 请求偶尔出现404 怎么办
1.首先定义带泛型的返回结果，RetrofitAPI的原生结果映射为这种形式：classResult{StringResultMessage;intResultCode;TData;}2.处理错误的方法和@朱诗雄前辈方法差不多，放到作为静态方法放到RetroUtil里，这里ApiException为自己定义的一个异常，放入错误码和错误信息（错误码不止一个）：staticObservableflatResult(Resultresult){returnObservable.create(subscriber->{switch(result.ResultCode){caseConstants.SUCCESS_CODE:subscriber.onNext(result.Data);break;caseConstants.ERROR_CODE:subscriber.onError(newApiException(result.ResultCode,result.ResultMessage);break;default://}subscriber.onCompleted();}});}3.在API包装类对于上述Result格式的返回结果，统一调用flatMap(RetroUtil::flatResult)后的API。这样每个API的返回结果就是Observable的形式并且在errorHandler中统一处理错误了。//接口方法Observable>getUserInfo();//包装后的方法ObservablegetUserInfo(){returnmApi.getUserInfo.flatMap(RetroUtil::flatResult);}//调用时apiWrapper.getUserInfo().subscrible(user->{//处理正常逻辑},error->{//处理错误逻辑和异常，这里封装时通常也会统一处理，//提供一个默认的Action1参数，弹出//throwable的message打印日志等});
Ⅸ Retrofit2.0+RxJava网络请求异常统一处理
本文内容是基于RxJava 2.0及Retrofit 2.1分析的。参考了 Rxjava +Retrofit 你需要掌握的几个技巧，Retrofit缓存，统一对有无网络处理, 异常处理，返回结果问题
下面列出具体添加的依赖。
以下这些错误，都是在网络请求中经常见的。我们可以通过Toast弹出消息通知用户具体的异常以及加载对应的UI界面。除此之外，通过具体的异常信息，方便我们及时的排查项目中的BUG。
那么问题就来了，我们如何判断异常的类型？
这就要从服务器返回的数据格式说起了。
我们一般请求的返回都是像下面这样
服务器端返回数据约定俗称就是大概以上的格式。可能具体的code码表示的含义不一样，这个可以与服务器端人员交流，灵活变化。
关于Retrofit的基本配置就不再讲述了，这里具体讲解如何对服务器返回数据封装以及使用RxJava对错误信息处理。
封装返回数据
对于上述的服务器返回数据我们要对code做出一些判断，code不为200（假设200表示请求网络成功）就抛出异常。所以我们新建一个BaseResponse类，对应上面的数据结构。
这算是所有实体的一个基类，data可以为任何数据类型。
然后要对返回结果进行预处理，新建一个ExceptionHandle。预处理无非就是当根据返回数据BaseResponse的isOk()方法判断为是否为true，若为true则正常处理，否则抛出异常让ExceptionHandle进一步处理，判断异常为何种异常。我们先跳过前面的逻辑，先了解如何判断是何种异常？
判断异常类型
详细可看源码，下面会贴出地址。
通过ExceptionHandle.handleException(Throwable e) 即可返回一个异常，并携带具体异常类型信息。
现在我们已经知道了如何判断是否产生以上以及如何判断异常类型。接下来需要解决地就是如何把异常传递给Observer的onError(Throwable e)去处理异常。
在进行异常传递的过程中，第一步我们先要判断服务器返回的数据是否是异常，如果不是异常则返回data数据，如果是异常则抛出异常。这个时候就包含了一个数据转换的过程即把BaseResponse对象转换成data类型的对象，所以需要map()操作符。
其中HandleFuc实现了 Function<BaseResponse<T>, T> 接口
如果不出现异常则不会走第二步。如果出现异常，则需要进行第二步，即对异常进行判断，然后将ExceptionHandle.handleException(Throwable e) 返回的异常传入onError()中处理。
重点来了：当产生异常时，应该终止对onNext()方法的调用并调用onError()方法。如果不继续处理，仅通过以上步骤，虽然会调用onError()方法，但是没有对异常进行判断，并且没有取消onNext()方法。那么有没有一个好的方法，可以即取消onNext()方法，又能在其中实现异常判断的执行，并且会调用onError()方法？
如此强大的RxJava自然有这样的方法了， onErrorResumeNext() 就能实现这个要求。对于 onErrorResumeNext() ，可以简单理解为：当发生错误的时候，由另外一个Observable来代替当前的Observable并继续发射数据。
onErrorResumeNext() 中传入的参数可以是一个Function接口。这样，我们可以在Function中生成一个Observable，该Observable执行异常判断的逻辑，并调用onError()方法。
具体实现如下：
至此，我们便实现了异常判断与传递的逻辑。这样我们就可以在onError()方法中提取具体的异常状态信息，进行相应的处理。
大概流程是：map()进行数据类型转换，并检测异常。如果正常，返回data类型的数据。如果不正常，onErrorResumeNext()判断异常类型并传递异常
上述情况关闭了网络。当发起网络请求，没有网络则抛出异常，然后检测出具体异常，Toast提示异常类型，用户便知道是什么地方出错了。
demo参考地址： https://github.com/maioo/RetrofitRxJavaException
Ⅹ Android上使用retrofit+okhttp时token失效的处理方案
提前声明，以下提到的方案并没有去验证过可行性，只是记录一下，未来需要用到的时候，在仔细验证一下。
一般情况下，各个公司的移动端关于登录令牌(token)的设定都各不相同。
可先参考这个链接： https://www.hu.com/question/30267006
了解一下，本文大概想说什么。
有些公司服务端是按照oauth设计，比较标准规范，但是有些公司有自己的特定业务，未完全按照oauth来设计。基于本公司的业务逻辑，考虑了一下登录的逻辑以及token的设计。
思路如下：
token即验证令牌，每次请求都带上，refreshToken用来刷新token的，每次请求可以不带上，但是要放在移动端保存。
1.通过username，password获取token和refreshToken
2.token的有效期为2小时，refreshToken的有效期为15天
3.如果服务器端判断token过期，而refreshToken未过期，就返回错误码给客户端，则客户端通过一个特定的接口传入refreshToken参数获取新的token和refreshToken
4.如果连续15天未使用app或者用户修改了密码，则表示refreshToken过期了，则跳到登录界面，重新登录获取token和refreshToken
基于上面的思路，如果服务端走rest风格，移动端（Android）采用retrofit(v2.0+)+okhttp(v2.7.0+)网络请求框架。那么当token过期了，Android端应该如何处理呢？
通过okhttp提供的Authenticator接口，相关资料 点击这里 ，但是查看okhttp的源码会发现，只有返回HTTP的状态码为401时，才会使用Authenticator接口，如果服务端设计规范，可以尝试如下方法。
实现Authenticator接口
然后给添加给OkHttpClient
第一种方案就这样了。
但是，万事不会尽如人意，如果服务端在token过期的时候，不给返回401的HTTP状态码，而是返回如下类型的数据，叫你根据code判断。
这里要清楚HTTP状态码是指200，404，401这些，而上面的数据中的code是自定义的。如果在token过期时，服务端返回的是如上类型的数据，那么第一种方案就行不通。
通过okhttp的拦截器，okhttp 2.2.0 以后提供了拦截器的功能，相关介绍 点击这里
然后给okhttp设置拦截器
第二种方案的思路是通过拦截返回的数据，判断token是否过期，如果过期则进行一次刷新token的操作。
上面2种方案都没有进行实际验证过，希望以后有机会能验证。
完。。。