「Charles 應用」經過 Charles 分析社區消息系統

背景

參考市面上相同維度的 App 產品，蔚來 理想，對其消息系統進行抓包分析。獲得比較適合咱們本身的消息系統設計。

理想 ONE

理想的消息系統設計師一種集中式的設計，將全部的消息集中管理，評論、贊、通知、私信、車輛。

在消息中心拉去通知類消息

對接口進行抓包以下。

https://api-app.lixiang.com/mms-api/v1-0/message?status=3&pageNumber=0&appId=chj_app_m01&channelType=1&pageSize=20&category=notice

接口設計上 經過 category 來區分是哪一個渠道上的消息，如今咱們請求的是通知 類型的消息，因此 category 爲 notice。

接口的響應參數以下

{
    "success": true,
    "code": 0,
    "msg": "SUCCESS",
    "data": {
        "pageSize": 20,
        "pageNumber": 0,
        "numberOfElements": 1,
        "totalPages": 1,
        "totalElements": 1,
        "elements": [{
            "requestId": "rC21P1A80H2DJJQIGR00",
            "messageId": "C21P1A80H2DJJQIGR0000000",
            "appId": "chj_app_m01",
            "recipient": "3250332467430584322",
            "sender": null,
            "title": "理想社區用戶公約（試行）",
            "summary": "親愛的理想用戶，爲了維護社羣的真實，友好的氛圍，咱們制定了理想的社羣規範。",
            "contentId": null,
            "action": "{\"accountId\":0,\"avatar\":\"\",\"comment\":\"\",\"commentId\":0,\"commentType\":1,\"createTime\":1598072448536,\"level\":1,\"messageType\":\"notice\",\"nickName\":\"\",\"productId\":754,\"surfacePlot\":\"https://p.ampmake.com/lixiangzhizao_app/pc_push_system/787334842102195.jpg\",\"type\":1}",
            "tag": ["[Ljava.lang.String;@474616fd"],
            "category": "notice",
            "status": 1,
            "encryption": null,
            "sendOn": 1598072449000,
            "receiveOn": 0,
            "createdOn": 1598072448000,
            "updatedOn": 1599009229000
        }]
    }
}

咱們將返回值和界面放在一塊兒對比一下

對比以後，界面元素的各個字段就比較清晰了。action 對象中，用來控制 查看詳情 按鈕，具體根據不一樣的 category 來控制不一樣的行爲，由於如今的通知消息爲一篇 文章，因此 點擊 查看詳情，就是拉去對應文章的信息，action 中 productId 就是指向的文章的主鍵 Id

點擊跳轉至 詳情頁，上方展現了 【詳情頁頁面】 【接口 URL 地址】 【接口詳情】。能夠看到對應的 productId 就是 754.

理想 消息分類

• 評論 comment

  

• 點贊 favour

  <img src="https://gitee.com/xiaoxiunique/picgo-image/raw/master/atips/image-20200903203620026.png" alt="image-20200903203620026" />

• 通知 notice
• 車輛 vehicle

蔚來 NIO

蔚來的消息入口是放在 IM 中的一個會話，和理想的設計不太同樣，消息點擊進入以後 分爲 互動 和 通知，對互動消息列表的抓包結果以下。

在抓包時發現，在每次請求消息列表 這個接口的時候，還會附帶一個 history_read 的一個接口

/api/1/message/history_read?app_id=10002&app_ver=4.4.0&device_id=2c0d36fa578c45c6819e0567399b8704&lang=zh-cn&region=cn&timestamp=1599026946&sign=4be15ff9fa6e02e2fe5b24bb06c74a03

猜想應該是控制當前用戶已經讀取過當前時間以前的消息。下次進入系統就不會再提示了。

在對比 通知裏面的消息結構。基本的消息結構就比較明確了。

上圖是在 蔚來 發表了一條 說說 以後，獲取獲得了 11 個點贊，28個評論後，第一次登錄時的在主界面 調用 history_info 接口，拉去消息列表。能夠看到在 notification 分類下有 1 條未讀消息，在 social_events 分類下有 28 條未讀消息。

在 data.msg 數組中，每一個類型下都有一條消息。結合界面能夠發現，這一條消息就是用來在界面最外面展現的。

第一張圖是 點贊 消息對應的 消息結構，第二張圖是 評論 對應的消息接口。

基本能夠肯定 蔚來 NIO 的消息結構裏面主要包括

• read 是否已讀。
• data 內容信息，博客信息和點贊評論信息。
• description 消息描述，這個字段應該是用於 消息推送 的時候的內容。
• title 在 App 消息列表中呈現的標題。
• scenario 場景，當前場景爲關注，點贊、收藏，都在這裏面。 like 點贊，comment 收藏
• category 類別，應該用來區分 互動類通知 和 系統類通知。
• msg_id 消息ID，由於這樣的操做可能會觸發消息推送，因此每條須要添加 惟一 ID。
• link_value 須要跳轉到對應的地址 nio:// 這種形式 應該是 客戶端的一種方式。

本文由博客羣發一文多發等運營工具平臺 OpenWrite 發佈