CN115866346A - 一种智能电视定时发布方法 - Google Patents

Abstract

本发明公开了一种智能电视定时发布方法，将launcher数据分为模式、板块、组件和内容四层，在各层之间的关联节点进行定时配置；将定时配置数据写入临时定时配置表，发布数据时，将临时表中的数据更新到正式表，将临时定时配置表更新到正式定时配置表；定时任务扫描正式定时配置表，定时生效时将默认下层替换为定时下层，过后将定时下层替换为默认下层；电视终端向云端请求数据时，从最上层获取数据，有变化则更新，再获取关联的下层的数据，直到各层均完成更新。本发明通过将数据进行分层，在关联节点进行定时配置，通过定时任务更新数据，终端桌面按照分层进行数据请求进行局部更新解决电视桌面的内容时效性显示问题。

Description

一种智能电视定时发布方法

技术领域

本发明涉及智能电视技术领域，具体的说，是一种智能电视定时发布方法。

背景技术

随着电视桌面运营的日渐成熟，桌面的部分海报或者桌面整体的时效性展示功能越加迫切，而当前在电视终端，存在时效性的媒资内容配属需要运营人员实时配置。如现在的直播，存在直播前预告海报、直播中海报以及直播结束后的精彩回顾海报；在大型节日时，需要进行模式或者板块的整体更改，而这需要运营人员于节日前零点附近进行配置更新热点坑位的内容、热点位置的组件或者板块需要频繁更换等。此外，数据的频繁更新也会导致终端频繁进行请求，从而大幅增加云端接口并发，而传统采用将原本的内容和配置的定时内容一起下发的方式，则会增加云端服务器带宽，降低接口性能，此外如果定时需要终端配合则需要进行大量测试以及终端大规模升级，耗时耗力，所以只能Launcher云端自己实现。

发明内容

本发明的目的在于提供一种智能电视定时发布方法，用于解决现有技术中更新内容的频繁更换导致云端接口并发，且增加云端服务器带宽，降低接口性能的问题。

本发明通过下述技术方案解决上述问题：

一种智能电视定时发布方法，包括：

步骤S100、将智能电视的launcher数据分为模式、板块、组件和内容四层，在各上下层之间的关联节点进行定时配置，每层的关联节点先关联一个默认下层，关联时不附带时间段，再在相同位置关联一个或多个需要定时下层，关联时附带时间段，同一下层所处的位置附带放入时间段不重合；

步骤S200、定时配置完成后，将定时配置数据写入临时定时配置表，未发布的模式、板块、组件和内容数据写入临时表，模式、板块和组件附带ID和版本号，发布数据时，将临时表中的该层数据、该层以下各层数据以及上下层数据的关联信息更新到正式表，同时将临时定时配置表的定时配置数据更新到正式定时配置表；

步骤S300、Spring定时任务扫描正式定时配置表，当达到定时配置的时间段的开始时间时，触发定时更新，从上层到下层依次进行更新，将默认下层替换为定时下层，并在定时配置的时间段的结束时间到达后，将定时下层替换为默认下层；

步骤S400、电视终端向云端请求数据时，首先从最上层获取数据，若根据当前层的ID与版本号判断需要更新本层数据，则更新本层数据，再获取本层关联的下层的数据，继续判断是否进行该下层更新请求，如需要，则更新该下层数据，并获取该下层关联的下层的数据，直到需要更新数据的各层均完成更新。

本发明将电视终端数据分为内容、组件、板块、模式四层，通过Launcher后台对每一层与下一层的关联节点进行下层数据排期配置，然后采用Spring定时任务根据数据的生效时间进行相应数据更新来实现数据的时效性，云端按照分层提供数据(即接口按照分层拆分)，终端请求后根据响应的分层以及关联下层的id和版本号变化进行局部请求解决整体更新带来的带宽问题，解决由于频繁数据变化引起的云端接口并发问题。

定时配置数据还包含状态字段，用于表示当前定时执行情况，状态字段的字段值为未生效、已替换或已回退，其中：

未生效指数据发布后，定时配置的时间段不包含当前时刻，即定时开始时间在当前时刻之后或者定时结束时间在当前时刻之前；

已更新是指定时开始时间在当前时刻之前，而定时结束时间在当前时刻之后，需要将当前定时配置的定时位置的默认下层替换为定时下层，替换成功后，当前定时配置状态变为已更新；

已回退是指当前时刻在定时结束时间之后，将定时配置的定时位置的定时下层替换成默认下层，再将当前定时配置状态更新为已回退。

本发明与现有技术相比，具有以下优点及有益效果：

(1)本发明通过将数据进行分层，在各个分层关联节点进行定时配置，通过定时任务更新数据以及各层版本号，终端桌面按照分层进行数据请求，根据对比数据变化进行局部更新的方式来解决电视桌面的内容时效性显示问题。

(2)本发明根据数据分层来提供云端接口，解决了传统定时配置数据下发方式导致的服务器带宽增加导致的并发问题；各层更新单独控制，接口的水平扩展更加合理，终端根据分层id和版本号进行数据局部更新，降低数据频繁变化导致的云端接口并发问题。

附图说明

图1为电视桌面数据的获取原理框图；

图2为定时发布优先逻辑示意图；

图3为数据更新与回退的流程图；

图4为终端数据请求以及终端缓存更新的流程图。

具体实施方式

下面结合实施例对本发明作进一步地详细说明，但本发明的实施方式不限于此。

实施例：

结合附图1所示，一种智能电视定时发布方法，包括：

步骤S100、将智能电视的launcher数据分为模式、板块、组件和内容四层，电视终端的机芯机型关联一个模式，模式关联多个板块，每个板块关联多个组件，每个组件关联多个内容，因此，在实现电视桌面局部或者整体的定时，采用在各个分层的关联节点(比如，模式与板块的关联，板块与组件的关联，组件与内容的关联)进行定时配置，配置方式为：每层先关联一个默认下级，关联时不附带时间段，再在相同位置关联一个或多个需要定时的下级，关联时附带时间段，也就是当前下级生效的时间段，如在机型组关联模式时，先关联一个默认模式，用于没有定时模式时保底显示，再去关联一个或者多个附带时间段的定时模式，每个时间段对应一个模式，模式关联板块、板块关联组件以及组件关联内容也进行类似配置。定时配置时，需要保证同一时间，电视关联的模式唯一，同一板块位对应的板块唯一，板块对应位置对应的组件唯一，同一组件坑位对应的内容唯一，避免发生冲突。因此，同一位置对应的定时配置的时间段范围不能重合，如对组件的一个坑位进行定时，那么除了默认内容外，其他对这个坑位的内容定时配置对应的时间段不能重合。

步骤S200、定时配置完成后，将定时配置数据写入临时定时配置表，原来的模式、板块、组件、内容的关联逻辑不做改变，依旧只关联默认的下层，而定时配置表中保存默认关联和定时关联，临时定时配置表和正式定时配置表的主要字段为：type(定时配置类型)、configId(本层的唯一id)、isTimed(是否定时)、subId(下层id)、sort(下层在本层的顺序)、status(定时配置状态，未生效，已更新，已回退)、startTime(开始时间)、endTime(结束时间)，

其中：

未生效指数据发布后，定时配置的时间段不包含当前时刻，即定时开始时间在当前时刻之后或者定时结束时间在当前时刻之前；此时云端响应电视终端的请求下发数据时，当前正式数据只有默认模式、默认板块、默认组件、默认内容；

已更新是指定时开始时间在当前时刻之前，而定时结束时间在当前时刻之后，需要将当前定时配置的定时位置的默认下层替换为定时下层，替换成功后，当前定时配置状态变为已更新；此时云端下发数据拿取的还是默认数据，但当前默认的下层数据变成了定时配置的下层数据；

已回退是指当前时刻在定时结束时间之后，将定时配置的定时位置的定时下层替换成默认下层，再将当前定时配置状态更新为已回退，此时云端拿到的下层则变成了最初的默认下层；

在模式、板块、组件以及内容在后台配属完成后写入临时表，模式、板块和组件附带ID和版本号，发布数据时，将临时表中的该层数据、该层以下各层数据以及上下层数据的关联信息更新到正式表，同时将临时定时配置表的定时配置数据更新到正式定时配置表，方便后面进行替换。

发布数据时，模式、板块、组件的版本号进行更新。数据发布后，云端才能从正式表获取数据。云端请求接口分为三个，分别对应模式、板块、组件，各需要一个版本，因为接口下发时，只会下发当前分层的信息以及与下层的关联，只有当电视端请求到的版本号或者数据id发生改变时才会进行相应位置的数据更新。由于请求的组件数据大小已经合适，不单独做内容更新接口，即组件是云端请求的最底层。通过与分层对应的接口进行相应层数据下发，解决数据量变大引起的带宽问题，同时每层对应接口根据实际请求量进行水平扩展也更加合理、容易，也了解决数据频繁变化导致的云端接口并发问题。

步骤S300、采用Spring定时任务，定时扫描(如时间频率为一分钟一次等)正式定时配置表，定时更新包含两种操作，即原来的默认下层替换为定时下层，以及定时配置到期后，将定时下层替换为原来的默认下层。

定时扫描：如图2所示，定时任务采用的是从上而下的方式，即按照模式定时->板块定时->组件定时->内容定时的顺序对定时配置表进行扫描(定时配置表有type字段，扫描是根据类型进行)，获取开始时间在当前时间之前，结束时间在当前时间之后，且定时配置状态为未生效的定时配置进行更新替换操作；获取结束时间在当前时间之前，且定时配置状态为已更新的定时配置进行回退操作。

定时更新：如图3所示，定时任务每分钟扫描一次，获取需要进行更新的定时配置，然后依次模式定时->板块定时->组件定时->内容定时的顺序进行更新，替换的目标是定时配置的下层，回退的目标是最初的源下层。进行本层关联的下层进行更新后，再更新当前层对应的缓存，如对板块下第一个组件位置的定时配置生效，那么需要将原来板块关联的第一个组件替换成生效定时配置绑定的组件，再更新板块的缓存。回退操作和替换操作逻辑一样，只是回退是生效定时配置到期后需要将现在的定时下层替换为原来的默认下层。

步骤S400、电视终端向云端请求数据时，如图4所示，终端进行数据请求时先进行模式数据获取，对比终端缓存与拉取模式的id和版本号，如果模式发生了变化，进行终端模式缓存更新，在进行模式关联的板块和板块关联的组件的数据获取，并进行缓存；如果模式没有变化，需要对比关联的板块的id和版本号，如果板块发生了变化，需要进行终端板块缓存的更新，再请求板块下的组件，并进行缓存；当板块没有变化时，对板块下关联的组件id和组件版本号进行对比，如果组件发生了变化，对发生变化的组件进行重新请求，并进行缓存，如果组件没有变化，不进行处理。

本发明将电视终端数据分为内容、组件、板块、模式四层，通过Launcher后台对每一层与下一层的关联节点进行下层数据排期配置，然后采用Spring定时任务根据数据的生效时间进行相应数据更新来实现数据的时效性，云端按照分层提供数据(即接口按照分层拆分)，更容易针对指定接口进行水平扩展，随实际请求增加接口TPS；电视终端按照分层进行数据请求，通过对整个Launcher数据中变化的局部进行数据更新的方式，可以有效的减少接口的并发以及下发数据量大引发的带宽问题，解决由于频繁数据变化引起的云端接口并发问题。

尽管这里参照本发明的解释性实施例对本发明进行了描述，上述实施例仅为本发明较佳的实施方式，本发明的实施方式并不受上述实施例的限制，应该理解，本领域技术人员可以设计出很多其他的修改和实施方式，这些修改和实施方式将落在本申请公开的原则范围和精神之内。

Claims (2)

1.一种智能电视定时发布方法，其特征在于，包括：

步骤S100、将智能电视的launcher数据分为模式、板块、组件和内容四层，在各上下层之间的关联节点进行定时配置，每层的关联节点先关联一个默认下层，关联时不附带时间段，再在相同位置关联一个或多个需要定时下层，关联时附带时间段，同一下层所处的位置附带放入时间段不重合；

步骤S200、定时配置完成后，将定时配置数据写入临时定时配置表，未发布的模式、板块、组件和内容数据写入临时表，模式、板块和组件附带ID和版本号，发布数据时，将临时表中的该层数据、该层以下各层数据以及上下层数据的关联信息更新到正式表，同时将临时定时配置表的定时配置数据更新到正式定时配置表；

步骤S300、Spring定时任务扫描正式定时配置表，当达到定时配置的时间段的开始时间时，触发定时更新，从上层到下层依次进行更新，将默认下层替换为定时下层，并在定时配置的时间段的结束时间到达后，将定时下层替换为默认下层；

步骤S400、电视终端向云端请求数据时，首先从最上层获取数据，若根据当前层的ID与版本号判断需要更新本层数据，则更新本层数据，再获取本层关联的下层的数据，继续判断是否进行该下层更新请求，如需要，则更新该下层数据，并获取该下层关联的下层的数据，直到需要更新数据的各层均完成更新。

2.根据权利要求1所述的一种智能电视定时发布方法，其特征在于，定时配置数据还包含状态字段，用于表示当前定时执行情况，状态字段的字段值为未生效、已替换或已回退，其中：

未生效指数据发布后，定时配置的时间段不包含当前时刻，即定时开始时间在当前时刻之后或者定时结束时间在当前时刻之前；

已更新是指定时开始时间在当前时刻之前，而定时结束时间在当前时刻之后，需要将当前定时配置的定时位置的默认下层替换为定时下层，替换成功后，当前定时配置状态变为已更新；

已回退是指当前时刻在定时结束时间之后，将定时配置的定时位置的定时下层替换成默认下层，再将当前定时配置状态更新为已回退。

Images