观战Retrofit开发中的哪点事

又是一年中秋佳节，祝各位中秋节快乐。

今天我们来聊聊这个最近很火的网络请求库retrofit，在此基础上会延伸出一些列的知识点。现在关于retrofit的文章很多，我之所以写这篇文章的原因在于：8月份负责假设新客户端底层的过程中首次尝试使用该库，并取得非常不错的效果，不到20天的时间内实现新产品的快速开发。

另外因为个人的原因，在写完基础框架及发布两个基础版本之后，我也选择的离职。现在，留给自己10天的时间，用来对2016年做个简短的总结，也希望能帮助各位。首先简单的说说会总结哪方面的，觉得感兴趣的同学可以关注下：

1. 网络请求及优化，以retrofit作为出发点，其中穿插源码分析
2. ANR原理及实现对ANR的监控
3. App省点开发技巧
4. apk混淆与逆向部分，其中拿一些市面上的app做示例。
5. App快速开发框架部分，其中夹杂这一些从后端到移动端设计的敏感点，也会去整理出一个基本的app开发框架做演示
6. 最后，就是一些杂七杂八点吧。对插件化之类的，目前市面上的文章已经非常不错了。

暂时的计划是这样。话不多说，这就开始。

---

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 usern