IM 客戶端伺服器資料互動整理
全量拉取資料
機制：
使用者啟動 App （登入後），立即開啟 IM 資料的驗證操作，包括
1. 本地資料是否存在。 — 資料不存在開啟 IM 拉取。
2. 本地資料如果存在的話，資料是否與伺服器資料一致。 — 資料不一致時，開啟資料拉取（拉取操作可以為從伺服器最新資料拉取到本地最新的一條資料，可以抽象到全量拉取）。
拉取的資料包括
1. 聯絡人列表，用於展示聊天列表（包括群聊和私聊兩種）。
2. 聊天資訊。
優點：
1. 業務比較簡單，邏輯比較清晰。
2. IM 資料儲存在本地，針對需要對本地資料的操作可以靈活操作（包括 tab 上方的紅點的顯示，就是未讀訊息）。
3. 進入聊天室，避免了多餘的資料請求，加快頁面載入速度。
缺點：
1. 全量資料的拉取，形式不好，不符合懶載入的設計模式。
2. 全量拉取時，資料量較大，一方面有多餘的資料請求，增加 App 流量的使用。另一方面，資料的請求可能會增加 CPU 的使用率，在效能不好的機器上可能會有卡頓。
3. 還是懶載入的問題，大量的資料存在本地，而其中大部分使用者是不會使用的，導致佔用了大量記憶體。
增量拉取
增量拉取的區別在於，聊天列表資料如何請求。
IM 資料的獲取基本方式為：
使用者點選進入聊天室時，檢查本地 IM 資料
1. 如果不存在。啟動資料拉取，只拉取一頁聊天資料，然後存在本地。
2. 如果存在，檢查與伺服器端的資料是否一致
1. 一致
2. 不一致：按頁拉取伺服器資料，知道拉取到能與本地資料相接。
聊天列表 的獲取分為：
1. 在 App 啟動時，請求聊天列表資料。列表資料儲存在本地。
2. 在使用者點選訊息 tab 進入到訊息頁面時，請求聊天列表資料。列表資料不會儲存在本地。
需要注意的是，這種方法在沒有點選進入到聊天室之前，聊天的具體資料都是沒有的，只有進入聊天室之後，才會去請求具體的聊天資料並且存在本地
以上兩種的區別在於：
1. 底部 tab 的未讀訊息的展示，這個地方需要在 app 啟動後就立即展示出來，所以資料需要在啟動後就拿到。以上兩種方法對這裡的處理不一致：
1. 方案 1 – 由於，在 App 啟動時獲取到了，資料處理所以放在客戶端處理。
2. 方案 2 – 中這個未讀訊息的處理會放在伺服器端，這樣的話伺服器會多進行一次或者多次
2. 對於在聊天列表位置顯示的未讀數目的處理
1. 方案 1 – 請求到的資料會包含聊天會話的基本資訊，包括聊天物件，時間，圖片等基本資訊以外，還有最後一天記錄和是否含有未讀訊息等。 對於我讀訊息，在群聊模組可以通過和本地資料進行對比來判斷是否展示（群聊只需要展示是否有未讀訊息），在私聊模組需要伺服器返回（私聊需要展示有幾條未讀訊息，這樣的話還是需要伺服器對資料進行遍歷，或者直接維護另外一個變數處理）。
2. 方案 2 – 首先一個問題就是 訊息 tab 位置的未讀訊息提示，需要在啟動的時候返回，因為本地並沒有資料來判斷。這樣的話，其實伺服器需要做一邊資料處理之後才能返回結果，客戶端用於判斷是否顯示未讀標記。關於私聊列表中的未讀訊息數目也是完全有伺服器來處理。