一种播放信息流的方法、客户端、介质及设备与流程

1.本技术涉及视频数据推送技术领域，尤其涉及一种播放信息流的方法、客户端、介质及设备。


背景技术：

2.在目前直播、视频类手机app的设计中，用户可以无限制地进行上下滑动翻页，来观看每一页展示的直播间或短视频对应的信息流。
3.并且当用户通过上下滑动，切换到当前信息流后，可通过切换入口无需滑动再跳转到另一个信息流中，从而观看另一个信息流。
4.但是相关技术中，一旦用户从入口切换到另一个信息流后，相当于进入了一个新的页面流，新的页面流中的数据与用户的相关性变差(一般来说第一个推荐的信息流是与用户相关性最高，用户可能最感兴趣的)，且用户也无法方便地返回到原来观看的信息流，导致用户的观看兴趣降低，用户留存率可能会降低。


技术实现要素：

5.针对现有技术存在的问题，本发明实施例提供了一种播放信息流的方法、客户端、介质及设备，以解决或者部分解决现有技术中用户从切换入口跳转到另一信息流后，无法方便地返回至原来的信息流进行观看，导致用户观看兴趣降低，进而导致用户留存率降低的技术问题。
6.本发明的第一方面，提供一种播放信息流的方法，所述方法包括：
7.获取推荐feed流；
8.响应用户对信息流切换入口的触发操作，获取所述信息流切换入口对应的目标信息流，其中，所述信息流切换入口位于父页面容器；所述父页面容器用于对所述推荐feed流的列表中的各个信息流按照索引顺序进行播放；
9.在确定所述目标信息流未位于所述推荐feed流的列表中时，在所述推荐feed流的列表中插入占位符，将所述目标信息流与所述占位符绑定；
10.在所述父页面容器中对绑定所述占位符的目标信息流进行播放。
11.上述方案中，所述方法还包括：
12.获取推荐feed流；
13.通过所述父页面容器对所述推荐feed流的列表中的第一信息流进行播放；
14.响应用户对信息流切换入口的触发操作，获取所述信息流切换入口对应的目标信息流，其中，所述信息流切换入口位于所述父页面容器；
15.在确定所述目标信息流未位于所述推荐feed流的列表中时，在所述推荐feed流的列表中的第一信息流的下一个位置插入占位符，将所述目标信息流与所述占位符绑定；
16.将所述父页面容器中播放的信息流由第一信息流切换至与所述占位符绑定的目标信息流，使得所述目标信息流在所述父页面容器中播放。
17.上述方案中，所述将所述父页面容器中播放的信息流由第一信息流切换至与所述占位符绑定的目标信息流，使得所述目标信息流在所述父页面容器中播放后，所述方法还包括：
18.响应所述用户对所述父页面容器的滑动操作，获取所述滑动操作停止时对应的第二信息流；
19.将所述父页面容器中播放的信息流由所述目标信息流切换至所述第二信息流，使得所述第二信息流在所述父页面容器中播放。
20.上述方案中，所述方法还包括：
21.若确定所述目标信息流位于所述推荐feed流的列表中时，获取所述目标信息流在所述推荐feed流的列表中的第一位置索引信息；
22.获取未执行切换之前对应的第一信息流在所述推荐feed流的列表中的第二位置索引信息；
23.基于所述第一位置索引信息及所述第二位置索引信息确定位置偏移量；
24.基于所述第一信息流对应的当前子页面容器索引信息及所述位置偏移量确定第一目标子页面容器索引信息；
25.基于所述第一目标子页面容器索引信息将所述目标信息流插入至第一目标子页面容器中，使得所述目标信息流在第一目标子页面容器中播放；其中，所述父页面容器包含多个子页面容器。
26.上述方案中，所述方法还包括：
27.若确定用户在预设的时间段内从当前子页面容器开始连续滑动多个子页面容器，获取用户停止滑动时对应的第二目标子页面容器索引信息；
28.基于所述第二目标子页面容器索引信息，将所述推荐feed流的列表中的当前信息流的下一信息流添加至第二目标子页面容器中，以播放所述当前信息流的下一信息流；其中，所述当前子页面容器用于播放所述当前信息流。
29.上述方案中，所述获取用户停止滑动时对应的第二目标子页面容器索引信息，包括：
30.获取当前子页面容器对应的索引信息；
31.监听从当前子页面容器开始滑动到滑动结束时滑过的子页面容器数量；
32.基于所述当前子页面容器对应的索引信息及滑过的子页面容器数量确定所述用户停止滑动时对应的第二目标子页面容器索引信息。
33.上述方案中，所述获取推荐feed流，包括：
34.当确定预加载请求被触发时，获取预设数量的待推荐feed流；其中，
35.当确定用户点击首个信息流时，则确定所述预加载请求被触发；或，
36.当确定所述用户浏览至所述推荐feed流的列表中的预设位置的信息时，则确定所述预加载请求被触发；所述预设位置的信息流位于所述推荐feed流的列表的尾部。
37.本发明的第二方面，提供一种播放信息流的客户端，所述客户端包括：
38.获取单元，用于获取推荐feed流；响应用户对信息流切换入口的触发操作，获取所述信息流切换入口对应的目标信息流，其中，所述信息流切换入口位于父页面容器；所述父页面容器用于对所述推荐feed流的列表中的各个信息流按照索引顺序进行播放；
39.绑定单元，用于在确定所述目标信息流未位于所述推荐feed流的列表中时，在所述推荐feed流的列表中插入占位符，将所述目标信息流与所述占位符绑定；
40.播放单元，在所述父页面容器中对绑定所述占位符的目标信息流进行播放。
41.本发明的第三方面，提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现第一方面中任一项所述方法的步骤。
42.本发明的第四方面，提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现第一方面中任一项所述方法的步骤。
43.本发明提供了一种播放信息流的方法、客户端、介质及设备，方法包括：获取推荐feed流；响应用户对信息流切换入口的触发操作，获取所述信息流切换入口对应的目标信息流，其中，所述信息流切换入口位于父页面容器；所述父页面容器用于对所述推荐feed流的列表中的各个信息流按照索引顺序进行播放；在确定所述目标信息流未位于所述推荐feed流的列表中时，在所述推荐feed流的列表中插入占位符，将所述目标信息流与所述占位符绑定；在所述父页面容器中对绑定所述占位符的目标信息流进行播放；如此，用户对信息流切换后，可通过在推荐feed流的列表中插入占位符的方式，使得切换后的信息流与切换前的信息流始终处于同一个父页面容器中；用户依然可方便地通过下滑方式观看到切换之前的信息流，进而提高用户的观看兴趣，提高用户的留存率。
附图说明
44.通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。
45.在附图中：
46.图1示出了根据本发明一个实施例的播放信息流的方法流程示意图；
47.图2示出了根据现有技术的当用户从切换入口跳转至目标信息流时，对应的处理逻辑示意图；
48.图2a示出根据现有技术的当用户从切换入口跳转至目标信息流时，信息流的跳转示意图；
49.图3示出了根据本发明实施例的当用户从切换入口跳转至目标信息流时，对应的处理逻辑示意图；
50.图3a示出根据本发明实施例的当用户从切换入口跳转至目标信息流时，信息流的跳转示意图；
51.图4示出了根据本发明一个实施例的播放信息流的客户端结构示意图；
52.图5示出了根据本发明一个实施例的计算机可读存储介质结构示意图；
53.图6示出了根据本发明一个实施例的计算机设备结构示意图。
具体实施方式
54.下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例
所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。
55.本实施例提供一种播放信息流的方法，如图1所示，方法主要包括以下步骤：
56.s110，获取推荐feed流。
57.在一种实施方式中，当确定预加载请求被触发时，可获取预设数量的待推荐feed流；其中，
58.当确定用户点击首个信息流时，则确定预加载请求被触发；或，
59.当确定所述用户浏览至推荐feed流的列表中的预设位置的信息时，则确定预加载请求被触发；预设位置的信息流位于推荐feed流的列表的尾部。
60.feed流是一种持续更新并呈现给用户内容的信息流。本实施例中，为确保数据的实时性，提高feed流播放过程的流畅度，每次确定预加载请求被触发时，只向服务器请求预设数量的待推荐信息流。预设数量可以基于平台的实际特性进行确定，在此不做限制。其中，预加载请求可以理解为推荐feed流的列表的分页请求。
61.在代码实现中，可以利用offset和page_limit参数来实现。offset是推荐feed流的列表中已经存在的信息流数量，page_limit是客户端每次请求期望获取的信息流数量，期望获取的信息流数量是预先设定的。比如第一次进行预加载时，offset是0，page_limit＝10，则客户端会从服务器请求获取到10条信息流，对应的是后端服务器推荐算法结果中的前十个信息流；下一次预加载时offset＝10，page_limit＝10，客户端会从服务器请求获取到新的10条信息流，对应的是后端服务器推荐算法结果中的第10～20个信息流，以此类推。
62.举例来说，当用户进入首次当前信息流a时，确定预加载请求被触发，此时会向服务器发送信息流请求数据，服务器会基于用户特征推荐相应数量的信息流。其中，用户特征可以包括：用户历史浏览数据、用户当前所在的直播分区类型以及用户的观看兴趣等等。当服务器将预设数量的信息流返回至客户端后，客户端会基于这些信息流生成推荐feed流的列表，比如推荐feed流的列表为[a,a1,a2,a3,a4,a5,a6,a7,a8,a9,a10]。
[0063]
然后用户会基于此列表进行浏览，假设预设位置的信息流为该列表中的倒数第三个，当用户浏览至a8信息流时，确定预加载请求再次被触发，此时向服务器重新发送信息流请求，当接收到服务器反馈的新的信息流数据后，将新的信息流数据添加至推荐feed流的列表的尾部，推荐feed流的列表更新为[a,a1,a2,a 3,a 4,a 5,a 6,a 7,a 8,a 9,a 10...a 20]。推荐feed流的列表中的每个信息流也具有相应的位置索引信息。
[0064]
通常一次网络请求的耗时不会超过500ms，而用户进入新的信息流中，至少需要数秒的时间来浏览和判定是否继续观看下去。因此本实施例中的预加载策略可以让用户用无止尽地向下浏览新的推荐数据。如此，可不断对推荐feed流的列表进行更新，用户可以无限制的进行上滑下滑操作，提高观看效率。
[0065]
当用户通过上下滑动，从当前信息流滑动至另一个信息流后，用户还可以通过点击信息流切换入口，直接地跳转到目标信息流。其中，切换入口包括但不限于：排行榜、推荐列表、广播通知、短信推送等入口。
[0066]
其中，信息流切换入口位于父页面容器，父页面容器用于对推荐feed流的列表中的各个信息流按照索引顺序进行播放。父页面容器中包含有多个子页面容器，每个子页面
容器具有对应的索引信息，子页面容器用于对应播放相应的信息流。可以理解的是，信息流切换入口是位于父页面容器中的某个子页面容器中。
[0067]
为了能够更好地理解本技术的技术方案，这里先介绍下现有技术中当用户从切换入口直接跳转到目标信息流的处理逻辑。参考图2，a1～an是用户通过上下滑动可观看到的信息流，若用户从a1滑动到a2，a2对应的子页面容器上有切换入口，用户可从切换入口跳转至b1信息流。当用户跳转至b1信息流，现有技术会重新开启一个父页面容器，以显示b1以及b1之后的信息流，此时b1相当于是新的feed流，再下滑b1是无法返回至a1信息流。如图2a所示，a1～an是用户通过上下滑动可观看到的一些推荐直播间(推荐feed流)，若用户在a1直播间，屏幕下方显示“向上滑动的箭头”，用户在从a1直播间向上滑动屏幕，滑动后会切换到a2直播间，用户可以点击直播间的“榜单挂件”，点击“榜单挂件”之后会在a2直播间中弹出一个“分区主播榜单”，用户可以在“分区主播榜单”中点击榜单中任意主播的直播房间的链接，例如用户点击榜一的“七哥七哥”这个主播的直播房间的链接，会跳转到“七哥七哥”的直播房间b1；用户在b1直播间，屏幕下方显示“向上滑动的箭头”，用户在从b1直播间向上滑动屏幕，此时b1相当于是新的feed流，再下滑b1会滑动到新的feed流中与b1相邻的b2直播间，无法返回至a1信息流。
[0068]
本实施例为了解决上述问题，对界面(视图层)及数据处理逻辑进行了改进。针对视图层，本实施例会在同一个父页面容器中对所有信息流进行展示，也即各信息流共用同一个父页面容器。当开发系统类型不同时，父页面容器的类型可能是不同的；比如父页面容器可以为activity组件。
[0069]
当父页面容器为activity组件时，需要先注册一个activity作为父页面容器，代码实现如下：
[0070]
《activity
[0071]
android:name＝".p.rambobase.ramboplayeractivity"
[0072]
android:configchanges＝"keyboardhidden|orientation|screensize|smallestscreensize|screenlayout"
[0073]
android:exported＝"true"
[0074]
android:label＝"@string/app_activity_player"
[0075]
android:launchmode＝"singletask"
[0076]
android:screenorientation＝"portrait"
[0077]
android:theme＝"@style/theme.appcompat.light.noactionbar"
[0078]
android:windowsoftinputmode＝"statehidden|adjustresize"/》
[0079]
并且，需要将activity组件的载入模式launchmode设置为singletask，以确保activity组件的唯一性，避免用户多次切换信息流时创建多个页面实例，从而确保用户通过切换入口执行跳转操作时，不会产生新的feed流。
[0080]
可参考图3，假设用户从a2上的切换入口跳转至b1后，b1依然和a1～an位于同一推荐feed流的列表中，当用户下滑b1时，可重新返回至a2。
[0081]
activity组件设置好之后，创建无限上下翻页的ui框架，本实施例是通过recylerview snaphelper nestedscroll机制来实现的。其中，recylerview控件用于处理上下方向无限滑动的交互逻辑；snaphelper控件用于处理界面回弹效果，当每一页滑过特
定距离后，再定位到目标子页面容器；比如手指上滑当前子页面容器的距离超过预设距离时，则将当前子页面容器的下一子页面容器作为目标子页面容器进行展示。
[0082]
nestedscroll控件用于解决子页面容器内部可滚动视图与子页面容器整体滑动之间的冲突问题。比如，子页面容器上会有弹幕滚动视图，子页面容器本身也需要滑动，那么nestedscroll控件可解决弹幕滚动视图与子页面容器自身滚动冲突的问题。
[0083]
具体实现中，是通过recyclerview控件 adatper类 layoutmanager类进行具体逻辑的处理。其中，recyclerview控件用于实现实现子页面容器的滑动功能，并且为了防止误触滑动，会实时监听手指在屏幕上产生的ontouch事件，以记录手指移动的距离及方向，根据移动的距离及方向判断特定手势完成之后，是否需要回弹到某一页面。
[0084]
比如，用户在屏幕中斜着划了一个手势，那么若确定手指横向移动距离《纵向移动距离，且纵向移动距离大于距离阈值时，需要进行回弹操作。若确定手指横向移动距离大于等于纵向移动距离，或纵向移动距离小于等于距离阈值时，则确定不需要进行回弹操作，避免用户手指轻轻滑动导致子页面容器被切换。
[0085]
具体来讲，手指在移动终端上的web页面触屏时会产生ontouch事件，包括：触屏开始事件ontouchstart、拖拽事件ontouchmove、触屏完成事件ontouchend及触屏取消ontouchcancel事件。当按下手指时，触发ontouchstart事件；当移动手指时，触发ontouchmove事件；当移走手指时，触发ontouchend事件；当一些更高级别的事件发生的时候(如电话接入或者弹出信息)会取消当前的touch操作，即触发ontouchcancel事件。因此本实施例可通过ontouch事件记录手指移动的距离和方向，代码实现如下：
[0086]
[0087][0088]
adatper类是视图层与数据层的连接层。一般来讲，adapter中getcount()方法的返回值，代表了列表中数据的总个数。本实施为了实现上的“无限滑动”，将adapter中getcount()方法返回为一个极大值，比如返回的是整型数的最大值，即2147483647。因为在编程领域中没有真正意义上的“无限大”，因此本实施例使用java中可以识别的最大整型数据作为getcount()返回的数据量，这样可支持用户无限的上下滑动，最终滑动数量不超过getcount()返回的数据量。
[0089]
代码实现如下：
[0090][0091]
若确定需要进行回弹操作，则通过layoutmananger类监听子页面容器的滚动状态，当页面滚动停止时，即state＝＝recyclerview.scroll_state_idle时，可获取当前子页面容器与屏幕中心点之间的第一距离，以及获取参考子页面容器与屏幕中心点之间的第二距离；将较小距离对应的子页面容器回弹至屏幕上进行展示。其中，参考子页面容器可以为当前子页面容器的上一直子页面容器，或者为当前子页面容器的下一子页面容器。
[0092]
比如，若用户在当前子页面容器进行下滑操作时，此时第一距离大于第二距离，那么则会将当前子页面容器的上一子页面容器回弹至屏幕上进行展示。
[0093]
执行回弹操作的代码实现如下：
[0094][0095]
以上是本实施例的页面回弹处理逻辑。下面继续阐述本实施例的滑动操作处理逻辑。
[0096]
由于adapter类中getcount()方法返回的是一个极大值，那么对应的子页面容器也有无限个，因此用户可以无限制的上下滑动。当用户停止滑动时，获取停止滑动时对应的子页面容器索引信息，并从推荐feed流的列表中确定出对应的目标信息流，将目标信息流添加至停止滑动时对应的子页面容器中，以将信息流内容展示在界面mainlayout中。具体代码实现如下：
[0097][0098]
这样就完成了一个基础的滑动 回弹定位的ui基本框架，为后续用户直接从子页面容器的切换入口执行跳转、用户上下缓慢滑动以及快速滑动的处理逻辑提供数据支撑。
[0099]
s111，响应用户对信息流切换入口的触发操作，获取所述信息流切换入口对应的目标信息流，其中，所述信息流切换入口位于父页面容器；所述父页面容器用于对所述推荐feed流的列表中的各个信息流按照索引顺序进行播放。
[0100]
继续以上述推荐feed流的列表[a,a1,a2,a3,a4,a5,a6,a7,a8,a 9,a10...a 20]为例进行说明：当用户从a1滑动到a2，a2信息流对应的子页面容器上有切换入口，用户可从切换入口跳转至目标信息流b1。
[0101]
那么本实施例可响应用户对信息流切换入口的触发操作，获取信息流切换入口对应的目标信息流。由于推荐feed流的列表是实时更新的，此时会出现两种情况：一种是目标信息流已更新到了推荐feed流的列表中，另一种是目标信息流未在推荐feed流的列表中。
[0102]
针对上述两种不同的情况，本实施例具有对应的执行策略，详见下文描述。
[0103]
s112，在确定所述目标信息流未位于所述推荐feed流的列表中时，在所述推荐feed流的列表中插入占位符，将所述目标信息流与所述占位符绑定。
[0104]
当确定目标信息流未在推荐feed流的列表中时，在推荐feed流的列表中插入占位符，将目标信息流与占位符绑定。
[0105]
具体来讲，可以在推荐feed流的列表中的当前信息流的下一个位置插入占位符，占位符中携带有目标信息流id；
[0106]
基于目标信息流id获取目标信息流，将目标信息流缓存至占位符中；
[0107]
控制滑动控件从当前子页面容器滑动至占位符对应的子页面容器，以利用占位符对应的子页面容器播放目标信息流。
[0108]
为更好地理解占位符的插入方式，这里以第一信息流为例进行说明，具体包括：
[0109]
获取推荐feed流；
[0110]
通过父页面容器对推荐feed流的列表中的第一信息流进行播放；
[0111]
响应用户对信息流切换入口的触发操作，获取信息流切换入口对应的目标信息流，其中，信息流切换入口位于父页面容器；
[0112]
在确定目标信息流未位于推荐feed流的列表中时，在推荐feed流的列表中的第一信息流的下一个位置插入占位符，将目标信息流与占位符绑定；
[0113]
将父页面容器中播放的信息流由第一信息流切换至与占位符绑定的目标信息流，使得目标信息流在父页面容器中播放。
[0114]
并且，将占位符插入至第一信息流的下一位置后，当用户继续基于目标信息流执行滑动操作时，方法还包括：
[0115]
将父页面容器中播放的信息流由第一信息流切换至与占位符绑定的目标信息流，使得目标信息流在父页面容器中播放后，响应用户对父页面容器的滑动操作，获取滑动操作停止时对应的第二信息流；其中，所述第二信息流为：所述在所述推荐feed流的列表中插入占位符，将所述目标信息流与所述占位符绑定的步骤之前，所述推荐feed流的列表中与第一信息流的占位符相邻的信息流；
[0116]
将父页面容器中播放的信息流由目标信息流切换至第二信息流，使得第二信息流在所述父页面容器中播放。
[0117]
继续以图3为例进行说明，假设a2为第一信息流，当用户从a2上跳转至目标信息流b1时，此时会在推荐feed流的列表中a2的下一位置插入占位符，然后将b1与占位符进行绑定，播放b1信息流。
[0118]
当用户从b1上滑至a3时，此时a3为第二信息流，那么会将父页面容器中播放的信息流由b1切换至a3。
[0119]
可理解的，见图3a，用户在a2直播间，当用户在a2直播间的榜单中点击榜单中任意主播的直播房间的链接，例如用户点击榜一的“七哥七哥”这个主播的直播房间的链接，会跳转到“七哥七哥”的直播房间b1(直播间b1位于其他feed流)，从a2直播间上跳转至直播房间b1过程中，此时会在推荐feed流的列表中a2的下一位置插入占位符，然后将b1与占位符进行绑定，播放直播房间b1的视频流；
[0120]
用户在b1直播间，(屏幕下方显示“向上滑动的箭头”)用户在从b1直播间向上滑动屏幕，会滑动至a3直播间；(屏幕上方显示“向下滑动的箭头”)用户在从b1直播间向下滑动屏幕，会返回至a2直播间；也就是说本发明的技术方案用户在从推荐feed流的房间通过其他方式(例如通过排行榜、推荐列表、广播通知、短信推送等入口)切换到其他feed流的房间之后，用户继续滑动直播间仍然可以浏览推荐feed流的房间视频。
[0121]
具体来讲，当目标信息流未在推荐feed流的列表中时，利用rambopageritem.newplaceholder(targetid)在当前信息流的下一位置插入一个占位符；targetid是目标信息流id，此时占位符还是一个空的占位。
[0122]
然后基于目标信息流id向服务器请求对应的流数据(externalroominfo remote)，将流数据缓存或绑定至占位符中；代码实现如下：
[0123][0124][0125]
最后利用layoutmanager.scrolltoposition方法，自动将滑动控件
reycylcerview向下挪一格，挪至占位符所处的位置，以展示目标信息流的内容。代码实现如下：
[0126]
这个过程是由代码自动触发，并不会造成ui界面的视觉效果变化，对于用户来说是无感知的，相比现有技术中由切换入口跳转后出现明显的黑屏来说，可提高信息流的切换质量。
[0127]
值得注意的是，基于目标信息流id获取对应的流数据，将流数据缓存至占位符中后，相当于是将目标目标信息流插入到了推荐feed流的列表中。但是后续当预加载请求再次被触发时，服务器返回的信息流数据也有可能包括目标信息流；为了确保信息流的唯一性，本实施例需要利用循环遍历推荐feed流的列表，并利用equals()方法判断列表中是否存在相同id的信息流，若存在，则剔除掉一个。代码实现如下：
[0128][0129][0130]
在另一种实施方式中，当若确定目标信息流位于推荐feed流的列表中时，方法还包括：
[0131]
获取目标信息流在推荐feed流的列表中的第一位置索引信息；
[0132]
获取未执行切换之前对应的第一信息流在推荐feed流的列表中的第二位置索引信息；
[0133]
基于第一位置索引信息及第二位置索引信息确定位置偏移量；
[0134]
基于第一信息流对应的当前子页面容器索引信息及位置偏移量确定第一目标子页面容器索引信息；第二目标子页面容器索引信息为当前子页面容器索引信息与位置偏移量之和；
[0135]
基于第一目标子页面容器索引信息将目标信息流插入至第一目标子页面容器中，使得所述目标信息流在第一目标子页面容器中播放。
[0136]
值得注意的是，从切换入口跳转至目标信息流的场景中，推荐feed流的列表中的位置索引信息与子页面容器索引信息是一一对应的，因此当确定出位置偏移量后，可根据偏移量确定出第二目标子页面容器。
[0137]
以上是用户基于切换入口跳转至目标信息流的处理逻辑。可以看出，无论用户怎样切换信息流，由于跳转后的目标信息流与第一信息流依然处于同一个推荐feed流的列表中，因此用户可方便返回至第一信息流以及返回至首次观看的信息流，避免出现平台给什么内容必须看什么内容的现象，从而可提高用户观看的主动性，进而提高用户的观看兴趣。
[0138]
s113，在所述父页面容器中对绑定所述占位符的目标信息流进行播放。
[0139]
如上文所述，父页面容器包含有多个子页面容器，当获取到目信息流后，将目标信息流绑定至占位符中，利用占位符对应的子页面容器播放目标信息流。
[0140]
在一种实施方式中，用户除可以直接跳转到目标信息流外，还可以通过上下无限的滑动来观看有兴趣的信息流。一般来说，用户滑动包括两种方式：一种是缓慢滑动(比如一次只滑动一个子页面容器)，另一种是快速滑动(比如在1s内滑过多个子页面容器)；两种滑动方式的处理逻辑也是不同的。
[0141]
承接上述推荐feed流的列表，假设用户从a1对应的子页面容器缓慢滑到a2对应的子页面容器，此时子页面容器索引会从a1对应的子页面容器索引加1，由于慢速滑动场景下，a1对应的子页面容器索引与推荐feed流的列表中的位置索引也是一一对应的，那么推荐feed流的列表中的位置索引也会加1，也即会获取a2信息流的数据。
[0142]
然后将a2信息流添加至对应的子页面容器中，对a2信息流进行播放展示。
[0143]
针对快速滑动方式，本实施例为了确保无限滑动的效果避免出现卡顿，子页面容器索引与推荐feed流的列表中的位置索引并不是一一对应的，那么方法包括：
[0144]
若确定用户在预设的时间段内连续滑动多个子页面容器，获取用户停止滑动时对应的目标子页面容器索引信息；
[0145]
基于目标子页面容器索引信息，将推荐feed流的列表中的当前信息流的下一信息流数据添加至目标子页面容器中。
[0146]
举例来说，假设用户从a1对应的子页面容器快速滑动到a10对应的子页面容器，此时a2～a9的信息流内容只是一闪而过，并不需要真正加载出来，为避免节约资源，省去不必要的加载过程，进而避免视频卡顿，此时推荐feed流的列表中的位置索引并不是从a1 9，而是依然是从a1 1，也即最终将a2信息流添加至目标子页面容器中。此处的目标子页面容器可以理解为在缓慢滑动场景下a10对应的子页面容器。
[0147]
在一种实施方式中，获取用户停止滑动时对应的第二目标子页面容器索引信息，包括：
[0148]
获取当前子页面容器对应的索引信息；
[0149]
监听从当前子页面容器开始滑动到滑动结束时滑过的子页面容器数量；
[0150]
基于当前子页面容器对应的索引信息及滑过的子页面容器数量确定用户停止滑动时对应的第二目标子页面容器索引信息。
[0151]
这样基于用户不同的操作方式，均有对应的处理逻辑，在提高直播性能的基础上
还能确保用户观看的主动性，进而提高用户的观看兴趣，提高用户留存率。
[0152]
基于与前述实施例中同样的发明构思，本实施例还提供一种播放信息流的客户端，如图4所示，装置包括：
[0153]
获取单元41，用于获取推荐feed流；响应用户对信息流切换入口的触发操作，获取所述信息流切换入口对应的目标信息流，其中，所述信息流切换入口位于父页面容器；所述父页面容器用于对所述推荐feed流的列表中的各个信息流按照索引顺序进行播放；
[0154]
绑定单元42，用于在确定所述目标信息流未位于所述推荐feed流的列表中时，在所述推荐feed流的列表中插入占位符，将所述目标信息流与所述占位符绑定；
[0155]
播放单元43，在所述父页面容器中对绑定所述占位符的目标信息流进行播放。
[0156]
由于本发明实施例所介绍的客户端，为实施本发明实施例的播放信息流的的方法所采用的客户端，故而基于本发明实施例所介绍的方法，本领域所属人员能够了解该客户端的具体结构及变形，故而在此不再赘述。凡是本发明实施例的方法所采用的客户端都属于本发明所欲保护的范围。
[0157]
基于同样的发明构思，本实施例提供一种计算机设备500，如图5所示，包括存储器510、处理器520及存储在存储器510上并可在处理器520上运行的计算机程序511，处理器520执行计算机程序511时实现前文所述方法的任一步骤。
[0158]
基于同样的发明构思，本实施例提供一种计算机可读存储介质600，如图6所示，其上存储有计算机程序611，该计算机程序611被处理器执行时实现前文任一所述方法的步骤。
[0159]
通过本发明的一个或者多个实施例，本发明具有以下有益效果或者优点：
[0160]
本发明提供了一种播放信息流的方法、客户端、介质及设备，方法包括：获取推荐feed流；响应用户对信息流切换入口的触发操作，获取所述信息流切换入口对应的目标信息流，其中，所述信息流切换入口位于父页面容器；所述父页面容器用于对所述推荐feed流的列表中的各个信息流按照索引顺序进行播放；在确定所述目标信息流未位于所述推荐feed流的列表中时，在所述推荐feed流的列表中插入占位符，将所述目标信息流与所述占位符绑定；在所述父页面容器中对绑定所述占位符的目标信息流进行播放；如此，用户对信息流切换后，可通过在推荐feed流的列表中插入占位符的方式，使得切换后的信息流与切换前的信息流始终处于同一个父页面容器中；用户依然可方便地通过下滑方式观看到切换之前的信息流，进而提高用户的观看兴趣，提高用户的留存率。
[0161]
在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。
[0162]
在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。
[0163]
类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施
例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。
[0164]
本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
[0165]
此外，本领域的技术人员能够理解，尽管在此的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
[0166]
本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(dsp)来实现根据本发明实施例的网关、代理客户端、系统中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。
[0167]
应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。
[0168]
尽管已描述了本技术的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本技术范围的所有变更和修改。
[0169]
以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。