想象下，如果沒有httpurlconnection和httpclient，一次性的api請求得有多麻煩。
現在，我們又多了一種okhttp，square出品。當然底層還是封裝socket。為什麼，為什麼還要再出乙個okhttp，吃飽了撐的？肯定不是，那究竟有什麼好的？自己動手查一下吧。
我們假設一下，應該是httpurlconnection和httpclient自身有bug和缺陷，所以才會再根據如今的網路情況設計okhttp吧。
如果你看過volley的源**，就知道當sdk>9時，預設使用httpurlconnection，<9的就用httpclient。
既然》9採用httpurlconnection了，那說明，再以後的版本中由android修復了，那httpclient呢，apache更新維護太慢，基本要被淘汰。
如果說你的專案還在用httpclient，甚至還在為httpclient的某些bug而苦惱，那麼你該考慮是否該換了。畢竟現實不可能給你那麼多時間去調研debug。
當然okhttp也是有bug的，從github上的issues就能知道，如果你用okhttp發現了bug，又不知道如何解決，不妨去那看看。
說了這麼多，stay想表達的有兩層意思：
1. 不妨使用新技術來解決老技術的缺陷，就好像如果現在還有人用tabactivity，tabhost，那給人感覺一定是做外包出身的。
2. 嘗試新技術的成本不高的，如果它開源，並且有release版本(1.0+)，你都可以整合試試。新技術都是為了更好的開發而被設計出來的，就算它不是最優的解決方案，至少設計理念，解決思路是值得參考的。
今天下午花了點時間，粗略的過了一遍okhttp，有意思的是，為了讓大家無縫整合，也是蠻拼的，額外提供httpurlconnection和httpclient的寫法。你只需要再依賴okhttp-urlconnection.jar或者okhttp-apache.jar就可以了。
本來stay是打算用okhttp自己的請求api整合的自己的網路框架裡，搗鼓了半天，怪麻煩的，api來來回回要找半天，索性就直接換成httpurlconnection的形式寫了。
**已在stay講的[自己動手寫個http框架]中更新，想嘗鮮的可以去看看。
okhttp的示例都很簡單，有很多配置(ssl, cookies, headers, timeout)沒詳細說明，那如果你想配置，該怎麼做捏。可以看原始碼，也可以看一些網路請求框架如：retrofit(square的網路請求框架，預設整合okhttp)原始碼中的api配置。
對於這類底層api創新，還是比較少的，幾年內能出乙個就不錯了，畢竟對http協議融會貫通而且能優化的大牛少之又少。對於一般的苦逼開發者來說，能做到及時跟進已屬不易。
多嘗試新技術，至少可以晚些結束自己的程式設計師生涯 :)
有心課堂，傳遞給你的不僅僅是技術。✈️ www.stay4it.com
HTTP協議那些事
1 http全程是hypertext transfer protocol 超文字傳輸協議 的簡寫，是tcp ip協議的乙個應用層協議，用於定義web遊覽器和web伺服器之間交換資料的過程，由請求和響應構成，是乙個標準的客戶端服務伺服器模型，乙個無狀態的協議 2 http版本 http 1.0和htt...
http協議那些事
乙個 中包含http協議，當然還有其他的協議，比如上傳檔案是採用tfp協議，還有ip位址，後期我們由於ip位址不容易被記憶，所以就出現了網域名稱，還有埠 ip位址是指某一網路中，唯一的位址 埠是指，伺服器跟伺服器之間的通訊通道 當瀏覽器輸入url的時候會發生什麼 當我們在瀏覽器位址列上輸入要訪問的u...
關於簡訊傳送與HTTP請求的那些事
我一直就納悶簡訊傳送這個東西是怎麼做的，之前駐場的地方說沒測試環境的簡訊傳送，讓直接上生產，心裡有千萬個草泥馬登山包飛翔而過，然而後來的需求改了不需要了，單還是飛翔著登山包。如今主要進行版本迭代，看到有個簡訊傳送寫好的東西，想到備用故寫此文，結果發現水還挺深的。先貼 public static bo...