基于Socket通信的社交應用軟件

甄泰航

（哈爾濱工程大學 黑龍江省哈爾濱市 150000）

1 課題背景

在實現階段，目前市場大部分社交軟件實現的客戶-服務器的通信方式，響應方面可能存在時間方面的不足。因此在社交應用軟件上的Socket 通信方式的優勢開始顯現出來：Socket(套接字)是把傳輸層上層復雜操作抽象化的一組實現接口，在編寫代碼時只需配置文件調用相應驅動方法就可以在數據傳輸時滿足TCP/IP協議，通過此方式實現通信過程。因此對于用戶使用來說，一組簡單的接口足以讓Socket 按照指定的協議組織數據。

該社交聊天系統將采用多種技術和平臺進行開發，從角色功能上將系統分為Android Studio 開發的用戶端和MyEclipse 開發的管理員端：

客戶端管理員與用戶分開開發實現。在客戶端的管理員模塊界面利用MyEclipse 平臺進行Servlet 配置和JDBC 配置開發Java web,管理員在瀏覽器上訪問頁面網址進入相應頁面，而用戶模塊界面采用Android Studio 平臺開發，依靠模擬器進行在PC 端實現。這樣開發的優勢在于我個人來說能進行對系統的分解開發，而且能夠充分利用所學知識進行畢業設計。此外在引入相關的SDK 時Android Studio 與MyEclipse 可進行共用，能更加方便組織相關開發工具包或者擴展包的路徑。

發布的空間動態和聊天信息的存儲。有關空間動態的存儲內容主要分為文字和圖片兩部分。對于文字信息的存儲，本系統采用MySQL 數據庫中相關位置來存儲，而對于圖片信息的存儲，則將其圖片的文件存放地址保存到數據庫中，這樣設計方便用戶在獲取圖片的時候直接在數據庫中訪問地址獲取圖片。有關用戶聊天信息的存儲則利用Android 支持的SQLite 數據庫進行存儲，它的優勢在于非常輕量級，存儲數據非常高效，查詢和操作數據簡單方便。此外 SQLite 不需要安裝和配置，有很好的遷移性，能夠嵌入到很多應用程序中。

2 系統關鍵技術

2.1 Android的系統架構

安卓系統層次主要分為四層，分為應用層（利用該層JAVA 編寫代碼進行實現功能）、應用框架層（主要包含的服務能提供各種安卓開發的基本組件，如內容提供器等等）、系統運行庫層（提供如SQLite 等可供調用的數據庫等功能）、Linux 內核層（與底層驅動相關）[7]。

2.1.1 Linux 內核層（Linux Kernel)

Linux 內核層主要涉及一些與底層驅動相關的方法和接口，如藍牙驅動、相機驅動等。

2.1.2 系統運行庫層（Libraries 和Android runtime）

該層主要對項目系統提供了開發可能使用的一些特性支持，如SQLite 庫提供微型數據庫，Webkit 提供瀏覽器內核支持，還有媒體框架等其他方面[9]。

2.1.3 應用框架層（ApplicationFramework）

在Android Studio 中我們各種管理器位于該層，可以用相應的代碼進行開發和驅動，其中與安卓開發有關的各種基本控件也都是在該層，對APP 程序進行管理。

2.1.4 應用層（Application）

在構建程序時在該層中進行代碼的編寫（Android Studio 中的APP 包），在項目中在該層采用java 語言進行編寫。此外該層也支持用戶所采用的一些前端，如手機模擬器、瀏覽器等。通過框架層管理好的APP 程序可以通過應用層服務于用戶。

2.2 Android四大核心組件

安卓系統在開發應用程序時有四個基本組件尤為重要，它們分別是Activity、Service、Content Provider 以及BroadcastReceiver[5]。

Activity 在應用程序中通常會以一個包含一些控件的界面來顯示，可以隨時監聽并處理即將發生的用戶事件。在一個Activity 與另一個Activity 之間采用相應的代碼來做連接實現相應的界面切換或者數據流傳輸，通常以按鈕的方式來使程序通過相應的判斷進入相應的下一界面。

Service 是一個長期存在的沒有用戶界面的程序，可用于開發監控等程序[11]。在用戶在使用應用程序時如果在利用Activity 實現各界面跳轉時而要維持某些狀態繼續運行，可以通過相應方法啟動Service 程序來完成，而該狀態會一直保持直到其結束，不受界面跳轉的影響。

Content Provider 能夠使程序指定的數據集提供給其他應用程序[2]，在應用程序內即將處理或者處理后數據要用于進行存儲或其他用處時就可以用到它進行處理，在某些方面起到了接口的作用。

BroadcastReceive 主要用于在Activity 進行事件處理的時候對于某些事件可起到屏蔽的作用。它和Service 一樣沒有用戶界面，但是能夠和Activity或者Service相互配合來響應應該接受的信息[5]，也對與框架層內其他部分進行調用來實現應用程序的相關要求。

2.3 B/S技術

B/S 結構（瀏覽器/服務器模式），是在互聯網技術興起后對C/S 進行改進而新形成的網絡結構，之所以快速崛起是因為C/S 只能應用在小范圍的網絡環境之中并配備專門服務器，相比B/S 則是以廣域網為基礎的，因此相比之下安全性隱患較大。但是B/S 架構可以讓我們在后臺編寫成的系統功能可以在服務器上得以實現，對系統開發人員、測試人員甚至用戶有極為方便的體驗。用戶需在系統開發后安裝瀏覽器后使項目利用服務器運行，如Internet Explorer等，安裝數據庫用以進行系統的數據訪問，如MySQL 等。只需要通過網絡服務器，瀏覽器與數據庫就可以隨時進行數據存儲或訪問。

用戶在瀏覽器上進行的如增刪改查等各種操作通過服務器進行對數據庫內數據的請求訪問。用戶在瀏覽器端的請求交由服務器處理，然后將相應的處理結果反饋給瀏覽器，這樣用戶的要求就會得以實現。其他的數據處理和請求都由Web 服務器完成。由于不同瀏覽器在操作系統中被廣泛嵌入和使用，而且不斷發展，該結構已經成為軟件應用的主流結構模式。

2.4 SQLite數據庫

SQLite 是一個輕型的、無需服務器的、無需復雜配置的開源數據庫，由D.Richard Hipp 在2000年發布。SQLite 最大的特點是使用便捷、調用方便，性能卓越，目前廣泛應用于各種領域的軟件開發中，仍然在不斷發展。此外最重要的時SQLite 存儲信息是無類型的，這意味著可以將任何類型的數據保存到任何要保存的所創建的表中任何列中，而且無需聲明該列的數據類型是什么，在SQLite數據庫中我們可以完全不用指明該字段的類型。

此外SQLite 還具有以下優缺點：

（1）輕量級：它所占用資源非常低，甚至只需要幾百K 的內存就可以運行。

（2）讀寫性能：由于它不存在數據庫的服務器端，因此對數據庫內數據的訪問性能很高，與其他的開源數據庫相比SQLite 的運行速度要快很多。但是在讀寫方面SQLite 存在性能不足的問題，在讀寫操作使可能會出現數據庫阻塞的現象。

（3）兼容性強：能在裝載32 位或64 位操作系統上的計算機上成功運行，除了當前主流的操作系統之外，它也能對許多移動嵌入式操作系統也提供支持，如安卓、塞班、Windows Mobile 等。

（4）接口：SQLite 能夠用不同編程語言進行實現并為其提供了編程接口，如Java、PHP、Python 等并有相應的配置代碼和驅動方法，對于掌握不同代碼要求的用戶有極大便利。

3 系統分析

3.1 系統功能需求分析

本社交聊天應用軟件主要滿足了用戶進行社交交友聊天的功能，前端用戶通過本平臺可進行添加好友、好友聊天，同時系統還設有朋友圈功能，用戶可發布分享信息，此外對于違規前端用戶可進行封禁，充分滿足前端用戶的各類需求。

后臺管理員可登錄賬號查看所有用戶的各項信息，并可對違規用戶進行封號或者解封操作。

本系統客戶端的大功能模塊可分為：用戶模塊、管理員模塊、用戶關系模塊、空間動態模塊、社交聊天模塊四部分。

用戶模塊：該模塊主要體現每位用戶的個人基本資料信息及其相關操作。主要包括用戶注冊子模塊、用戶登錄子模塊、個人資料修改子模塊、賬號登出子模塊、密碼修改子模塊。

用戶關系模塊：該模塊主要體現用戶之間的關系，如在社交軟件中兩個用戶甲和乙，甲向乙發送好友請求后，乙收到通知消息后同意添加好友，則甲和乙成為好友關系，而無需乙再向甲發送好友請求。這種單向關系在社交聊天軟件中非常方便。此外系統用戶間存在投訴關系，其他可對非法用戶提供投訴并反饋至后臺處理，該模塊主要包括檢索聯系人模塊，添加好友模塊、投訴用戶模塊、好友驗證模塊。

空間動態模塊：該模塊主要實現用戶的空間動態的發布，文本和圖片形式均可實現，其他用戶可以對其動態進行點贊與評論。主要包括點贊模塊、評論模塊、發布模塊。

社交聊天模塊：該模塊是本系統所實現的最重要部分，用戶之間進行聊天交流都需要通過該模塊實現，用戶之間可通過發送文本、圖片、語音以及Emoji 表情等進行信息交流。

系統的后臺管理系統中作為系統管理者和維護者，管理員通過賬號密碼進行登錄后查詢看到所有用戶注冊的基本信息，對于其他用戶的投訴信息可進行處理（進行解禁或者徹底清空該違禁用戶數據）。

3.2 系統性能需求分析

（1）存儲性：用戶數據方面可能信息數量過大，存儲處理較為麻煩，所以項目采用MySQL 數據庫進行開發，利用其能夠存儲處理大量數據的特點。此外在軟件實際投入使用或者后續開發時，最好再額外配備專門的數據庫管理員進行管理，保證存儲的用戶數據完整性和安全性。

（2）易學性：系統設計的各種功能操作對于用戶使用應該簡單方便，在界面上有合理明確的控件或者文字提示，保證用戶按照正常使用習慣滿足自己需求。

（3）數據要求：數據庫內的數據應該統一規范化處理，保證存儲數據的實時性和獨立性。例如不能產生刪除某些數據的時候會連帶著把不需要刪除的數據都刪除掉的情況發生（本系統刪除封禁用戶，即解禁時，不應把該用戶的全部數據庫數據刪除）。

（4）穩定性：開發的基于Socket 通信的社交應用軟件在服務器開啟、代碼運行之后系統各界面、控件以及鏈接等應該能夠穩定實現，所運行的代碼不出現崩潰現象。

（5）安全性：在開發系統的編碼過程中要避免病毒類或漏洞類代碼的產生，必須在登陸、注冊等方面設計相應的驗證方法以攔截陌生或非法賬號。

4 系統設計與實現

4.1 系統開發流程設計

在開發基于Socket 通信的社交應用軟件時，需要進行項目分析對系統的整個流程進行規范設計。首先從業務、用戶等多方面角度進行項目系統的需求分析。第二根據需求分析的結果進行各部分和整體的設計，注意各部分之間的關系。第三將編寫代碼實現各部分功能。第四將開發好的各功能模塊進行整合，并整體開發。最后對系統進行的測試，發現錯誤或者缺陷后及時修正。

4.2 系統運行環境設計

系統開發運行采用支持Windows10 操作系統和配置好Java 環境的計算機，采用開源的Tomcat7.0 作為服務器，采用MySQL 數據庫進行數據存儲，通過MyEclipse 平臺和Android Studio 平臺分別對管理員界面和用戶界面進行代碼編寫開發。

4.3 數據庫表設計

基于Socket 通信的社交聊天應用軟件基于MYSQL 數據庫進行數據存儲，下面介紹數據庫中的各個表的詳細信息。

表1：瀏覽器兼容性測試用例表

表2：模擬器兼容性測試用例表

好友信息表：表中包含用戶與好友對應關系的基本屬性信息。friendId（編號）為主鍵，經分析在系統中每個用戶與其好友為一對多的關系，因此，建表將friendUserId（用戶Id）與其friendRecommendUserId（好友Id）進行對應存儲來實現目的。friendState（狀態）通過置整數型（如“1”、“2”）的方式確定發送好友申請的用戶是否通過驗證成為好友。

朋友圈信息表：表中包含用戶發表動態的基本屬性信息。imgId（編號）為主鍵，用戶在發布動態時多字符型imgMsg（標題）與imgMessage（內容）為非空項。其他屬性為imgUserId（用戶編號）、imgUserName（用戶名）、imgTime（添加時間）。

用戶信息表：表中包含用戶的基本屬性信息。表中uid（編號）為主鍵，用戶通過注冊子模塊進行相應的數據輸入，其中uname（用戶名）和upswd（密碼）為非空項，其中整數型utype（類型）通過置“0”或置“1”的方式確定該用戶是否為違規用戶。其他屬性為usign（簽名）等基本用戶個人信息不再贅述。

評論信息表：表中包含用戶動態評論的基本屬性信息。reviewId（編號）為主鍵，各個用戶在對各個朋友圈的評論在數據庫通過imgUserId（用戶編號）和reviewMessageId（朋友圈編號）進行確定存儲。其他屬性reviewMessage（評論內容）、reviewTime（評論時間）。

4.4 用戶功能模塊代碼實現

（1）登陸注冊實現：與之對應RegisterDAO 類，里面提供了相應的add、update 等方法在用戶注冊后實現數據庫賬號注入的功能，在注冊之后RegisterCheck 方法進行用戶進行賬號注冊時的合法性，按情況返回true 或者false 值，在RegisterService 類中聲明方法抽象類供RegisterAction 類進行調用。代碼中的Login 方法進行從數據庫中賬號密碼進行獲取，并進行匹配識別，根據情況返回true或false 值。在登陸時Servlet 端響應方法put(“repMsg”,“登錄成功）才可登陸成功，然后通過response.getWriter().print(jsonmsg)將路徑返回客戶端。

（2）朋友圈實現：朋友圈模塊涉及到朋友圈實體類Message 類、朋友圈數據訪問類MessageDAO 類、朋友圈服務類MessageService、朋友圈操作類MessageAction、評論數據訪問類commentDAO、評論服務類CommentService 以及它們相應的接口。從Action 到Service 到Dao 層層訪問，發布的文本及圖片信息的更新分別對應方法UpdateMessage()和UpdateImg()。評論模塊類似以上方法進行數據庫基本調用利用UpdateReview()進行評論消息的更新。

（3）搜索好友實現：用戶在Web 端操作后通過Action 層action_flag.equals("search")接著訪問Service 層中的search 方法，最后通過Dao 包中的類查詢數據庫內的數據。

（4）個人資料查看編輯實現：該部分代碼實現方法相對簡單，通過Action、Service、Dao 層調用，是UpdateUsernamebyId()、UpdateUserpasswordbyId()、UpdateUsersignbyId()等更新方法的基本實現，最后修改數據庫內相應的個人信息。

（5）好友請求響應實現：響應方法holder.uname.setText(getUserMessage（）.getUname（）+“請求添加好友”）進行操作判斷處理，根據用戶是否同意來利用uhobby.SetText()方法進行相應狀態修改。

（6）添加好友實現：在ContactNtfMessage 類中的同名方法里獲取sourceUserid（請求者id）和targetUserid（響應者id）來實現聯系人添加功能，在對方選擇同意或者拒絕好友添加時狀態改變時，發送方也通過SetText()方法進行狀態的修改，與好友請求界面的方法實現響應是同步進行的。

（7）社交實現：系統利用融云提供的推送方式進行社交聊天功能的輔助工具，先預設消息基類BaseMessage,聲明getType 方法和toString 方法。發送消息時語音消息類VoiceMessage 與文本消息類TxtMessage 均繼承基類進行開發。

本部分是系統開發的核心部分。社交聊天部分基于Socket 通信開發，首先必須建立前后端的Socket 連接，在連接成功后把消息請求傳送給后端進行處理，后端就會進行相應處理后再將數據處理結果通過session.SendText（）方法推送給前端。這樣用戶在進入前端界面時，連接就成功建立，在該連接中發送請求就會進行傳輸。配置完成之可以通過調用后臺接口的方式進行后臺向前臺推送數據。

在發送消息方面采用推送的方法，在發送中如果fromuserid（發送人用戶id）、touserid（接收人用戶id)和message 均為空時則拋出異常取消連接發送。發送方經客戶端將聊天消息發送至服務器上，broadcastpush 負責接受從服務器傳來的消息，通過廣播方式發送出去。

4.5 管理員功能模塊的實現

（1）登錄實現：主要涉及的類有管理員實體類Admin、管理員服務類AdminService；管理員數據訪問類AdminDAO、管理員操作類AdminAction。

（2）用戶信息查看編輯實現：管理員在Web 端進行刪除操作通過AdminAction 轉向AdminService 中具體Update 方法的實現，通過AdminDAO 對數據庫內用戶信息進行刪除。

（3）投訴處理實現：編寫updateFriendState 方法，用戶被投訴后此方法將該賬號在數據庫對應的用戶類型屬性進行更改（正常賬號置“0”，違規賬號置“1”），對該用戶進行登陸限制。

5 測試分析

5.1 兼容性測試

如表1所示，測試后發現在火狐瀏覽器進行測試時，雖然頁面大小正常，但部分操作按鈕顯示不同，至今無法解決。這是因為W3C 推出了一個網頁規范標準，即Web 標準，火狐瀏覽器嚴格遵循這個標準，而ie 瀏覽器對網頁的解析標準與其不同，造成了這樣的結果，不影響正常使用。

如表2所示，測試后發現在藍疊（BlueStacks）模擬器中在運行時項目會報出錯誤，至今無法解決。經查閱相關資料和進行分析后發現BlueStacks 這個模擬器對系統和電腦配置要求十分挑剔，有時安裝成功后未必可以運行軟件應用，能否成功還是要看電腦配置和版本兼容性。

5.2 主要功能性能測試

5.2.1 表單驗證功能測試

系統的登陸注冊模塊是涉及到數據安全性和正確性的重中之重，因此這也模塊界面的測試尤為重要。測試后在登陸或者注冊當用戶輸入為空時當密碼和賬號不符時會給出錯誤提示。

5.2.2 投訴封禁功能測試

投訴封禁功能測試主要測試經其他用戶投訴處理的賬號是否可以正常登錄，對其測試采用多個安全賬號和非法賬號注入的方法；安全賬號注入是用未被投訴的賬號密碼進行登錄，非法賬號注入是用已被投訴的賬號密碼進行登錄。測試后安全賬號可成功登錄，非法賬號則被提示“已被封禁”而無法登錄。

5.2.3 搜索功能測試

搜索功能測試主要測試系統搜索功能是否得以實現以及搜索結果的合理性，對其測試采用有效信息輸入搜索和無效信息輸入搜索的方法；有效信息輸入搜索是指滿足查詢條件的記錄是存在的，無效信息輸入搜索是指滿足該條件的記錄是不存在的。測試后成功在頁面查詢到有效信息，而無效信息不顯示在頁面上。

5.2.4 圖片上傳功能測試

圖片上傳功能測試主要測試在空間動態發布和社交聊天中圖片能否正常發送，對其測試采用不同大小不同格式圖片進行發送，目前圖片上傳大小限制為30K 并且上傳格式僅限于JPG 格式。測試后上傳不同格式或者超過規定大小的圖片會給出錯誤提示。

5.2.5 聊天消息響應功能測試

聊天消息相應測試主要測試在用戶甲發送消息給用戶乙時用戶乙提示消息是否響應，消息是否正常接收。經測試在甲未發送消息時乙方正常無響應，在甲發送消息后乙方有類似QQ 的紅點提示，正常接收甲方信息，點開閱讀后提示即消失。