關於客戶端資訊流思考

littleplayer發表於2018-06-02
客戶端

題記

移動網際網路狂野發展了10年多，造就了很多TOP級APP，但每個APP都無法避免的一個問題是，資訊流管理。關於資訊流的實踐方式有多種多樣，我結合自己這兩年在蛙趣的經驗，簡單談談，希望多指正。

客戶端中資訊流

產品：這個列表我需要視訊大卡片，還要視訊的小卡片，
      還要廣告（大圖、小圖、三聯圖），還有Topic，劇集，
      OP廣告位，還...，還要隨後臺隨意配置...
程式設計師：****
複製程式碼

這是很經典的一個場景需求，面對這樣的問題，資訊流設計很關鍵。 這兩年在資訊流上的理解，就是各端和伺服器API提供者約定一種正規化，用來表示各種不同的資料和樣式。

以前的API設計

客戶端：給我一個視訊列表，開始位置0，總共20個
        /getHotVideos?start=0&size=20
伺服器: 給你20個視訊
        resp：{
            "videos":[
                {
                    "id":"1",
                    "title:"...."
                },
                ...
                {
                    "id":"20",
                    "title:"...."
                }
                
            ]
        }

複製程式碼

現在的API設計

客戶端：給我一個視訊列表(包含廣告，大視訊樣式，小視訊樣式，op廣告)，開始位置0，總共20個
        /getHotVideos?start=0&size=20
伺服器: 給你20個卡片
        resp：{
            "videos":[
                {
                    "ct":"video_big",
                    "data":{
                        "id":"1",
                        "title:"...."
                    }
                },
                ...
                {
                    "ct":"video_small",
                    "data":{
                        "id":"1",
                        "title:"...."
                    }
                },
                
                {
                    "ct":"ad_big",
                    "data":{
                        "id":"1",
                        "title:"...."
                    }
                }
                ...
                
            ]
        }
複製程式碼

這時客戶端的工作就是對，返回的卡片做不同Model的解析，從而形成 dataArr = [bigVideo, smallVideo, bigAd, smallAd, ...]，列表註冊支援樣式即可。

建議

如果您的專案有很多資訊流，而且每個資訊流要支援不同的樣式，不妨及早更新API介面，約定一套穩健的資訊流卡片樣式，在您日後的開發中，減少不比較的口水。 本文純屬路過來打個醬油。

相關文章