专栏目录
[0]专栏前言
[1]短视频首页feed的redis设计实战1
首页对于一个app来说是最为重要的一个模块,不管新老用户对一个app的首页加载速度都是有很高的要求,尤其是对新用户来说,首页的加载速度是一个很重要的一个体验指标,如果你的应用首页加载很慢,说明你的应用该做性能优化了.
分析首页
我们先观察首页模块的组成部分都有哪些,以某短视频观察来看,首页上方包含2个tab页,1个推荐列表,一个关注列表,右边一个搜索框入口,首页主体内容是视频内容,右侧包含作者头像,关注标志,点赞数,评论数,分享数,首页下方是用户昵称和短视频的简介,还包含了视频使用的音乐信息.这是我们通过观察首页初步掌握的信息.可能还会有一些活动角标,或者浏览时长送金币的浮窗,甚至还有直播的入口,这些都是带有活动时间,或者推广时间的,在活动时间期间可能才会看到,这些特殊的首页内容我们可以放到后面的思考或者首页模块的最后面来说.我们先来入手今天的重头戏,完成对首页模块的分析和拆分子模块.
我们先把上述的功能拆解出一个模块列表,这是一个非常有必要而且重要的一个步骤.当我们接到像这样的一个界面模块的需求时,应该迅速的把这些界面涉及到的内容整理成一个一个的小模块,当然了,实际开发的时候,这么大的一个模块肯定不是交给一个人做,但是流程基本都是一样的.
我们假设自己现在接到了这么一个首页模块的设计,已经完成了第一步,现在要做第二步和第三步.
这里我想重点对理解需求进行说明一下,这个步骤是需要根据需求的大小,需求的复杂程度和开发对需求的认可来决定这个步骤需要做些什么事,因为有些需求本身就不合理,比如给手机应用增加一个根据手机壳颜色变换手机应用主题的功能,这种需求别说开发不认可,但凡在合理的需求评审过程中,这种需求都不会过审,但是有些需求是属于看似合理,但是实际上却有悖产品本身定位.比如:有关push的需求,分别放在一个工具类应用和短视频应用上就是两种效果,工具类应用是属于用户有需要才会打开,这个是符合用户对工具类应用的一个心理预期,但是push这种强打扰用户的行为放在工具类上,会让用户觉得自己老是被干扰,但是如果push需求放在短视频应用上,比如点赞push,评论push,这种用户反而会更喜欢这类push,因为短视频应用本身就有一部分的社交属性,虽然很弱,只是基于用户关系的社交属性,但是用户在发布视频后是渴望得到其他用户的点赞,评论,因为用户使用短视频应用的心理预期就是得到别人的关注和喜爱,所以用户被这类push打扰不会觉得自己被打扰,反而会更高兴,这就是需求本身很合理,但是有悖产品本身定位的一些设计.
当然,不是说工具类push需求不合理,只是举例说明一下不同应用之间的一些需求或者策略不能简单的一照搬,应该结合产品本身去全面考虑需求的合理性,这也是为什么很多程序员觉得产品的水平低下,双方冲突的原因之一就是需求的合理和需求的价值体现,毕竟谁都想在自己的岗位上找到成就感.
扯远了,其实就是想说作为一个研发,应该对产品提出的需求是要产生自己的理解,并能从中提出合理建议,而不是被动接受需求,因为想做好一个产品,是多方共同努力的结果,所以研发具有一定的产品思维也是很重要的.理解需求这一步你会在不同的阶段有不同的理解.这里就不多说了.其实已经说了很多…
那我们现在就按照上述的步骤来罗列出我们现在已知的信息.
- 接到需求
我们就大概的整理下接到的需求,毕竟这不是重点,真实的需求文档会比这个更详细,更全,还会有交互原型等内容.我们这里就先暂时列一个需求的表格,我们接下来从这个表格里拆解出来具体的功能模块.
需求 | 详情 |
---|---|
首页模块 | 需要展示视频内容,还包含用户点赞,评论,分享,关注等模块 |
点赞特效 | 屏幕出现小心心叠加特效… |
关注特效 | 用户头像下的➕号变成✅ |
长按视频特效 | 出现功能浮层 |
… | … |
-
理解需求
上述的需求只有第一个是咱们需要关心的, 其他的都是前端的工作.我们针对首页模块进行理解就行, 首页模块里的东西没有理解上的困难,都是目标明确,条理清晰的需求. -
整理需求
这一步主要是为了大概把所有的需求粗略的过一下然后看这些需求在项目上线前是否都能做完,这一步主要是为了在合理的时间内完成合理的需求,有些需求开发时间长,收益低,完全可以放到下一阶段充分的时间去做,这里会涉及到一个需求的优先级.整理需求是为了把本期确定要做的需求尽快确认和落地到开发阶段. -
拆解需求
我们通过需求背景和第一步罗列的东西可以拆分出以下具体的需求模块
需求模块 | 具体详情 |
---|---|
推荐视频列表(略) | 需要确认推荐视频的算法规则,按照什么推荐模型产生用户最喜欢看的视频列表的视频id(每个视频都有一个唯一id,用来标识资源),这里我们不涉及推荐算法相关的东西,所以这个列表我们可以不用去考虑如何得到 |
视频详情 | 这个是属于视频的元数据,包括视频的封面地址,不同清晰度的播放地址, 视频的宽,高,播放时长,视频的标题,简介,作者等基础数据 |
用户详情 | 这个模块是给首页模块和评论模块里提供作者用户的信息,包括昵称,头像,性别等基础数据. |
交互数据模块 | 交互数据可以拆分成评论数,点赞数,分享数这三个,我们需要设计一个交互数据的模块,甚至要考虑到如何扩展增加其他维度的统计信息,比如视频的观看次数等 |
音乐 | 视频里使用的音乐信息,还有使用同款音乐的视频列表 |
评论 | 满足一个按照时间倒序+点赞数倒序双重权重的评论列表和发评论 |
我们拆解需求的过程本身会加强自身对需求的理解程度,而且一个大模块也是拆成各个小模块去估算工作量,进行排期的,而且这个步骤期间也会对接下来要做的模块会有一个初步的的方案设计.
本篇现在已经将一个短视频的首页模块的一个大需求经过这些步骤,拆分成了一个一个的子模块,接下来我会一步一步的去实现这些子模块里是如何运用redis提高性能.