分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！http://blog.csdn.net/jiangjunshow

也歡迎大家轉載本篇文章。分享知識，造福人民，實現我們中華民族偉大復興！

               

    轉載請註明出處，本文來自【 Mr.Simple的部落格 】。

 我正在參加部落格之星， 點選這裡投我一票吧，謝謝~   

前言

 在前段時間，偶然參加了部落格之星的評選，也偶然的進入到了鴻洋和任玉剛兩知名博主的開發群，感受到了很濃厚的技術探討氛圍，於是自己也冒出了寫一些系列部落格的想法。雖說本人水平有限，但是也希望自己的部落格能夠幫到一些需要幫助的人。需要你是高手，那麼顯然不適合你，就沒有必要再看下去了。如果你對框架開發或者說Android網路請求不是很瞭解，每次要使用網路時都要到百度搜索一番，那麼著可能是你需要的。  在開發過程中，網路是我們很重要的一部分，因此我們就以網路框架或者說網路模組開始。在這個框架開發過程中，我會整理開發思路、以及遇到一些設計問題時會有怎麼樣的考慮、解決方案，當然這只是我個人的觀點，大家也可以有自己的實現。除了網路框架，後續的系列還想更新ImageLoader框架、ORM框架，如果有時間也會增加動畫框架和微博開發的系列文章。當然這些框架只是一些簡單的框架基礎，本人水平、時間有限，而且已經有現成、成熟的很多框架，我們在這裡只是以重複造輪子的態度去學習輪子構建過程，從而達到能夠造輪子的地步。至於很多細節的問題，我們這裡就補過多討論了，如果有興趣，各位可以自行研究。  最後，我們暫且把這個框架命名為Simple_Net_Framework，下面我們一起進入主題吧。

基本結構

                   圖1 （ Simple_Net_Framework的基本結構 ）  SimpleNet框架的基本結構類似於Volley,包括一些命名上也有跟Volley一致。它主要分為四個部分，最上面的部分為Request，即各種請求型別。例如返回的資料型別為json的對應為JsonRequest，返回資料字串的為StringRequest，如果需要上傳檔案，那麼你需要使用MultipartRequest，該請求只支援小檔案的上傳，如果上傳的檔案過大則會產生OOM。  第二部分為訊息佇列，訊息佇列維護了提交給網路框架的請求列表，並且根據相應的規則進行排序。預設情況下更具優先順序和進入佇列的順序來執行，該佇列使用的是執行緒安全的PriorityBlockingQueue<E>，因為我們的佇列會被併發的訪問，因此需要保證訪問的原子性。  第三部分是Executor，也就是網路的執行者。該Executor繼承自Thread，在run方法中迴圈訪問第二部分的請求佇列，請求完成之後將結果投遞給UI執行緒。為了更好的控制請求佇列，例如請求排序、取消等操作，這裡我們並沒有使用執行緒池來操作，而是自行管理佇列和Thread的形式，這樣整個結構也變得更為靈活。  第四部分則是Response投遞類，在第三部分的Executor中執行網路請求，Executor是Thread，但是我們並不能在主執行緒中更新UI，因此我們使用

ResponseDelivery來封裝Response的投遞，保證Response執行在UI執行緒。

 每個部分職責都相對單一，這樣便於日後的升級和維護。

框架分析

 圖1中看起來有點像是分層架構，其實不是，這個圖更多的是表達了它的邏輯順序，而不是結構。而在我們的應用開發中，分層架構是一個重要的手段，如圖2所示。                        圖2   但在開發過程中，我們往往會把UI和業務層耦合起來，因為它們的關係太密切了，分解起來並不是那麼容易。高手能夠把複雜的事情簡單化，而分解就是簡單化的重要手段，分解這個過程在開發過程中我們成為重構。但是如何分離UI和業務層也是本人最近想學習的，如果各位有好的解決方案，還希望多多指教。  那麼我們就引入了一個分層概念，為了便於理解你也可以按照如圖1的結構來加深理解。那麼分層有什麼優缺點呢？

優點：

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

       2、職責分離，複雜的系統都有很多人員進行開發，這些功能開發的管理和整合是個很嚴重的問題，分層設計實現之後，每層只需定義好自己的對外介面，其他依賴層服務的就可以進行開發；

       3、每一層對其他層都是獨立的，對外隱藏實現細節，上層無需知道下層的細節，只需呼叫介面即可；

       4、有利於標準化。

缺點：

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

        2、過多的層次影響效能。

 如上所說，我們的Simple_Net_Framework並不是分層的， 而是簡單的模組化，但是理論基礎都是類似的，依賴於抽象而不依賴於實現、單一職責......這裡引入分層的概念，這是便於理解，同時也是希望大家在開發過程中能夠儘量保證模組的內聚性、耦合性。  再看 Simple_Net_Framework，Request是一個抽象的泛型類，泛型型別就是返回的Response型別，例如StringRequest就是繼承自Request<String>。第二部分的RequestQueue依賴於Request，Request是抽象的，因此任何Request的子類都可以傳遞到請求佇列中來，它依賴的是抽象Request，而不是具體的某個實現，因此保證了可擴充套件性。你可以自己實現自己所需的Request，例如大檔案的上傳Request。同理，第三部分的NetworkExecutor也只是依賴於Request抽象，但這裡又引入了一個型別HttpStack，這個網路請求的真正執行者，有HttpClientStack和HttpUrlConnStack，兩者分別為Apache的HttpClient和java的HttpURLConnection，關於這兩者的區別請參考: Android訪問網路，使用HttpURLConnection還是HttpClient？。HttpStack也是一個抽象，具體使用 HttpClient還是HttpURLConnection則由執行系統版本來定，HttpStackFactory會根據系統版本給框架返回對應的 HttpStack。最後的ResponseDelivery比較簡單了，只是通過Handler將結果投遞給UI執行緒執行，也就是執行RequestListener的onComplete方法，此時網路執行完成，使用者即可在該方法中更新UI或者相關的其他的操作。  下面我們再看看SimpleNet的工程結構，如圖3所示。              圖3            圖4  這就是 Simple_Net_Framework框架的基本結構了，如果期待下一篇部落格的更新，就請頂個帖吧！謝謝~  我正在參加部落格之星，點選這裡投我一票吧，謝謝~   
           

給我老師的人工智慧教程打call！http://blog.csdn.net/jiangjunshow