王玉明，陳鈞

（南京工程學(xué)院計算機工程學(xué)院，南京 211167）

0 引言

Android系統(tǒng)占有市場超過80%的份額，占有更大的用戶基數(shù)，世界很多智能手機廠家?guī)缀醵技尤肓薃n?droid陣營，并推出了一系列的Android智能機。終端越多，其市場潛力就越大。從程序的移植和安裝這一角度來說，Android應(yīng)用商店最大的優(yōu)勢是，不對An?droid應(yīng)用程序的來源或者提供商進行嚴(yán)格的把控。在這一點上優(yōu)于蘋果。從Android系統(tǒng)自身的而更深層面來說，Android平臺是基于Linux內(nèi)核，具有更佳的可靠和安全，新的Linux內(nèi)核是未來的發(fā)展趨勢，An?droid開發(fā)更是未來趨勢[1]。

本項目的主要任務(wù)是完成在Android平臺上開發(fā)以XMPP協(xié)議為通信協(xié)議的即時通信應(yīng)用。在項目的研究開始階段，首先要求的是Android模擬器上模擬客戶端應(yīng)用程序的運行，搭設(shè)Tomcat或者Java程序作為主要通信的服務(wù)器。在項目的后期，豐富功能后，添加設(shè)計Socket服務(wù)器作為輔助進行通信。同時在設(shè)計該保證節(jié)約成本，優(yōu)化存儲結(jié)構(gòu)，使用客戶端和服務(wù)器一同進行存儲，避免相同數(shù)據(jù)的冗余和堆積現(xiàn)象。重要的是，對于聊天信息的閱讀狀況的正確及時的反饋。

1 系統(tǒng)相關(guān)技術(shù)

1.1 Android的相關(guān)組件

Android開發(fā)四大組件分別是：活動（Activity）：用于提供功能模塊的實現(xiàn)以及可視化的表現(xiàn)。服務(wù)（Ser?vice）：后臺運行服務(wù)，對用戶隱藏，不對用戶可見，不會和應(yīng)用組件進行交互。廣播接收器（Broadcast Re?ceiver）：用于接收廣播，異步接受Intent，一類主要是完全異步的接收正常廣播，另外一種是傳播有序廣播。內(nèi)容提供商（Content Provider）：主要功能是存儲和傳遞數(shù)據(jù)，另一個重要的功能是對外數(shù)據(jù)共享。

1.2 Android的UI的優(yōu)勢

Android平臺兼容多種的媒體格式，并提供相關(guān)插件和版本控制。在部分的按鍵和Viewer上，提供全息樣式和3D的立體圖標(biāo)，并且自帶圖片編輯器利用相關(guān)的數(shù)值參數(shù)控制斜度和紋理等特點。另外，Android的UI設(shè)計采用的是單線程的模型，拒絕在子線程中對于UI進行操作，所以另外提供了Handler的機制來進行協(xié)調(diào)通信。Handler機制中的主要對象是Looper，每一個線程中只會存在一個Looper對象，與ThreadLocal的思路一致，解決多線程的并發(fā)問題。

2 XMPP協(xié)議

XMPP協(xié)議是一個開放源碼的，以XML為基礎(chǔ)的可擴展的即時通信協(xié)議，其繼承了XML的靈活的可擴展性，以XML數(shù)據(jù)流為載體進行數(shù)據(jù)傳輸。其前身是Jabber協(xié)議，在2002年，XMPP工作組開發(fā)和改編協(xié)議以適應(yīng)IETF組織的消息和出席技術(shù)后有了目前的XMPP協(xié)議可以說協(xié)議是Jabber協(xié)議的核心。XMPP盡管不局限網(wǎng)絡(luò)拓撲結(jié)構(gòu)，但是通信時必須采用TCP協(xié)議，在協(xié)議結(jié)構(gòu)上使用的是結(jié)構(gòu)模型，由支持該協(xié)議的服務(wù)器轉(zhuǎn)發(fā)到目標(biāo)用戶，完成此類通訊[3]。

3 創(chuàng)新點和技術(shù)點

3.1 消息回執(zhí)的實現(xiàn)

在聊天的過程中，如果消息的接收方在已經(jīng)查看了信息的情況下，應(yīng)該對于該條的信息的發(fā)送方，給出一個問題的反饋，從而使得發(fā)送方得知，這條消息已經(jīng)被閱讀，從一定程度上，能夠解決問題推諉的問題。

其實現(xiàn)主要是對于消息包的監(jiān)控。在檢測到包的相關(guān)內(nèi)部檢測標(biāo)準(zhǔn)已經(jīng)有了改變的話，通過成員方法獲得到消息的相關(guān)信息，然后交給服務(wù)端，反饋信息給發(fā)送者。

3.2 長鏈接的實現(xiàn)

用戶所在客戶端需要不斷地從網(wǎng)絡(luò)上獲取信息，那么就需要解決兩個問題，一個是判斷當(dāng)前是否鏈接到網(wǎng)絡(luò)，另一則就是是否有新的信息需要接受。那么就需要一個長鏈接模塊。

長鏈接線程會先檢查網(wǎng)絡(luò)連接的狀態(tài)，由內(nèi)部的循環(huán)判斷是否建立過連接，是否來連接網(wǎng)絡(luò)，連接是否超時，一次來確定是否連接到網(wǎng)絡(luò)/。建立長鏈接的過程，其實質(zhì)是客戶端向服務(wù)器發(fā)送連接請求，請求服務(wù)器通過此鏈接向客戶端發(fā)送消息，客戶端維持一個消息分發(fā)線程，消息調(diào)用不同的處理過程

另外，如果想保持websocket連接的穩(wěn)定性，建議加上心跳包。可以每隔一段時間就發(fā)個簡單的字符串給后臺，讓后臺知道用戶在線，可以調(diào)用timetask以及CountDownTimer來完成。

4 系統(tǒng)模塊的設(shè)計與實現(xiàn)

4.1 系統(tǒng)總體框架的實現(xiàn)

參照MVC（Model View Controller，模型—視圖—控制器）的架構(gòu)設(shè)計模式，可以達到將業(yè)務(wù)邏輯、數(shù)據(jù)、界面顯示分離的結(jié)構(gòu)形式?？梢园堰@個系統(tǒng)分為如下的幾個功能層次：數(shù)據(jù)庫層（Model層），表現(xiàn)層（View層），業(yè)務(wù)處理層（Controller層），網(wǎng)絡(luò)通信層（網(wǎng)絡(luò)業(yè)務(wù)的處理層）。根據(jù)不同的業(yè)務(wù)要求，每一個層次同樣具有不同的模塊，每個模塊都具備各自的功能。

注意點主要集中在，需要固定層與層之間的通信接口，能夠清楚明白的描述層次和功能。有專業(yè)的要求盡量做到“高內(nèi)聚，低耦合”，在層次的內(nèi)部應(yīng)該模塊化，盡可能的降低模塊與模塊之間的聯(lián)系。同時要保證，接口的調(diào)用清晰明了。

4.2 客戶端的功能模塊與設(shè)計

針對此次對于通訊軟件的設(shè)計要求，盡量將軟件的使用的模塊簡化，大致包括以下的模塊：登錄注冊模塊、主界面顯示模塊、好友管理模塊、群組管理模塊、聊天模塊、個性化設(shè)置模塊等。每個模塊負責(zé)具體的不同的功能。

（1）用戶注冊界面：在新用戶要求注冊時，提供界面要求用戶對于昵稱、密碼、email信息進行填寫，并且在提交之前進行檢驗，滿足全部要求的才能注冊到服務(wù)器中保存。保存剛注冊的賬號和密碼，方便及時登錄。

（2）用戶登錄界面：在用戶登錄時，檢測賬號、密碼是否正確進行匹配，判斷賬號是否的格式、內(nèi)容輸入有誤，判斷該賬號有沒有存在共同登錄或者異地登錄的情況。

（3）好友管理模塊：進行好友的管理，功能要求要能夠進行添加好友、刪除好友、修改好友備注和分組等的操作，在這些操作之后，需要將修改的內(nèi)容存儲到本地或者是遠程的數(shù)據(jù)庫。

（4）群組管理模塊：進行群組的管理，功能要求要能夠進行創(chuàng)建群組、刪除群組、邀請好友、修改群組信息等。同時這些信息要注意管理員與普通用戶之間的權(quán)限的不同。

（5）主界面模塊：負責(zé)多個功能之間的切換。通過左劃、右劃以及對提供的工具欄的操作方式實現(xiàn)。以此來完成多個不同的模塊的功能的集合。同時要能夠顯示用戶的頭像，個性簽名，呈現(xiàn)狀態(tài)以及最近的聊天界面等狀態(tài)。但是同樣這些功能有的是平行的功能，有的是作為承載在主界面是上面的應(yīng)用。如聊天管理界面圖1。

由此也是所有的activity中布局最為復(fù)雜的一種，通過添加TextView,Button,ProgressBar等常用控件來編寫程序界面。主界面下需要防止多個聊天的窗口。主要的監(jiān)控就要交給后臺功能。Service不能自己運行，只能后臺運行，并且可以和其他組件進行交互。但是主界面一定存在相當(dāng)?shù)暮臅r操作，像需要發(fā)送網(wǎng)絡(luò)請求的時候，服務(wù)器未必會立刻的給出回復(fù)，如果不交給子線程，會導(dǎo)致主線程被阻塞，從而程序和用戶體驗。

聊天模塊：負責(zé)對于聊天的支持，對聊天的內(nèi)容進行處理。能群聊、單聊，能添加表情等。聊天記錄一樣能夠在本地端進行存儲，并且全部都以聊天窗口的形式顯示出來。主要的個人聊天界面，如圖2。

圖1 聊天管理界面

圖2 個人聊天界面

功能設(shè)置模塊：主要對應(yīng)用進行功能性設(shè)置，包括個人設(shè)置和系統(tǒng)設(shè)置。此類的系統(tǒng)配置屬于用戶對于Android的個性化配置，可以使用Android的Shared?Preferences功能，它是一個輕量級的存儲類，所以很適合用于保存軟件配置參數(shù)。通過XML文件存放數(shù)據(jù)，文件存放在本地安裝目錄下的/data/data//shared_prefs目錄下。

4.3 系統(tǒng)的用例分析

依據(jù)上面一個模塊對于功能模塊的分析結(jié)果，下面給出相關(guān)的用例圖，圖3。

從圖中可以看出，用戶需要先行注冊成為用戶，將其注冊的相關(guān)信息包括密碼賬號等，保存在數(shù)據(jù)庫，其次登錄客戶端，在這樣的情況下，用戶就可以查詢聊天記錄。查看發(fā)送的圖片或者文件等的操作，但是想進行單人聊天，群聊天需要先連接到服務(wù)器。

圖3 功能模塊的用例分析圖

4.4 系統(tǒng)的數(shù)據(jù)庫設(shè)計

在設(shè)計本課題系統(tǒng)時，需要考慮到數(shù)據(jù)的保存和可重復(fù)多次讀取的相關(guān)措施。Android本身有提供5中數(shù)據(jù)的存儲方式。第一種是SharedPreferences主要是用于存儲一些簡單的系統(tǒng)配置的信息，優(yōu)點在于簡單快捷的讀取和寫入方式。第二種是通過文件存儲數(shù)據(jù)，利用和Java一致的文件輸入輸出流實現(xiàn)。第三種是網(wǎng)絡(luò)存儲方式，主要是解決Android網(wǎng)絡(luò)數(shù)據(jù)包的問題。第四種就是組件之一的ContentProvider。第四種是利用開發(fā)的數(shù)據(jù)庫SQLite。

本課題系統(tǒng)的設(shè)計架構(gòu)是C/S架構(gòu)，為了降低數(shù)據(jù)的大量冗余，和堆積在服務(wù)器影響性能的問題，需要在服務(wù)器和客戶端上面同事的存儲數(shù)據(jù)。服務(wù)器主要利用輕型的mysql數(shù)據(jù)庫進行處理?？蛻舳藢⑸倭康南到y(tǒng)配置信息，例如用戶名和密碼，用戶的私人配置等信息保存在SharedPreferences中，主要還是通過SQLite進行保存。

本項目主要的數(shù)據(jù)庫表有User用戶信息表、Con?tacts：聯(lián)系人列表、Single_session單人會話列表、Sin?gle_message單人聊天信息表、Group_session多人會話列表、Group_message多人聊天信息表。

以下是聊天系統(tǒng)的ER圖：

圖4 聊天系統(tǒng)ER圖

5 結(jié)語

本系統(tǒng)主要使用Java語言開發(fā)，通過原型設(shè)計，數(shù)據(jù)庫設(shè)計，已完成基本的閱讀回執(zhí)功能，即時反饋已讀動態(tài)以及對重要的信息做出提醒，有一定的實用性。根據(jù)我們對于國內(nèi)外研究現(xiàn)狀、發(fā)展水平的分析了解，本系統(tǒng)開發(fā)成本低廉，效率高，擴展性好。

[1]呂留記.基于Android的即時通訊系統(tǒng)的研究與實現(xiàn)[D].電子科技大學(xué),2016.

[2]王少蕾.安全通信軟件“密迅”的Android手機客戶端的設(shè)計與實現(xiàn)[D].北京交通大學(xué),2014.

[3]高明鵬.基于XMPP協(xié)議的Android手機即時通信應(yīng)用研究與實現(xiàn)[D].南昌大學(xué),2012.

[4]郝秋影.基于Android的消息應(yīng)用的設(shè)計與實現(xiàn)[D].北京郵電大學(xué),2013.