I摘要基于Android系統(tǒng)的移動通信軟件框架系統(tǒng)設(shè)計摘要國內(nèi)的Android系統(tǒng)在如今的手機(jī)網(wǎng)絡(luò)使用環(huán)境中占重要比例。伴隨著越來越多的應(yīng)用軟件的開發(fā)，Android系統(tǒng)承載功能也越來越重要，Android代碼管理相對也變得越來越復(fù)雜?；贏ndroid系統(tǒng)的移動通信軟件框架設(shè)想了一種軟件框架，該框架設(shè)計使用了WM（WindowsMobile）為基礎(chǔ)框架的開發(fā)環(huán)境，采用C/S（Client-Server）架構(gòu)的方法，以Java為基礎(chǔ)來進(jìn)行開發(fā)，服務(wù)器端則選擇Netty作為底層網(wǎng)絡(luò)通信框架。Android的移動手機(jī)客戶端基于MVP（ModelViewPresenter）框架來進(jìn)行開發(fā)，當(dāng)下MVP設(shè)計模式大量的應(yīng)用于Android軟件的開發(fā)架構(gòu)中，該設(shè)計模式的引入使得Android框架的開發(fā)降低了耦合，簡易了框架的測試，增強(qiáng)了框架的穩(wěn)定性。通過OkHttp框架進(jìn)行網(wǎng)絡(luò)請求并以此為基礎(chǔ)，相應(yīng)式網(wǎng)絡(luò)請求框架等技術(shù)，計劃為Android系統(tǒng)用戶開發(fā)具有一定功能且能提供較為完備的基礎(chǔ)框架。關(guān)鍵詞：Android系統(tǒng)；移動通信；框架設(shè)計；MVP模式；Java；計算機(jī)信息工程學(xué)院畢業(yè)設(shè)計說明書1第1章 緒論 41.1課題研究背景 41.2課題研究意義 41.3全球研究背景 41.4全球研究意義 5第2章 需求分析 62.1軟件框架 62.1.1基礎(chǔ)層 92.1.2應(yīng)用層 92.2功能設(shè)計 102.3移動通信軟件框架的實現(xiàn)應(yīng)用 102.3.1軟件框架中通信機(jī)制設(shè)計 102.3.2軟件框架內(nèi)的通信模塊設(shè)計 102.4實現(xiàn)原理 112.4.1等停協(xié)議數(shù)據(jù)發(fā)送與接收算法 112.4.2組件管理 14第3章 服務(wù)器與移動端的通信框架 193.1服務(wù)器與移動端的通信協(xié)議 203.2服務(wù)器與移動端通信框架的實現(xiàn) 203.3服務(wù)器與設(shè)備端的通信框架 213.3.1服務(wù)器與設(shè)備端的通信協(xié)議 213.3.2服務(wù)器與設(shè)備端通信框架的實現(xiàn) 22第4章 詳細(xì)設(shè)計 254.1MVP模式 254.1.1設(shè)計思想 254.1.2實現(xiàn)過程 264.2響應(yīng)式網(wǎng)絡(luò)請求框架 284.2.1設(shè)計思想 284.2.2OkHttp3 284.2.3Retrofit2 284.2.4RxJava2 294.2.5實現(xiàn)過程 294.3MVP模式和網(wǎng)絡(luò)框架在Android應(yīng)用開發(fā)中的應(yīng)用 314.3.1Model層 314.3.2View層 334.3.3Presenter層 33第5章 框架測試 34參考文獻(xiàn) 36緒論1.1課題研究背景現(xiàn)如今基于Android系統(tǒng)的移動通訊領(lǐng)域軟件發(fā)展處于黃金時期，且在不斷成熟，以國內(nèi)的QQ、WeChat，國外的MSN、Facebook、Telegram等為代表，作為由知名公司支持的商業(yè)軟件，上述軟件提供了強(qiáng)大的功能和極佳的用戶體驗。然而，這些成熟的商業(yè)軟件并不是全部開源的，無法看到軟件的系統(tǒng)框架，而大部分絕對的C/S模式對服務(wù)器有很大的依賴。與此同時隨著手機(jī)硬件配置的不斷完善，WIFI將作為一種必要的資源整合到智能手機(jī)中，但目前WIFI豐富的網(wǎng)絡(luò)資源并沒有得到充分合理的利用。國內(nèi)的Android系統(tǒng)在如今的手機(jī)網(wǎng)絡(luò)使用環(huán)境中占重要比例。伴隨著越來越多的應(yīng)用軟件的開發(fā)，Android系統(tǒng)承載功能也越來越重要，Android代碼管理相對也變得越來越復(fù)雜。Android端的開發(fā)也作為其中一個重要的部分也在極速發(fā)展，Android移動軟件開發(fā)中，傳統(tǒng)MVC設(shè)計模式存在較大問題，會影響了軟件開發(fā)的效率和穩(wěn)定性。1.2課題研究意義基于Android系統(tǒng)的移動通信軟件框架設(shè)計所提出的框架就是在利用WM、C/S、Netty、MVP模式的前提下，在底層能夠提供網(wǎng)內(nèi)路由的前提下而設(shè)計框架的。該框架設(shè)計目的是為了讓手機(jī)發(fā)現(xiàn)網(wǎng)絡(luò)中的資源，并通過控制協(xié)議支持，使網(wǎng)絡(luò)中的用戶能夠享受并利用到網(wǎng)絡(luò)中的資源。基于Android系統(tǒng)的軟件框架在所給出的基礎(chǔ)之上實現(xiàn)了即時通訊功能。基于Android系統(tǒng)的軟件框架提出了用組件管理技術(shù)解決新業(yè)務(wù)的拓展，作為具有一定技術(shù)背景的用戶，只需實現(xiàn)規(guī)定的接口，新增的功能就會以組件的形式由框架動態(tài)地加載。從理論上講，即時通訊的軟件與軟件互聯(lián)技術(shù)的操作難度系數(shù)偏低，因此在設(shè)計層面上完全有機(jī)會實現(xiàn)軟件與軟件的兼容性和互聯(lián)性?；ヂ?lián)互通的難點在于參與互聯(lián)互通的企業(yè)之間的利益分配。大多數(shù)即時通訊軟件的用戶希望通過即時通訊軟件來進(jìn)行網(wǎng)絡(luò)通訊。1.3全球研究背景如今即時通信應(yīng)用軟件發(fā)展欣欣向榮。例如中國的QQ、WeChat、和國外的MSN、Facebook、Telegram。市場一家研究公司的統(tǒng)計數(shù)據(jù)表明，在近幾年里，QQ、WeChat和Facebook、Telegram的用戶數(shù)量增長率持續(xù)上升。即時通訊應(yīng)用軟件并不是只有免費的信息接受與發(fā)送功能受好評，QQ、WeChat如之前的社交網(wǎng)絡(luò)出現(xiàn)的通信應(yīng)用軟件類似，全球用戶在手機(jī)上從事一切活動的門戶就是這樣的通信軟件。上述軟件可以提供人們之間的相互聯(lián)絡(luò)、共享美圖、視頻戀愛等功能以及參與各種可為這些應(yīng)用軟件帶來較高收益的活動，例如網(wǎng)上沖浪、購買虛擬產(chǎn)品以及網(wǎng)絡(luò)購物。1.4全球研究意義相較全球來說，用戶群組偏大的即時通訊軟件功能已經(jīng)相對完善，軟件運行過程中也相對比較穩(wěn)定，這也是用戶群組偏好于QQ和MSN這類老牌軟件的原因。對于像QQ、MSN這樣的企業(yè)，他們擁有大量的用戶，所以他們更愿意專注于在此基礎(chǔ)上即時通訊產(chǎn)品的進(jìn)一步開發(fā)研究。產(chǎn)品與產(chǎn)品的互聯(lián)在將一定程度上轉(zhuǎn)移企業(yè)的潛在用戶，甚至現(xiàn)有用戶。至于安全方面，無論是個人用戶，還是企業(yè)用戶，都面臨新的威脅。對于個體用戶們來說，通過即時通信軟件而傳播的病毒，會造成不可估量的損失，一旦爆發(fā)將會造成個人資料丟失，信息泄露，最壞的情況會造成即時通信用戶與用戶的誤會。服務(wù)器是其他部分之間進(jìn)行信息交互的中間媒介，是整個系統(tǒng)的中心，通過實現(xiàn)服務(wù)器與移動端的通信框架以及服務(wù)器與設(shè)備端的通信框架來實現(xiàn)整個系統(tǒng)的連通。

需求分析現(xiàn)如今移動通信服務(wù)已經(jīng)滲透到人們生活每一方面，爆炸式的移動數(shù)據(jù)、流量增長、海量的移動終端設(shè)備連接、不斷涌現(xiàn)的各類應(yīng)用場景和新業(yè)務(wù)，推動移動通信網(wǎng)絡(luò)技術(shù)不斷更迭。移動端又因其便攜性、使得人們與外部世界進(jìn)行網(wǎng)絡(luò)連接更加方便而舒適。國內(nèi)的Android系統(tǒng)在移動手機(jī)網(wǎng)絡(luò)使用環(huán)境中占重要比例。而越來越多小軟件的開發(fā)，Android系統(tǒng)承載功能也變得越來越重要，Android代碼管理也相對變得越來越復(fù)雜?；贏ndroid系統(tǒng)的移動軟件框架設(shè)計目的旨在為無線通信領(lǐng)域提供一個較為簡易的軟件基礎(chǔ)平臺，能夠為基礎(chǔ)的業(yè)務(wù)擴(kuò)展提供一個更為便利的方式，在框架內(nèi)能夠?qū)崿F(xiàn)即時通訊的功能，在設(shè)計過程中，將與框架無關(guān)的部分都作為一個組件，由框架的組件管理器實現(xiàn)對未來諸多組件的統(tǒng)一管理，逐步實現(xiàn)軟件的可擴(kuò)展性。2.1軟件框架基于Android系統(tǒng)的移動軟件框架設(shè)計目的旨在為無線通信領(lǐng)域提供一個較為簡易的軟件基礎(chǔ)平臺，能夠為基礎(chǔ)的業(yè)務(wù)擴(kuò)展提供一個更為便利的方式，在框架內(nèi)能夠?qū)崿F(xiàn)即時通訊的功能。同時在框架中實現(xiàn)即時消息功能，并在框架上以組件的方式實現(xiàn)流媒體業(yè)務(wù)。其中流媒體技術(shù)則是將一系列的數(shù)據(jù)壓縮后，用流的方式在網(wǎng)上分段傳送，實現(xiàn)在網(wǎng)絡(luò)上實時傳輸影像的技術(shù)。移動通信軟件框架是基于底層支持基于Adhoc網(wǎng)絡(luò)路由轉(zhuǎn)發(fā)的服務(wù)設(shè)計，將底部的路由部分作為系統(tǒng)服務(wù)的基礎(chǔ)，框架可以提供通過其接口實現(xiàn)信息的交互，這兩個操作系統(tǒng)，一路由，二基本業(yè)務(wù)以及移動通信軟件框架之間的關(guān)系如圖2-1所示。圖2-1移動通信框架體系結(jié)構(gòu)圖移動通信軟件框架與路由基礎(chǔ)設(shè)施服務(wù)和操作系統(tǒng)有著直接的關(guān)系。路由基礎(chǔ)設(shè)施服務(wù)通過指定的接口為上層應(yīng)用軟件提供收集鄰居節(jié)點、檢測狀態(tài)等功能。流媒體服務(wù)作為一種基于移動通信軟件框架的服務(wù)，充分利用框架提供的功能，在AdHoc網(wǎng)絡(luò)中實現(xiàn)資源共享。該框架的目的是為嵌入式無線通信領(lǐng)域提供一個更加通用的應(yīng)用軟件基礎(chǔ)平臺，為未來業(yè)務(wù)拓展提供一種更加方便的添加方式。同時在框架中實現(xiàn)即時消息功能，并在框架上以組件的方式實現(xiàn)流媒體業(yè)務(wù)。因此，在框架的設(shè)計過程中，部分與被視為一個組件框架，框架的和組件管理器實現(xiàn)了統(tǒng)一管理的許多組件在未來，真正實現(xiàn)軟件的可擴(kuò)展性，也是一個重要的特征框架。路由基礎(chǔ)設(shè)施服務(wù)的設(shè)計不是框架的重點。這里推薦使用優(yōu)化的鏈路狀態(tài)路由協(xié)議結(jié)構(gòu)來描述底層路由基礎(chǔ)設(shè)施服務(wù)提供給通信軟件框架的基本接口和服務(wù)。框架結(jié)構(gòu)圖如圖2-2所示。圖2-2移動通信軟件框架結(jié)構(gòu)圖從圖2-2中可以看出，移動通信軟件框架主要由個人信息管理、日志管理、網(wǎng)絡(luò)交換模塊、界面設(shè)計、用戶管理、組件管理、網(wǎng)絡(luò)模塊和路由基本業(yè)務(wù)交互模塊組成。除了組件管理器的流媒體服務(wù)部分外，框架的其余部分構(gòu)成了整體結(jié)構(gòu)。該框架的一個特性是組件管理器，它的設(shè)計目的是動態(tài)加載用戶自己設(shè)計的新功能組件。網(wǎng)絡(luò)通信模塊封裝了底層的事件驅(qū)動套接字，并將它們作為框架的一部分提供給上層。由于篇幅限制，這里不詳細(xì)介紹各個模塊的功能和實現(xiàn)。為了使整個框架更具可擴(kuò)展性，可重用性更高，易于維護(hù)，在基于Android系統(tǒng)的移動軟件框架采用面向?qū)ο蟮脑O(shè)計思想理念，個人信息存儲采用XML語言格式，便于擴(kuò)展內(nèi)容和后期軟件升級。下面簡略介紹以下各個模塊功能。1）個人信息管理模塊：可以修改個人資料，也可以添加新用戶資料。2）日志管理模塊：日志頁面查詢，日志刪除，日志添加的實現(xiàn)。3）網(wǎng)絡(luò)交換模塊：物理尋址，網(wǎng)絡(luò)拓?fù)?，幀序列?）界面設(shè)計模塊：基本界面創(chuàng)建。5）用戶管理模塊：用戶信息管理，用戶注冊，用戶權(quán)限。6）組件管理模塊：組件管理，內(nèi)容管理。7）網(wǎng)絡(luò)模塊：中間連接器。8）路由基本業(yè)務(wù)交互模塊：業(yè)務(wù)數(shù)據(jù)管理。2.1.1基礎(chǔ)層基礎(chǔ)層作為整個框架的支撐，提供網(wǎng)絡(luò)通信功能，用于應(yīng)用層各種業(yè)務(wù)的擴(kuò)展。它隱藏了自組網(wǎng)的復(fù)雜性。從應(yīng)用層的角度來看，底層網(wǎng)絡(luò)是一個純粹的基于Ip的網(wǎng)絡(luò)。為了實現(xiàn)準(zhǔn)確高效的用戶體驗，需要不斷優(yōu)化底層的設(shè)計，使其穩(wěn)定高效地運行。設(shè)計同時，基礎(chǔ)層是屬于框架所提供的軟件框架的基本組件，也是提供路由基礎(chǔ)設(shè)施服務(wù)基地層可以作為終端網(wǎng)絡(luò)基礎(chǔ)設(shè)施服務(wù)，從而達(dá)到對未來基于無線廣告促進(jìn)新業(yè)務(wù)，新的思維方式，減少軟件開發(fā)的重復(fù)性工作。2.1.2應(yīng)用層作為框架的另一個重要組件，應(yīng)用軟件層也是框架的重點。需要在底層從零開始構(gòu)建服務(wù)框架，既符合用戶的操作習(xí)慣，又便于未來業(yè)務(wù)擴(kuò)展，充分考慮各種用例等綜合因素。按照功能模塊的劃分，應(yīng)用層一般包括以下幾個方面1）基于組件的服務(wù)管理；2）圖形用戶界面；3）服務(wù)發(fā)現(xiàn)；4）服務(wù)組件；5）網(wǎng)絡(luò)通信。2.2功能設(shè)計針對上述框架的主要組成部分，下面對主要功能模塊進(jìn)行簡要描述，以便對框架所完成的功能有更深入的了解。1）界面設(shè)計是用戶直接接觸的部分。它試圖使用戶操作簡單。設(shè)計中采用了控件動態(tài)生成技術(shù)，使用戶開發(fā)的組件可以方便地加載到框架的界面顯示中。2）組件管理器的設(shè)計是動態(tài)加載用戶設(shè)計的新功能組件，用戶只要按照指定的接口設(shè)計新服務(wù)。3）網(wǎng)絡(luò)通信模塊封裝底層事件驅(qū)動套接字，作為框架基本服務(wù)的一部分提供給上層。最后實現(xiàn)效果較好的網(wǎng)絡(luò)通信功能，并利用該模塊在框架中實現(xiàn)即時通訊功能。4）用戶管理模塊作為用戶信息的數(shù)據(jù)源，動態(tài)地存儲和更新網(wǎng)絡(luò)中的鄰居信息，通過消息機(jī)制與接口控件進(jìn)行通信，將真實的鄰居信息實時反映到接口顯示中，使用戶可以隨時感知網(wǎng)絡(luò)中可見的鄰居2.3移動通信軟件框架的實現(xiàn)應(yīng)用2.3.1軟件框架中通信機(jī)制設(shè)計為了實現(xiàn)無線網(wǎng)絡(luò)環(huán)境或惡劣環(huán)境下實現(xiàn)可靠的網(wǎng)絡(luò)信號的移動通信網(wǎng)絡(luò)，需要設(shè)計兩個方案，即發(fā)送方和接收方，發(fā)送方也可以使用接收方可以指定發(fā)送文件，接收方需要發(fā)送的信息數(shù)據(jù)可以包含在控制指令中啟動發(fā)送方，該文件將作為流傳輸。發(fā)送端接收數(shù)據(jù)流以后，接收端先記錄數(shù)據(jù)流長度，并將相應(yīng)數(shù)據(jù)寫入緩沖區(qū)，其次下個數(shù)據(jù)塊的傳輸控制指令問題在同時傳播給下一個數(shù)據(jù)塊，然后給一個打開的文件追加緩沖區(qū)的數(shù)據(jù)流，傳輸過程是發(fā)送方和接收方之間的協(xié)作過程，不存在循環(huán)控制語句。而在Windows中Socket的相關(guān)通信是操作系統(tǒng)排隊得來的，接收方與發(fā)送方兩者均要協(xié)同工作，不然會造成數(shù)據(jù)丟失。所以不能采用相關(guān)的循環(huán)語句發(fā)送多組數(shù)據(jù)以及接受數(shù)據(jù)。網(wǎng)絡(luò)通信的請求和應(yīng)答是基本模式。Sock-ET的代碼編程同樣遵循了數(shù)據(jù)轉(zhuǎn)包的基本要點。在編程中每發(fā)送和接收的數(shù)據(jù)包，都能夠保證數(shù)據(jù)的傳輸安全性，穩(wěn)定性從而不占用相對較多的系統(tǒng)資源。2.3.2軟件框架內(nèi)的通信模塊設(shè)計因為無連接的數(shù)據(jù)報文的方式取締了數(shù)據(jù)重發(fā)校驗機(jī)制，從而數(shù)據(jù)可以擁有較高的通信效率，此設(shè)計針對于數(shù)據(jù)可靠性要求不高的通信，而這個特性恰好適合于框架所論述框架的應(yīng)用場景（移動Ad-hoc網(wǎng)絡(luò)，信號弱，有一定的覆蓋范圍，而且網(wǎng)絡(luò)中節(jié)點位置不斷變化），所以通訊模塊實現(xiàn)過程中采用基于事件驅(qū)動的網(wǎng)絡(luò)套接字，從而實現(xiàn)與同一網(wǎng)絡(luò)中的其它結(jié)點進(jìn)行數(shù)據(jù)交互，并將網(wǎng)絡(luò)通信模塊封裝成類以供上層使用，而底層主要基于Windows消息機(jī)制，但考慮到無線網(wǎng)絡(luò)環(huán)境穩(wěn)定性差、可靠性低等特點，框架內(nèi)實現(xiàn)了簡易的等停協(xié)議的數(shù)據(jù)發(fā)送接收算法。在框架論述的框架中，因為應(yīng)用于條件比較特殊的移動Ad-hoc網(wǎng)絡(luò)，這里把框架分為基礎(chǔ)層和應(yīng)用層。在框架的通訊模塊部分，設(shè)計過程中將經(jīng)典的停止等待協(xié)議在網(wǎng)絡(luò)層實現(xiàn)，而且根據(jù)具體情況在某些加以修改，使之更好地應(yīng)用于本框架的應(yīng)用中。因為整個框架應(yīng)用于通信質(zhì)量比較差的無線網(wǎng)絡(luò)中，而且伴隨著網(wǎng)絡(luò)中用戶不斷的位移，信號及網(wǎng)絡(luò)拓?fù)涠紩r刻在發(fā)生著變化，所以在框架的網(wǎng)絡(luò)通信部分設(shè)計實現(xiàn)了該協(xié)議。2.4實現(xiàn)原理2.4.1等停協(xié)議數(shù)據(jù)發(fā)送與接收算法事件驅(qū)動的網(wǎng)絡(luò)套接字用于與同一網(wǎng)絡(luò)中的其他節(jié)點交換數(shù)據(jù)。網(wǎng)絡(luò)通信模塊被封裝成類供上層使用。底層主要基于Windows消息機(jī)制，但考慮到無線網(wǎng)絡(luò)環(huán)境的穩(wěn)定性差、可靠性低，在框架中實現(xiàn)了一種簡單的等待協(xié)議的數(shù)據(jù)發(fā)送和接收算法。之所以稱其為簡單等待和停止協(xié)議，是因為整個框架是用于通信質(zhì)量較差的無線網(wǎng)絡(luò)中。并且隨著網(wǎng)絡(luò)中用戶的不斷遷移，信號和網(wǎng)絡(luò)拓?fù)湟苍诓粩嘧兓?。同時，框架提出的框架針對個人休閑娛樂，用戶在網(wǎng)絡(luò)上互動的大部分信息不需要嚴(yán)格跟蹤和回答。同時，考慮到保證基本通信質(zhì)量，該協(xié)議在框架的網(wǎng)絡(luò)通信部分進(jìn)行了設(shè)計和實現(xiàn)。等待協(xié)議的數(shù)據(jù)流程圖如圖2-3所示。圖2-3等停協(xié)議流程圖為了充分體現(xiàn)面向?qū)ο蟮脑O(shè)計思想，將每個用戶設(shè)計為一個類，任何用戶之間的數(shù)據(jù)通信都通過一個會話類來組織，會話類有兩個內(nèi)部隊列，分別對應(yīng)發(fā)送隊列和接收隊列。等待停止協(xié)議的數(shù)據(jù)發(fā)送算法由獨立線程中的定時器連續(xù)觸發(fā)，從而在用戶管理模塊中輪詢每個用戶的會話，最終將需要發(fā)送的數(shù)據(jù)串行發(fā)送。等待協(xié)議的數(shù)據(jù)傳輸算法對應(yīng)的類視圖如圖2-4所示。圖2-4數(shù)據(jù)發(fā)送接收視圖該框架提供的網(wǎng)絡(luò)通信模塊采用無連接UDP服務(wù)，但為了盡可能克服無線網(wǎng)絡(luò)的不穩(wěn)定因素，在傳輸算法中加入了數(shù)據(jù)重傳和有效的時間檢測機(jī)制，有效地避免了單數(shù)據(jù)傳輸容易丟失的缺點，在測試過程中取得了良好的效果。等待停止協(xié)議的數(shù)據(jù)傳輸算法說明如下：（1）判斷發(fā)送時鐘周期是否已經(jīng)到達(dá)。如果到達(dá)發(fā)送時間點，則輸入步驟（2）；（2）遍歷用戶管理類中注冊的所有用戶，查看每個用戶會話中的發(fā)送隊列。如果發(fā)送隊列不為空，則輸入步驟（3），否則繼續(xù)讀取下一個有效用戶；（3）讀取發(fā)送隊列頭的數(shù)據(jù)包，判斷最后一次發(fā)送時間是否超時。如果超時，則將報文組織成指定的傳輸格式，通過報文對應(yīng)的會話統(tǒng)一分配消息序列號，發(fā)送到網(wǎng)絡(luò)中特定的IP。同時更新發(fā)送的報文數(shù)。當(dāng)發(fā)送的報文數(shù)達(dá)到最大值時，報文將從發(fā)送隊列中刪除。對于那些需要更嚴(yán)格數(shù)據(jù)傳輸?shù)臉I(yè)務(wù)，框架內(nèi)給出的通信模塊可能不是最好的解決方案，這需要上層業(yè)務(wù)實現(xiàn)其追求的高質(zhì)量、可靠的通信模式。數(shù)據(jù)發(fā)送和接收是相反的過程。在數(shù)據(jù)接收過程中，該框架采用了多線程事件驅(qū)動的異步套接字模式，增加了重復(fù)檢測和數(shù)據(jù)響應(yīng)機(jī)制，克服了無線網(wǎng)絡(luò)環(huán)境惡劣和多數(shù)據(jù)接收可能性的缺陷。等待停止協(xié)議的具體數(shù)據(jù)接收算法說明如下：（1）等待異步套接字?jǐn)?shù)據(jù)到達(dá)事件的發(fā)生，如果有數(shù)據(jù)到達(dá)，則轉(zhuǎn)到步驟（2）；（2）將接收到的數(shù)據(jù)包轉(zhuǎn)換為標(biāo)準(zhǔn)數(shù)據(jù)格式，根據(jù)發(fā)送方地址在用戶管理類中找到對應(yīng)的用戶，返回對應(yīng)的會話。如果收到的數(shù)據(jù)包不是報文應(yīng)答，則剛收到的數(shù)據(jù)包的數(shù)據(jù)應(yīng)答將立即通過會話發(fā)送給發(fā)送方。到步驟（3）；（3）根據(jù)會話記錄的消息序號判斷剛收到的消息是否經(jīng)過處理，如果之前已經(jīng)收到則退出；否則，執(zhí)行步驟（4）；（4）將接收到的數(shù)據(jù)包扔到分析鏈表中，根據(jù)消息類型找到相應(yīng)的消息處理函數(shù)，完成對接收到的數(shù)據(jù)的處理。接收數(shù)據(jù)算法中提到的消息處理軟件是那些已經(jīng)注冊了，在應(yīng)用軟件初始化期間的函數(shù)；消息類型，消息處理軟件；在映射表中，框架默認(rèn)的消息會被回復(fù)消息處理器注冊進(jìn)來，但是對于以后增加的新業(yè)務(wù)，需要用戶在組件中實現(xiàn)相應(yīng)的接口，框架會在導(dǎo)入組件的過程中，完成類似的注冊，并接收屬于組件的數(shù)據(jù)，將數(shù)據(jù)包分發(fā)到解析器內(nèi)部的組件進(jìn)行處理，具體的處理規(guī)則和操作邏輯由組件本身定義和實現(xiàn)?；谏鲜鰯?shù)據(jù)發(fā)送和接收算法，在該框架下實現(xiàn)了同一網(wǎng)絡(luò)內(nèi)點對點即時通信功能。2.4.2組件管理移動通信軟件框架是為了在WindowsMobile系統(tǒng)中添加新的基于AdHoc網(wǎng)絡(luò)的流媒體應(yīng)用而設(shè)計的。在完成框架設(shè)計的基礎(chǔ)上，實現(xiàn)了流媒體服務(wù)。不僅想提供一個具有一定功能的手機(jī)軟件，還希望未來的用戶可以利用這個框架上的底層資源，實現(xiàn)更豐富的服務(wù)，更好地滿足用戶的需求。因此，在框架設(shè)計過程中，有意將與框架無關(guān)的義務(wù)逐個抽象成一個構(gòu)件，框架可以實現(xiàn)對這些構(gòu)件的統(tǒng)一管理。其中包括GUI（GraphicalUserInterface）顯示、消息處理功能索引、資源加載與釋放等工作?？蚣苤械慕M件管理器用于管理應(yīng)用對等目錄/plugins/中的所有組件。所有組件都需要實現(xiàn)框架指定的接口，框架中的組件管理器將動態(tài)加載它們，并在運行時以統(tǒng)一的方式調(diào)度每個組件。組件管理器和組件之間的關(guān)系視圖如圖2-5所示。圖2-5組件管理器與組件關(guān)系視圖組件管理器在應(yīng)用軟件初始化期間加載所有組件，并根據(jù)定義的接口構(gòu)造每個組件對象?？蚣軐⑦@些組件組織成一個鏈表，每個組件由唯一的ID標(biāo)識。在應(yīng)用軟件工作時，與組件相關(guān)的操作包括以下內(nèi)容。（1）在應(yīng)用初始化過程中，框架負(fù)責(zé)加載組件，組件將內(nèi)部生成的接口資源句柄返回給框架，框架負(fù)責(zé)通過組件接口組織的相關(guān)類將資源集成到框架中。（2）屬于組件本身的網(wǎng)絡(luò)數(shù)據(jù)需要由組件進(jìn)行解析、處理和響應(yīng)。在組件初始化期間，框架將組件內(nèi)部實現(xiàn)的網(wǎng)絡(luò)數(shù)據(jù)響應(yīng)接口注冊到一個消息類型，消息處理軟件；當(dāng)框架的網(wǎng)絡(luò)通信模塊接收到網(wǎng)絡(luò)數(shù)據(jù)時，通過在映射表中查找數(shù)據(jù)，將屬于特定組件的數(shù)據(jù)包分發(fā)給指定組件。（3）組件可以獨立實現(xiàn)具有特定功能的網(wǎng)絡(luò)通信機(jī)制，同時組件也可以方便地使用框架本身的網(wǎng)絡(luò)通信模塊。如果使用網(wǎng)絡(luò)通信模塊提供的框架，組件在發(fā)送數(shù)據(jù)之前，獲取組件屬于用戶的手，根據(jù)結(jié)構(gòu)，組件可以獲得通信會話，只需要發(fā)送發(fā)送數(shù)據(jù)加入隊列，可以通過這樣的協(xié)議框架停止發(fā)送完整的數(shù)據(jù)發(fā)送算法。利用框架提供的網(wǎng)絡(luò)通信模塊，不同終端對等組件之間通信的數(shù)據(jù)流圖如圖2-6所示圖2-6對等組件通信數(shù)據(jù)流圖根據(jù)該框架提供的組件管理來設(shè)計并完成流媒體服務(wù)，與此同時遠(yuǎn)程用戶提供流媒體服務(wù)，本地用戶安裝了流媒體組件，雙方都可以查看對方的媒體資源列表，享受對方提供的流媒體服務(wù)。流媒體服務(wù)的則是通過流媒體服務(wù)器的支持。在運行過程中，需要在支持流媒體服務(wù)的終端上安裝MobileWindowsServer軟件，并將媒體文件放置在服務(wù)器的標(biāo)準(zhǔn)目錄下，以便網(wǎng)絡(luò)上的其他用戶可以看到。流媒體可通過WindowsMobile的媒體播放器本地播放器。

服務(wù)器與移動端的通信框架Netty框架是一種應(yīng)用廣泛的Java網(wǎng)絡(luò)編程框架，Netty有很多重要的特性，主要特性如下：（1）優(yōu)雅的設(shè)計；（2）統(tǒng)一的API接口，支持多種傳輸類型，例如OIO、NIO；（3）簡單而強(qiáng)大的線程模型；（4）豐富的文檔；（5）卓越的性能；（6）擁有比原生JavaAPI更高的性能與更低的延遲；（7）基于池化和復(fù)用技術(shù)，使資源消耗更低；（8）安全性；（9）完整的SSL/TLS以及StartTLS支持；（10）可用于受限環(huán)境，如Applet以及OSGI；服務(wù)器端則選擇基于Java的Netty作為底層網(wǎng)絡(luò)通信框架。同時，Android手機(jī)APP也是基于Java語言開發(fā)的，系統(tǒng)通過在服務(wù)器系統(tǒng)和手機(jī)APP上分別搭建Netty框架的服務(wù)器端和客戶端來實現(xiàn)服務(wù)器端和手機(jī)端之間的通信?？蚣苋缦聢D3-1所示圖3-1Netty框架3.1服務(wù)器與移動端的通信協(xié)議該通信協(xié)議由數(shù)據(jù)頭和數(shù)據(jù)體兩部分組成。數(shù)據(jù)頭的內(nèi)容用整個數(shù)據(jù)長度的二進(jìn)制格式表示，數(shù)據(jù)體為所傳輸數(shù)據(jù)內(nèi)容的二進(jìn)制格式，其協(xié)議格式如圖3-2所示。圖3-2移動端通信協(xié)議為了方便信息的傳播對象在移動端和服務(wù)器端之間，系統(tǒng)采用的JSON數(shù)據(jù)交換格式和相應(yīng)的轉(zhuǎn)換工具集成FastJSONMessage對象轉(zhuǎn)換成一個格式化的字符串，并深入到數(shù)據(jù)的二進(jìn)制格式的身體，并通過Netty通信框架實現(xiàn)消息對象的傳輸。3.2服務(wù)器與移動端通信框架的實現(xiàn)在Netty通信框架的客戶端與服務(wù)器端通信過程中，經(jīng)常會出現(xiàn)TCP粘包/拆包問題，這將對接收到的數(shù)據(jù)的解析造成很大的干擾。為了解決這個問題，框架根據(jù)自定義編碼器來讓傳輸對象被轉(zhuǎn)化為JSON字符串，其次在發(fā)送數(shù)據(jù)的同時轉(zhuǎn)換為二進(jìn)制數(shù)據(jù)，與此同時使用Netty來提供的LengthFieldPrepender編碼器如下如3-3所示來自行計算目前要發(fā)送的二進(jìn)制字節(jié)長度。該長度添加到當(dāng)前數(shù)據(jù)的頭部，來形成要發(fā)送的完整數(shù)據(jù)幀。并置是與LengthFieldPrepender編碼器使用的LengthFieldBasedFrameDecoder解碼器，當(dāng)接收數(shù)據(jù)時，通過解碼器可以自動攔截數(shù)據(jù)頭，并隨后攔截數(shù)據(jù)內(nèi)容的部分字節(jié)。圖3-3使用LengthFieldPrepender編碼轉(zhuǎn)換后的字節(jié)作為單獨的信息傳遞給下一自定義消息的解碼器，同時二進(jìn)制的數(shù)據(jù)通過FastJSON來進(jìn)一步轉(zhuǎn)換成為序列化信息對象，在最后交給特化的事務(wù)處理軟件來處理相應(yīng)。相應(yīng)的協(xié)議編解碼器框架如圖3-4所示。圖3-4移動端通信協(xié)議解編碼框架3.3服務(wù)器與設(shè)備端的通信框架硬件的平臺端根據(jù)的是stm32單片機(jī)器件，利用WiFi模塊組件與GPRS模塊組件來達(dá)到通信功能，由于硬件設(shè)備和服務(wù)器只能通過TCP傳輸基本的二進(jìn)制數(shù)據(jù)流，所以服務(wù)器與設(shè)備通過制定自定義通信協(xié)議和通信規(guī)則來實現(xiàn)通信框架，完成數(shù)據(jù)交互。3.3.1服務(wù)器與設(shè)備端的通信協(xié)議設(shè)備端自定義通信協(xié)議格式如表3-1所示。表3-1設(shè)備端通信協(xié)議幀頭幀長度指令類型設(shè)備編號設(shè)備編號幀編號檢驗和4Byte2Byte1Byte2Byte2Byte0~1024Byte1Byte其中，各字段的說明如表3-2所示。

表3-2協(xié)議字段設(shè)備字段名稱長度說明幀頭4固定為0x0a0x0a0x0a幀長度2無符號short類型指令類型1無符號byte數(shù)據(jù)類型設(shè)備編碼2無符號short類型數(shù)據(jù)內(nèi)容0~1024變長可選字段幀編號2無符號short類型校驗和1有符號byte類型比較的核心字段是指令類型和數(shù)據(jù)內(nèi)容。指令類型用于指示不同的指令，每個指令具有特定的功能任務(wù)，可以通過增加指令的數(shù)量來擴(kuò)展服務(wù)功能。數(shù)據(jù)內(nèi)容用于存儲不同指令中包含的不同數(shù)據(jù)信息，如存戶/取戶信息、存戶密碼等。通過開發(fā)自定義協(xié)議，服務(wù)器和設(shè)備都可以很容易地對接收到的二進(jìn)制信息進(jìn)行分段來提取消息，或者按照協(xié)議對發(fā)送的數(shù)據(jù)進(jìn)行統(tǒng)一編碼。同時，對于功能的擴(kuò)展需求，通信指令也易于實現(xiàn)擴(kuò)展。3.3.2服務(wù)器與設(shè)備端通信框架的實現(xiàn)在服務(wù)器端與設(shè)備端通信的過程中，數(shù)據(jù)傳輸將會不可避免地出現(xiàn)數(shù)據(jù)丟失以及數(shù)據(jù)錯誤等問題。而由于通信過程是基于TCP協(xié)議的，也會產(chǎn)生TCP粘包、拆包等問題，這將對接收數(shù)據(jù)端產(chǎn)生很大的影響。為了盡可能保證數(shù)據(jù)的完整性和準(zhǔn)確性，有必要制定一些自定義的通信規(guī)則進(jìn)行干預(yù)。（1）解決TCP粘包拆包問題。如下圖3-5所示圖3-5粘包拆包示意圖系統(tǒng)規(guī)定，無論服務(wù)器還是設(shè)備，只有連續(xù)讀取4個0x0A（即幀頭）時，才認(rèn)為是讀取完整數(shù)據(jù)的開始，并根據(jù)后續(xù)幀長度截取相應(yīng)的數(shù)據(jù)部分。同時，通過比較校驗和部分的內(nèi)容來判斷數(shù)據(jù)的正確性。如果數(shù)據(jù)的內(nèi)容有誤，數(shù)據(jù)將被丟棄。（2）指揮響應(yīng)機(jī)制。系統(tǒng)調(diào)節(jié)端，服務(wù)器和設(shè)備對于每個接收到的指令消息（響應(yīng)命令消息除外）都必須將指令響應(yīng)應(yīng)用到操作中，即接收到正確的指令后立即返回相應(yīng)的幀號（FrameId）響應(yīng)指令新聞，通知另一端具有接收幀號順序的完整權(quán)利信息。（3）超時重傳機(jī)制。系統(tǒng)規(guī)定，無論服務(wù)器還是設(shè)備端，對于已發(fā)送的每一條指令，都必須等待接收其回復(fù)指令后才能繼續(xù)下一個操作。為了避免響應(yīng)指令丟失或錯誤引起的系統(tǒng)到無限的等待狀態(tài)，系統(tǒng)由一個計時器超時重傳機(jī)制，即指令的發(fā)送完成后將開始相應(yīng)的定時器，如果在一段時間內(nèi)沒有收到回復(fù)消息的指令，認(rèn)為指令缺失或錯誤，立即發(fā)送指令。如果多個郵件沒有收到回復(fù)，請停止發(fā)送并報告錯誤。（4）心跳檢測機(jī)制。每隔一段時間，設(shè)備端上的每個設(shè)備都必須向服務(wù)器發(fā)送一個心跳，以證明它仍在工作。服務(wù)器對每臺設(shè)備進(jìn)行定期檢測。如果服務(wù)器多次沒有收到設(shè)備的心跳信息，服務(wù)器會認(rèn)為設(shè)備出故障，主動關(guān)閉其通信通道，釋放資源。移動通信軟件框架旨在為基于AdHoc網(wǎng)絡(luò)的無線終端提供一個通用的通信軟件基礎(chǔ)平臺。應(yīng)用于嵌入式領(lǐng)域的移動通信軟件框架的總體結(jié)構(gòu)和主要設(shè)計環(huán)節(jié)，其中詳細(xì)闡述了等待停止協(xié)議的發(fā)送和接收算法以及組件管理機(jī)制。并在該框架的基礎(chǔ)上實現(xiàn)了即時消息和流媒體業(yè)務(wù)。經(jīng)過測試，可以獲得比較滿意的服務(wù)體驗。在順序模式挖掘中，挖掘結(jié)果必須由數(shù)據(jù)源的特征決定?？蚣苡懻摿丝蛻粜蛄刑枴⑵骄蛄虚L度、平均事務(wù)長度和項目號等數(shù)據(jù)特征對挖掘結(jié)果的影響，找出了單個特征的影響程度。進(jìn)一步研究了平均項數(shù)對模型結(jié)果的影響以及四種特征對采礦結(jié)果的綜合影響，進(jìn)一步得到采礦前的采礦結(jié)果預(yù)測值.通信協(xié)議和通信規(guī)則的制定與實施是智能外賣自助柜體物聯(lián)網(wǎng)系統(tǒng)的核心?？蚣軐φ麄€物聯(lián)網(wǎng)系統(tǒng)通信框架的設(shè)計和實現(xiàn)進(jìn)行了總結(jié)和闡述，基本保證了智能自提物聯(lián)網(wǎng)系統(tǒng)能夠安全、穩(wěn)定、高效地通信和傳輸數(shù)據(jù)。同時，該框架系統(tǒng)具有很強(qiáng)的可擴(kuò)展性，只需要進(jìn)行簡單的修改，即可應(yīng)用于其他物聯(lián)網(wǎng)系統(tǒng)。為了加速開發(fā)和提高代碼質(zhì)量，應(yīng)該使用MVP+Retrofit2+OkHTTP3+RxJava2模式來編譯和運行單個Presenter文件和服務(wù)文件作為JUnit單元測試。這種方法不需要在真實的機(jī)器或模擬器上進(jìn)行全局調(diào)試，也不需要考慮其他類文件的影響。通過JUnit單元測試，可以快速定位問題。通過對MVC模式和HTTP網(wǎng)絡(luò)請求的系統(tǒng)分析，發(fā)現(xiàn)在大中型項目中，MVC模式的應(yīng)用會使Activity/Fragment作為Controller層同時扮演View層的角色，這使得文件代碼數(shù)量膨脹，并增加了業(yè)務(wù)邏輯的耦合度。在項目的開發(fā)乃至后期的維護(hù)中都造成了很多問題。同時，官方提供的HttpURLConnection類在項目進(jìn)行復(fù)雜的多網(wǎng)絡(luò)請求場景時表現(xiàn)出了較差的性能和復(fù)雜的邏輯。根據(jù)MVP模式的設(shè)計理念，業(yè)務(wù)交付事件Presenter層進(jìn)行處理，這樣模型層和視圖層完全解耦，和責(zé)任分工開發(fā)模塊是整個項目更加明顯，所以邏輯代碼的耦合程度降低，便于后期維護(hù)和二次開發(fā)。同時，基于Retrofit+OkHttp+RxJava的響應(yīng)式網(wǎng)絡(luò)框架對于HTTP請求來說比HttpURlConnection更高效，業(yè)務(wù)處理也更簡單。隨著網(wǎng)絡(luò)請求邏輯變得更加復(fù)雜，RxJava的使用仍然很簡潔。用戶登錄模塊驗證了在Android應(yīng)用開發(fā)中結(jié)合MVP模式與Retrofit+OkHttp+RX-Java網(wǎng)絡(luò)框架的可行性。

詳細(xì)設(shè)計基于Android移動軟件框架是對移動通信軟件框架的一次研究，并且以服務(wù)器與移動端的框架設(shè)計為一方面，采用MVP、MVC模式與響應(yīng)式網(wǎng)絡(luò)請求框架為內(nèi)容，設(shè)計一個的移動框架，在這個框架中可以進(jìn)行網(wǎng)絡(luò)來構(gòu)建手機(jī)Android系統(tǒng)網(wǎng)絡(luò)即時通訊用戶之間的通信?？蚣芟旅鎸㈥U述了系統(tǒng)框架設(shè)計以及各個模式設(shè)計的方案細(xì)節(jié)。4.1MVP模式MVP，全稱Model-View-Presenter。MVP是在MVC的基礎(chǔ)上變化而出的，他們的思想有一些相通的地方。在MVP設(shè)計模式中，Model層只需要專注于數(shù)據(jù)的處理，View層專注于界面的展示，及生命周期的控制，而Presenter層負(fù)責(zé)全部業(yè)務(wù)處理，提供View層想要的數(shù)據(jù)，成為View層與Model層之間的橋梁。如圖4-1所示：圖4-1MVP模式4.1.1設(shè)計思想MVP的核心是View層不持有Model層對象任何引用，當(dāng)然參數(shù)里面和臨時變量里可以有Model層對象，只持有Presenter層對象引用，任何需要更新或者操作數(shù)據(jù)的，都間接通過Presenter對象去操作數(shù)據(jù)。而Model層想要操作View層是無法實現(xiàn)的，必須通過Presenter層。Presenter層持有View層對象的引用，除此之外不持有其他的UI控件等的引用，Model層會把想要更新View的操作委托Presenter去操作，而Presenter層會把更新View操作交給View層對象去操作。MVP最早出現(xiàn)在IBM的項目開發(fā)中。它由模型層（負(fù)責(zé)數(shù)據(jù)修改和操作）、視圖層（包含所有UI組件并負(fù)責(zé)與演示者層的所有交互）和演示者層（負(fù)責(zé)所有項目邏輯）組成。當(dāng)多個開發(fā)人員協(xié)作進(jìn)行開發(fā)和測試時，MVP模式提供了更大的解耦。使用MVP模式的優(yōu)點包括：（1）可以在Activity/Fragment中分離任務(wù)；（2）可以將一個復(fù)雜的多任務(wù)分解成幾個簡單的任務(wù)；（3）可以將頁面和數(shù)據(jù)分開；（4）推進(jìn)自動化單元測試；4.1.2實現(xiàn)過程應(yīng)用軟件中MVP模式的序列圖如圖4-2所示。在一個典型的Android應(yīng)用軟件中，有兩個參與者用戶（使用應(yīng)用軟件的人）和數(shù)據(jù)（存儲的信息實體）。以登錄操作為例：（1）用戶點擊按鈕獲取驗證碼；（2）View對象接收用戶動作并將委托動作發(fā)送給Presenter層，即執(zhí)行ActionSendMessage（）函數(shù)；（3）如果Presenter層需要接口或數(shù)據(jù)庫中的數(shù)據(jù)，它將通過GetMessage（）函數(shù)向Model層發(fā)送一個消息檢索數(shù)據(jù)。在這個過程中，Presenter層和Model層屬于觀察者和被觀察者之間的關(guān)系；（4）模型層獲取數(shù)據(jù)時，發(fā)送的主持人層將觀察的事件模型層，執(zhí)行ReturnSendMessage（）函數(shù)同時，發(fā)送一條消息到視圖層，并獲得CAPTCODE返回給用戶，從而完成獲得CAPTCODE的操作；圖4-2MVP模式順序圖4.2響應(yīng)式網(wǎng)絡(luò)請求框架4.2.1設(shè)計思想Retrofit2+OkHTTP3+RxJava2是如今使用廣泛的Android系統(tǒng)網(wǎng)絡(luò)框架。面對大量網(wǎng)絡(luò)請求時，性能不佳。與HttpURLConnection相比，底層的OkHttp3是基于OkHttp開源庫的。這樣一個根據(jù)OkHttp封裝而成的RESTful網(wǎng)絡(luò)請求軟件框架，Retrofit2是目前可用的耦合最少、功能最強(qiáng)大的網(wǎng)絡(luò)請求框架。當(dāng)與RxJava2結(jié)合使用時，Retrofit2將請求封裝到一個Observable對象中，在一個新線程中執(zhí)行HTTP請求，然后切換到IO線程來執(zhí)行用戶的后續(xù)操作。一般來說，Retrofit2將HTTP網(wǎng)絡(luò)請求作為接口，負(fù)責(zé)請求數(shù)據(jù)和接收結(jié)果，OkHttp3負(fù)責(zé)HTTP請求處理，RxJava2負(fù)責(zé)異步和多線程切換。4.2.2OkHttp3OkHttp是一個非常高效的Http客戶端，近年來幾乎所有的Android應(yīng)用都會使用它作為網(wǎng)絡(luò)訪問的框架。OkHttp特點有：（1）支持HTTP/2；（2）支持連接復(fù)用；（3）內(nèi)部維護(hù)連接池；（4）支持GZIP壓縮，節(jié)省流量；（5）維護(hù)緩存，提高響應(yīng)效率；（6）支持自動重連；OkHttp3是Square用于web請求的開源庫。使用OkHttp3進(jìn)行web請求可以更快地加載HTTP請求并節(jié)省帶寬。OKHTTP3在三個方面是有效的：（1）同意所有連接到同樣的一個主機(jī)請求共享同樣的一個套接字；（2）通過響應(yīng)式緩存避免重復(fù)請求；（3）每當(dāng)服務(wù)器中存在多個IP地址，第一個地址連接不成功，OKHttp3則會通過嘗試備用的IP地址來靜默恢復(fù)。4.2.3Retrofit2Retrofit來自Square，其中Retrofit可以理解為OkHttp的加強(qiáng)版，底層封裝了OkHttp。更加準(zhǔn)確的來說，Retrofit是一個RESTful的Http網(wǎng)絡(luò)請求框架的封裝。因為網(wǎng)絡(luò)請求工作本質(zhì)上是由OkHttp來完成，而Retrofit負(fù)責(zé)網(wǎng)絡(luò)請求接口的封裝。Retrofit的優(yōu)點有：（1）超級解耦，接口定義、接口參數(shù)、接口回調(diào)不在耦合在一起；（2）可以配置不同的HttpClient來實現(xiàn)網(wǎng)絡(luò)請求，如Okhttp、HttpClient；（3）支持同步、異步、RxJava；（4）可以配置不同反序列化工具類來解析不同的數(shù)據(jù)，如Json、Xml；（5）請求速度快，使用方便靈活簡潔；Retrofit2則能夠看成HTTP網(wǎng)絡(luò)請求的適配器，它通過Java或Kotlin接口來將HTTP的請求顯示為動態(tài)代理，與此同時通過OKHttp3來發(fā)送HTTP請求。Retrofit和OkHttp之間的關(guān)系可以概括為：OkHttp是一個純HTTP/SPDY客戶端；Retrofit是基于HTTP的高級REST抽象。Retrofit框架的優(yōu)點是：（1）盡量簡化URL的拼寫，使用清晰的注釋；（2）自由度大，支持自定義轉(zhuǎn)換器等業(yè)務(wù)邏輯；（3）支持同步執(zhí)行和異步同時執(zhí)行；（4）支持GSON、JSON、XML等多種文件解析；（5）支持RXJava；4.2.4RxJava2RXJava2則是一個根據(jù)異步事件而成的庫，異步操作中很關(guān)鍵的一點是簡潔性，因為在調(diào)度過程比較復(fù)雜的情況下，異步代碼既難寫也難讀懂。Android創(chuàng)造的Handler和AsyncTask其實都是為了讓異步代碼更加簡潔，RxJava的優(yōu)勢也是簡潔，它的特別之處是：隨著程序代碼邏輯的變得越來越復(fù)雜，它依然保持簡潔，如下圖4-3所示。圖4-3RxJava2RXJava2在Java虛擬機(jī)上運用能夠探測序列?？梢詫⑵湟暈橐粋€觀察者模式，RXJava2使用觀察者與被觀察者來進(jìn)行異步操作。與Android官方異步操作方法相比，RxJava的優(yōu)勢在于它的簡潔，這一點在項目因迭代而變得麻煩時得到了保留。4.2.5實現(xiàn)過程基于Retrofit2+OkHTTP3+RxJava2的響應(yīng)式網(wǎng)絡(luò)請求框架的整體流程如圖4-4所示。圖4-4網(wǎng)絡(luò)請求流程圖（1）導(dǎo)入相關(guān)的依賴項，并將域名傳遞到Retrofit構(gòu)造函數(shù)中；（2）通過改造。創(chuàng)建（）到Java接口并返回一個Call對象（默認(rèn)使用OKHttp3作為HTTP請求的客戶端）；（3）RXJava2調(diào)用。訂閱HTTP異步請求時使用enqueue（）；（4）網(wǎng)絡(luò)請求接收到響應(yīng)后，Call對象按照集合轉(zhuǎn)置模式對返回的信息進(jìn)行轉(zhuǎn)換；（5）返回結(jié)果數(shù)據(jù)；4.3MVP模式和網(wǎng)絡(luò)框架在Android應(yīng)用開發(fā)中的應(yīng)用4.3.1Model層Model層功能是處理數(shù)據(jù)和業(yè)務(wù)邏輯，如下圖4-5所示4-5Model層模型層的主要功能是從服務(wù)器獲取數(shù)據(jù)，由LoginRepository、LoginService和LoginServiceImpl組成。1）檢索用戶認(rèn)證代碼是在LoginRepository類中通過LoginRepositorysend–Message（）方法實現(xiàn)的，通過調(diào)用Retrofit2send–Message（）方法，實現(xiàn)HTTP請求，請求成功后，對數(shù)據(jù)進(jìn)行格式化。項目目錄結(jié)構(gòu)圖如圖4-6圖4-6項目目錄結(jié)構(gòu)圖為SendMessageBean實體類對象返回轉(zhuǎn)置。定義LoginRepository，SendMessage直到窗口過程處理完消息后才返回RetrofitFactory調(diào)用接口的過程之間，RetrofitFactory返回Retrofit的實例同時配置請求參數(shù)，并讓OkHttp3對服務(wù)器端進(jìn)行網(wǎng)絡(luò)請求。Retrofit實例調(diào)用接口API類中的相應(yīng)方法SendMessage（），并獲取HTTP請求的URL以發(fā)出網(wǎng)絡(luò)請求。（2）LoginService是一個接口類，定義了要實現(xiàn)的方法。（3）用戶信息系統(tǒng)LoginServiceImpl是LoginService接口的實現(xiàn)類。它通過調(diào)用LoginRepository類的SendMessage（）方法傳遞HTTP請求參數(shù)，并獲得請求結(jié)果的觀察對象。4.3.2View層View層的功能是顯示界面，展示結(jié)果等。View層主要對應(yīng)登錄接口LoginFragment。同時，View層定義了LoginView接口，包含了獲取短信成功和失敗的回調(diào)方法。LoginPresenter通過ReturnSendMessage（）和ReturnSendMessageError（）接口與LoginFragment交互。在LoginFragment中實現(xiàn)LoginView接口，獲取接口的返回值，更新UI等操作。4.3.3Presenter層Presenter的功能是協(xié)調(diào)Model和View模塊工作，處理交互。Presenter層是視圖層和模型層之間的橋梁。Login-Presenter持有對LoginView的引用，并在用戶觸發(fā)LoginFragment中的一個鍵時調(diào)用該方法中相應(yīng)的LoginPresenter方法。通過LoginService對象訪問Model層，獲得Observer對象的HTTP返回值，并在LoginFragmentUI更新中將該值傳遞給LoginView對象。

框架測試移動通信軟件框架旨在為基于AdHoc網(wǎng)絡(luò)的無線終端提供一個通用的通信軟件基礎(chǔ)平臺。應(yīng)用于嵌入式領(lǐng)域的移動通信軟件框架的總體結(jié)構(gòu)和主要設(shè)計環(huán)節(jié)，其中詳細(xì)闡述了等待停止協(xié)議的發(fā)送和接收算法以及組件管理機(jī)制。并在該框架的基礎(chǔ)上實現(xiàn)了即時消息和流媒體業(yè)務(wù)。經(jīng)過測試，可以獲得比較滿意的服務(wù)體驗。在順序模式挖掘中，挖掘結(jié)果必須由數(shù)據(jù)源的特征決定?；贏ndroid系統(tǒng)的移動軟件框架討論了客戶序列號、平均序列長度、平均事務(wù)長度和項目號等數(shù)據(jù)特征對挖掘結(jié)果的影響，找出了單個特征的影響程度。進(jìn)一步研究了平均項數(shù)對模型結(jié)果的影響以及四種特征對采礦結(jié)果的綜合影響，進(jìn)一步得到采礦前的采礦結(jié)果預(yù)測值.通信協(xié)議和通信規(guī)則的制定與實施是智能外賣自助柜體物聯(lián)網(wǎng)系統(tǒng)的核心?；贏ndroid系統(tǒng)的移動軟件框架對整個物聯(lián)網(wǎng)系統(tǒng)通信框架的設(shè)計和實現(xiàn)進(jìn)行了總結(jié)和闡述，基本保證了智能自提物聯(lián)網(wǎng)系統(tǒng)能夠安全、穩(wěn)定、高效地通信和傳輸數(shù)據(jù)。同時，該框架系統(tǒng)具有很強(qiáng)的可擴(kuò)展性，只需要進(jìn)行簡單的修改，即可應(yīng)用于其他物聯(lián)網(wǎng)系統(tǒng)。為了加速開發(fā)和提高代碼質(zhì)量，應(yīng)該使用MVP+Retrofit2+OkHTTP3+RxJava2模式來編譯和運行單個Presenter文件和服務(wù)文件作為Unit單元測試。這種方法不需要在真實的機(jī)器或模擬器上進(jìn)行全局調(diào)試，也不需要考慮其他類文件的影響。通過Unit單元測試，可以快速定位問題。通過對MVC模式和HTTP網(wǎng)絡(luò)請求的系統(tǒng)分析，發(fā)現(xiàn)在大中型項目中，MVC模式的應(yīng)用會使Activity/Fragment作為Controller層同時扮演View層的角色，這使得文件代碼數(shù)量膨脹，并增加了業(yè)務(wù)邏輯的耦合度。在項目的開發(fā)乃