直播类APP的推荐页面和一般信息展示类的界面有所区别的一点是:要求信息的实时更新.尽量去避免界面上信息的不准确,比如:
1.主播已经关播了,而界面上仍然显示该主播,观众点进去却得不到想要的结果,体验并不好;
2.主播的热度得不到更新,在推荐上顺序得不到及时的更新;
当考虑到信息的时效性,有效的优化细节,考虑了几个方案:
1,使用socket长连接与Http相结合的方式.Http用来请求整个列表,针对场景为:刷新整个列表.长连接是由后台来推送某一个主播或几个主播更新后的信息,比如是否关播,热度,顺序等,这种情形下,前端显示需要处理的情况相当多,比如调整列表顺序,这就存在很多的问题(一个本来在中间的主播调整到首位的需求,我们需要先通过ID找到这个主播,然后调整位置,关键在于找到需要使用循环,那么问题来了当列表里主播越多需要循环的次数就越多,多主播位置变动的时候,频繁度和复杂度又升级了,当我一个循环还没走完,另外一个长连接信息来了...)这种对于前端来讲非常被动的处理方式,实时性高,复杂度高,消耗大,开发时间充足且逻辑处理能力强的可以尝试.
2,Http单轮询的方式.这种方式很多人都能想到,定时器跑一个,时间间隔短一点,拉取用户列表.但是可能没有考虑周详,我们的主播列表如果有500条信息(这么大的信息量肯定在服务器端压缩过),每10s,20s拉取有一次,后台压力会非常大.那分页呢,抱歉,分页虽然数据少了,但是在要求失效性的情形下不可能(如果A主播开始在第一页,之后服务器数据更新,将A放到了第二页,那用户在拉取第二页的时候又出现了A,那么我们要做排重吗,第二页信息每一个在加入列表的前都要遍历一遍?)
3,Http双轮询的方式.这是我们目前使用的方式,每10s种拿到当前用户停留位置上下共6-7个用户的ID,发给服务器,服务器返回针对这几个用户需要更新的数据.同时120s刷新整个列表一次.实时性不高,复杂度低,用户体验方面也可以.能够满足需求.用户整体排序依赖于用户主动下拉刷新以及后台正列表轮训,并且相对于上次拉取整个列表时间在60s内的请求进行拦截.
对于小公司来说节省服务器资源还是很有必要的,我们APP刚上线的时候,因为开发周期短,很多问题没解决匆匆上线,服务器爆掉好几次~
