阅读 215

关于客户端信息流思考

题记

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