TeamTalk項目iOS端代碼總結(jié)

前段時間加入一個團(tuán)隊，對TeamTalk進(jìn)行二次開發(fā)。我負(fù)責(zé)iOS端的功能擴(kuò)展。這個項目目前已少有人維護(hù)，iOS端在我接手后進(jìn)行了一些底層改動，現(xiàn)介紹給大家。

TeamTalk是一個很有名氣的即時通訊解決方案，
github地址：https://github.com/meili/TeamTalk
但由于維護(hù)一個即時通訊項目工作量太大，內(nèi)部人員分崩離析，導(dǎo)致項目無人維護(hù)了。iOS端最大的過時體現(xiàn)就是google的Protobuf庫沒有更新，無法使用當(dāng)前最新的3.6.1版本生成的proto文件。下文中我會給出解決方案。

先總體介紹一下TeamTalk的iOS端項目。它采用google的Protobuf協(xié)議對數(shù)據(jù)進(jìn)行封裝，使用一個基于TCP協(xié)議的消息服務(wù)器來處理網(wǎng)絡(luò)消息，實(shí)現(xiàn)即時通訊。一條數(shù)據(jù)的傳輸，比如發(fā)送一個文字消息，首先對消息進(jìn)行加密，當(dāng)然只有通訊消息會有這個加密過程，一般的數(shù)據(jù)傳輸是不需要特別加密的。然后將要傳輸?shù)母鞣N數(shù)據(jù)轉(zhuǎn)化成protobuf格式的數(shù)據(jù)，發(fā)送給服務(wù)器?？蛻舳私邮盏椒?wù)器傳回的響應(yīng)數(shù)據(jù)后，先通過Protobuf轉(zhuǎn)化為iOS中的數(shù)據(jù)，比如NSString，int等，再進(jìn)行邏輯處理。

來說說protobuf的升級方案。當(dāng)前項目使用的pb文件是google pb庫2.6.1版本生成出來的，不兼容當(dāng)前3.6.1版本生成出來的pb文件，我的解決方案是去掉項目中負(fù)責(zé)pb數(shù)據(jù)解析的ProtocolBuffers庫，改用Protobuf庫進(jìn)行pb數(shù)據(jù)解析。Protobuf庫支持最新的pb文件格式。在代碼中，需要將原來使用ProtocolBuffers庫的代碼改為使用Protobuf庫后的代碼。舉個例子：

ProtocolBuffers庫：
IMLogoutReqBuilder logoutbuilder = [IMLogoutReq builder];
DDDataOutputStream dataout = [[DDDataOutputStream alloc] init];
[dataout writeInt:0];
[dataout writeTcpProtocolHeader:SID_LOGIN cId:IM_LOGOUT_REQ seqNo:seqNo];
[dataout directWriteBytes:[logoutbuilder build].data];
[dataout writeDataCount];
return [dataout toByteArray];

Protobuf庫：
IMLogoutReq logoutbuilder = [[IMLogoutReq alloc] init];
DDDataOutputStream dataout = [[DDDataOutputStream alloc] init];
[dataout writeInt:0];
[dataout writeTcpProtocolHeader:SID_LOGIN cId:IM_LOGOUT_REQ seqNo:seqNo];
[dataout directWriteBytes:[logoutbuilder data]];
[dataout writeDataCount];
return [dataout toByteArray];

從例子中可以發(fā)現(xiàn)兩個庫是略有不同的，但相差不大，原理是一樣的。更換了PB解析庫后，就可以使用最新版本的pb庫生成各種proto文件并使用了。附上兩篇貼子，分別介紹原來的解決方案和現(xiàn)在的解決方案：
老TeamTalkPB解析方案：
Protobuf： 2.6.1
ios Pods庫：ProtocolBuffers
https://blog.devzeng.com/blog/ios-protobuf.html
我采用的新方案：
Protobuf：3.6.0
ios Pods庫：Protobuf
https://www.jianshu.com/p/c17260b36928

介紹完升級PB庫，說一下工程目錄，以便大家可以快速的對整個項目有個印象。iOS工程目錄如下圖：

Category：存放對各種元數(shù)據(jù)的擴(kuò)展文件。比如NSData的擴(kuò)展。
Config：存放基礎(chǔ)配置文件。
Control：存放公用界面文件。比如彈出警告。
Entity：存放pb數(shù)據(jù)實(shí)例化文件，pb數(shù)據(jù)經(jīng)解析后，保存為一個個名為Entity的數(shù)據(jù)集合，相當(dāng)于mvc中的model。
Exist：各種第三方庫，比如消息加密庫。
GlobalData：全局信息，比如當(dāng)前用戶信息。
Module：存放各個模塊數(shù)據(jù)處理管理文件。比如登錄管理，用戶管理，消息管理，群組管理等，里面的TCPAPI，則是協(xié)議管理文件。如果想擴(kuò)展協(xié)議，就的在這里進(jìn)行添加。相當(dāng)于mvc中的control。
Resource：資源文件。
Util：工具類文件，主要是數(shù)據(jù)庫工具。
ViewController：界面文件。其中Chatting目錄下是主聊天界面，最難。通過對cell擴(kuò)展實(shí)現(xiàn)不同的聊天氣泡。相當(dāng)于mvc中的view。

再說一下項目中網(wǎng)絡(luò)傳輸處理方式。在DDTcpClientManager類中建立了一個基于TCP的消息服務(wù)器。每條數(shù)據(jù)包含cid，sid和seqNo。cid表示大類功能，比如用戶，消息等，sid表示大類功能下的具體功能，比如刪除用戶，seqNo是消息序號，通過序號做到消息有序發(fā)送和接收。比如我發(fā)了一個序號是70的消息，服務(wù)器返回的響應(yīng)消息中序號也是70，說明正好是我這個消息的響應(yīng)。還有一種監(jiān)聽消息，監(jiān)聽服務(wù)器發(fā)來的數(shù)據(jù)信息，然后通知app進(jìn)行邏輯處理。大致就這兩種消息了，一種是一來一回的，跟http通訊一樣，一種是監(jiān)聽服務(wù)器的。

下圖是基于這種消息通訊，擴(kuò)展出一個文件發(fā)送的時序圖：

之前iOS端并沒有支持文件發(fā)送，我們在新功能里進(jìn)行了擴(kuò)展?？傮w思路是新建一個文件服務(wù)器，也是TCP的，然后一來一回傳文件，具體技術(shù)細(xì)節(jié)我不贅述了。

擴(kuò)展后代碼下載路徑：
https://download.csdn.net/download/yige2002/10653517

如果誰愿意交流咨詢可以在帖子下留言。

PS：設(shè)置登錄服務(wù)器功能已經(jīng)添加，如圖