Android網(wǎng)絡(luò)編程總結(jié)

Android網(wǎng)絡(luò)編程總結(jié)

1.網(wǎng)絡(luò)分層

OSI七層模型
OSI七層協(xié)議模型主要是：應(yīng)用層（Application）蚤蔓、表示層（Presentation）、會話層（Session）闹炉、傳輸層（Transport）、網(wǎng)絡(luò)層（Network）、數(shù)據(jù)鏈路層（Data Link）苏研、物理層（Physical）寸齐。

2.TCP/IP五層模型

TCP/IP五層模型：應(yīng)用層（Application）欲诺、傳輸層（Transport）抄谐、網(wǎng)絡(luò)層（Network）、數(shù)據(jù)鏈路層（Data Link）扰法、物理層（Physical）蛹含。

3.三次握手與四次揮手

第一次握手：客戶端發(fā)送syn包(syn=j)到服務(wù)器，并進入SYN_SEND狀態(tài)塞颁，等待服務(wù)器確認浦箱；
第二次握手：服務(wù)器收到syn包，必須確認客戶的SYN（ack=j+1）祠锣，同時自己也發(fā)送一個SYN包（syn=k）酷窥，即SYN+ACK包，此時服務(wù)器進入SYN_RECV狀態(tài)锤岸；
第三次握手：客戶端收到服務(wù)器的SYN＋ACK包竖幔，向服務(wù)器發(fā)送確認包ACK(ack=k+1)，此包發(fā)送完畢是偷，客戶端和服務(wù)器進入ESTABLISHED狀態(tài)拳氢，完成三次握手。
握手過程中傳送的包里不包含數(shù)據(jù)蛋铆，三次握手完畢后馋评，客戶端與服務(wù)器才正式開始傳送數(shù)據(jù)。理想狀態(tài)下刺啦，TCP連接一旦建立留特，在通信雙方中的任何一方主動關(guān)閉連接之前，TCP 連接都將被一直保持下去玛瘸。斷開連接時服務(wù)器和客戶端均可以主動發(fā)起斷開TCP連接的請求蜕青，斷開過程需要經(jīng)過“四次握手”
第一次揮手：客戶端發(fā)送報文告訴服務(wù)器沒有數(shù)據(jù)要發(fā)送了
第二次揮手：服務(wù)端收到，再發(fā)送給客戶端告訴它我收到了
第三次揮手：服務(wù)端向客戶端發(fā)送報文糊渊，請求關(guān)閉連接
第四次揮手：客戶端收到關(guān)閉連接的請求右核，向服務(wù)端發(fā)送報文，服務(wù)端關(guān)閉連接

4.TCP為什么三次握手不是兩次握手渺绒，為什么兩次握手不安全

為了實現(xiàn)可靠數(shù)據(jù)傳輸贺喝， TCP 協(xié)議的通信雙方， 都必須維護一個序列號宗兼， 以標識發(fā)送出去的數(shù)據(jù)包中躏鱼， 哪些是已經(jīng)被對方收到的。 三次握手的過程即是通信雙方相互告知序列號起始值殷绍， 并確認對方已經(jīng)收到了序列號起始值的必經(jīng)步驟
如果只是兩次握手染苛， 至多只有連接發(fā)起方的起始序列號能被確認， 另一方選擇的序列號則得不到確認

5.為什么TCP是可靠的主到，UDP早不可靠的?為什么UDP比TCP快?

TCP/IP協(xié)議擁有三次握手雙向機制茶行，這一機制保證校驗了數(shù)據(jù)贸呢，保證了他的可靠性。
UDP就沒有了拢军，udp信息發(fā)出后,不驗證是否到達對方,所以不可靠。

6.http協(xié)議

http協(xié)議是一個基于請求與響應(yīng)模式的無連接怔鳖，無狀態(tài)茉唉，應(yīng)用層的協(xié)議，支持c/s模式结执，簡單快速度陆，靈活
簡單快速：協(xié)議簡單，通信速度快
靈活：允許傳輸任意類型的數(shù)據(jù)對象献幔，由Content-Type標記
無連接：每次處理一個請求懂傀，處理完成后既斷開
無狀態(tài)：對事務(wù)處理沒有記憶能力
http有兩種報文：請求報文和響應(yīng)報文
請求報文由請求行，請求報頭蜡感，和請求數(shù)據(jù)組成
請求行：抓包第一行蹬蚁，包括請求方法，url和http版本
請求報頭：指的就是題目中“里面的協(xié)議頭部”
請求數(shù)據(jù)：指post方式提交的表單數(shù)據(jù)
響應(yīng)報文由狀態(tài)行郑兴，響應(yīng)報頭犀斋，響應(yīng)正文組成
狀態(tài)行：狀態(tài)碼
響應(yīng)報頭：同請求報頭
響應(yīng)正文：服務(wù)器返回的資源數(shù)據(jù)
接下來是http頭部，既請求報頭和響應(yīng)報頭情连，統(tǒng)稱消息報頭叽粹，消息報頭可以分為通用報頭，請求報頭却舀，響應(yīng)報頭虫几，實體報頭等
通用報頭和實體報頭既可以出現(xiàn)在請求報頭中，也可以出現(xiàn)在響應(yīng)報頭中挽拔，通用報頭包含的字段如：Date Connection Cache-Control,實體報頭中有Content-Type Content-Length Content-Language Content-Encoding.
請求報頭中包含的字段有：
Host,User-Agent,Accept-Encoding,Accept-Language,Connection
響應(yīng)報頭包含的字段：
Location辆脸，Server

7.http的get和post的區(qū)別

http是應(yīng)用層的協(xié)議，底層基于TCP/IP協(xié)議篱昔，所以本質(zhì)上每强，get和post請求都是TCP請求。所以二者的區(qū)別都是體現(xiàn)在應(yīng)用層上（HTTP的規(guī)定和瀏覽器/服務(wù)器的限制）
1.參數(shù)的傳輸方式：GET參數(shù)通過URL傳遞州刽，POST放在Request body中空执。
2.GET請求在URL中傳送的參數(shù)是有長度限制的，而POST沒有穗椅。
3.對于GET方式的請求辨绊，瀏覽器會把http header和data一并發(fā)送出去，服務(wù)器響應(yīng)200（返回數(shù)據(jù)）匹表；而對于POST门坷，瀏覽器先發(fā)送header宣鄙，服務(wù)器響應(yīng)100 continue，瀏覽器再發(fā)送data默蚌，服務(wù)器響應(yīng)200 ok（返回數(shù)據(jù)）冻晤。不過要注意，并不是所有瀏覽器都會在POST中發(fā)送兩次包绸吸，比如火狐
4.對參數(shù)的數(shù)據(jù)類型鼻弧，GET只接受ASCII字符，而POST沒有限制锦茁。
5.GET比POST更不安全攘轩，因為參數(shù)直接暴露在URL上，所以不能用來傳遞敏感信息码俩。
6.GET請求只能進行url編碼度帮，而POST支持多種編碼方式。
7.GET在瀏覽器回退時是無害的稿存，而POST會再次提交請求笨篷。
8.GET產(chǎn)生的URL地址可以被Bookmark，而POST不可以瓣履。
9.GET請求會被瀏覽器主動cache冕屯，而POST不會，除非手動設(shè)置拂苹。

8.socket和http的區(qū)別：

Http協(xié)議：簡單的對象訪問協(xié)議安聘，對應(yīng)于應(yīng)用層。Http協(xié)議是基于TCP鏈接的瓢棒。
tcp協(xié)議：對應(yīng)于傳輸層
ip協(xié)議：對應(yīng)與網(wǎng)絡(luò)層
TCP/IP是傳輸層協(xié)議浴韭，主要解決數(shù)據(jù)如何在網(wǎng)絡(luò)中傳輸；而Http是應(yīng)用層協(xié)議脯宿，主要解決如何包裝數(shù)據(jù)念颈。
Socket是對TCP/IP協(xié)議的封裝，Socket本身并不是協(xié)議连霉，而是一個調(diào)用接口（API）榴芳，通過Socket，我們才能使用TCP/IP協(xié)議跺撼。
Http連接：http連接就是所謂的短連接窟感，及客戶端向服務(wù)器發(fā)送一次請求，服務(wù)器端相應(yīng)后連接即會斷掉歉井。
socket連接：socket連接及時所謂的長連接柿祈，理論上客戶端和服務(wù)端一旦建立連接，則不會主動斷掉；但是由于各種環(huán)境因素可能會是連接斷開躏嚎，比如說：服務(wù)器端或客戶端主機down了蜜自，網(wǎng)絡(luò)故障，或者兩者之間長時間沒有數(shù)據(jù)傳輸卢佣，網(wǎng)絡(luò)防火墻可能會斷開該鏈接已釋放網(wǎng)絡(luò)資源重荠。所以當(dāng)一個socket連接中沒有數(shù)據(jù)的傳輸，那么為了位置連續(xù)的連接需要發(fā)送心跳消息虚茶，具體心跳消息格式是開發(fā)者自己定義的晚缩。

9.TCP與UDP區(qū)別總結(jié)：

1、TCP面向連接（如打電話要先撥號建立連接）;UDP是無連接的媳危，即發(fā)送數(shù)據(jù)之前不需要建立連接
2、TCP提供可靠的服務(wù)冈敛。也就是說待笑，通過TCP連接傳送的數(shù)據(jù)，無差錯抓谴，不丟失暮蹂，不重復(fù)，且按序到達;UDP盡最大努力交付癌压，即不保 證可靠交付
3仰泻、TCP面向字節(jié)流，實際上是TCP把數(shù)據(jù)看成一連串無結(jié)構(gòu)的字節(jié)流;UDP是面向報文的
UDP沒有擁塞控制滩届，因此網(wǎng)絡(luò)出現(xiàn)擁塞不會使源主機的發(fā)送速率降低（對實時應(yīng)用很有用集侯，如IP電話，實時視頻會議等）
4帜消、每一條TCP連接只能是點到點的;UDP支持一對一棠枉，一對多，多對一和多對多的交互通信
5泡挺、TCP首部開銷20字節(jié);UDP的首部開銷小辈讶，只有8個字節(jié)
6、TCP的邏輯通信信道是全雙工的可靠信道娄猫，UDP則是不可靠信道

10.https

HTTPS(全稱：Hyper Text Transfer Protocol over Secure Socket Layer)贱除，是以安全為目標的HTTP通道，簡單講是HTTP的安全版媳溺。HTTP是應(yīng)用層協(xié)議月幌，位于HTTP協(xié)議之下是傳輸協(xié)議TCP。TCP負責(zé)傳輸悬蔽，HTTP則定義了數(shù)據(jù)如何進行包裝飞醉，在HTTP跟TCP中間加多了一層加密層TLS/SSL，SSL是個加密套件，負責(zé)對HTTP的數(shù)據(jù)進行加密缅帘。TLS是SSL的升級版≈崾酰現(xiàn)在提到HTTPS，加密套件基本指的是TLS钦无。
傳輸加密的流程：http是應(yīng)用層將數(shù)據(jù)直接給到TCP進行傳輸逗栽，https是應(yīng)用層將數(shù)據(jù)給到TLS/SSL，將數(shù)據(jù)加密后失暂，再給到TCP進行傳輸彼宠。
HTTPS是如何加密數(shù)據(jù)的：
一般來說，加密分為對稱加密弟塞、非對稱加密

  1. 對稱加密：
    對稱加密的意思就是凭峡，加密數(shù)據(jù)用的密鑰，跟解密數(shù)據(jù)用的密鑰是一樣的决记。
    對稱加密的優(yōu)點在于加密摧冀、解密效率通常比較高。缺點在于系宫，數(shù)據(jù)發(fā)送方索昂、數(shù)據(jù)接收方需要協(xié)商固阁、共享同一把密鑰骑疆，并確保密鑰不泄露給其他人甚脉。傳輸過程中容易被截獲筛峭。
    網(wǎng)上一個很形象的例子：假如現(xiàn)在小客與小服要進行一次私密的對話撕贞，他們不希望這次對話內(nèi)容被其他外人知道螃壤〈土樱可是映九，我們平時的數(shù)據(jù)傳輸過程中又是明文傳輸?shù)募档剑f一被某個黑客把他們的對話內(nèi)容給竊取了秉宿，那就難受了。為了解決這個問題屯碴，小服這家伙想到了一個方法來加密數(shù)據(jù)描睦，讓黑客看不到具體的內(nèi)容。該方法是這樣子的：在每次數(shù)據(jù)傳輸之前导而，小服會先傳輸小客一把密鑰忱叭，然后小服在之后給小客發(fā)消息的過程中，會用這把密鑰對這些消息進行加密今艺。小客在收到這些消息后韵丑，會用之前小服給的那把密鑰對這些消息進行解密，這樣虚缎，小客就能得到密文里面真正的數(shù)據(jù)了撵彻。如果小客要給小服發(fā)消息钓株，也同樣用這把密鑰來對消息進行加密，小服收到后也用這把密鑰進行解密陌僵。 這樣轴合，就保證了數(shù)據(jù)傳輸?shù)陌踩浴?br> 2.非對稱加密
    非對稱加密的意思就是，加密數(shù)據(jù)用的密鑰（公鑰）碗短，跟解密數(shù)據(jù)用的密鑰（私鑰）是不一樣的受葛。
    網(wǎng)上一個很形象的例子：小服還是挺聰明的，得意了一會之后偎谁，小服意識到了密鑰會被截取這個問題总滩。倔強的小服又想到了另外一種方法：用非對稱加密的方法來加密數(shù)據(jù)。該方法是這樣的：小服和小客都擁有兩把鑰匙巡雨，一把鑰匙的公開的（全世界都知道也沒關(guān)系）闰渔，稱之為公鑰；而另一把鑰匙是保密（也就是只有自己才知道）铐望，稱之為私鑰冈涧。并且，用公鑰加密的數(shù)據(jù)蝌以，只有對應(yīng)的私鑰才能解密；用私鑰加密的數(shù)據(jù)何之，只有對應(yīng)的公鑰才能解密跟畅。所以在傳輸數(shù)據(jù)的過程中，小服在給小客傳輸數(shù)據(jù)的過程中溶推，會用小客給他的公鑰進行加密徊件，然后小客收到后，再用自己的私鑰進行解密蒜危。小客給小服發(fā)消息的時候虱痕，也一樣會用小服給他的公鑰進行加密，然后小服再用自己的私鑰進行解密辐赞。 這樣部翘，數(shù)據(jù)就能安全著到達雙方。是什么原因?qū)е路菍ΨQ加密這種方法的不安全性呢响委？它和對稱加密方法的不安全性不同新思。非對稱加密之所以不安全，是因為小客收到了公鑰之后赘风，無法確定這把公鑰是否真的是小服夹囚。
    解決的辦法就是數(shù)字證書：小服再給小客發(fā)公鑰的過程中，會把公鑰以及小服的個人信息通過Hash算法生成消息摘要邀窃，為了防止摘要被人調(diào)換荸哟，小服還會用CA提供的私鑰對消息摘要進行加密來形成數(shù)字簽名，當(dāng)小客拿到這份數(shù)字證書之后，就會用CA提供的公鑰來對數(shù)字證書里面的數(shù)字簽名進行解密得到消息摘要鞍历，然后對數(shù)字證書里面小服的公鑰和個人信息進行Hash得到另一份消息摘要舵抹，然后把兩份消息摘要進行對比，如果一樣堰燎，則證明這些東西確實是小服的掏父，否則就不是。

11.加密算法

1.對稱加密算法
Data Encryption Standard(DES)
DES 是一種典型的塊加密方法：將固定長度的明文通過一系列復(fù)雜的操作變成同樣長度的密文秆剪，塊的長度為64位赊淑。同時，DES 使用的密鑰來自定義變換過程仅讽，因此算法認為只有持有加密所用的密鑰的用戶才能解密密文陶缺。 DES 的密鑰表面上是64位的，實際有效密鑰長度為56位洁灵，其余8位可以用于奇偶校驗饱岸。
DES 現(xiàn)在已經(jīng)不被視為一種安全的加密算法，主要原因是它使用的56位密鑰過短徽千。
為了提供實用所需的安全性苫费，可以使用 DES 的派生算法 3DES 來進行加密 (雖然3DES 也存在理論上的攻擊方法)。
Advanced Encryption Standard(AES)
AES 在密碼學(xué)中又稱 Rijndael 加密法双抽，用來替代原先的 DES百框，已經(jīng)被多方分析且廣泛使用。
DES與AES的比較
自DES 算法公諸于世以來牍汹，學(xué)術(shù)界圍繞它的安全性等方面進行了研究并展開了激烈的爭論铐维。在技術(shù)上，對DES的批評主要集中在以下幾個方面：
1慎菲、作為分組密碼嫁蛇，DES 的加密單位僅有64 位二進制，這對于數(shù)據(jù)傳輸來說太小露该，因為每個分組僅含8 個字符睬棚，而且其中某些位還要用于奇偶校驗或其他通訊開銷。
2解幼、DES 的密鑰的位數(shù)太短闸拿，只有56 比特，而且各次迭代中使用的密鑰是遞推產(chǎn)生的书幕，這種相關(guān)必然降低密碼體制的安全性新荤，在現(xiàn)有技術(shù)下用窮舉法尋找密鑰已趨于可行。
3台汇、DES 不能對抗差分和線性密碼分析苛骨。
4篱瞎、DES 用戶實際使用的密鑰長度為56bit，理論上最大加密強度為256痒芝。DES 算法要提高加密強度（例如增加密鑰長度）俐筋，則系統(tǒng)開銷呈指數(shù)增長。除采用提高硬件功能和增加并行處理功能外严衬，從算法本身和軟件技術(shù)方面都無法提高DES 算法的加密強度澄者。

  1. 非對稱加密算法
    RSA
    1977年由 MIT 的 Ron Rivest、Adi Shamir 和 Leonard Adleman 一起提出请琳，以他們?nèi)诵帐祥_頭字母命名粱挡，是一種獲得廣泛使用的非對稱加密算法。
    對極大整數(shù)做因數(shù)分解的難度 (The Factoring Problem) 決定了 RSA 算法的可靠性俄精。換言之询筏，對一個極大整數(shù)做因數(shù)分解愈困難，RSA 算法就愈可靠竖慧。假如有人找到一種快速因數(shù)分解的算法的話嫌套，那么用 RSA 加密的信息的可靠性就肯定會極度下降。目前看來找到這樣的算法的可能性非常小圾旨。
    DES與RSA的比較
    RSA算法的密鑰很長踱讨，具有較好的安全性，但加密的計算量很大砍的，加密速度較慢限制了其應(yīng)用范圍痹筛。為減少計算量，在傳送信息時挨约，常采用傳統(tǒng)加密方法與公開密鑰加密方法相結(jié)合的方式味混，即信息采用改進的DES對話密鑰加密产雹，然后使用RSA密鑰加密對話密鑰和信息摘要诫惭。對方收到信息后，用不同的密鑰解密并可核對信息摘要蔓挖。
    采用DES與RSA相結(jié)合的應(yīng)用夕土，使它們的優(yōu)缺點正好互補，即DES加密速度快瘟判，適合加密較長的報文怨绣，可用其加密明文；RSA加密速度慢拷获，安全性好篮撑，應(yīng)用于DES 密鑰的加密，可解決DES 密鑰分配的問題匆瓜。
    目前這種RSA和DES結(jié)合的方法已成為EMAIL保密通信標準赢笨。

12.Volley

1未蝌、Volley的特點
Volley是谷歌大會上推出的網(wǎng)絡(luò)通信框架（2.3之前使用HttpClient，之后使用HttpUrlConnection）茧妒，它既可以訪問網(wǎng)絡(luò)獲取數(shù)據(jù)萧吠，也可以加載圖片，并且在性能方面進行了大幅度的調(diào)整桐筏，它的設(shè)計目的就是適合進行數(shù)據(jù)量不大但通信頻繁的網(wǎng)絡(luò)操作纸型，而對于大數(shù)據(jù)量的操作，比如文件下載梅忌，表現(xiàn)很糟糕狰腌，因為volley處理http返回的默認實現(xiàn)是BasicNetwork，它會把返回的流全部導(dǎo)入內(nèi)存中铸鹰，下載大文件會發(fā)生內(nèi)存溢出
2癌别、Volley執(zhí)行的過程：
默認情況下，Volley中開啟四個網(wǎng)絡(luò)調(diào)度線程和一個緩存調(diào)度線程蹋笼，首先請求會加入緩存隊列展姐，，緩存調(diào)度線程從緩存隊列中取出線程剖毯，如果找到該請求的緩存就直接讀取該緩存并解析圾笨，然后回調(diào)給主線程，如果沒有找到緩存的響應(yīng)逊谋，則將這個請求加入網(wǎng)絡(luò)隊列擂达，然后網(wǎng)絡(luò)調(diào)度線程會輪詢?nèi)〕鼍W(wǎng)絡(luò)隊列中的請求，發(fā)起http請求胶滋，解析響應(yīng)并將響應(yīng)存入緩存板鬓，回調(diào)給主線程
3、Volley為什么不適合下載上傳大文件究恤？為什么適合數(shù)據(jù)量小的頻率高的請求俭令？
1.volley基于請求隊列，Volley的網(wǎng)絡(luò)請求線程池默認大小為4部宿。意味著可以并發(fā)進行4個請求抄腔，大于4個，會排在隊列中理张。并發(fā)量小所以適合數(shù)據(jù)量下頻率高的請求
2.因為Volley下載文件會將流存入內(nèi)存中（是一個小于4k的緩存池）赫蛇，大文件會導(dǎo)致內(nèi)存溢出，所以不能下載大文件雾叭，不能上傳大文件的原因和1中差不多悟耘，設(shè)想你上傳了四個大文件，同時占用了volley的四個線程织狐，導(dǎo)致其他網(wǎng)絡(luò)請求都阻塞在隊列中暂幼，造成反應(yīng)慢的現(xiàn)象

13.OKHttp

1掘殴、OKHttp的特點
1.相較于Volley，它的最大并發(fā)量為64
2.使用連接池技術(shù)粟誓，支持5個并發(fā)的socket連接默認keepAlive時間為5分鐘奏寨，解決TCP握手和揮手的效率問題，減少握手次數(shù)
3.支持Gzip壓縮鹰服，且操作對用戶透明病瞳，可以通過header設(shè)置，在發(fā)起請求的時候自動加入header悲酷，Accept-Encoding: gzip套菜，而我們的服務(wù)器返回的時候header中有Content-Encoding: gzip
4.利用響應(yīng)緩存來避免重復(fù)的網(wǎng)絡(luò)請求
5.很方便的添加攔截器，通常情況下设易，攔截器用來添加逗柴，移除，轉(zhuǎn)換請求和響應(yīng)的頭部信息顿肺，比如添加公參等
6.請求失敗戏溺，自動重連，發(fā)生異常時重連屠尊，看源碼調(diào)用recover方法重連了一次
7.支持SPDY協(xié)議(SPDY是Google開發(fā)的基于TCP的應(yīng)用層協(xié)議旷祸，用以最小化網(wǎng)絡(luò)延遲，提升網(wǎng)絡(luò)速度讼昆，優(yōu)化用戶的網(wǎng)絡(luò)使用體驗托享。SPDY并不是一種用于替代HTTP的協(xié)議，而是對HTTP協(xié)議的增強浸赫。新協(xié)議的功能包括數(shù)據(jù)流的多路復(fù)用闰围、請求優(yōu)先級以及HTTP報頭壓縮。谷歌表示既峡，引入SPDY協(xié)議后羡榴，在實驗室測試中頁面加載速度比原先快64%)
8.使用Okio來簡化數(shù)據(jù)的訪問與存儲，提高性能
2涧狮、 OkHttp的缺點
1.消息回來需要切到主線程炕矮，主線程要自己去寫么夫。
2.調(diào)用比較復(fù)雜者冤，需要自己進行封裝。
3.緩存失效：網(wǎng)絡(luò)請求時一般都會獲取手機的一些硬件或網(wǎng)絡(luò)信息档痪，比如使用的網(wǎng)絡(luò)環(huán)境涉枫。同時為了信息傳輸?shù)陌踩裕赡苓€會對請求進行加密腐螟。在這些情況下OkHttp的緩存系統(tǒng)就會失效了愿汰，導(dǎo)致用戶在無網(wǎng)絡(luò)情況下不能訪問緩存困后。
3、 OkHttp框架中都用到了哪些設(shè)計模式
1.最明顯的Builder設(shè)計模式衬廷，如構(gòu)建對象OkHttpClient摇予，還有單利模式
2.工廠方法模式，如源碼中的接口Call
3.觀察者模式如EventListener吗跋，監(jiān)聽請求和響應(yīng)
4.策略模式
5.責(zé)任鏈模式侧戴，如攔截器

14.Retrofit

Retrofit底層是基于OkHttp實現(xiàn)的，與其他網(wǎng)絡(luò)框架不同的是跌宛，它更多使用運行時注解的方式提供功能
1酗宋、原理
通過java接口以及注解來描述網(wǎng)絡(luò)請求，并用動態(tài)代理的方式生成網(wǎng)絡(luò)請求的request疆拘，然后通過client調(diào)用相應(yīng)的網(wǎng)絡(luò)框架（默認okhttp）去發(fā)起網(wǎng)絡(luò)請求蜕猫，并將返回的response通過converterFactorty轉(zhuǎn)換成相應(yīng)的數(shù)據(jù)model，最后通過calladapter轉(zhuǎn)換成其他數(shù)據(jù)方式（如rxjava Observable）
2哎迄、Retrofit流程
（1）通過解析 網(wǎng)絡(luò)請求接口的注解 配置 網(wǎng)絡(luò)請求參數(shù)
（2）通過 動態(tài)代理 生成 網(wǎng)絡(luò)請求對象
（3）通過 網(wǎng)絡(luò)請求適配器 將 網(wǎng)絡(luò)請求對象 進行平臺適配
（4）通過 網(wǎng)絡(luò)請求執(zhí)行器 發(fā)送網(wǎng)絡(luò)請求
（5）通過 數(shù)據(jù)轉(zhuǎn)換器 解析服務(wù)器返回的數(shù)據(jù)
（6）通過 回調(diào)執(zhí)行器 切換線程（子線程 ->>主線程）
（7）用戶在主線程處理返回結(jié)果
3回右、 Retrofit優(yōu)點
1.可以配置不同HTTP client來實現(xiàn)網(wǎng)絡(luò)請求，如okhttp漱挚、httpclient等楣黍；
2.請求的方法參數(shù)注解都可以定制；
3.支持同步棱烂、異步和RxJava租漂；
4.超級解耦；
5.可以配置不同的反序列化工具來解析數(shù)據(jù)颊糜，如json哩治、xml等
6.框架使用了很多設(shè)計模式

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末，一起剝皮案震驚了整個濱河市衬鱼，隨后出現(xiàn)的幾起案子业筏，更是在濱河造成了極大的恐慌，老刑警劉巖鸟赫，帶你破解...
    沈念sama閱讀 211,123評論 6贊 490
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件蒜胖，死亡現(xiàn)場離奇詭異，居然都是意外死亡抛蚤，警方通過查閱死者的電腦和手機台谢，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 90,031評論 2贊 384
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進店門，熙熙樓的掌柜王于貴愁眉苦臉地迎上來岁经，“玉大人朋沮，你說我怎么就攤上這事∽喝溃” “怎么了樊拓？”我有些...
    開封第一講書人閱讀 156,723評論 0贊 345
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵纠亚，是天一觀的道長。 經(jīng)常有香客問我筋夏，道長蒂胞，這世上最難降的妖魔是什么？ 我笑而不...
    開封第一講書人閱讀 56,357評論 1贊 283
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任条篷，我火速辦了婚禮啤誊，結(jié)果婚禮上，老公的妹妹穿的比我還像新娘拥娄。我一直安慰自己蚊锹，他們只是感情好，可當(dāng)我...
    茶點故事閱讀 65,412評論 5贊 384
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布稚瘾。 她就那樣靜靜地躺著牡昆，像睡著了一般。 火紅的嫁衣襯著肌膚如雪摊欠。 梳的紋絲不亂的頭發(fā)上丢烘，一...
    開封第一講書人閱讀 49,760評論 1贊 289
  • 城市分裂傳說
    那天，我揣著相機與錄音些椒，去河邊找鬼播瞳。 笑死，一個胖子當(dāng)著我的面吹牛免糕，可吹牛的內(nèi)容都是我干的赢乓。 我是一名探鬼主播，決...
    沈念sama閱讀 38,904評論 3贊 405
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼石窑，長吁一口氣：“原來是場噩夢啊……” “哼牌芋！你這毒婦竟也來了？” 一聲冷哼從身側(cè)響起松逊，我...
    開封第一講書人閱讀 37,672評論 0贊 266
  • 萬榮殺人案實錄
    序言：老撾萬榮一對情侶失蹤躺屁，失蹤者是張志新（化名）和其女友劉穎，沒想到半個月后经宏，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體犀暑，經(jīng)...
    沈念sama閱讀 44,118評論 1贊 303
  • ?護林員之死
    正文 獨居荒郊野嶺守林人離奇死亡，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 36,456評論 2贊 325
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年烁兰，在試婚紗的時候發(fā)現(xiàn)自己被綠了耐亏。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 38,599評論 1贊 340
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡缚柏，死狀恐怖苹熏，靈堂內(nèi)的尸體忽然破棺而出碟贾，到底是詐尸還是另有隱情币喧，我是刑警寧澤轨域，帶...
    沈念sama閱讀 34,264評論 4贊 328
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布，位于F島的核電站杀餐，受9級特大地震影響干发，放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜史翘，卻給世界環(huán)境...
    茶點故事閱讀 39,857評論 3贊 312
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一枉长、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧琼讽，春花似錦必峰、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,731評論 0贊 21
  • 一樁弒父案吼蚁，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至问欠，卻和暖如春肝匆，著一層夾襖步出監(jiān)牢的瞬間，已是汗流浹背顺献。 一陣腳步聲響...
    開封第一講書人閱讀 31,956評論 1贊 264
  • 情欲美人皮
    我被黑心中介騙來泰國打工旗国， 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留，地道東北人注整。 一個月前我還...
    沈念sama閱讀 46,286評論 2贊 360
  • 代替公主和親
    正文 我出身青樓能曾，卻偏偏與公主長得像，于是被迫代替她去往敵國和親肿轨。 傳聞我的和親對象是個殘疾皇子借浊，可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 43,465評論 2贊 348