CN106155828A - 用于播放应用程序资源控制方法和设备 - Google Patents

Abstract

本申请的目的是提供一种用于播放应用程序资源控制的方法和设备，通过在用户设备端获取播放应用程序的播放信息，根据所述播放信息确定可用播放应用程序资源信息；根据所述可用播放应用程序资源信息判断播放请求是否合理，得到判断结果；根据所述判断结果调整播放应用程序资源的资源分配。进而实现播放应用程序编程接口层面的资源管理，解决各个播放应用程序之间潜在的播放冲突；另外，将播放信息上传至网络设备进行大数据分析。进而，网络设备对所存储的系统级的播放信息进行大数据分析，能够及时发现应用程序的功能问题，提前诊断优化。

Description

用于播放应用程序资源控制方法和设备

技术领域

本申请涉及计算机领域，尤其涉及一种用于播放应用程序资源控制的技术。

背景技术

随着终端设备上的视频播放需求的不断扩大，用户对于视频相关类产品需求也逐渐增多，对于提升视频本身播放性能以及体验的要求越来越高。对于视频播放类应用，依赖于底层的播放资源管理调度算法，如果算法不好，会造成播放资源申请失败，无法播放的情况；在多任务系统中，引入audio focus(音频焦点)的机制来管理对音频(audio)资源的竞争的管理与协调，对于audio focus，如果第三方应用程序(app)不调用相关的编程接口(api)，audio focus不会起作用，难以起到协调音频输出的目的；对于同一个视频源，当播放器发生错误时，可能会一直无法播放，无法恢复，也不一定能及时发现，用户体验很差。

发明内容

本申请的目的是提供一种用于播放应用程序资源控制的方法与设备，以解决现有技术中不能解决播放应用程序编程接口层面的资源管理及各个应用程序之间潜在的播放冲突问题。

根据本申请的一个方面，提供了一种在用户设备端用于播放应用程序资源控制的方法，包括：

获取播放应用程序的播放信息，根据所述播放信息确定可用播放应用程序资源信息；

根据所述可用播放应用程序资源信息判断播放请求是否合理，得到判断结果；

根据所述判断结果调整播放应用程序资源的资源分配。

进一步地，获取播放应用程序的播放信息之后，包括：根据所述播放信 息，判断对应的应用程序的播放过程中是否发生异常，若是，则将异常的播放信息上传至网络设备，其中，所述异常的播放信息包括出错的播放应用程序及其出错类型。

进一步地，根据所述判断结果调整播放应用程序资源的资源分配包括：

若所述判断结果为所述播放请求为合理，则判断当前播放应用程序的播放是否占用下一个播放应用程序资源；若是，

则释放当前占用的全部或部分播放应用程序资源。

进一步地，根据所述判断结果调整播放应用程序资源的资源分配包括：

若所述判断结果为所述播放请求为不合理，则拒绝为所述播放请求分配播放应用程序资源。

进一步地，根据所述可用播放应用程序资源信息判断播放请求是否合理，得到判断结果包括：

判断所述播放请求是否有可用播放应用程序资源；

根据预设播放规则判断是否允许所述播放请求；

根据所述可用播放应用程序资源信息和所述预设播放规则判断所述播放请求是否合理，得到判断结果。

进一步地，获取播放应用程序的播放信息，包括：

监控所述播放应用程序的编程接口是否正常；若是，

在所述播放应用程序的播放过程中通过消息机制或回调机制获取播放应用程序的播放信息。

进一步地，获取播放应用程序的播放信息之后，还包括：将所述播放信息上传至网络设备。

进一步地，所述方法还包括：接收由所述网络设备反馈的出错的播放应用程序及其出错类型；基于所述出错的播放应用程序及其出错类型对对应的播放应用程序进行优化。

根据本申请的一个方面，还提供了一种在网络设备端用于播放应用程序资源控制的方法，包括：

接收播放应用程序的播放信息，其中所述播放信息包括播放过程中的正常和异常的播放信息；

基于所述播放信息进行数据分析，得到对应的播放应用程序的分析结果；

将所述播放应用程序的分析结果反馈至对应的用户设备。

进一步地，基于所述播放信息进行数据分析，得到对应的播放应用程序的分析结果包括：根据所述异常的播放信息确定出错的播放应用程序及其出错类型，得到对应的播放应用程序的分析结果。

更进一步地，将所述播放应用程序的分析结果反馈至对应的用户设备包括：将所述出错的播放应用程序及其出错类型发送至对应的用户设备。

根据本申请的另一方面，还提供了一种用于播放应用程序资源控制的用户设备，包括：

获取装置，用于获取播放应用程序的播放信息，根据所述播放信息确定可用播放应用程序资源信息；

判断装置，用于根据所述可用播放应用程序资源信息判断播放请求是否合理，得到判断结果；

调整装置，用于根据所述判断结果调整播放应用程序资源的资源分配。

进一步地，所述用户设备包括：传送装置，用于根据所述播放信息，判断对应的应用程序的播放过程中是否发生异常，若是，则将异常的播放信息上传至网络设备，其中，所述异常的播放信息包括出错的播放应用程序及其出错类型。

进一步地，所述调整装置用于：

若所述判断结果为所述播放请求为合理，则判断当前播放应用程序的播放是否占用下一个播放应用程序资源；若是，则释放当前占用的全部或部分播放应用程序资源。

进一步地，所述调整装置用于：

若所述判断结果为所述播放请求为不合理，则拒绝为所述播放请求分配播放应用程序资源。

进一步地，所述判断装置包括：

第一判断单元，用于判断所述播放请求是否有可用播放应用程序资源；

第二判断单元，用于根据预设播放规则判断是否允许所述播放请求；

确定结果单元，用于根据所述可用播放应用程序资源信息和所述预设播 放规则判断所述播放请求是否合理，得到判断结果。

进一步地，所述获取装置用于：

监控所述播放应用程序的编程接口是否正常；若是，

在所述播放应用程序的播放过程中通过消息机制或回调机制获取播放应用程序的播放信息。

进一步地，所述用户设备还包括：发送装置，用于将所述播放信息上传至网络设备。

进一步地，所述用户设备还包括：

确定装置，用于接收由所述网络设备反馈的出错的播放应用程序及其出错类型；

优化装置，用于基于所述出错的播放应用程序及其出错类型对对应的播放应用程序进行优化。

根据本申请的另一方面，还提供了一种用于播放应用程序资源控制的网络设备，其中，所述网络设备包括：

接收装置，用于接收播放应用程序的播放信息，其中所述播放信息包括播放过程中的正常和异常的播放信息；

分析装置，用于基于所述播放信息进行数据分析，得到对应的播放应用程序的分析结果；

反馈装置，用于将所述播放应用程序的分析结果反馈至对应的用户设备。

进一步地，所述分析装置用于，根据所述异常的播放信息确定出错的播放应用程序及其出错类型，得到对应的播放应用程序的分析结果。

更进一步地，所述反馈装置用于，将所述出错的播放应用程序及其出错类型发送至对应的用户设备。

与现有技术相比，本申请通过在用户设备端获取播放应用程序的播放信息，根据所述播放信息确定可用播放应用程序资源信息；根据所述可用播放应用程序资源信息判断播放请求是否合理，得到判断结果；根据所述判断结果调整播放应用程序资源的资源分配。进而实现播放应用程序编程接口层面的资源管理，解决各个播放应用程序之间潜在的播放冲突；另外，在网络设备端接收播放应用程序的播放信息，其中所述播放信息包括播放过程中的 正常和异常的播放信息；基于所述播放信息进行数据分析，得到对应的播放应用程序的分析结果；将所述播放应用程序的分析结果反馈至对应的用户设备。进而，网络设备对所存储的系统级的播放信息进行大数据分析，能够及时发现应用程序的功能问题，提前诊断优化。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1示出根据本申请一个方面的一种用于播放应用程序资源控制的用户设备的结构示意图；

图2示出根据本申请一个方面的一个优选实施例的判断装置的结构示意图；

图3示出根据本申请一个方面的一种用于播放应用程序资源控制的网络设备的结构示意图；

图4示出根据本申请一个方面的一个优选实施例的播放诊断控制系统示意图；

图5示出根据本申请另一个方面的一种在用户设备端用于播放应用程序资源控制的方法流程示意图；

图6示出根据本申请另一个方面的一个优选实施例的步骤S12的流程示意图；

图7示出根据本申请另一个方面的一种在网络设备端用于播放应用程序资源控制的方法流程示意图。

附图中相同或相似的附图标记代表相同或相似的部件。

具体实施方式

下面结合附图对本申请作进一步详细描述。

为更进一步阐述本申请所采取的技术手段及取得的效果，下面结合附图及较佳实施例，对本申请的技术方案，进行清楚和完整的描述。

图1示出根据本申请一个方面的一种用于播放应用程序资源控制的用 户设备的结构示意图。所述用户设备1包括获取装置11、判断装置12和调整装置13；其中，获取装置11获取播放应用程序的播放信息，根据所述播放信息确定可用播放应用程序资源信息；判断装置12根据所述可用播放应用程序资源信息判断播放请求是否合理，得到判断结果；调整装置13根据所述判断结果调整播放应用程序资源的资源分配。

上述各装置之间是持续不断工作的，在此，本领域技术人员应理解“持续”是指上述各装置分别实时地或者按照设定的或实时调整的工作模式要求。

在此，所述用户设备1包括但不限于任何一种可与用户通过遥控器或触摸板进行人机交互的互联网电视产品或移动电子产品，例如智能手机、PDA等，所述移动电子产品可以采用任意操作系统，如android操作系统、iOS操作系统等。优选地，用户设备1还可以是运行于所述用户设备、或用户设备与网络设备、触摸终端或网络设备与触摸终端通过网络相集成所构成的设备上的脚本程序。当然，本领域技术人员应能理解上述用户设备1仅为举例，其他现有的或今后可能出现的用户设备1如可适用于本申请，也应包含在本申请保护范围以内，并在此以引用方式包含于此。

具体地，获取装置11获取播放应用程序的播放信息，根据所述播放信息确定可用播放应用程序资源信息。

在一实施例中，所述播放应用程序(APP，application)优选为播放器，如视频APPA、视频APP B。所述可用播放应用程序资源信息优选为可用播放器资源。获取装置11获取每一个播放器的播放信息，其中，播放信息包括播放视频标题、当前播放进度、网络下载速度变化、播放视频的分辨率大小、视频源的音视频及图片格式、播放过程中发生的错误等信息。使用不同类型的播放器，使用播放器的个数会影响播放效果，每个播放器播放视频音频时会请求分配播放器资源，由每个播放器的播放信息可确定当前可用的播放器资源信息，当来新的播放请求时，能够合理分配播放资源。

具体地，判断装置12根据所述可用播放应用程序资源信息判断播放请求是否合理，得到判断结果。

在一实施例中，用户设备1优选为互联网电视，当有新的播放请求时，互联网电视端会分析已有的播放信息，如目前哪些播放资源被占用及被哪些 APP占用，可用的播放器资源信息，当前播放器播放的视频类型、播放时长等播放数据，判断新的播放请求是否合理，如是否有可用播放器资源，使用某播放器时在播放过程中逻辑上是否允许终端等。

优选地，如图2所示，图2示出根据本申请一个方面的一个优选实施例的判断装置的结构示意图；所述判断装置12包括：第一判断单元121、第二判断单元122和确定结果单元123，其中，第一判断单元121判断所述播放请求是否有可用播放应用程序资源；第二判断单元122根据预设播放规则判断是否允许所述播放请求；确定结果单元123根据所述可用播放应用程序资源信息和所述预设播放规则判断所述播放请求是否合理，得到判断结果。

在一实施例中，当有新的播放请求时，判断装置12对已经记录的播放信息进行综合分析，例如，已给之前的播放请求分配完了播放器资源，则之前的播放请求对应的为已播放或当前播放，则分析之前的播放请求和新播放请求的进程处于前台还是后台，播放的是音频还是视频，系统层音视频的可用播放器资源数，以及是否满足预设播放规则，其中，预设播放规则可为播放器在产品策略上是否允许播放请求，例如，播放器APP A禁止后台播放，而新的播放请求为使用APP A进行后台播放，则该新的播放请求是不合理的。当新的播放请求来时，根据可用播放应用程序资源是否有剩余和预设播放规则是否允许该新的播放请求进行综合判断新的播放请求是否合理，得到最终的判断结果。需要说明的是，新的播放请求可为播放测试时任意发的一个播放请求。

本领域技术人员应能理解，上述根据可用播放应用程序资源信息和预设播放规则判断播放请求是否合理仅为一种判断标准的举例，其他现有的或今后可能出现的判断播放请求是否合理的判断标准如可适用于本申请，也应包含在本申请保护范围以内，并在此以引用方式包含于此。

具体地，调整装置13根据所述判断结果调整播放应用程序资源的资源分配。

在此，根据判断结果调整播放器资源的资源分配，解决各个app之间潜在的播放冲突。优选地，若所述判断结果为所述播放请求为合理，则判断当前播放应用程序的播放是否占用下一个播放应用程序资源；若是，则释放当 前占用的全部或部分播放应用程序资源。优选地，若所述判断结果为所述播放请求为不合理，则拒绝为所述播放请求分配播放应用程序资源。

在一具体实施例中，如当有新的播放请求来时，根据已有的播放数据进行综合分析，判断新的播放请求是否合理，若不合理，则拒绝给新的播放请求分配播放器资源；若合理并且旧有的播放占用了新的播放器资源，会通过消息机制释放旧有的播放器资源，或者内部直接释放旧有的播放器，将当前占用的播放器资源全部释放或部分释放，如同时使用音乐播放器和视频播放器时，来一个新的播放请求是使用视频播放器进行播放，则将界面上的音乐播放器关闭，但后台进程没有结束，则属于释放部分播放器资源。

需要说明的是，对于特定的互联网电视系统，播放器资源是有限的，可以写几个强制霸占播放器资源的视频播放器进行播放测试，例如，写两个播放类的app，在app退出到后台后不调用释放播放器的api接口(编程接口)，看每个播放器起播是否正常，如app安装后有对应的图标，先选择一个app进入播放，再退出选择另一个app播放，查看第二个app播放是否正常，如果播放正常，则对播放器资源做了相关的释放处理，利用了本申请所述的用于播放应用程序资源控制的方法。

优选地，所述用户设备1包括：传送装置(未示出)，用于根据所述播放信息，判断对应的应用程序的播放过程中是否发生异常，若是，则将异常的播放信息上传至网络设备，其中，所述异常的播放信息包括出错的播放应用程序及其出错类型。

在此，所述异常的播放信息为播放过程中发生的错误，将在播放过程中通过消息及回调机制等所获取的播放器底层的各类错误信息上传至网络设备，包括播放视频标题、当前播放进度、错误的类型(网络/服务器/解码器等)，例如，DNS劫持、服务器错误、播放器不支持特定的格式，app对于播放api的调用状态机不对，下载的数据源有错误等，将异常的播放信息上传至网络设备，以便统计和分析。

优选地，所述获取装置11用于：监控所述播放应用程序的编程接口是否正常；若是，在所述播放应用程序的播放过程中通过消息机制或回调机制获取播放应用程序的播放信息。

在一具体实施例中，监控播放器api接口的调用是否正常，若api调用不正常，则播放可能会出错，严重时可能会终止播放，需要说明的是，api本身可能调用是正常的，但由于播放器资源不足或产品策略的规则导致调用不正常，可以将这一事件上传至网络设备以备做分析改进。通过状态机判断api调用是否正常，如果正常，则在api层面能够及时发现播放类应用对于播放资源的使用以及可能出现的问题，通过消息机制或回调机制获取每个播放类应用的播放信息，其中，所获取的播放信息包括正常的播放参数数据和播放过程中出现的错误。在此，消息机制为api层面出现错误后，通过特定的socket(通信链的句柄)端口发送消息给播放器管理；回调机制为播放器管理在api接口设个回调接口，出现问题后再调用这个回调通知到播放器管理。

本领域技术人员应能理解，上述实施例中使用消息机制或回调机制获取每个播放类应用的播放信息的方法仅为举例，其他现有的或今后可能出现的获取每个播放类应用的播放信息的方法如可适用于本申请，也应包含在本申请保护范围以内，并在此以引用方式包含于此。

优选地，所述用户设备1还包括：发送装置(未示出)，用于将所述播放信息上传至网络设备。

接上述实施例，通过播放器api接口获取每个播放类应用的播放信息，包括基于播放器api的使用发现可能的使用异常和在播放过程中通过消息及回调机制等获取的播放器底层的各类错误信息。将所获得的播放信息上传至网络设备，有利于根据对播放信息的分析进行快速定位并做出改进。

优选地，所述用户设备1还包括：确定装置(未示出)，用于接收由所述网络设备反馈的出错的播放应用程序及其出错类型；优化装置(未示出)，用于基于所述出错的播放应用程序及其出错类型对对应的播放应用程序进行优化。

在此，接收网络设备反馈的出错的播放应用程序及其出错类型，在一实施例中，网络设备反馈哪个播放app出现问题，播放视频格式不支持哪种格式，网络类型哪种不支持该播放app进行播放的功能，网络出现异常，视频分辨率过低，解码出错等问题，以及每个播放应用程序所占用内存大小等，优化装置可根据网络设备反馈的信息对对应的播放应用程序进行优化，用户 设备也可根据网络设备反馈的信息，对播放器资源进行调整，对于播放请求能够更合理的分配播放资源。需要说明的是，网络设备反馈的信息可由用户设备1接收，使用后台服务进行优化，也可是第三方设备进行接收，例如某个播放app开发者或团队。

图3示出根据本申请一个方面的一种用于播放应用程序资源控制的网络设备的结构示意图；所述网络设备2包括：接收装置21、分析装置22和反馈装置23，其中，接收装置21接收播放应用程序的播放信息，其中，所述播放信息包括播放过程中的正常和异常的播放信息；分析装置22基于所述播放信息进行数据分析，得到对应的播放应用程序的分析结果；反馈装置23将所述播放应用程序的分析结果反馈至对应的用户设备。

在此，网络设备2可以是一台服务器，也可以是通过局域网连接的多台服务器或者通过互联网连接的多台服务器，还可以是由多台服务器构成的云。在此，云由基于云计算(Cloud Computing)的大量计算机或网络服务器构成，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个超级虚拟计算机。

具体地，接收装置21接收播放应用程序的播放信息，其中，所述播放信息包括播放过程中的正常和异常的播放信息；

在此，接收由用户设备反馈来的播放应用程序的播放信息，其中，播放信息包括播放过程中正常和异常的播放信息，其中，正常的播放信息包括播放的节目源信息、播放时长、各类播放app的使用频次等，所述异常的播放信息包括播放过程中出现的不支持播放问题、播放时解码错误、网络异常等。

具体地，分析装置22基于所述播放信息进行数据分析，得到对应的播放应用程序的分析结果；

在此，对所获取到的播放信息进行数据分析，例如，播放应用程序占用内存大小，播放时的视频分辨率大小、能够兼容的视频格式；优选地，根据所述异常的播放信息确定出错的播放应用程序及其出错类型，得到对应的播放应用程序的分析结果。网络设备根据已有的播放信息可确定哪个播放应用程序在播放视频过程中出现错误及出现错误的类型，有利于快速定位出错的播放所对应的播放应用程序，方便对该播放应用程序进行优化。

具体地，反馈装置23将所述播放应用程序的分析结果反馈至对应的用户设备。

在此，网络设备优选为云端，所述播放应用程序的分析结果包括出错的播放应用程序及其出错类型。优选地，反馈装置23将所述出错的播放应用程序及其出错类型发送至对应的用户设备。实现了平台级播放信息的云记录，进行大数据分析，将分析结果反馈给平台自己的app团队或第三方，对播放应用程序进行优化或更新版本，如提高稳定性和兼容性，从而提高用户体验。需要说明的是，云端也可将对播放应用程序的分析结果反馈至后台服务器，进行改进播放规则，通过云端将播放规则下发给播放器管理。

图4示出根据本申请一个方面的一个优选实施例的播放诊断控制系统示意图；在此，用户设备优选为播放诊断控制系统，播放诊断控制系统最核心的部分为播放器管理(Player Manager)，通过APP A、APP B等与Player Manager模块间的箭头所示的信息流向，实现了Player Manager对于每个APP的播放信息的记录，通过Player Manager内部的策略管理，对新的播放请求进行判断，决定是否允许新的播放请求。另外，Player Manager对所获取到的播放信息上传至网络设备，其中，播放信息包括Player Manager本身基于播放器api的使用发现可能的使用异常和在播放过程中通过消息及回调机制等获取播放器底层的各类错误信息，比如网络异常，解码出错等，这些信息会及时发送给网络设备，网络设备优选为云端，云端对已有的播放信息进行分析，将分析结果反馈至对应的用户设备，这里对应的用户设备优选为app开发者。Player Manager本身会基于app的优先级的策略避免资源冲突下无法播放的问题，app开发者基于云端的反馈信息对播放器应用进行优化改进，例如，改进播放规则或对播放器app进行版本迭代。

本申请实施例中所述的用于播放应用程序资源控制的用户设备和网络设备，对于播放类应用，从api的层面直接进行监控，有利于第一时间发现并解决问题，并且可以在不修改应用代码的情况下协调播放器资源；当有播放错误发生时，可以通过诊断控制系统回传错误给云端，有利于对错误进行梳理定位并作出有针对性的改进。例如，对于同一个平台，可以增 强播放器的稳定性及兼容性，提高用户体验，并且在系统层面可以及早发现应用的兼容性问题，可以通知到对应的应用程序所属人或团队进行修改，还可以在不修改应用的情况下通过Player Manager让应用能正常工作。

图5示出根据本申请另一个方面的一种在用户设备端用于播放应用程序资源控制的方法流程示意图。所述方法包括步骤S11、步骤S12和步骤S13；其中，在步骤S11中，获取播放应用程序的播放信息，根据所述播放信息确定可用播放应用程序资源信息；在步骤S12中，根据所述可用播放应用程序资源信息判断播放请求是否合理，得到判断结果；在步骤S13中，根据所述判断结果调整播放应用程序资源的资源分配。

具体地，在步骤S11中，获取播放应用程序的播放信息，根据所述播放信息确定可用播放应用程序资源信息。

在一实施例中，所述播放应用程序(APP，application)优选为播放器，如视频APPA、视频APP B。所述可用播放应用程序资源信息优选为可用播放器资源。在步骤S11中获取每一个播放器的播放信息，其中，播放信息包括播放视频标题、当前播放进度、网络下载速度变化、播放视频的分辨率大小、视频源的音视频及图片格式、播放过程中发生的错误等信息。使用不同类型的播放器，使用播放器的个数会影响播放效果，每个播放器播放视频音频时会请求分配播放器资源，由每个播放器的播放信息可确定当前可用的播放器资源信息，当来新的播放请求时，能够合理分配播放资源。

具体地，在步骤S12中，根据所述可用播放应用程序资源信息判断播放请求是否合理，得到判断结果。

在一实施例中，用于播放应用程序资源控制的方法优选为在互联网电视端进行，当有新的播放请求时，互联网电视端会分析已有的播放信息，如目前哪些播放资源被占用及被哪些APP占用，可用的播放器资源信息，当前播放器播放的视频类型、播放时长等播放数据，判断新的播放请求是否合理，如是否有可用播放器资源，使用某播放器时在播放过程中逻辑上是否允许终端等。

优选地，如图6所示，图6示出根据本申请另一个方面的一个优选实施例的步骤S12的流程示意图；所述步骤S12包括：步骤S121、步骤S122 和步骤S123，其中，在步骤S121中，判断所述播放请求是否有可用播放应用程序资源；在步骤S122中，根据预设播放规则判断是否允许所述播放请求；在步骤S123中，根据所述可用播放应用程序资源信息和所述预设播放规则判断所述播放请求是否合理，得到判断结果。

在一实施例中，当有新的播放请求时，对已经记录的播放信息进行综合分析，例如，已给之前的播放请求分配完了播放器资源，则之前的播放请求对应的为已播放或当前播放，则分析之前的播放请求和新播放请求的进程处于前台还是后台，播放的是音频还是视频，系统层音视频的可用播放器资源数，以及是否满足预设播放规则，其中，预设播放规则可为播放器在产品策略上是否允许播放请求，例如，播放器APP A禁止后台播放，而新的播放请求为使用APP A进行后台播放，则该新的播放请求是不合理的。当新的播放请求来时，根据可用播放应用程序资源是否有剩余和预设播放规则是否允许该新的播放请求进行综合判断新的播放请求是否合理，得到最终的判断结果。需要说明的是，新的播放请求可为播放测试时任意发的一个播放请求。

本领域技术人员应能理解，上述根据可用播放应用程序资源信息和预设播放规则判断播放请求是否合理仅为一种判断标准的举例，其他现有的或今后可能出现的判断播放请求是否合理的判断标准如可适用于本申请，也应包含在本申请保护范围以内，并在此以引用方式包含于此。

具体地，在步骤S13中，根据所述判断结果调整播放应用程序资源的资源分配。

在此，根据判断结果调整播放器资源的资源分配，解决各个app之间潜在的播放冲突。优选地，若所述判断结果为所述播放请求为合理，则判断当前播放应用程序的播放是否占用下一个播放应用程序资源；若是，则释放当前占用的全部或部分播放应用程序资源。优选地，若所述判断结果为所述播放请求为不合理，则拒绝为所述播放请求分配播放应用程序资源。

在一具体实施例中，如当有新的播放请求来时，根据已有的播放数据进行综合分析，判断新的播放请求是否合理，若不合理，则拒绝给新的播放请求分配播放器资源；若合理并且旧有的播放占用了新的播放器资源，会通过消息机制释放旧有的播放器资源，或者内部直接释放旧有的播放器，将当前 占用的播放器资源全部释放或部分释放，如同时使用音乐播放器和视频播放器时，来一个新的播放请求是使用视频播放器进行播放，则将界面上的音乐播放器关闭，但后台进程没有结束，则属于释放部分播放器资源。

需要说明的是，对于特定的互联网电视系统，播放器资源是有限的，可以写几个强制霸占播放器资源的视频播放器进行播放测试，例如，写两个播放类的app，在app退出到后台后不调用释放播放器的api接口(编程接口)，看每个播放器起播是否正常，如app安装后有对应的图标，先选择一个app进入播放，再退出选择另一个app播放，查看第二个app播放是否正常，如果播放正常，则对播放器资源做了相关的释放处理，利用了本申请所述的用于播放应用程序资源控制的方法。

优选地，所述获取播放应用程序的播放信息之后，包括：根据所述播放信息，判断对应的应用程序的播放过程中是否发生异常，若是，则将异常的播放信息上传至网络设备，其中，所述异常的播放信息包括出错的播放应用程序及其出错类型。

在此，所述异常的播放信息为播放过程中发生的错误，将在播放过程中通过消息及回调机制等所获取的播放器底层的各类错误信息上传至网络设备，包括播放视频标题、当前播放进度、错误的类型(网络/服务器/解码器等)，例如，DNS劫持、服务器错误、播放器不支持特定的格式，app对于播放api的调用状态机不对，下载的数据源有错误等，将异常的播放信息上传至网络设备，以便统计和分析。

优选地，获取播放应用程序的播放信息包括：监控所述播放应用程序的编程接口是否正常；若是，在所述播放应用程序的播放过程中通过消息机制或回调机制获取播放应用程序的播放信息。

在一具体实施例中，监控播放器api接口的调用是否正常，若api调用不正常，则播放可能会出错，严重时可能会终止播放，需要说明的是，api本身可能调用是正常的，但由于播放器资源不足或产品策略的规则导致调用不正常，可以将这一事件上传至网络设备以备做分析改进。通过状态机判断api调用是否正常，如果正常，则在api层面能够及时发现播放类应用对于播放资源的使用以及可能出现的问题，通过消息机制或回调机制获取每个播放类 应用的播放信息，其中，所获取的播放信息包括正常的播放参数数据和播放过程中出现的错误。在此，消息机制为api层面出现错误后，通过特定的socket(通信链的句柄)端口发送消息给播放器管理；回调机制为播放器管理在api接口设个回调接口，出现问题后再调用这个回调通知到播放器管理。

本领域技术人员应能理解，上述实施例中使用消息机制或回调机制获取每个播放类应用的播放信息的方法仅为举例，其他现有的或今后可能出现的获取每个播放类应用的播放信息的方法如可适用于本申请，也应包含在本申请保护范围以内，并在此以引用方式包含于此。

优选地，获取播放应用程序的播放信息之后，还包括：将所述播放信息上传至网络设备。

接上述实施例，通过播放器api接口获取每个播放类应用的播放信息，包括基于播放器api的使用发现可能的使用异常和在播放过程中通过消息及回调机制等获取的播放器底层的各类错误信息。将所获得的播放信息上传至网络设备，有利于根据对播放信息的分析进行快速定位并做出改进。

优选地，所述方法还包括：接收由所述网络设备反馈的出错的播放应用程序及其出错类型；基于所述出错的播放应用程序及其出错类型对对应的播放应用程序进行优化。

在此，接收网络设备反馈的出错的播放应用程序及其出错类型，在一实施例中，网络设备反馈哪个播放app出现问题，播放视频格式不支持哪种格式，网络类型哪种不支持该播放app进行播放的功能，网络出现异常，视频分辨率过低，解码出错等问题，以及每个播放应用程序所占用内存大小等，接着，根据网络设备反馈的信息对对应的播放应用程序进行优化，用户设备也可根据网络设备反馈的信息，对播放器资源进行调整，对于播放请求能够更合理的分配播放资源。需要说明的是，网络设备反馈的信息可由用户设备接收，使用后台服务进行优化，也可是第三方设备进行接收，例如某个播放app开发者或团队。

图7示出根据本申请另一个方面的一种在网络设备端用于播放应用程序资源控制的方法流程示意图；所述方法包括：步骤S21、步骤S22和步骤S23，其中，在步骤S21中，接收播放应用程序的播放信息，其中，所述播放 信息包括播放过程中的正常和异常的播放信息；在步骤S22中，基于所述播放信息进行数据分析，得到对应的播放应用程序的分析结果；在步骤S23中，将所述播放应用程序的分析结果反馈至对应的用户设备。

在此，网络设备2可以是一台服务器，也可以是通过局域网连接的多台服务器或者通过互联网连接的多台服务器，还可以是由多台服务器构成的云。在此，云由基于云计算(Cloud Computing)的大量计算机或网络服务器构成，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个超级虚拟计算机。

需要说明的是，所述用户设备包括但不限于任何一种可与用户通过遥控器或触摸板进行人机交互的互联网电视产品或移动电子产品，在本申请的一优选实施例中，用户设备优选为互联网电视。

具体地，在步骤S21中，接收播放应用程序的播放信息，其中，所述播放信息包括播放过程中的正常和异常的播放信息；

在此，接收由用户设备反馈来的播放应用程序的播放信息，其中，播放信息包括播放过程中正常和异常的播放信息，其中，正常的播放信息包括播放的节目源信息、播放时长、各类播放app的使用频次等，所述异常的播放信息包括播放过程中出现的不支持播放问题、播放时解码错误、网络异常等。

具体地，在步骤S22中，基于所述播放信息进行数据分析，得到对应的播放应用程序的分析结果；

在此，对所获取到的播放信息进行数据分析，例如，播放应用程序占用内存大小，播放时的视频分辨率大小、能够兼容的视频格式；优选地，根据所述异常的播放信息确定出错的播放应用程序及其出错类型，得到对应的播放应用程序的分析结果。网络设备根据已有的播放信息可确定哪个播放应用程序在播放视频过程中出现错误及出现错误的类型，有利于快速定位出错的播放所对应的播放应用程序，方便对该播放应用程序进行优化。

具体地，在步骤S23中，将所述播放应用程序的分析结果反馈至对应的用户设备。

在此，网络设备优选为云端，所述播放应用程序的分析结果包括出错的播放应用程序及其出错类型。优选地，在步骤S23中，将所述出错的播放应 用程序及其出错类型发送至对应的用户设备。实现了平台级播放信息的云记录，进行大数据分析，将分析结果反馈给平台自己的app团队或第三方，对播放应用程序进行优化或更新版本，如提高稳定性和兼容性，从而提高用户体验。需要说明的是，云端也可将对播放应用程序的分析结果反馈至后台服务器，进行改进播放规则，通过云端将播放规则下发给播放器管理。

图4示出根据本申请一个方面的一个优选实施例的播放诊断控制系统示意图；在此，用户设备优选为播放诊断控制系统，播放诊断控制系统最核心的部分为播放器管理(Player Manager)模块，通过APP A、APP B等与Player Manager模块间的箭头所示的信息流向，实现了Player Manager对于每个APP的播放信息的记录，通过Player Manager内部的策略管理，对新的播放请求进行判断，决定是否允许新的播放请求。另外，Player Manager对所获取到的播放信息上传至网络设备，其中，播放信息包括Player Manager本身基于播放器api的使用发现可能的使用异常和在播放过程中通过消息及回调机制等获取播放器底层的各类错误信息，比如网络异常，解码出错等，这些信息会及时发送给网络设备，网络设备优选为云端，云端对已有的播放信息进行分析，将分析结果反馈至对应的用户设备，这里对应的用户设备优选为app开发者。Player Manager本身会基于app的优先级的策略避免资源冲突下无法播放的问题，app开发者基于云端的反馈信息对播放器应用进行优化改进，例如，改进播放规则或对播放器app进行版本迭代。

本申请实施例中所述的用于播放应用程序资源控制的用户设备和网络设备，对于播放类应用，从api的层面直接进行监控，有利于第一时间发现并解决问题，并且可以在不修改应用代码的情况下协调播放器资源；当有播放错误发生时，可以通过诊断控制系统回传错误给云端，有利于对错误进行梳理定位并做出有针对性的改进。例如，对于同一个平台，可以增强播放器的稳定性及兼容性，提高用户体验，并且在系统层面可以及早发现应用的兼容性问题，可以通知到对应的应用程序的开发者或团队进行修改，还可以在不修改应用的情况下通过Player Manager让应用能正常工作。

需要注意的是，本申请可在软件和/或软件与硬件的组合体中被实施，例 如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一个实施例中，本申请的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地，本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

另外，本申请的一部分可被应用为计算机程序产品，例如计算机程序指令，当其被计算机执行时，通过该计算机的操作，可以调用或提供根据本申请的方法和/或技术方案。而调用本申请的方法的程序指令，可能被存储在固定的或可移动的记录介质中，和/或通过广播或其他信号承载媒体中的数据流而被传输，和/或被存储在根据所述程序指令运行的计算机设备的工作存储器中。在此，根据本申请的一个实施例包括一个装置，该装置包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发该装置运行基于前述根据本申请的多个实施例的方法和/或技术方案。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

Claims (22)

1.一种在用户设备端用于播放应用程序资源控制方法，其中，所述方法包括：

获取播放应用程序的播放信息，根据所述播放信息确定可用播放应用程序资源信息；

根据所述可用播放应用程序资源信息判断播放请求是否合理，得到判断结果；

根据所述判断结果调整播放应用程序资源的资源分配。

2.根据权利要求1所述的方法，其中，所述获取播放应用程序的播放信息之后，包括：

根据所述播放信息，判断对应的应用程序的播放过程中是否发生异常，若是，则将异常的播放信息上传至网络设备，其中，所述异常的播放信息包括出错的播放应用程序及其出错类型。

3.根据权利要求1所述的方法，其中，所述根据所述可用播放应用程序资源信息判断播放请求是否合理，得到判断结果包括：

判断所述播放请求是否有可用播放应用程序资源；

根据预设播放规则判断是否允许所述播放请求；

根据所述可用播放应用程序资源信息和所述预设播放规则判断所述播放请求是否合理，得到判断结果。

4.根据权利要求1至3中任一项所述的方法，其中，所述获取播放应用程序的播放信息，包括：

监控所述播放应用程序的编程接口是否正常；若是，

在所述播放应用程序的播放过程中通过消息机制或回调机制获取播放应用程序的播放信息。

5.根据权利要求1至3中任一项所述的方法，其中，获取播放应用程序的播放信息之后，还包括：

将所述播放信息上传至网络设备。

6.根据权利要求1至3中任一项所述的方法，其中，所述方法还包括：

接收由网络设备反馈的出错的播放应用程序及其出错类型；

基于所述出错的播放应用程序及其出错类型对对应的播放应用程序进行优化。

7.根据权利要求1至3中任一项所述的方法，其中，所述根据所述判断结果调整播放应用程序资源的资源分配包括：

若所述判断结果为所述播放请求为合理，则判断当前播放应用程序的播放是否占用下一个播放应用程序资源；若是，

则释放当前占用的全部或部分播放应用程序资源。

8.根据权利要求1至3中任一项所述的方法，其中，所述根据所述判断结果调整播放应用程序资源的资源分配包括：

若所述判断结果为所述播放请求为不合理，则拒绝为所述播放请求分配播放应用程序资源。

9.一种在网络设备端用于播放应用程序资源控制方法，其中，所述方法包括：

接收播放应用程序的播放信息，其中所述播放信息包括播放过程中的正常和异常的播放信息；

基于所述播放信息进行数据分析，得到对应的播放应用程序的分析结果；

将所述播放应用程序的分析结果反馈至对应的用户设备。

10.根据权利要求9所述的方法，其中，所述基于所述播放信息进行数据分析，得到对应的播放应用程序的分析结果包括：

根据所述异常的播放信息确定出错的播放应用程序及其出错类型，得到对应的播放应用程序的分析结果。

11.根据权利要求10所述的方法，其中，所述将所述播放应用程序的分析结果反馈至对应的用户设备包括：

将所述出错的播放应用程序及其出错类型发送至对应的用户设备。

12.一种用于播放应用程序资源控制的用户设备，其中，所述用户设备包括：

获取装置，用于获取播放应用程序的播放信息，根据所述播放信息确定可用播放应用程序资源信息；

判断装置，用于根据所述可用播放应用程序资源信息判断播放请求是否合理，得到判断结果；

调整装置，用于根据所述判断结果调整播放应用程序资源的资源分配。

13.根据权利要求12所述的用户设备，其中，所述用户设备包括：

传送装置，用于根据所述播放信息，判断对应的应用程序的播放过程中是否发生异常，若是，则将异常的播放信息上传至网络设备，其中，所述异常的播放信息包括出错的播放应用程序及其出错类型。

14.根据权利要求12所述的用户设备，其中，所述判断装置包括：

第一判断单元，用于判断所述播放请求是否有可用播放应用程序资源；

第二判断单元，用于根据预设播放规则判断是否允许所述播放请求；

确定结果单元，用于根据所述可用播放应用程序资源信息和所述预设播放规则判断所述播放请求是否合理，得到判断结果。

15.根据权利要求12至14中任一项所述的用户设备，其中，所述获取装置用于：

监控所述播放应用程序的编程接口是否正常；若是，

在所述播放应用程序的播放过程中通过消息机制或回调机制获取播放应用程序的播放信息。

16.根据权利要求12至14中任一项所述的用户设备，其中，所述用户设备包括：

发送装置，用于将所述播放信息上传至网络设备。

17.根据权利要求12至14中任一项所述的用户设备，其中，所述用户设备还包括：

确定装置，用于接收由网络设备反馈的出错的播放应用程序及其出错类型；

优化装置，用于基于所述出错的播放应用程序及其出错类型对对应的播放应用程序进行优化。

18.根据权利要求12至14中任一项所述的用户设备，其中，所述调整装置用于：

若所述判断结果为所述播放请求为合理，则判断当前播放应用程序的播放是否占用下一个播放应用程序资源；若是，

则释放当前占用的全部或部分播放应用程序资源。

19.根据权利要求12至14中任一项所述的用户设备，其中，所述调整装置用于：

若所述判断结果为所述播放请求为不合理，则拒绝为所述播放请求分配播放应用程序资源。

20.一种用于播放应用程序资源控制的网络设备，其中，所述网络设备包括：

接收装置，用于接收播放应用程序的播放信息，其中所述播放信息包括播放过程中的正常和异常的播放信息；

分析装置，用于基于所述播放信息进行数据分析，得到对应的播放应用程序的分析结果；

反馈装置，用于将所述播放应用程序的分析结果反馈至对应的用户设备。

21.根据权利要求20所述的网络设备，其中，所述分析装置用于：

根据所述异常的播放信息确定出错的播放应用程序及其出错类型，得到对应的播放应用程序的分析结果。

22.根据权利要求21所述的网络设备，其中，所述反馈装置用于：

将所述出错的播放应用程序及其出错类型发送至对应的用户设备。