大家都知道，從本質上來說app實際只是整個大系統當中的View層，因為設計優秀的系統中，app基本都不會承擔任何實際的業務邏輯處理，只是負責向用戶展示資料以及從使用者端蒐集使用者資料。而這個資料的一來一去，自然離不開網路通訊協議，而我們用得最多的，自然是這個http協議。目前優秀的第三方http框架有很多，例如volley，okHttp等，但是從我目前給一些開發者面試的結果來看，很多安卓開發者對http協議幾乎一無所知，更不要說去深入理解一個http框架是如何構建的，雖然你會覺得這並不影響你完成你的工作，但如果你是一個有追求真正對技術感興趣的開發者，只做api的搬運工我相信不是你的理想。所以自己花了將近一個月的業餘時間，去深入學習http協議的一些核心內容，並設計編寫這樣一個底層框架，因為框架內容較多，這裡大致會分成兩到三篇來完成，希望對各位有所幫助。

今天第一篇我們先不寫程式碼，先來分析一下http框架，大概要完成哪些工作。
一、我看過不少公司的程式碼，http協議的url資訊都是在程式碼裡寫死的，這樣做有什麼壞處我想也不必贅述了。所以我們的第一個目標，就是實現url的動態配置，讓url的修改完全和程式碼無關，一個配置檔案就全部搞定。
二、根據配置檔案自動處理get和post引數的新增以及加密。這個是每個框架必定要實現的功能。很多面試者連get和post的區別都不知道的原因也基於此，因為框架把這個細節進行了封裝，讓呼叫者只關注拼裝引數而無需在意引數是如何傳送到伺服器的。
三、可自行配置httpHeader。很多公司都需要在http頭中加入自己的欄位並修改一些內容，所以框架必須有httpheader的修改能力。
四、快取和快取時間處理。為了提升使用者體驗，很多場景下並不是每次都需要重新請求伺服器獲取資料的，我們可以把上一次快取的資料拿出來直接展示給使用者，當快取過期之後才重新請求伺服器。所以我們的框架中要整合一個快取能力，並且可以對配置的快取時間進行處理。這裡我們選擇的快取方案就是把伺服器返回的response字串進行快取。
五、執行緒池和安卓端非同步請求的處理。手機資源有限眾所周知，如果任由客戶端隨意新建執行緒執行http請求，最極端情況就是一堆執行緒由於阻塞耗盡系統資源，所以必須通過執行緒池來管理所有的http請求。另外一個問題就是安卓是不允許UI執行緒直接進行http請求這類耗時操作的，所以框架中要把這件事也完成，讓這件事對呼叫者也直接透明，省的handler弄得到處都是。
六、response的動態解析。通過配置檔案，我們可以把response需要解析成的實體類直接配置在檔案中，在呼叫者拿到的時候直接就是想要的class。同時通過何種方式解析也可以配置，xml，String，JSON，只要使用者配置了，框架可以自動獲得解析器並進行解析，向上層返回實體類。
七、請求可以發出，也必然可以取消，在使用者主動退出程式或者某個Activity時框架必須提供請求取消的能力，否則將導致記憶體溢位或請求返回時的程式崩潰。
八、Cookie和Session的處理，cookie和session在框架中如何處理，一般要根據實際的業務需求來確定，這次就不在我們框架的重點之中，但是其原理，大家還是應該深入瞭解的。
九、Mock能力，也就是樁。很多客戶端開發者都會有過這種經歷，自己寫程式碼都駕輕就熟，但是一碰到聯調就肝顫，經常加班的原因是白天伺服器都在開發，客戶端到了晚上才有介面可以聯調。這樣搞就太不專業了，所以客戶端自己要有mock能力，無非是假資料而已，所以框架中要提供介面，讓我們可以自己配置假資料包括超時來確認各種場景下客戶端的資料展示是否正確，這樣聯調的時候，我們早就把各種場景都測試OK，剩下的，無非是確認伺服器的返回資料是否正確而已，效率高高，拒絕加班。
十、框架對外的介面，提供配置能力，所有框架都必須要有的東西。

囧rz，其實我之前也沒想到居然總結出這麼多玩意兒來，不過基本就這些整出來的話，這個框架已經很完善了，好，下一篇開始把這些需求一個一個用程式碼來完成。