TeamTalk Android程式碼分析（商務程序篇）---訊息發送和接收的整體邏輯說明

標籤：

第一次紀錄東西，也沒有特別的順序，想到哪裡就隨手畫了一下，後續會繼續整理～

 

6.2訊息頁面動作流程

6.2.1 訊息頁面初始化的總體思路

1.頁面資料的填充更新直接由頁面主線程從本機資料庫請求

 

2.資料庫資料的填充由後台線程非同步方式從網路請求

 

3.前台線程每次按照18條記錄讀取資料庫資料，後台線程按照每次18*3從網路請求資料

 

4.後台線程資料的請求由主線程滿足一定的條件後發送匯流排事件，在 oneventbackgroudthread 中處理，具體條件（或的關係）如下：

  1>第一次請求

  2>本機資料庫沒有載入到資料

  3>請求次數是3的倍數（為了滿足本機資料能夠及時讀取到）

 

5.後台非同步線程讀取網路資訊有目前兩個介面，分別是

 

  1>CID_MSG_LIST_REQUEST_VALUE 即：傳入一個最後的訊息id（lastmsgid）和 請求的數量（msgcnt），從服務端請求資料

  2>CID_MSG_GET_BY_MSG_ID_REQ_VALUE 即 傳入需要請求的訊息id列表，從服務端請求資料

 

  目前使用方式：

 

  ［第一次］從資料庫請求的［當屏訊息列表（18條或少）］,全部都是［本地發送失敗］的訊息時，採用第一種方式，傳入一個很大的數字和請求數量，去服務端拉取資料，否則，按照最後一個成功訊息的msgid 和 請求數量（18*3）作為條件，從本機資料庫讀取訊息列表（beginid －> endid）,然後，按照該列表和 msgid 與 msgid－18*3 的區間過濾出本地沒有的msgid，進而按照第二種方式去服務端請求資料。(因為從服務端是按照訊息倒序的形式拉取的)

 

6.向下拉動時傳入當前頁面的第一個訊息實體（msgid最新的實體）和拉動次數（pulltimes）作為參數，從本機資料庫讀取新資料，資料擷取成功後，拉動次數加1.

6.2.2 訊息接收的邏輯說明

1>總體實質：接收到服務端的pb資料轉換為greendao產生的實體類messageentity及其子類（按照展示形式和業務分為textMessage,imageMessage,audioMessage,mixMessage[圖文混合],並且子類利用重寫messageEntity的getContent 等欄位擷取方法），並且儲存messageEntity訊息到資料庫,及時更新資料庫和本機快取sessionmap，然後發送接收訊息的事件，通知ui線程重新讀取資料並重新整理介面，當然，更新session的過程，也同樣伴隨資料庫和介面資料的更新。

 

2>messageEntity子類的差異主要在於按照業務和展現形式的分類，具體子類按照具體形式擴充欄位，例如：imagemessage，需要擴充欄位 path，url，loadstatus。在資料庫儲存時都會序列化為json，儲存在content欄位內，從資料庫讀取資料時再反序列為不同的訊息對象，這個正是orm架構的優勢所在。

 

3>需要知道的，目前語音訊息是通過socket發送的，所以就直接儲存了，圖片發送的是一個url，在頁面展示時，再去請求地址。

6.2.3 訊息發送的邏輯說明

1>構建發送對象（TextMessage,ImageMessage,AudioMessage）

 

2>儲存訊息對象到資料庫

 

3>更新或建立Session緩衝及儲存資料庫，並發送事件通知，更新session相關ui

 

4>更新訊息介面（簡訊直接更新了，其他複雜一些）

 

5>發送訊息到伺服器，並添加檢測隊列。

 

6>ack返回後的處理

 （1）更新本地訊息資料庫

  (2) 更新session相關（sessionmap 以及db）

 （3）發送匯流排事件（messageevent），通知介面更新。

6.2.4 圖片訊息的發送過程

TeamTalk Android程式碼分析（商務程序篇）---訊息發送和接收的整體邏輯說明