1. 网络分层
OSI七层模型
OSI七层协议模型主要是：应用层（Application）、表示层（Presentation）、会话层（Session）、传输层（Transport）、网络层（Network）、数据链路层（Data Link）、物理层（Physical）。
2. TCP/IP五层模型
TCP/IP五层模型：应用层（Application）、传输层（Transport）、网络层（Network）、数据链路层（Data Link）、物理层（Physical）。
3. 三次握手与四次挥手
第一次握手：客户端发送syn包(syn=j)到服务器，并进入SYN_SEND（邮寄）状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV（记录）状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。断开连接时服务器和客户端均可以主动发起断开TCP连接的请求，断开过程需要经过“四次握手”
第一次挥手：客户端发送报文告诉服务器没有数据要发送了
第二次挥手：服务端收到，再发送给客户端告诉它我收到了
第三次挥手：服务端向客户端发送报文，请求关闭连接
第四次挥手：客户端收到关闭连接的请求，向服务端发送报文，服务端关闭连接
4. TCP为什么三次握手不是两次握手，为什么两次握手不安全
为了实现可靠数据传输， TCP 协议的通信双方， 都必须维护一个序列号， 以标识发送出去的数据包中， 哪些是已经被对方收到的。 三次握手的过程即是通信双方相互告知序列号起始值， 并确认对方已经收到了序列号起始值的必经步骤
如果只是两次握手， 至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到确认
5. 为什么TCP是可靠的，UDP早不可靠的?为什么UDP比TCP快?
TCP/IP协议拥有三次握手双向机制，这一机制保证校验了数据，保证了他的可靠性。
UDP就没有了，udp信息发出后,不验证是否到达对方,所以不可靠。
TCP和UDP的区别
1、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接
2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达; UDP尽最大努力交付，即不保证可靠交付
3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的
UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）
4、每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
5、TCP首部开销20字节;UDP的首部开销小，只有8个字节
6、TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道
TCP粘包、分包的解决办法
粘包的原因：
(1)发送方引起的粘包是由TCP协议本身造成的，TCP为提高传输效率，发送方往往要收集到足够多的数据后才发送一包数据。若连续几次发送的数据都很少，通常TCP会根据优化算法把这些数据合成一包后一次发送出去，这样接收方就收到了粘包数据。
(2)接收方引起的粘包是由于接收方用户进程不及时接收数据，从而导致粘包现象。这是因为接收方先把收到的数据放在系统接收缓冲区，用户进程从该缓冲区取数据，若下一包数据到达时前一包数据尚未被用户进程取走，则下一包数据放到系统接收缓冲区时就接到前一包数据之后，而用户进程根据预先设定的缓冲区大小从系统接收缓冲区取数据，这样就一次取到了多包数据。
粘包的解决办法————封包：
封包就是给一段数据加上包头,这样一来数据包就分为包头和包体两部分内容了。包头其实上是个大小固定的结构体，其中有个结构体成员变量表示包体的长度，这是个很重要的变量，其他的结构体成员可根据需要自己定义。根据包头长度固定以及包头中含有包体长度的变量就能正确的拆分出一个完整的数据包。
拆包：
根据封包的包头规则解析出每一个完整的数据包，然后做相应的业务处理。
UDP分包发送和接收方重组数据包
分包：
分包发送(封装包的首部，包括包的大小、类型、序号、数量等)
1、在客户端将你要发送的内容(文件什么的都可以)分块，每块内容进行编号，然后发送；
2、服务端在接收到你的分块数据以后，根据你的客户端数据类容的编号重新组装；
3、一般我们在发送数据的时候，尽量采用比较小的数据块的方式(我的都没有超过1024的)，数据块太大的话容易出现发送和接收的数据时间长，匹配出问题。
组包：
假设一个端口只接收固定一个对方数据源,这样，收到一个数据包放到缓冲里，然后在缓冲里根据帧的序号排序(每一帧的大序号是相同的，自己可以给每一个小片加上小序号,包头里可以加上本次数据帧一共分多少片，收到一片就统计一下，判断是否收齐)。 当收齐后，这个帧去掉包头回调给上层。当在一定时间内该帧数据还没有收齐，就说明传输过程有丢包了，把已收到的都丢掉就可以。
当上层的应该收到回调的数据后，可以进行解码播放。不过在解码之前，先判断一下帧序列是否连续。做为视频数据，
如果中间有缺少的，就把这一序列都丢掉，直到下一个I帧。每个帧的序号，最好收发之间协商好，在发送的时候带上。
6. http协议
http协议是一个基于请求与响应模式的无连接，无状态，应用层的协议，支持c/s模式，简单快速，灵活。
C/S：支持C/S（客户/服务器）模式。
简单快速：客户向服务器请求服务时，只需传送请求方法和路径。
请求方法常用的有GET、HEAD、POST，每种方法规定了客户与服务器联系的类型不同。 由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
灵活：允许传输任意类型的数据对象，由Content-Type标记
无连接：每次处理一个请求，处理完成后既断开（服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。）
无状态：对事务处理没有记忆能力，少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。
另一方面，在服务器不需要先前信息时它的应答就较快。
http有两种报文：请求报文和响应报文
请求报文由请求行，请求报头，和请求数据组成
请求行：抓包第一行，包括请求方法，url和http版本
请求报头：指的就是题目中“里面的协议头部”
请求数据：指post方式提交的表单数据
响应报文由状态行，响应报头，响应正文组成
状态行：状态码
响应报头：同请求报头
响应正文：服务器返回的资源数据
接下来是http头部，既请求报头和响应报头，统称消息报头，消息报头可以分为通用报头，请求报头，响应报头，实体报头等
通用报头和实体报头既可以出现在请求报头中，也可以出现在响应报头中，通用报头包含的字段如：Date Connection Cache-Control,实体报头中有Content-Type Content-Length Content-Language Content-Encoding.
请求报头中包含的字段有：
Host,User-Agent,Accept-Encoding,Accept-Language,Connection
响应报头包含的字段：
Location，Server
HTTP请求方法
HTTP请求方法有8种，分别是GET、POST、DELETE、PUT、HEAD、TRACE、CONNECT 、OPTIONS。
其中PUT、DELETE、POST、GET分别对应着增删改查，对于移动开发最常用的就是POST和GET了。
GET：请求获取Request-URI所标识的资源
POST：在Request-URI所标识的资源后附加新的数据
HEAD：请求获取由Request-URI所标识的资源的响应消息报头
PUT： 请求服务器存储一个资源，并用Request-URI作为其标识
DELETE ：请求服务器删除Request-URI所标识的资源
TRACE ： 请求服务器回送收到的请求信息，主要用于测试或诊断
CONNECT： HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
OPTIONS ：请求查询服务器的性能，或者查询与资源相关的选项和需求
状态代码
状态代码有三位数字组成，第一个数字定义了响应的类别，且有五种可能取值：
100~199：指示信息，表示请求已接收，继续处理
200~299：请求成功，表示请求已被成功接收、理解、接受
300~399：重定向，要完成请求必须进行更进一步的操作
400~499：客户端错误，请求有语法错误或请求无法实现
500~599：服务器端错误，服务器未能实现合法的请求
常见的状态码如下：
200 OK：客户端请求成功
400 Bad Request：客户端请求有语法错误，不能被服务器所理解
401 Unauthorized：请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用
403 Forbidden：服务器收到请求，但是拒绝提供服务
500 Internal Server Error：服务器发生不可预期的错误
503 Server Unavailable：服务器当前不能处理客户端的请求，一段时间后可能恢复正常
HTTP的消息报头
消息报头分为通用报头、请求报头、响应报头、实体报头等。
消息头由键值对组成，每行一对，关键字和值用英文冒号“:”分隔。
既可以出现在请求报头，也可以出现在响应报头中
Date：表示消息产生的日期和时间
Connection：允许发送指定连接的选项
例如指定连接是连续的，或者指定“close”选项，通知服务器，在响应完成后，关闭连接
Cache-Control：用于指定缓存指令，缓存指令是单向的（响应中出现的缓存指令在请求中未必会出现），且是独立的（一个消息的缓存指令不会影响另一个消息处理的缓存机制）
请求报头通知服务器关于客户端请求的信息，典型的请求头有：
Host：请求的主机名，允许多个域名同处一个IP地址，即虚拟主机
User-Agent：发送请求的浏览器类型、操作系统等信息
Accept：客户端可识别的内容类型列表，用于指定客户端接收那些类型的信息
Accept-Encoding：客户端可识别的数据编码
Accept-Language：表示浏览器所支持的语言类型
Connection：允许客户端和服务器指定与请求/响应连接有关的选项，例如这是为Keep-Alive则表示保持连接。
Transfer-Encoding：告知接收端为了保证报文的可靠传输，对报文采用了什么编码方式。
用于服务器传递自身信息的响应，常见的响应报头：
Location：用于重定向接受者到一个新的位置，常用在更换域名的时候
Server：包含可服务器用来处理请求的系统信息，与User-Agent请求报头是相对应的
实体报头用来定义被传送资源的信息，既可以用于请求也可用于响应。
请求和响应消息都可以传送一个实体，常见的实体报头为：
Content-Type：发送给接收者的实体正文的媒体类型
Content-Lenght：实体正文的长度
Content-Language：描述资源所用的自然语言，没有设置则该选项则认为实体内容将提供给所有的语言阅读
Content-Encoding：实体报头被用作媒体类型的修饰符，它的值指示了已经被应用到实体正文的附加内容的编码，因而要获得Content-Type报头域中所引用的媒体类型，必须采用相应的解码机制。
Last-Modified：实体报头用于指示资源的最后修改日期和时间
Expires：实体报头给出响应过期的日期和时间
7. http的get和post的区别
http是应用层的协议，底层基于TCP/IP协议，所以本质上，get和post请求都是TCP请求。所以二者的区别都是体现在应用层上（HTTP的规定和浏览器/服务器的限制）
1.参数的传输方式：GET参数通过URL传递，POST放在Request body中，当然由于GET/POST都是TCP链接。GET和POST能做的事情是一样一样的。你要给GET加上request body，给POST带上url参数，技术上是完全行的通的。但是HTTP规定，当执行GET请求的时候，要贴上GET的标签(设置method为GET)，而且要求把传送的数据放在url中以方便记录。如果是POST请求，就要贴上POST的标签，并把数据放在request body里。当然，你也可以在GET的时候往request body内偷偷藏点数据，但不同服务器的处理方式也是不同的，有些服务器会读出数据，有些服务器直接忽略，所以，虽然GET可以带request body，也不能保证一定能被接收到哦;也可以在POST的时候在url上也放一些数据，让人觉得傻乎乎的。HTTP只是个行为准则，而TCP才是GET和POST怎么实现的基本
2.GET请求在URL中传送的参数是有长度限制的，2k，而POST没有，也有说是2g的。GET请求之所以限制2k，是因为数据量太大对浏览器和服务器都是很大负担。业界不成文的规定是，(大多数)浏览器通常都会限制url长度在2K个字节，而(大多数)服务器最多处理64K大小的url。超过的部分，恕不处理。
3GET产生一个TCP数据包;POST产生两个TCP数据包，.对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。不过要注意，并不是所有浏览器都会在POST中发送两次包，比如火狐
4.对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
5.GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
6.GET请求只能进行url编码，而POST支持多种编码方式。
7.GET在浏览器回退时是无害的，而POST会再次提交请求。
8.GET产生的URL地址可以被Bookmark，而POST不可以。
9.GET请求会被浏览器主动cache，而POST不会，除非手动设置。
10. GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
8. socket和http的区别：
Http协议：简单的对象访问协议，对应于应用层。Http协议是基于TCP链接的。
tcp协议：对应于传输层
ip协议：对应与网络层
TCP/IP是传输层协议，主要解决数据如何在网络中传输；而Http是应用层协议，主要解决如何包装数据。
Socket是对TCP/IP协议的封装，Socket本身并不是协议，而是一个调用接口（API），通过Socket，我们才能使用TCP/IP协议。
Http连接：http连接就是所谓的短连接，及客户端向服务器发送一次请求，服务器端响应后连接即会断掉。
socket连接：socket连接及时所谓的长连接，理论上客户端和服务端一旦建立连接，则不会主动断掉；但是由于各种环境因素可能会是连接断开，比如说：服务器端或客户端主机down了，网络故障，或者两者之间长时间没有数据传输，网络防火墙可能会断开该链接已释放网络资源。所以当一个socket连接中没有数据的传输，那么为了连续的连接需要发送心跳消息，具体心跳消息格式是开发者自己定义的。
10. https
HTTPS(全称：Hyper Text Transfer Protocol over Secure Socket Layer)，是以安全为目标的HTTP通道，简单讲是HTTP的安全版。HTTP是应用层协议，位于HTTP协议之下是传输协议TCP。TCP负责传输，HTTP则定义了数据如何进行包装，在HTTP跟TCP中间加多了一层加密层TLS/SSL，SSL是个加密套件，负责对HTTP的数据进行加密。TLS是SSL的升级版。现在提到HTTPS，加密套件基本指的是TLS。
传输加密的流程：http是应用层将数据直接给到TCP进行传输，https是应用层将数据给到TLS/SSL，将数据加密后，再给到TCP进行传输。
HTTPS是如何加密数据的：
一般来说，加密分为对称加密、非对称加密
对称加密：
对称加密的意思就是，加密数据用的密钥，跟解密数据用的密钥是一样的。
对称加密的优点在于加密、解密效率通常比较高。缺点在于，数据发送方、数据接收方需要协商、共享同一把密钥，并确保密钥不泄露给其他人。传输过程中容易被截获。
网上一个很形象的例子：假如现在小客与小服要进行一次私密的对话，他们不希望这次对话内容被其他外人知道。可是，我们平时的数据传输过程中又是明文传输的，万一被某个黑客把他们的对话内容给窃取了，那就难受了。为了解决这个问题，小服这家伙想到了一个方法来加密数据，让黑客看不到具体的内容。该方法是这样子的：在每次数据传输之前，小服会先传输小客一把密钥，然后小服在之后给小客发消息的过程中，会用这把密钥对这些消息进行加密。小客在收到这些消息后，会用之前小服给的那把密钥对这些消息进行解密，这样，小客就能得到密文里面真正的数据了。如果小客要给小服发消息，也同样用这把密钥来对消息进行加密，小服收到后也用这把密钥进行解密。 这样，就保证了数据传输的安全性。
非对称加密
非对称加密的意思就是，加密数据用的密钥（公钥），跟解密数据用的密钥（私钥）是不一样的。
网上一个很形象的例子：小服还是挺聪明的，得意了一会之后，小服意识到了密钥会被截取这个问题。倔强的小服又想到了另外一种方法：用非对称加密的方法来加密数据。该方法是这样的：小服和小客都拥有两把钥匙，一把钥匙的公开的（全世界都知道也没关系），称之为公钥；而另一把钥匙是保密（也就是只有自己才知道），称之为私钥。并且，用公钥加密的数据，只有对应的私钥才能解密；用私钥加密的数据，只有对应的公钥才能解密。所以在传输数据的过程中，小服在给小客传输数据的过程中，会用小客给他的公钥进行加密，然后小客收到后，再用自己的私钥进行解密。小客给小服发消息的时候，也一样会用小服给他的公钥进行加密，然后小服再用自己的私钥进行解密。 这样，数据就能安全着到达双方。是什么原因导致非对称加密这种方法的不安全性呢？它和对称加密方法的不安全性不同。非对称加密之所以不安全，是因为小客收到了公钥之后，无法确定这把公钥是否真的是小服。
解决的办法就是数字证书：小服再给小客发公钥的过程中，会把公钥以及小服的个人信息通过Hash算法生成消息摘要，为了防止摘要被人调换，小服还会用CA提供的私钥对消息摘要进行加密来形成数字签名，当小客拿到这份数字证书之后，就会用CA提供的公钥来对数字证书里面的数字签名进行解密得到消息摘要，然后对数字证书里面小服的公钥和个人信息进行Hash得到另一份消息摘要，然后把两份消息摘要进行对比，如果一样，则证明这些东西确实是小服的，否则就不是。
11. 加密算法
对称加密算法
Data Encryption Standard(DES)
DES 是一种典型的块加密方法：将固定长度的明文通过一系列复杂的操作变成同样长度的密文，块的长度为64位。同时，DES 使用的密钥来自定义变换过程，因此算法认为只有持有加密所用的密钥的用户才能解密密文。 DES 的密钥表面上是64位的，实际有效密钥长度为56位，其余8位可以用于奇偶校验。
DES 现在已经不被视为一种安全的加密算法，主要原因是它使用的56位密钥过短。
为了提供实用所需的安全性，可以使用 DES 的派生算法 3DES 来进行加密 (虽然3DES 也存在理论上的攻击方法)。
Advanced Encryption Standard(AES)
AES 在密码学中又称 Rijndael 加密法，用来替代原先的 DES，已经被多方分析且广泛使用。
DES与AES的比较
自DES 算法公诸于世以来，学术界围绕它的安全性等方面进行了研究并展开了激烈的争论。在技术上，对DES的批评主要集中在以下几个方面：
1、作为分组密码，DES 的加密单位仅有64 位二进制，这对于数据传输来说太小，因为每个分组仅含8 个字符，而且其中某些位还要用于奇偶校验或其他通讯开销。
2、DES 的密钥的位数太短，只有56 比特，而且各次迭代中使用的密钥是递推产生的，这种相关必然降低密码体制的安全性，在现有技术下用穷举法寻找密钥已趋于可行。
3、DES 不能对抗差分和线性密码分析。
4、DES 用户实际使用的密钥长度为56bit，理论上最大加密强度为256。DES 算法要提高加密强度（例如增加密钥长度），则系统开销呈指数增长。除采用提高硬件功能和增加并行处理功能外，从算法本身和软件技术方面都无法提高DES 算法的加密强度。
非对称加密算法
RSA
1977年由 MIT 的 Ron Rivest、Adi Shamir 和 Leonard Adleman 一起提出，以他们三人姓氏开头字母命名，是一种获得广泛使用的非对称加密算法。
对极大整数做因数分解的难度 (The Factoring Problem) 决定了 RSA 算法的可靠性。换言之，对一个极大整数做因数分解愈困难，RSA 算法就愈可靠。假如有人找到一种快速因数分解的算法的话，那么用 RSA 加密的信息的可靠性就肯定会极度下降。目前看来找到这样的算法的可能性非常小。
DES与RSA的比较
RSA算法的密钥很长，具有较好的安全性，但加密的计算量很大，加密速度较慢限制了其应用范围。为减少计算量，在传送信息时，常采用传统加密方法与公开密钥加密方法相结合的方式，即信息采用改进的DES对话密钥加密，然后使用RSA密钥加密对话密钥和信息摘要。对方收到信息后，用不同的密钥解密并可核对信息摘要。
采用DES与RSA相结合的应用，使它们的优缺点正好互补，即DES加密速度快，适合加密较长的报文，可用其加密明文；RSA加密速度慢，安全性好，应用于DES 密钥的加密，可解决DES 密钥分配的问题。
目前这种RSA和DES结合的方法已成为EMAIL保密通信标准。
12. Volley
1、 Volley的特点
Volley是谷歌大会上推出的网络通信框架（2.3之前使用HttpClient，之后使用HttpUrlConnection），它既可以访问网络获取数据，也可以加载图片，并且在性能方面进行了大幅度的调整，它的设计目的就是适合进行数据量不大但通信频繁的网络操作，而对于大数据量的操作，比如文件下载，表现很糟糕，因为volley处理http返回的默认实现是BasicNetwork，它会把返回的流全部导入内存中，下载大文件会发生内存溢出
2、 Volley执行的过程：
默认情况下，Volley中开启四个网络调度线程和一个缓存调度线程，首先请求会加入缓存队列，，缓存调度线程从缓存队列中取出线程，如果找到该请求的缓存就直接读取该缓存并解析，然后回调给主线程，如果没有找到缓存的响应，则将这个请求加入网络队列，然后网络调度线程会轮询取出网络队列中的请求，发起http请求，解析响应并将响应存入缓存，回调给主线程
3、 Volley为什么不适合下载上传大文件？为什么适合数据量小的频率高的请求？
1.volley基于请求队列，Volley的网络请求线程池默认大小为4。意味着可以并发进行4个请求，大于4个，会排在队列中。并发量小所以适合数据量下频率高的请求
2.因为Volley下载文件会将流存入内存中（是一个小于4k的缓存池），大文件会导致内存溢出，所以不能下载大文件，不能上传大文件的原因和1中差不多，设想你上传了四个大文件，同时占用了volley的四个线程，导致其他网络请求都阻塞在队列中，造成反应慢的现象
13. OKHttp
1、 OKHttp的特点
1.相较于Volley，它的最大并发量为64
2.使用连接池技术，支持5个并发的socket连接默认keepAlive时间为5分钟，解决TCP握手和挥手的效率问题，减少握手次数
3.支持Gzip压缩，且操作对用户透明，可以通过header设置，在发起请求的时候自动加入header，Accept-Encoding: gzip，而我们的服务器返回的时候header中有Content-Encoding: gzip
4.利用响应缓存来避免重复的网络请求
5.很方便的添加拦截器，通常情况下，拦截器用来添加，移除，转换请求和响应的头部信息，比如添加公参等
6.请求失败，自动重连，发生异常时重连，看源码调用recover方法重连了一次
7.支持SPDY协议(SPDY是Google开发的基于TCP的应用层协议，用以最小化网络延迟，提升网络速度，优化用户的网络使用体验。SPDY并不是一种用于替代HTTP的协议，而是对HTTP协议的增强。新协议的功能包括数据流的多路复用、请求优先级以及HTTP报头压缩。谷歌表示，引入SPDY协议后，在实验室测试中页面加载速度比原先快64%)
8.使用Okio来简化数据的访问与存储，提高性能
2、 OkHttp的缺点
1.消息回来需要切到主线程，主线程要自己去写。
2.调用比较复杂，需要自己进行封装。
3.缓存失效：网络请求时一般都会获取手机的一些硬件或网络信息，比如使用的网络环境。同时为了信息传输的安全性，可能还会对请求进行加密。在这些情况下OkHttp的缓存系统就会失效了，导致用户在无网络情况下不能访问缓存。
3、 OkHttp框架中都用到了哪些设计模式
1.最明显的Builder设计模式，如构建对象OkHttpClient，还有单利模式
2.工厂方法模式，如源码中的接口Call
3.观察者模式如EventListener，监听请求和响应
4.策略模式
5.责任链模式，如拦截器
14. Retrofit
Retrofit底层是基于OkHttp实现的，与其他网络框架不同的是，它更多使用运行时注解的方式提供功能
1、 原理
通过java接口以及注解来描述网络请求，并用动态代理的方式生成网络请求的request，然后通过client调用相应的网络框架（默认okhttp）去发起网络请求，并将返回的response通过converterFactorty转换成相应的数据model，最后通过calladapter转换成其他数据方式（如rxjava Observable）
2、 Retrofit流程
（1）通过解析 网络请求接口的注解 配置 网络请求参数
（2）通过 动态代理 生成 网络请求对象
（3）通过 网络请求适配器 将 网络请求对象 进行平台适配
（4）通过 网络请求执行器 发送网络请求
（5）通过 数据转换器 解析服务器返回的数据
（6）通过 回调执行器 切换线程（子线程 ->>主线程）
（7）用户在主线程处理返回结果
3、 Retrofit优点
1.可以配置不同HTTP client来实现网络请求，如okhttp、httpclient等；
2.请求的方法参数注解都可以定制；
3.支持同步、异步和RxJava；
4.超级解耦；
5.可以配置不同的反序列化工具来解析数据，如json、xml等
6.框架使用了很多设计模式
网友评论