您當前位置：首頁 > php開源 > 綜合技術 > 教你寫Android網絡框架之基本架構

教你寫Android網絡框架之基本架構

來源：程序員人生發布時間：2015-02-07 09:03:19 閱讀次數：2896次

轉載請注明出處，本文來自【 Mr.Simple的博客】。

我正在參加博客之星，點擊這里投我1票吧，謝謝~

前言

在前段時間，偶然參加了博客之星的評選，也偶然的進入到了鴻洋和任玉剛兩知名博主的開發群，感遭到了很濃厚的技術探討氛圍，因而自己也冒出了寫1些系列博客的想法。雖然說本人水平有限，但是也希望自己的博客能夠幫到1些需要幫助的人。需要你是高手，那末明顯不合適你，就沒有必要再看下去了。如果你對框架開發或說Android網絡要求不是很了解，每次要使用網絡時都要到百度搜索1番，那末著多是你需要的。

在開發進程中，網絡是我們很重要的1部份，因此我們就以網絡框架或說網絡模塊開始。在這個框架開發進程中，我會整理開發思路、和遇到1些設計問題時會有怎樣樣的斟酌、解決方案，固然這只是我個人的觀點，大家也能夠有自己的實現。除網絡框架，后續的系列還想更新ImageLoader框架、ORM框架，如果有時間也會增加動畫框架和微博開發的系列文章。固然這些框架只是1些簡單的框架基礎，本人水平、時間有限，而且已有現成、成熟的很多框架，我們在這里只是以重復造輪子的態度去學習輪子構建進程，從而到達能夠造輪子的地步。至于很多細節的問題，我們這里就補過量討論了，如果有興趣，各位可以自行研究。

最后，我們暫且把這個框架命名為Simple_Net_Framework，下面我們1起進入主題吧。

基本結構

圖1 （ Simple_Net_Framework的基本結構）

SimpleNet框架的基本結構類似于Volley,包括1些命名上也有跟Volley1致。它主要分為4個部份，最上面的部份為Request，即各種要求類型。例如返回的數據類型為json的對應為JsonRequest，返回數據字符串的為StringRequest，如果需要上傳文件，那末你需要使用MultipartRequest，該要求只支持小文件的上傳，如果上傳的文件過大則會產生OOM。

第2部份為消息隊列，消息隊列保護了提交給網絡框架的要求列表，并且根據相應的規則進行排序。默許情況下更具優先級和進入隊列的順序來履行，該隊列使用的是線程安全的PriorityBlockingQueue<E>，由于我們的隊列會被并發的訪問，因此需要保證訪問的原子性。

第3部份是Executor，也就是網絡的履行者。該Executor繼承自Thread，在run方法中循環訪問第2部份的要求隊列，要求完成以后將結果投遞給UI線程。為了更好的控制要求隊列，例如要求排序、取消等操作，這里我們并沒有使用線程池來操作，而是自行管理隊列和Thread的情勢，這樣全部結構也變得更加靈活。

第4部份則是Response投遞類，在第3部份的Executor中履行網絡要求，Executor是Thread，但是我們其實不能在主線程中更新UI，因此我們使用

ResponseDelivery來封裝Response的投遞，保證Response履行在UI線程。

每一個部份職責都相對單1，這樣便于往后的升級和保護。

框架分析

圖1中看起來有點像是分層架構，其實不是，這個圖更多的是表達了它的邏輯順序，而不是結構。而在我們的利用開發中，分層架構是1個重要的手段，如圖2所示。

圖2

但在開發進程中，我們常常會把UI和業務層耦合起來，由于它們的關系太密切了，分解起來其實不是那末容易。高手能夠把復雜的事情簡單化，而分解就是簡單化的重要手段，分解這個進程在開發進程中我們成為重構。但是如何分離UI和業務層也是本人最近想學習的，如果各位有好的解決方案，還希望多多指教。

那末我們就引入了1個分層概念，為了便于理解你也能夠依照如圖1的結構來加深理解。那末分層有甚么優缺點呢？

優點：

1、復雜問題分解簡單化，每層負責自己的實現，并向外提供服務；

2、職責分離，復雜的系統都有很多人員進行開發，這些功能開發的管理和集成是個很嚴重的問題，分層設計實現以后，每層只需定義好自己的對外接口，其他依賴層服務的就能夠進行開發；

3、每層對其他層都是獨立的，對外隱藏實現細節，上層無需知道下層的細節，只需調用接口便可；

4、有益于標準化。

缺點：

1、分層以后對領域業務的修改有可能需要修改很多層；

2、過量的層次影響性能。

如上所說，我們的Simple_Net_Framework其實不是分層的，而是簡單的模塊化，但是理論基礎都是類似的，依賴于抽象而不依賴于實現、單1職責......這里引入分層的概念，這是便于理解，同時也是希望大家在開發進程中能夠盡可能保證模塊的內聚性、耦合性。

再看Simple_Net_Framework，Request是1個抽象的泛型類，泛型類型就是返回的Response類型，例如StringRequest就是繼承自Request<String>。第2部份的RequestQueue依賴于Request，Request是抽象的，因此任何Request的子類都可以傳遞到要求隊列中來，它依賴的是抽象Request，而不是具體的某個實現，因此保證了可擴大性。你可以自己實現自己所需的Request，例如大文件的上傳Request。同理，第3部份的NetworkExecutor也只是依賴于Request抽象，但這里又引入了1個類型HttpStack，這個網絡要求的真正履行者，有HttpClientStack和HttpUrlConnStack，二者分別為Apache的HttpClient和java的HttpURLConnection，關于這二者的區分請參考:Android訪問網絡，使用HttpURLConnection還是HttpClient？。HttpStack也是1個抽象，具體使用HttpClient還是HttpURLConnection則由運行系統版本來定，HttpStackFactory會根據系統版本給框架返回對應的HttpStack。最后的ResponseDelivery比較簡單了，只是通過Handler將結果投遞給UI線程履行，也就是履行RequestListener的onComplete方法，此時網絡履行完成，用戶便可在該方法中更新UI或相干的其他的操作。

下面我們再看看SimpleNet的工程結構，如圖3所示。