一種基于Android系統(tǒng)的多協(xié)議通訊框架及通訊方法
【專利摘要】一種基于Android系統(tǒng)的多協(xié)議通訊框架及通訊方法，涉及Android系統(tǒng)的網(wǎng)絡(luò)通訊【技術(shù)領(lǐng)域】。該多協(xié)議通訊框架包括依次連接的NI0線程池模塊、NI0網(wǎng)絡(luò)連接模塊和NI0數(shù)據(jù)處理模塊。其中，所述NI0線程池模塊根據(jù)每次接收到的至少一個(gè)連接請求，創(chuàng)建一個(gè)NI0通訊線程；所述NI0網(wǎng)絡(luò)連接模塊根據(jù)每個(gè)連接請求的類型創(chuàng)建相應(yīng)的連接通道及相應(yīng)的數(shù)據(jù)處理接口，并將數(shù)據(jù)處理接口接收到的數(shù)據(jù)傳送給NI0數(shù)據(jù)處理模塊；所述NI0數(shù)據(jù)處理模塊用于對NI0網(wǎng)絡(luò)連接模塊傳來的數(shù)據(jù)進(jìn)行處理。本發(fā)明支持多種協(xié)議的并發(fā)請求，能高效、快捷地實(shí)現(xiàn)網(wǎng)絡(luò)通訊，降低了資源和時(shí)間的消耗。
【專利說明】-種基于Android系統(tǒng)的多協(xié)議通訊框架及通訊方法

【技術(shù)領(lǐng)域】
[0001] 本發(fā)明涉及Android系統(tǒng)的網(wǎng)絡(luò)通訊【技術(shù)領(lǐng)域】，具體來講是一種基于Android系 統(tǒng)的多協(xié)議通訊框架及通訊方法。

【背景技術(shù)】
[0002] Android是新一代的智能平臺，越來越多的電子終端使用Android作為操作系統(tǒng)， 使得Android系統(tǒng)的電子終端的用戶與日俱增。近年來，Android系統(tǒng)的攜著其顯著的開 放性、豐富的硬件選擇（手機(jī)或者平板電腦等產(chǎn)品）、強(qiáng)大的網(wǎng)絡(luò)應(yīng)用和全球IT企業(yè)都助 力Android等優(yōu)勢，成為時(shí)代潮流的引領(lǐng)者。越來越多的人開始使用帶有Android系統(tǒng)的 手機(jī)或者平板電腦等產(chǎn)品（最新數(shù)據(jù)顯示智能手機(jī)的市場份額為88%)。但Android系統(tǒng) 在多協(xié)議信息交換和應(yīng)對高并發(fā)網(wǎng)絡(luò)請求方面的應(yīng)用技術(shù)尚未成熟，特別是Android系統(tǒng) 的通訊無法快速高效地進(jìn)行多種協(xié)議切換。
[0003] 目前，現(xiàn)已存在的Android系統(tǒng)通訊多采用多線程處理多個(gè)連接的一對一方式。 當(dāng)有10000個(gè)連接請求時(shí)，可能就需要有10000個(gè)線程來處理，資源消耗極大，且會產(chǎn)生阻 塞。而一旦阻塞產(chǎn)生就會帶來大量的線程頻繁地進(jìn)行上下文切換，從而使得時(shí)間消耗過大。 另外，現(xiàn)有的Android系統(tǒng)通訊中，多協(xié)議并發(fā)請求沒有系統(tǒng)的整合在一起，無法快速地實(shí) 現(xiàn)多種協(xié)議之間的切換，使得通訊連接請求的處理速度較慢。


【發(fā)明內(nèi)容】

[0004] 針對現(xiàn)有技術(shù)中存在的缺陷，本發(fā)明的目的在于提供一種基于Android系統(tǒng)的多 協(xié)議通訊框架及通訊方法，支持多種協(xié)議的并發(fā)請求，能高效、快捷地實(shí)現(xiàn)網(wǎng)絡(luò)通訊，降低 了資源和時(shí)間的消耗。
[0005] 為達(dá)到以上目的，本發(fā)明提供一種基于Android系統(tǒng)的多協(xié)議通訊框架，包括：依 次連接的ΝΙ0線程池模塊、ΝΙ0網(wǎng)絡(luò)連接模塊和ΝΙ0數(shù)據(jù)處理模塊。其中，所述ΝΙ0線程池 模塊根據(jù)每次接收到的至少一個(gè)連接請求，創(chuàng)建一個(gè)ΝΙ0通訊線程，所述ΝΙ0通訊線程將每 個(gè)連接請求發(fā)送給ΝΙ0網(wǎng)絡(luò)連接模塊；所述ΝΙ0網(wǎng)絡(luò)連接模塊根據(jù)每個(gè)連接請求的類型創(chuàng) 建相應(yīng)的連接通道及相應(yīng)的數(shù)據(jù)處理接口，并將數(shù)據(jù)處理接口接收到的數(shù)據(jù)傳送給ΝΙ0數(shù) 據(jù)處理模塊；所述ΝΙ0數(shù)據(jù)處理模塊用于對ΝΙ0網(wǎng)絡(luò)連接模塊傳來的數(shù)據(jù)進(jìn)行處理。
[0006] 在上述技術(shù)方案的基礎(chǔ)上，所述ΝΙ0線程池模塊每次接收到的連接請求的個(gè)數(shù)范 圍為1?5。
[0007] 在上述技術(shù)方案的基礎(chǔ)上，所述連接請求的類型包括TCP連接、UDP連接和HTTP連 接。
[0008] 在上述技術(shù)方案的基礎(chǔ)上，所述ΝΙ0數(shù)據(jù)處理模塊包括處理TCP連接數(shù)據(jù)的TCP 數(shù)據(jù)處理模塊、處理m)P連接數(shù)據(jù)的UDP數(shù)據(jù)處理模塊以及處理HTTP連接數(shù)據(jù)的HTTP數(shù) 據(jù)處理模塊。
[0009] 本發(fā)明還提供一種基于Android系統(tǒng)的多協(xié)議通訊方法，包括如下步驟：
[0010] SI :初始化NI0線程池模塊，并接收連接請求，且NI0線程池模塊每次接收至少一 個(gè)連接請求。
[0011] S2 :ΝΙ0線程池模塊每次接收到所述至少一個(gè)連接請求后，就創(chuàng)建一個(gè)ΝΙ0通訊線 程，所述ΝΙ0通訊線程將每個(gè)連接請求發(fā)送給ΝΙ0網(wǎng)絡(luò)連接模塊。
[0012] S3 :ΝΙ0網(wǎng)絡(luò)連接模塊根據(jù)每個(gè)連接請求的類型，創(chuàng)建相應(yīng)的連接通道及相應(yīng)的 數(shù)據(jù)處理接口。
[0013] S4 :ΝΙ0通訊線程對每個(gè)數(shù)據(jù)處理接口進(jìn)行監(jiān)聽，判斷是否有數(shù)據(jù)到來，若是，則 進(jìn)入S5,若否，則繼續(xù)監(jiān)聽。
[0014] S5 :ΝΙ0通訊線程通知ΝΙ0網(wǎng)絡(luò)連接模塊，并將數(shù)據(jù)提交給ΝΙ0網(wǎng)絡(luò)連接模塊。
[0015] S6 :ΝΙ0網(wǎng)絡(luò)連接模塊在接收到數(shù)據(jù)之后，交由ΝΙ0數(shù)據(jù)處理模塊進(jìn)行處理。
[0016] 在上述技術(shù)方案的基礎(chǔ)上，步驟S1中，所述連接請求的類型包括TCP連接、UDP連 接和HTTP連接。
[0017] 在上述技術(shù)方案的基礎(chǔ)上，步驟S3中，ΝΙ0網(wǎng)絡(luò)連接模塊，根據(jù)TCP連接的連接請 求創(chuàng)建套接字通道以及相應(yīng)的ΝΙ0處理器接口；根據(jù)UDP連接的連接請求創(chuàng)建數(shù)據(jù)報(bào)通道 以及相應(yīng)的ΝΙ0處理器接口；根據(jù)HTTP連接的連接請求創(chuàng)建套接字通道以及相應(yīng)的ΝΙ0處 理器接口。
[0018] 在上述技術(shù)方案的基礎(chǔ)上，所述ΝΙ0數(shù)據(jù)處理模塊包括TCP數(shù)據(jù)處理模塊、UDP數(shù) 據(jù)處理模塊以及HTTP數(shù)據(jù)處理模塊。步驟S6中，ΝΙ0網(wǎng)絡(luò)連接模塊在接收到數(shù)據(jù)之后，將 根據(jù)數(shù)據(jù)的連接通道判斷屬于TCP連接、UDP連接、HTTP連接中的哪一種，并交由ΝΙ0數(shù)據(jù) 處理模塊中相應(yīng)的TCP數(shù)據(jù)處理模塊、UDP數(shù)據(jù)處理模塊、HTTP數(shù)據(jù)處理模塊進(jìn)行處理。
[0019] 在上述技術(shù)方案的基礎(chǔ)上，所述步驟S6中，ΝΙ0數(shù)據(jù)處理模塊進(jìn)行處理時(shí)，若出現(xiàn) 數(shù)據(jù)接收不完全的情況，表明連接斷開，則反饋需要重新連接的消息給ΝΙ0網(wǎng)絡(luò)連接模塊； 若出現(xiàn)接收不到數(shù)據(jù)的情況，表明連接超時(shí)，則提示ΝΙ0網(wǎng)絡(luò)連接模塊檢查連接通道及相 應(yīng)的數(shù)據(jù)處理接口，并重新連接；若出現(xiàn)接收的數(shù)據(jù)錯(cuò)誤的情況，則通知ΝΙ0網(wǎng)絡(luò)連接模塊 重新指定連接通道及相應(yīng)的數(shù)據(jù)處理接口。
[0020] 本發(fā)明的有益效果在于：
[0021] 1、本發(fā)明采用了線程池模塊的設(shè)計(jì)，形成了 NI0(N〇n-bl〇cking 1/0,非阻塞通訊 模式）的通訊方法。該方法使得處理連接的線程數(shù)和連接請求的個(gè)數(shù)沒有一對一的聯(lián)系， 也就是說處理10000個(gè)連接請求，ΝΙ0方式不需要10000個(gè)線程，可以用2000或更少的線 程來處理。這樣，就避免了大量的線程頻繁地進(jìn)行上下文切換，能高效、快捷地實(shí)現(xiàn)網(wǎng)絡(luò)通 訊，降低資源和時(shí)間的消耗。
[0022] 2、本發(fā)明將多協(xié)議并發(fā)請求系統(tǒng)的整合在一起，同時(shí)支持TCP(Transmission Control Protocol,傳輸控制協(xié)議）、UDP(User Data Protocol,用戶數(shù)據(jù)報(bào)協(xié)議）以及 HTTP (Hypertext Transfer Protocol,超文本傳送協(xié)議），能夠方便快捷地在多協(xié)議之間切 換，大幅提升了系統(tǒng)工作效率。
[0023] 3、本發(fā)明的ΝΙ0數(shù)據(jù)處理模塊還能實(shí)現(xiàn)連接斷開、連接超時(shí)以及數(shù)據(jù)接收錯(cuò)誤等 故障的處理，提升了系統(tǒng)的容錯(cuò)性，保證了系統(tǒng)運(yùn)行的穩(wěn)定性。

【專利附圖】

【附圖說明】
[0024] 圖1為本發(fā)明基于Android系統(tǒng)的多協(xié)議通訊框架的結(jié)構(gòu)框圖；
[0025] 圖2為本發(fā)明基于Android系統(tǒng)的多協(xié)議通訊方法的流程圖。

【具體實(shí)施方式】
[0026] 以下結(jié)合附圖對本發(fā)明的實(shí)施例作進(jìn)一步詳細(xì)說明。
[0027] 如圖1所示，本發(fā)明提供一種基于Android系統(tǒng)的多協(xié)議通訊框架，包括依次連接 的ΝΙ0線程池模塊、ΝΙ0網(wǎng)絡(luò)連接模塊和ΝΙ0數(shù)據(jù)處理模塊。
[0028] 其中，所述ΝΙ0線程池模塊根據(jù)每次接收到的至少一個(gè)連接請求，創(chuàng)建一個(gè)ΝΙ0通 訊線程，所述ΝΙ0通訊線程將每個(gè)連接請求發(fā)送給ΝΙ0網(wǎng)絡(luò)連接模塊。ΝΙ0線程池模塊的設(shè) 計(jì)，形成了非阻塞通訊模式，使得處理連接的ΝΙ0通訊線程的個(gè)數(shù)和連接請求的個(gè)數(shù)無需 一對一的聯(lián)系，避免了大量的線程頻繁地進(jìn)行上下文切換，能高效、快捷地實(shí)現(xiàn)網(wǎng)絡(luò)通訊， 降低資源和時(shí)間的消耗。并且，ΝΙ0線程池模塊每次接收到的連接請求的個(gè)數(shù)范圍為1? 5,連接請求的類型包括TCP連接、UDP連接和HTTP連接，能同時(shí)支持TCP協(xié)議、UDP協(xié)議以 及HTTP協(xié)議，能夠方便快捷地在多協(xié)議之間切換，大幅提升了系統(tǒng)工作效率。
[0029] 所述ΝΙ0網(wǎng)絡(luò)連接模塊根據(jù)每個(gè)連接請求的類型創(chuàng)建相應(yīng)的連接通道及相應(yīng)的 數(shù)據(jù)處理接口，并將數(shù)據(jù)處理接口接收到的數(shù)據(jù)傳送給ΝΙ0數(shù)據(jù)處理模塊。
[0030] 所述ΝΙ0數(shù)據(jù)處理模塊用于對ΝΙ0網(wǎng)絡(luò)連接模塊傳來的數(shù)據(jù)進(jìn)行處理。其中，所 述ΝΙ0數(shù)據(jù)處理模塊包括處理TCP連接數(shù)據(jù)的TCP數(shù)據(jù)處理模塊、處理UDP連接數(shù)據(jù)的UDP 數(shù)據(jù)處理模塊以及處理HTTP連接數(shù)據(jù)的HTTP數(shù)據(jù)處理模塊。
[0031] 如圖2所示，一種基于Android系統(tǒng)的多協(xié)議通訊方法，包括如下步驟：
[0032] S1 :初始化ΝΙ0線程池模塊，并接收連接請求，且ΝΙ0線程池模塊每次接收至少一 個(gè)連接請求。其中，連接請求的類型包括TCP連接、UDP連接和HTTP連接。
[0033] S2 :ΝΙ0線程池模塊每次接收到所述至少一個(gè)連接請求后，就創(chuàng)建一個(gè)ΝΙ0通訊線 程，所述ΝΙ0通訊線程將每個(gè)連接請求發(fā)送給ΝΙ0網(wǎng)絡(luò)連接模塊；
[0034] S3 :ΝΙ0網(wǎng)絡(luò)連接模塊根據(jù)每個(gè)連接請求的類型，創(chuàng)建相應(yīng)的連接通道及相應(yīng)的 數(shù)據(jù)處理接口。具體來說，根據(jù)TCP連接的連接請求創(chuàng)建套接字通道（SocketChannel) 以及相應(yīng)的ΝΙ0處理器（NIOHandler)接口；根據(jù)UDP連接的連接請求創(chuàng)建數(shù)據(jù)報(bào)通道 (DatagramChannel)以及相應(yīng)的ΝΙ0處理器接口；根據(jù)HTTP連接的連接請求創(chuàng)建套接字通 道以及相應(yīng)ΝΙ0處理器接口。
[0035] S4 :ΝΙ0通訊線程對每個(gè)數(shù)據(jù)處理接口進(jìn)行監(jiān)聽，判斷是否有數(shù)據(jù)到來，若是，則 進(jìn)入S5,若否，則繼續(xù)監(jiān)聽；
[0036] S5 :ΝΙ0通訊線程通知ΝΙ0網(wǎng)絡(luò)連接模塊，并將數(shù)據(jù)提交給ΝΙ0網(wǎng)絡(luò)連接模塊；
[0037] S6 :ΝΙ0網(wǎng)絡(luò)連接模塊在接收到數(shù)據(jù)之后，交由ΝΙ0數(shù)據(jù)處理模塊進(jìn)行處理，所述 ΝΙ0數(shù)據(jù)處理模塊包括TCP數(shù)據(jù)處理模塊、UDP數(shù)據(jù)處理模塊以及HTTP數(shù)據(jù)處理模塊。ΝΙ0 網(wǎng)絡(luò)連接模塊將根據(jù)數(shù)據(jù)的連接通道判斷屬于TCP連接、UDP連接、HTTP連接中的哪一種， 并交由ΝΙ0數(shù)據(jù)處理模塊中相應(yīng)的TCP數(shù)據(jù)處理模塊、UDP數(shù)據(jù)處理模塊、HTTP數(shù)據(jù)處理模 塊進(jìn)行處理。
[0038] ΝΙ0數(shù)據(jù)處理模塊進(jìn)行處理時(shí)，若出現(xiàn)數(shù)據(jù)接收不完全的情況，表明連接斷開，則 反饋需要重新連接的消息給ΝΙ0網(wǎng)絡(luò)連接模塊；若出現(xiàn)接收不到數(shù)據(jù)的情況，表明連接超 時(shí)，則提示NIO網(wǎng)絡(luò)連接模塊檢查連接通道及相應(yīng)的數(shù)據(jù)處理接口，并重新連接；若出現(xiàn) 接收的數(shù)據(jù)錯(cuò)誤的情況，則通知NI0網(wǎng)絡(luò)連接模塊重新指定連接通道及相應(yīng)的數(shù)據(jù)處理接 口。NI0數(shù)據(jù)處理模塊的故障處理功能，提升了系統(tǒng)的容錯(cuò)性，保證了系統(tǒng)運(yùn)行的穩(wěn)定性。
[0039] 本發(fā)明不局限于上述實(shí)施方式，對于本【技術(shù)領(lǐng)域】的普通技術(shù)人員來說，在不脫離 本發(fā)明原理的前提下，還可以做出若干改進(jìn)和潤飾，這些改進(jìn)和潤飾也視為本發(fā)明的保護(hù) 范圍之內(nèi)。本說明書中未作詳細(xì)描述的內(nèi)容屬于本領(lǐng)域?qū)I(yè)技術(shù)人員公知的現(xiàn)有技術(shù)。
【權(quán)利要求】
1. 一種基于Android系統(tǒng)的多協(xié)議通訊框架，其特征在于：包括依次連接的NIO線程 池模塊、NI0網(wǎng)絡(luò)連接模塊和NI0數(shù)據(jù)處理模塊； 其中，所述NI0線程池模塊根據(jù)每次接收到的至少一個(gè)連接請求，創(chuàng)建一個(gè)NI0通訊線 程，所述NI0通訊線程將每個(gè)連接請求發(fā)送給NI0網(wǎng)絡(luò)連接模塊； 所述NI0網(wǎng)絡(luò)連接模塊根據(jù)每個(gè)連接請求的類型創(chuàng)建相應(yīng)的連接通道及相應(yīng)的數(shù)據(jù) 處理接口，并將數(shù)據(jù)處理接口接收到的數(shù)據(jù)傳送給NI0數(shù)據(jù)處理模塊； 所述NI0數(shù)據(jù)處理模塊用于對NI0網(wǎng)絡(luò)連接模塊傳來的數(shù)據(jù)進(jìn)行處理。
2. 如權(quán)利要求1所述的基于Android系統(tǒng)的多協(xié)議通訊框架，其特征在于：所述NI0線 程池模塊每次接收到的連接請求的個(gè)數(shù)范圍為1?5。
3. 如權(quán)利要求1所述的基于Android系統(tǒng)的多協(xié)議通訊框架，其特征在于：所述連接 請求的類型包括TCP連接、UDP連接和HTTP連接。
4. 如權(quán)利要求1所述的基于Android系統(tǒng)的多協(xié)議通訊框架，其特征在于：所述NI0數(shù) 據(jù)處理模塊包括處理TCP連接數(shù)據(jù)的TCP數(shù)據(jù)處理模塊、處理UDP連接數(shù)據(jù)的UDP數(shù)據(jù)處 理模塊以及處理HTTP連接數(shù)據(jù)的HTTP數(shù)據(jù)處理模塊。
5. -種基于權(quán)利要求1所述多協(xié)議通訊框架的多協(xié)議通訊方法，其特征在于，包括如 下步驟： 51 :初始化NI0線程池模塊，并接收連接請求，且NI0線程池模塊每次接收至少一個(gè)連 接請求； 52 :NI0線程池模塊每次接收到所述至少一個(gè)連接請求后，就創(chuàng)建一個(gè)NI0通訊線程， 所述NI0通訊線程將每個(gè)連接請求發(fā)送給NI0網(wǎng)絡(luò)連接模塊； 53 :NI0網(wǎng)絡(luò)連接模塊根據(jù)每個(gè)連接請求的類型，創(chuàng)建相應(yīng)的連接通道及相應(yīng)的數(shù)據(jù) 處理接口； 54 :NI0通訊線程對每個(gè)數(shù)據(jù)處理接口進(jìn)行監(jiān)聽，判斷是否有數(shù)據(jù)到來，若是，則進(jìn)入 S5,若否，則繼續(xù)監(jiān)聽； 55 :NI0通訊線程通知NI0網(wǎng)絡(luò)連接模塊，并將數(shù)據(jù)提交給NI0網(wǎng)絡(luò)連接模塊； 56 :NI0網(wǎng)絡(luò)連接模塊在接收到數(shù)據(jù)之后，交由NI0數(shù)據(jù)處理模塊進(jìn)行處理。
6. 如權(quán)利要求5所述的多協(xié)議通訊方法，其特征在于：步驟S1中，所述連接請求的類 型包括TCP連接、UDP連接和HTTP連接。
7. 如權(quán)利要求6所述的多協(xié)議通訊方法，其特征在于：步驟S3中，NI0網(wǎng)絡(luò)連接模塊， 根據(jù)TCP連接的連接請求創(chuàng)建套接字通道以及相應(yīng)的NI0處理器接口；根據(jù)UDP連接的連 接請求創(chuàng)建數(shù)據(jù)報(bào)通道以及相應(yīng)的NI0處理器接口；根據(jù)HTTP連接的連接請求創(chuàng)建套接字 通道以及相應(yīng)的NI0處理器接口。
8. 如權(quán)利要求7所述的多協(xié)議通訊方法，其特征在于：所述NI0數(shù)據(jù)處理模塊包括TCP 數(shù)據(jù)處理模塊、m)P數(shù)據(jù)處理模塊以及HTTP數(shù)據(jù)處理模塊；步驟S6中，NI0網(wǎng)絡(luò)連接模塊 在接收到數(shù)據(jù)之后，將根據(jù)數(shù)據(jù)的連接通道判斷屬于TCP連接、UDP連接、HTTP連接中的哪 一種，并交由NI0數(shù)據(jù)處理模塊中相應(yīng)的TCP數(shù)據(jù)處理模塊、UDP數(shù)據(jù)處理模塊、HTTP數(shù)據(jù) 處理模塊進(jìn)行處理。
9. 如權(quán)利要求8所述的多協(xié)議通訊方法，其特征在于：所述步驟S6中，NI0數(shù)據(jù)處理模 塊進(jìn)行處理時(shí)，若出現(xiàn)數(shù)據(jù)接收不完全的情況，表明連接斷開，則反饋需要重新連接的消息 給NIO網(wǎng)絡(luò)連接模塊；若出現(xiàn)接收不到數(shù)據(jù)的情況，表明連接超時(shí)，則提示NIO網(wǎng)絡(luò)連接模 塊檢查連接通道及相應(yīng)的數(shù)據(jù)處理接口，并重新連接；若出現(xiàn)接收的數(shù)據(jù)錯(cuò)誤的情況，則通 知NI0網(wǎng)絡(luò)連接模塊重新指定連接通道及相應(yīng)的數(shù)據(jù)處理接口。
【文檔編號】H04L29/06GK104219231SQ201410419975
【公開日】2014年12月17日 申請日期:2014年8月25日 優(yōu)先權(quán)日:2014年8月25日
【發(fā)明者】金鑫 申請人:華中科技大學(xué)