关于客户端信息流思考

题记

移动互联网狂野发展了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接口，约定一套稳健的信息流卡片样式，在您日后的开发中，减少不比较的口水。 本文纯属路过来打个酱油。