CN114422637B - 媒体请求处理方法和跨平台引擎系统 - Google Patents

Abstract

公开一种媒体请求处理方法和跨平台引擎系统。该方法包括：根据用户的媒体相关访问请求，确定需要调用的插件；判断所述需要调用的插件是否包含在多个插件中，如果是，则调用所述需要调用的插件来完成相应功能处理。本公开实施例将音视频处理插件化从而音视频开发更加简单易用、扩展性更高。

Description

媒体请求处理方法和跨平台引擎系统

技术领域

本公开涉及自媒体处理领域，具体而言，涉及一种媒体请求处理方法和跨平台引擎系统。

背景技术

当今自媒体时代，任何用户(包括个人和企业)都可将自己的媒体系统接入到网络中，以获得复杂的媒体能力。这些媒体能力例如为直播带货、在线课堂、主播等等。但是不是所有的用户都有能力构建自己的媒体系统，为此软件服务提供商提供一种软件开发工具包(Software Development Kit，SDK)，并将各种复杂的媒体能力封装在该软件开发工具包中提供用户，以帮助用户构建自己的自媒体系统。

但是随着用户数量的不断增加，为了应对每个用户的个性化需求，需要提供的功能模块和需要支持的系统版本越来越多，导致SDK变得越来越大，从而不利于维护和使用。

发明内容

有鉴于此，本公开的目的是提供一种媒体请求处理方法和跨平台引擎系统，通过将媒体能力插件化来解决上述问题。

第一方面，本公开提供一种媒体请求处理方法，包括：

根据用户的媒体相关访问请求，确定需要调用的插件；

判断所述需要调用的插件是否包含在多个插件中，如果是，则调用所述需要调用的插件来完成相应功能处理。

在一些实施例中，还包括：每个用户通过提交插件使用申请确定该用户要使用的插件；以及仅将每个用户要使用的插件集成到安装包中发送到该用户的终端，以便于在该用户的终端上仅存在该用户要使用的插件。

在一些实施例中，所述媒体相关访问请求包含功能标识，则所述根据所述媒体相关访问请求确定需要调用的插件包括：基于所述功能标识获得对应的插件执行链，并从所述插件执行链中获得所述需要调用的插件以及所述需要调用的插件之间的执行顺序和信息传递方式。

在一些实施例中，还包括：在每个用户的终端上，在系统初始化阶段，将该用户要使用的插件加载到内存中进行实例化和初始化。

在一些实施例中，还包括：生成插件列表，所述插件列表的多个节点分别对应于该用户要使用的插件，每个节点至少包括插件标识和实例化句柄，从而在调用插件时通过对应的实例化句柄进行调用。

在一些实施例中，还包括：在系统初始化阶段，进行插件依赖性检查和/或功能依赖性检查。

在一些实施例中，所述安装包中的插件为JAVA字节码文件，则所述调用所述需要调用的插件来完成相应功能处理包括：利用JAVA的反射机制来完成插件调用。

在一些实施例中，还包括：记录所述插件执行链中的每个插件的输入输出数据，并记录每个插件的执行结果。

在一些实施例中，每个用户要使用的插件为由该用户发布的插件，所述媒体请求处理方法还包括：接收插件规范检索请求，并基于所述插件规范请求提供插件定义规范，以便于该用户发布符合插件规范的插件。

第二方面，本公开一种跨平台引擎系统，包括：

媒体功能处理模块，用于接收用户的媒体相关访问请求，根据所述媒体相关访问请求确定需要调用的插件，判断所述需要调用的插件是否在多个插件中，如果是，则调用所述需要调用的插件来完成相应功能处理；

插件管理器，用于管理和维护所述多个插件。

第三方面，本公开提供一种电子设备，包括存储器和处理器，所述存储器还存储有可由所述处理器执行的计算机指令，所述计算机指令被执行时，实现上述任一项所述的媒体请求处理方法。

第四方面，本公开提供一种计算机可读介质，所述计算机可读介质存储有可由电子设备执行的计算机指令，所述计算机指令被执行时，实现上述任一项所述的媒体请求处理方法。

本公开实施例的技术方案将视音频处理能力插件化，基于媒体相关请求确定需要调用的插件并组装需要调用的插件以完成媒体相应功能处理，如此可解决SDK过于庞大的问题。进一步地，仅将每个用户要使用的插件集成到发送给该用户终端的安装包里，以便于在该用户的终端上仅存在该用户要使用的插件，以此降低该用户终端上的性能压力。

附图说明

通过参考以下附图对本公开实施例的描述，本公开的上述以及其它目的、特征和优点将更为清楚，在附图中：

图1是用于示意本公开实施例的理念的系统架构图；

图2是用户的媒体系统接入到网络的场景示意图；

图3为一个用于实施本公开实施例的示例性的智能手机的结构示意图；

图4A是本公开实施例的跨平台引擎和媒体系统的交互流程图；

图4B是本公开实施例的跨平台引擎和终端的集成开发环境的交互流程图；

图5A是跨平台引擎在初始化阶段加载要使用的插件的流程图；

图5B是跨平台引擎基于图5A所构建的插件列表执行图4A中的步骤S04和S05的流程图；

图6是本公开实施例提供一种跨平台引擎系统的示意图。

具体实施方式

以下基于实施例对本公开进行描述，但是本公开并不仅仅限于这些实施例。在下文对本公开的细节描述中，详尽描述了一些特定的细节部分。对本领域技术人员来说没有这些细节部分的描述也可以完全理解本公开。为了避免混淆本公开的实质，公知的方法、过程、流程没有详细叙述。另外附图不一定是按比例绘制的。

在介绍本公开的各个实施例之前，先介绍本公开实施例的核心理念。

参考背景技术所述，传统的媒体系统是由软件服务提供商向企业内的开发人员提供SDK工具包，在工具包内封装实现各种媒体能力的多个功能模块，用户根据所需媒体能力调用相应功能模块。这种方法的坏处在于随着用户要求的媒体能力变多，工具包变得越来越大。为了解决这一问题，本公开提出一个理念：媒体能力插件化。具体而言，如图1所示，跨平台引擎100包括能够支持各种终端操作系统的跨平台应用层，各种终端操作系统包括但不局限于图上示出的android、ios、windows、mac等终端操作系统，跨平台应用层从用户的媒体系统接收媒体相关访问请求并根据请求完成相应功能处理，其中用于支持跨平台应用层进行功能处理的是各种插件，这就是媒体能力插件化的理念所在，即将媒体能力分解成一个个插件并将通过插件管理器管理起来，以便于跨平台应用层根据处理逻辑从插件管理器调用所需插件来完成相应功能处理。每个插件可以独立编译打包，参考图上所示，直播是直播原子能力的插件，连麦是用于实时通信的插件，互动是弹幕或聊天的插件，白板是用于展示PPT、白板的插件。

同时对于每个用户而言，自身的媒体系统在其终端上运行，跨平台引擎和插件管理器是运行自身的媒体系统所必需的包文件，但是所有插件中只有一部分插件为该用户需要使用的插件，因此没有必要将所有插件都部署到其终端上，仅部署该用户需要的插件即可。

进一步地，软件服务提供商可向企业内的开发人员提供各种插件的规范(包括功能、输入输出等)，企业内的开发人员需要的个性化插件，软件服务提供商无法提供，则由企业内的开发人员构建并发布到插件管理器中，这类插件仅在该用户所在的媒体系统中使用不会发布给其他用户。

图2是用户的媒体系统接入到网络的场景示意图。如图上所示，该场景200示出了两种将媒体视频流提供给观众终端的两种方式。一种方式中，用户终端203将生成的媒体视频流经由网络201通过内容分发网络(CDN)202提供给观众终端205，另一种方式中，用户终端203将生成的自媒体视频流经由网络201提供给自媒体软件204，由自媒体软件204提供给观众终端205。

网络201为基于交换信号实现的各种通信技术之一或多种通信技术的组合，包括但不限于采用电和/或光传导线缆的有线技术，以及采用红外、射频和/或其它形式的无线技术。在不同的应用场景下，网络201可以是互联网、广域网或局域网，例如为公司的专有网络。网络201还可以为有线网络或无线网络。

内容分发网络202利用就近原则向各个节点推送视频流。通过内容分发网络，能够将视频制作者(对应于图上的用户终端203)发布的媒体视频流快速推送给各个观众(对应于图上的观众终端205)。

自媒体软件204是指目前已经商业化、用户可通过其发布视频的软件，例如微博。这样的软件提供一套完整的视频发布流程，用户可将视频发布到软件上，观众终端205可通过软件观看视频。当然，自媒体软件204的系统架构也可以基于内容发布网络来构建。

用户终端203用于运行根据图1所示的理念构建的跨平台引擎2032和媒体系统2031。跨平台引擎2032在特定用户终端上运行时仅管理该特定用户需要使用的插件。跨平台引擎2032从媒体系统2031接收媒体相关访问请求，并基于媒体相关访问请求获取要调用的插件并执行插件以完成相应媒体处理。媒体系统2031用于组织数据以生成媒体相关访问请求。媒体系统2031如果为直播或在线课堂等实时系统，则可以从观众终端205和视频制作者收集各种指示以生成媒体相关访问请求，如果是录播等非实时系统，则可以从视频制作者收集各种指示以生成媒体相关访问请求。

对用户终端203的类型不作限定，它可以为例如智能手机、台式机、笔记本、PAD等设备。以用户终端为智能手机为例。图3为一个示例性的智能手机的结构示意图。智能手机300包括：处理器301、输入单元302、显示单元303、传感器304、音频设备305、短距离通讯模块306、移动通讯模块307、电源308、存储器309。但本领域技术人员可以理解，图3中示出的手机结构并不构成对手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面结合图3对手机的各个构成部件进行具体的介绍。

输入单元302用于接收输入的数字或字符信息，以及产生与手机300的用户设置以及功能控制有关的键信号输入。具体地，输入单元302可包括触摸屏。触摸屏可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控屏上或在触控屏附近的操作)，并根据预先设定的程式驱动相应的连接装置，连接装置将触摸操作转换为触点坐标，送给处理器301。除了触摸屏之外，输入单元302还可以包括其他输入设备，例如摄像头,摄像头的位置可以为前置的，也可以为后置的，本申请实施例对此不作限定。此外，其他输入设备还可包括物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元303可用于显示由用户输入的信息或提供给用户的信息以及各种界面。显示单元可包括显示面板，显示面板可以采用液晶显示器(Liquid Crystal Disp lay，LCD)、有机发光二极管(Organic Light-Emitting Diode,OLED)等形式来配置。进一步地，触控屏可覆盖显示面板，当触控屏检测到在其上或附近的触摸操作后，传送给处理器301以确定触摸事件的类型，随后处理器301根据触摸事件的类型在显示面板上提供相应的视觉输出，因此虽然在图中，显示单元和输入单元作为两个独立的部件示出，但是实际上手机的输入输出功能是可以集成为一个部件的。手机300还可包括至少一种传感器304，比如光传感器、运动传感器以及其他传感器，在此不再赘述。

音频设备305用于收集音频数据并存储到存储器109中以制作媒体视频流，以及播放视频流中的声音信息。

短距离通讯模块306例如为WiFi模块、蓝牙模块等。WiFi模块用于无线的宽带互联网访问。蓝牙模块用于在不同机器之间通过蓝牙协议进行信号收发。

移动通讯模块307用于基于移动通讯协议进行信号接收和发送，特别地，将基站的下行信号接收后提供给处理器301处理，另外，将上行数据发送给基站。移动通讯模块307包括但不限于天线、至少一个放大器、收发信机、耦合器、双工器等。移动通讯模块307还可使用任一通信标准或协议与其他设备进行通信，包括但不限于全球移动通讯系统(GSM)、通用分组无线服务(GPRS)、码分多址(CDMA)、宽带码分多址(WCDMA)、长期演进(LTE))、电子邮件、短消息服务(Short Messaging Service，SMS)等。

电源308用于向系统供电。优选的，电源可以通过电源管理系统与处理器301逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。

存储器309可用于存储软件程序以及模块。处理器301是手机300的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器309内的软件程序和/或模块，以及调用存储在存储器309内的数据，执行手机的各种功能和处理数据。存储器309存储的软件程序和模块包括：操作系统、用户界面和应用程序等。特别地，根据本公开实施例，存储器309存储的软件程序还包括基于本公开的上述理念构建的跨平台引擎2032和媒体系统2031的代码。处理器301在运行相应代码时，能够生成媒体视频流。众所周知，目前智能手机支持的两大主流的操作系统有Android操作系统和苹果ios操作系统，再加上到其他电子设备所运行的操作系统类型和版本，因此跨平台引擎2032需要支持众多操作系统类型和版本。但同时，特定用户要使用的个性化插件只部署在该用户的终端上，这样的插件无需支持众多操作系统类型和版本，仅支持该用户终端所运行的操作系统和版本即可。

图4A是本公开实施例的跨平台引擎和媒体系统的交互流程图，该交互流程图描述在特定用户的终端上运行的跨平台引擎和媒体系统之间的交互关系，具体可结合图1所示。

在步骤S01中，跨平台引擎2032中的插件管理器管理特定用户要使用的插件。

在步骤S02中，媒体系统2031发送媒体相关访问请求。

在步骤S03中，跨平台引擎2032中的跨平台应用层根据媒体相关访问请求确定需要调用的插件。

在步骤S04中，跨平台引擎2032中的跨平台应用层判断需要调用的插件是否存在于要使用的插件中，如果是，执行步骤S05和S06，如果否，则可将不具有相关插件的信息反馈给媒体系统2031。

在步骤S05中，跨平台引擎2032中的跨平台应用层调用相应插件来完成相应功能处理。

在步骤S06中，跨平台引擎2032中的跨平台应用层将完成相应功能处理产生的媒体视频流发送给媒体系统2031。

在本公开中，可使用插件管理器管理所有用户需要使用的插件，但是在特定用户的终端上，插件管理器只管理该用户要使用的插件。其中，插件管理器所执行的管理包括但不限于以下操作：首先维护插件索引信息(包含增加、删除和修改各个插件的索引信息)；维护各个插件的实体，插件本质上是一些可独立编译打包的代码文件，在索引信息中，插件目录指示每个插件对应的代码文件所存在的文件夹，由此维护各个插件的实体就是维护存放在插件目录下的代码文件(包括将新增插件对应的代码文件存放新生成的插件目录下，以及从对应插件目录一并删除代码文件和插件目录等等)。

在本公开中，可使用跨平台应用层根据媒体相关访问请求确定需要调用的插件。即跨平台应用层接收到媒体系统发送的媒体相关访问请求。在本实施例中，该请求并未直接指定需要调用的插件，而是指示需要完成的媒体能力，由此跨平台应用层可预先维护媒体能力与插件执行链之间的对应关系，当接收到媒体相关访问请求时，基于其指示的媒体能力检索对应关系，以得到对应的插件执行链，由对应的插件执行链可得到需要调用的多个插件的插件标识以及所述多个插件之间的执行顺序和信息传递方法，进而，跨平台应用层检索插件索引信息确定相应插件是否都存在，如果是，得到相应插件的插件目录，进而加载并调用相应插件完成功能处理。但在另一实施例中，媒体系统向跨平台应用层发送的请求可直接包含插件标识，相应地，跨平台应用层采用该标识检索插件索引信息确定对应插件存在并得到插件目录，然后跨平台应用层从对应的插件目录中加载并执行该插件来完成相应功能处理。

在一些实施例中，为了方便插件间的信息传递，插件执行链中的每个插件将其他插件所需的信息存储在全局变量中以方便其他插件读取。

图4B是本公开实施例的跨平台引擎和终端的集成开发环境的交互流程图。如图上所示，包括以下步骤。

在步骤S11和S12中，用户经由集成开发环境2033构建插件并将插件发布到跨平台引擎2032。

在步骤S13中，用户终端发送插件使用申请，插件使用申请指示该用户要使用的插件，该用户要使用的插件可以是经由步骤S11和S12自行发布到插件管理器中的插件，也可以是插件管理器中已有的插件。

在步骤S14中，只将要使用的插件集成到安装包内。

在步骤S15中，将安装包发布到对应用户的终端中。

集成开发环境(IDE)是用于提供程序开发环境的研发工具软件，一般包括代码编辑器、编译器、调试器和图形用户界面等工具、集成了代码编写、代码编译、代码调试等一体化的研发功能。在本实施例中，关于插件的发布和申请都是在集成开发环境中进行，即用户采用IDE研发插件并发布到跨平台引擎的IDE中，用户在自身的IDE发送要使用的插件申请，跨平台引擎的IDE接收插件申请并根据插件申请为用户打包安装包并将安装包发布到对应用户的终端中。参考图1所示，多个用户终端各自接收的安装包内可包含相同的跨平台应用层、插件管理器但不同的插件(每个用户的终端上仅存在自身所要使用的插件)。当然，本实施例的上述操作并不是必须在集成开发环境中完成，用户也可以以其他方式，例如其他开发软件或在自身的媒体系统中，完成上述操作。

在一些实施例中，插件管理器还维护所需的插件规范，并通过一定方法将插件规范提供用户，因此每个插件都对应一个插件配置文件，该插件配置文件可以指定但不限于以下信息：插件标识、插件里包含的各种类的名称、每个类中包含的各种类方法和变量的名称、每个类方法的输入输出参数，在图4B所示的用户终端的集成开发环境2033中，用户可以从跨平台引擎的IDE环境2034获取插件配置文件，并根据配置文件构建插件(即图4B中的步骤S11之前是获取插件配置文件)。

图5A是跨平台引擎在初始化阶段加载要使用的插件的流程图。如图上所示包括以下步骤。

在步骤S501中，读取每个要使用的插件的索引信息。

在步骤S502中，对于每个插件，扫描对应的插件目录。

在步骤S503中，判断是否存在对应插件，如果是，则执行步骤S504，如果否，则系统退出并反馈异常。

在步骤S504中，将插件加载到内存中。

在步骤S505中，插件实例化、初始化。

在步骤S506中，将已加载的插件信息添加到插件列表中。

图5B是跨平台引擎2032基于图5A所构建的插件列表执行图4A中的步骤S04和S05的流程图。如图上所示，包括以下步骤。

在步骤S511中，对于每个需要调用的插件，检索插件列表。

在步骤S512中，判断插件列表中是否存在对应插件，如果是，则执行步骤S513。

在步骤S513中，获取对应插件的实例化句柄，并基于句柄调用插件中的类方法。

根据本实施例，跨平台引擎2032在初始化时将所有要使用的插件加载内存中并完成实例化和初始化，并建立已完成实例化和初始化的插件列表，由此，跨平台引擎2032在接收到媒体相关访问请求时，可检索插件列表以确定某个插件是否存在，并在该插件存在时执行该插件。可选地，插件列表可包括插件标识和实例化的句柄，从而可通过实例化的句柄访问插件中的类方法。

应该理解，本实施例中，跨平台引擎2032确定需要调用的插件后，由于已经在初始化阶段将各个插件进行了实例化和初始化，因此可以直接调用插件中的类方法，和跨平台引擎2032在确定需要调用的插件后再实例化和初始化需要调用的插件相比，向媒体系统2031提供反馈的时间更短，这也是该实施例的优势所在。

在一些实施例中，在图5A所示的系统初始化阶段，还应该包括根据每个插件执行链进行插件依赖性检查和功能依赖性检查。插件依赖性为，在实现过程中，对于那些需要其他插件的参与才能实现自身功能的插件，在构建插件列表之前或者之后，需要检查该插件所依赖的其他插件是否存在。具体地，以某个媒体能力，该媒体能力对应的标识为ID1，通过ID1检索插件执行链，得到插件A、B、C、D，则功能依赖性检查就是检查A、B、C、D是否都已初始化，而对于插件A而言，插件A中需要调用插件1、2、3和4，则插件依赖性检查而言就是检查插件1、2、3和4是否都已初始化，因此该媒体能力对应的插件执行链可表示为A(1、2、3、4)、B、C、D。但是这种方式需要深入到每个插件的代码中去确认该插件是否依赖其他插件，而且如果插件依赖关系是动态的，则可能只有在执行时才得到，例如，A可能依赖1、2和3，也可能依赖2、3和4，只有到真正执行A时才能确定，因此系统初始化阶段检查插件依赖性比较复杂，因而也可在系统初始化时只检查功能依赖性。

在一些实施例中，提供给用户的安装包内只包括可执行文件。例如对于JAVA语言，其对应的可执行文件为字节码文件(CLASS文件)，为了在图5A所示的系统初始化阶段，调用字节码文件中的方法和属性，必须利用JAVA反射机制才能够实现调用。JAVA反射机制的核心是在程序运行时动态加载类并获取类的详细信息，从而操作类或对象的属性和方法。

在一些实施例中，跨平台引擎在接收到媒体系统提供的媒体相关访问请求后，可先对该用户的身份进行认证，如果认证通过，则可向该系统提供访问服务，否则拒绝提供访问服务。具体地，跨平台引擎还可包括一个鉴权模块，用户在第一次发布或申请插件时，向跨平台引擎提供身份信息，通过鉴权模块存储身份信息，并在用户使用媒体系统发送媒体相关访问请求时，进行身份认证。同样，对于跨平台引擎提供的通用插件，只有通过身份认证的用户才可以使用。

在一些实施例中，跨平台引擎2032还提供日志功能。例如，对于上述的标识ID1的处理过程，记录所述插件执行链中的每个插件的输入输出数据，并记录每个插件的执行结果以提供给用户查看。

与上述方法相对应地，本公开实施例提供一种跨平台引擎系统，如图6所示，该系统包括媒体功能处理模块601和插件管理器602。

媒体功能处理模块601用于接收媒体相关访问请求，根据媒体相关访问请求确定需要调用的插件，以及判断需要调用的插件是否在所有要使用的插件中，如果是，则调用所述需要调用的插件来完成相应功能处理。

插件管理器602用于管理和维护要使用的插件。

本公开实施例提供的方法，对传统的音视频处理进行了场景化封装，让接口更加简单易用，解决了客户接入成本大的问题，该方案将媒体能力插件化，并在用户需要时，组织成媒体功能处理模块，从而可以进行扩展，扩展能力强。而且插件迭代周期短，有利于更新。

应该理解，本公开实施例提到的插件来自两个方面：软件提供商向用户提供跨平台引擎时，同时提供一些用于媒体能力实现的基础插件；用户终端在设计自身个性化需求时，向跨平台引擎发布自身所需的个性化插件。可以两者结合，也可以所有插件只来自其中一个方面，无论何种，都不影响本公开实施例的实施和获得的技术效果。

本领域的技术人员能够理解，本公开可以实现为系统、方法和计算机程序产品。因此，本公开可以具体实现为以下形式，即完全的硬件、完全的软件(包括固件、驻留软件、微代码)，还可以实现为软件和硬件结合的形式。此外，在一些实施例中，本公开还可以实现为一个或多个计算机可读介质中的计算机程序产品的形式，该计算机可读介质中包含计算机可读的程序代码。

可以采用一个或多个计算机可读介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如但不限于为电、磁、光、电磁、红外线或半导体的系统、装置或器件，或其他任意以上的组合。计算机可读存储介质的更具体的例子包括：具体一个或多个导线的电连接，便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或者闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器、磁存储器或者上述任意合适的组合。在本文中，计算机可读的存储介质可以是任意包含或存储程序的有形介质，该程序可以被处理单元、装置或者器件使用，或者与其结合使用。

计算机可读信号介质可以包括在基带中或者作为截波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或者其他任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质之外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令系统、装置或器件使用或者与其结合使用的程序。

计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、电线、光缆、RF等等，以及上述任意合适的组合。

可以以一种或者多种程序设计语言或者组合来编写用于执行本公开实施例的计算机程序代码。所述程序设计语言包括面向对象的程序设计语言，例如JAVA、C++，还可以包括常规的过程式程序设计语言，例如C。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络包括局域网(LAN)或广域网(WAN)连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

以上所述仅为本公开的优选实施例，并不用于限制本公开，对于本领域技术人员而言，本公开可以有各种改动和变化。凡在本公开的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本公开的保护范围之内。

Claims (11)

1.一种媒体请求处理方法，包括：

根据用户的媒体相关访问请求，确定需要调用的插件；

判断所述需要调用的插件是否包含在多个插件中，如果是，则调用所述需要调用的插件来完成相应功能处理，其中，所述多个插件集成在安装包中，并且通过以下步骤获得所述安装包：

经由用户终端的IDE环境向跨平台引擎的IDE环境发布个性化插件；

经由用户终端的IDE环境发送插件使用申请，所述插件使用申请指示用户要使用的插件；

经由所述跨平台引擎的IDE环境仅打包用户要使用的插件到所述安装包中，并将所述安装包发布到对应的用户终端中，所述用户要使用的插件包括实现媒体能力的基础插件和所述个性化插件。

2.根据权利要求1所述的媒体请求处理方法，其中，所述媒体相关访问请求包含功能标识，则所述根据所述媒体相关访问请求确定需要调用的插件包括：基于所述功能标识获得对应的插件执行链，并从所述插件执行链中获得所述需要调用的插件以及所述需要调用的插件之间的执行顺序和信息传递方式。

3.根据权利要求1所述的媒体请求处理方法，还包括：在对应的用户终端，在系统初始化阶段，将所述用户要使用的插件加载到内存中进行实例化和初始化。

4.根据权利要求3所述的媒体请求处理方法，还包括：生成插件列表，所述插件列表的多个节点分别对应于所述用户要使用的插件，每个节点至少包括插件标识和实例化句柄，从而在调用插件时通过对应的实例化句柄进行调用。

5.根据权利要求3所述的媒体请求处理方法，还包括：在系统初始化阶段，进行插件依赖性检查和/或功能依赖性检查。

6.根据权利要求1所述的媒体请求处理方法，其中，所述安装包中的插件为JAVA字节码文件，则所述调用所述需要调用的插件来完成相应功能处理包括：利用JAVA的反射机制来完成插件调用。

7.根据权利要求2所述的媒体请求处理方法，还包括：记录所述插件执行链中的每个插件的输入输出数据，并记录每个插件的执行结果。

8.根据权利要求1所述的媒体请求处理方法，还包括：接收插件规范检索请求，并基于所述插件规范请求提供插件定义规范，以便于用户发布符合插件规范的个性化插件。

9.一种跨平台引擎系统，包括：

媒体功能处理模块，用于接收用户的媒体相关访问请求，根据所述媒体相关访问请求确定需要调用的插件，判断所述需要调用的插件是否在多个插件中，如果是，则调用所述需要调用的插件来完成相应功能处理；

插件管理器，用于管理和维护所述多个插件，所述多个插件集成在安装包中，并且通过以下步骤获得所述安装包：经由用户终端的IDE环境向跨平台引擎的IDE环境发布个性化插件；经由用户终端的IDE环境发送插件使用申请，所述插件使用申请指示用户要使用的插件；经由所述跨平台引擎的IDE环境仅打包用户要使用的插件到所述安装包中，并将所述安装包发布到对应的用户终端中，所述用户要使用的插件包括实现媒体能力的基础插件和所述个性化插件。

10.一种电子设备，包括存储器和处理器，所述存储器还存储有可由所述处理器执行的计算机指令，所述计算机指令被执行时，实现如权利要求1至8任一项所述的媒体请求处理方法。

11.一种计算机可读介质，所述计算机可读介质存储有可由电子设备执行的计算机指令，所述计算机指令被执行时，实现如权利要求1至8任一项所述的媒体请求处理方法。