CN110297675A - 模块间相互调用的方法、装置、电子设备及存储介质 - Google Patents

Abstract

本发明提供了一种模块间相互调用的方法、装置、电子设备及存储介质，其中，所述模块间相互调用的方法包括：接收当前业务模块发送的调用请求；按照预设发送顺序，向各待调用业务模块发送所述调用请求；接收所述待调用业务模块的响应结果；如果所述响应结果为可以处理，则生成终止指令；向所述当前业务模块发送目标业务模块返回的反馈值。本申请所提供的模块间相互调用的方法能够有效解决现有模块运行脚本时无法实现模块间完全隔离的问题。

Description

模块间相互调用的方法、装置、电子设备及存储介质

技术领域

本申请涉及用户界面开发技术领域，尤其涉及一种模块间相互调用的方法、装置、电子设备及存储介质。

背景技术

在UI(User Interface，用户界面)的开发过程中，为了能够动态高效地更新UI，通常选择使用Webview来展示UI，Webview在展示UI的过程中会与相关原生应用发生交 互，这就需要提前注入能够调用该原生应用运行的调用方法，以及该原生应用对应的业 务逻辑。在更新并展示一个UI时，通常需要调用大量的原生应用，一旦原生应用的调用 方法出现逻辑混乱的问题，就会导致UI展示卡顿。因此，有序管理各个调用方法是实现 快速更新和展示UI的基础。

为避免调用方法出现逻辑混乱，通常会采用模块化技术实现对原生应用的调用。模 块化技术的核心是要求所有模块之间完全隔离，以达到分别管理的效果，从而保证各个原生应用相应调用方法的有序性。技术人员会根据需要建立若干模块，每个模块对应一 种原生应用，并在模块中写入相应的原生应用的业务逻辑。若要展示一个UI，需要调用 各种原生应用，通过调用各种模块即可实现。例如，用户想要查看一个附近工作推荐界 面，如果该界面需要展示二维平面地图，并在地图上展示用户的当前位置，以及用户附 近的工作信息；在该附近工作推荐界面在展示的过程中，在运行本身界面展示模块的脚 本的基础上，需要调用地图展示应用来展示二维平面地图，调用定位应用来展示用户的 当前位置，调用信息获取应用来展示用户附近的工作信息。相应地，若要正常运行界面 展示模块展示该附近工作界面，就需要调用地图展示模块、定位模块和调用信息模块。

虽然在形式上，各原生应用的业务逻辑按照模块被隔离开，当前模块只需通过使用 相应的调用方法，即可调用相关模块，但是在运行过程中，当前模块调用相关模块的过程，实际上是通过执行当前模块的脚本实现的，而如果想要实现调用，就需要在当前模 块的脚本中写入相关模块的调用方法和业务逻辑，这也就出现了当前模块的脚本与各相 关模块之间的交互。可见，在脚本层面，各模块之间仍然无法实现完全隔离。

发明内容

本申请提供了一种模块间相互调用的方法、装置、电子设备及存储介质，以解决现有模块运行脚本时无法实现模块间完全隔离的问题。

第一方面，本发明实施例提供了一种模块间相互调用的方法，包括：

接收当前业务模块发送的调用请求，所述调用请求用于调用相应的业务模块；

按照预设发送顺序，向各待调用业务模块发送所述调用请求，所述待调用业务模块 为存储于模块层中的业务模块；

接收所述待调用业务模块的响应结果；

如果所述响应结果为可以处理，则生成终止指令，所述终止指令为终止发送所述调 用请求至余下的待调用业务模块；

向所述当前业务模块发送目标业务模块返回的反馈值，所述目标业务模块为可以处 理所述调用请求的待调用业务模块。

在本发明实施例第一方面一种可能的实现方式中，所述接收当前业务模块发送的调 用请求之前包括：

针对每一个业务模块，建立一个相应的JS引擎管理器，所述JS引擎管理器设置于H5容器层，且用于分发相应业务模块的调用请求。

在本发明实施例第一方面一种可能的实现方式中，所述接收当前业务模块发送的调 用请求之前还包括：

获取各JS引擎在H5容器层中的注册时间，所述JS引擎用于处理业务模块相应的调用方法；

以所述注册时间从先到后的顺序，生成预设发送顺序。

在本发明实施例第一方面一种可能的实现方式中，所述以注册时间从先到后的顺序， 生成预设发送顺序之后包括：

按照所述预设发送顺序，生成发送列表，所述发送列表包括发送次序及其对应的JS 引擎。

在本发明实施例第一方面一种可能的实现方式中，接收所述待调用业务模块的响应 结果之后还包括：

如果所述响应结果为不可以处理，则继续向模块层中余下的待调用业务模块发送所 述调用请求，直至接收到可以处理的响应结果。

在本发明实施例第一方面一种可能的实现方式中，所述如果响应结果为不可以处理， 则继续向模块层中余下的待调用业务模块发送调用请求，直至接收到可以处理的响应结 果之后包括：

确定待删除JS引擎，所述待删除JS引擎为不可以处理当前业务模块发送的调用请求的JS引擎；

从所述发送列表中删除所述待删除JS引擎及其对应的发送次序，得到待更新发送列 表，所述待更新发送列表包括余下的可用JS引擎及其对应的发送次序；

以所述注册时间从先到后的顺序，将所述可用JS引擎所对应的发送次序替换为连续 编号，得到更新后的发送列表。

第二方面，本发明实施例提供了一种模块间相互调用的装置，所述装置包括：

调用请求接收单元，用于接收当前业务模块发送的调用请求，所述调用请求用于调 用相应的业务模块；

分发单元，用于按照预设发送顺序，向各待调用业务模块发送所述调用请求，所述待调用业务模块为存储于模块层中的业务模块；

响应结果接收单元，用于接收所述待调用业务模块的响应结果；

终止指令生成单元，用于如果所述响应结果为可以处理，则生成终止指令，所述终止指令为终止发送所述调用请求至余下的待调用业务模块；

结果反馈单元，用于向所述当前业务模块发送目标业务模块返回的反馈值，所述目 标业务模块为可以处理所述调用请求的待调用业务模块。

在本发明实施例第二方面一种可能的实现方式中，所述装置还包括：

管理器建立单元，用于针对每一个业务模块，建立一个相应的JS引擎管理器，所述JS引擎管理器设置于H5容器层，且用于分发相应业务模块的调用请求。

在本发明实施例第二方面一种可能的实现方式中，所述装置还包括：

注册时间获取单元，用于获取各JS引擎在H5容器层中的注册时间，所述JS引擎用于处理业务模块相应的调用方法；

发送顺序生成单元，用于以所述注册时间从先到后的顺序，生成预设发送顺序。

在本发明实施例第二方面一种可能的实现方式中，所述装置还包括：

发送列表生成单元，用于按照所述预设发送顺序，生成发送列表，所述发送列表包括发送次序及其对应的JS引擎。

在本发明实施例第二方面一种可能的实现方式中，所述装置还包括：

继续发送单元，用于如果所述响应结果为不可以处理，则继续向模块层中余下的待 调用业务模块发送所述调用请求，直至接收到可以处理的响应结果。

在本发明实施例第二方面一种可能的实现方式中，所述装置还包括：

待删除JS引擎确定单元，用于确定待删除JS引擎，所述待删除JS引擎为不可以处理当前业务模块发送的调用请求的JS引擎；

删除单元，用于从所述发送列表中删除所述待删除JS引擎及其对应的发送次序，得 到待更新发送列表，所述待更新发送列表包括余下的可用JS引擎及其对应的发送次序；

更新单元，用于以所述注册时间从先到后的顺序，将所述可用JS引擎所对应的发送 次序替换为连续编号，得到更新后的发送列表。

第三方面，本发明实施例提供了一种电子设备，包括：

处理器，以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行所述的模块间相互调用的 方法。

第四方面，本发明实施例提供了一种计算机可读存储介质，其上存储有计算机程序， 所述计算机程序被处理器执行时实现所述的模块间相互调用的方法。

本发明实施例提供的模块间相互调用的方法、装置、电子设备及存储介质，其中，在模块间相互调用的方法中，接收当前业务模块发送的调用请求；按照预设发送顺序， 向各待调用业务模块发送所述调用请求；接收所述待调用业务模块的响应结果；如果所 述响应结果为可以处理，则生成终止指令；向所述当前业务模块发送目标业务模块返回 的反馈值。当前业务模块发送调用请求至JS引擎管理器，JS引擎管理器根据内置的预 设发送顺序，将所述调用请求依次发送至各待调用业务模块，询问各待调用业务模块是 否能够处理所述调用请求。各待调用业务模块将响应结果反馈至JS引擎管理器，JS引 擎管理器根据响应结果做出判断和动作，如果待调用业务模块的响应结果为可以处理， 那么JS引擎管理器就停止继续发送调用请求至余下的待调用业务模块，并且由该目标业 务模块处理调用请求。目标业务模块将处理调用请求之后的反馈值返回给JS引擎管理器， 再由JS引擎管理器将该反馈值发送至当前业务模块，从而令当前业务模块完成对所述调 用请求对应的业务模块的调用动作。可见，本发明所提供的模块间相互调用方法中，当 前模块发出调用其他业务模块的调用请求之后，由JS引擎管理器将该调用请求发送至有 能力处理的待调用业务模块，并在该待调用业务模块内处理该调用请求，而当前业务模 块只是直接利用该待调用业务模块处理调用请求之后的反馈值，从而实现了各业务模块 只处理自身的业务逻辑，无需在业务逻辑上与其他业务逻辑相耦合，而各个业务模块之 间通过JS引擎处理器传递请求与结果，进而真正实现各业务模块之间的隔离。

附图说明

为了更清楚地说明本申请的技术方案，下面将对实施例中所需要使用的附图作简单 地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的模块间相互调用的方法的流程示意图；

图2为本发明实施例提供的模块间相互调用的场景示意图；

图3为本发明实施例提供的一种生成预设发送顺序的方法的流程示意图；

图4为本发明实施例提供的一种更新发送列表的方法的流程示意图；

图5为本发明实施例提供的一种更新发送列表的场景示意图；

图6为本发明实施例提供的模块间相互调用的装置的结构示意图；

图7为提供的模块间相互调用的装置的结构示意图；

图8为本发明实施例提供的电子设备的硬件结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整 的描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

图1为本发明实施例提供的模块间相互调用的方法的流程示意图。如图1所示，本实施例提供的模块间相互调用的方法包括：

S1、接收当前业务模块发送的调用请求，所述调用请求用于调用相应的业务模块。

当前业务模块是指当前时刻存在调用其他业务模块需求的业务模块。当前业务模块 在正常运行时，需要调用相关的业务模块实现功能上的支持，而调用其他的业务模块需要通过调用请求来实现。通常，调用请求包括相应业务模块的名称、所需实现的功能、 调用时间、实现数据传输的接口等信息。在本发明实施例中，当前业务模块将调用请求 发送至相应的JS引擎管理器，而JS引擎管理器对应接收调用请求，并启动分发状态。

S2、按照预设发送顺序，向各待调用业务模块发送所述调用请求，所述待调用业务模块为存储于模块层中的业务模块。

JS引擎管理器只要检测到存在已接收到，但是未发送的调用请求，就会立即发送该 调用请求至各待调用业务模块，以避免调用请求堆积，提高当前业务模块调用动作的效率。

JS引擎管理器按照内置的预设发送顺序，向各待调用业务模块发送调用请求。其中， 预设发送顺序可以为各待调用业务模块在JS引擎管理器中注册的先后顺序，即先发送至 注册时间最早的待调用业务模块，再依次发送至注册时间较晚的待调用业务模块；也可以为各待调用业务模块的当前空闲程度，即先发送至较空闲的待调用业务模块，再发送 至较繁忙的待调用业务模块；也可以为各待调用业务模块的处理质量高低，即先发送至 调用请求处理质量较高的业务模块，再发送至调用请求处理质量较低的业务模块等。但 是需要注意的是，无论采用何种预设发送顺序，均需保证调用请求一次只能发送至一个 待调用业务模块，然后在JS引擎管理器收到该待调用业务模块的响应结果之后，再判断 是否需要继续将该调用请求发送至下一个待调用业务模块，以此避免待调用业务模块对 调用请求出现处理混乱的问题，进而保证待调用业务模块处理调用请求的高效性和有效 性。

S3、接收所述待调用业务模块的响应结果。

在S2中的JS引擎管理器发送调用请求至待调用业务模块之后，主要是询问各待调用业务模块是否能够处理该调用请求。通常，待调用业务模块根据调用请求内的相应业 务模块的名称、所需实现的功能等，可以判断是否具有与该调用请求相应的处理能力。 如果待调用业务模块具有相应的处理能力，就会将可以处理作为响应结果；如果待调用 业务模块不具有相应的处理能力，就会将不可以处理作为响应结果。最后由待调用业务 模块将响应结果返回至JS引擎管理器。

S4、如果所述响应结果为可以处理，则生成终止指令，所述终止指令为终止发送所述调用请求至余下的待调用业务模块。

JS引擎管理器接收到由S3得到的响应结果后，会根据响应结果做出相应的动作。如果响应结果为可以处理，那么JS引擎管理器就会生成终止指令，并停止继续发送调用 请求至余下的待调用业务模块。

S5、向所述当前业务模块发送目标业务模块返回的反馈值，所述目标业务模块为可 以处理所述调用请求的待调用业务模块。

由S4可知，如果待调用业务模块可以处理调用请求，则将该调用业务模块确定为目 标业务模块，并由该目标业务模块处理调用请求，进而完成当前业务模块所要调用的目标业务模块的运行动作，并得到运行结果。目标业务模块将该运行结果作为反馈值返回 至JS引擎管理器，再由JS引擎管理器将该反馈值发送至当前业务模块，由当前业务模 块利用该反馈值维持正常运行，进而实现当前业务模块对目标业务模块的成功调用。

如图2所示，模块层中存储有各业务模块，Model A、Model B、Model C、Model D 和Model E，Model A需要调用其他的业务模块，因此，Model A即为当前业务模块，Model B、Model C、Model D和Model E即为待调用业务模块。Model A通过自身的脚本引擎(JSEngine A)实现运行，如果Model A发出调用请求c，则Model A首先将调用请求c 发送至Model A对应的JS引擎管理器(JSEnginesMgr A)，然后由JSEnginesMgr A将调 用请求c依次发送至各待调用业务模块，按照预设发送顺序，JSEnginesMgr A第一次将 调用请求c发送至Model B，但是Model B的响应结果为不可以处理，因此，JSEnginesMgr A第二次将调用请求c发送至Model C，此时，Model C的响应结果为可以处理，因此 JSEnginesMgr A不再继续发送调用请求c至Model D和Model E。Model C通过自身的 脚本引擎(JSEngine C)处理调用请求c，并得到反馈值c’，Model C将反馈值c’返 回至JSEnginesMgr A，再由JSEnginesMgr A将反馈值c’发送至Model A，供JSEngine A利用，进而完成Model A的调用动作。

可见，本发明所提供的模块间相互调用方法中，当前模块发出调用其他业务模块的 调用请求之后，由JS引擎管理器将该调用请求发送至有能力处理的待调用业务模块，并在该待调用业务模块内处理该调用请求，而当前业务模块只是直接利用该待调用业务模块处理调用请求之后的反馈值，从而实现了各业务模块只处理自身的业务逻辑，无需在 业务逻辑上与其他业务逻辑相耦合，而各个业务模块之间通过JS引擎处理器传递请求与 结果，进而真正实现各业务模块之间的隔离。

由S1～S5可知，JS引擎管理器是保证各业务模块在能够相互调用的基础上，实现各 业务模块的完全隔离的关键，只有保证JS引擎管理器能够有效传递调用请求和反馈值，才能保证业务模块的调用有效性，因此，JS引擎管理器的有效建立非常重要。

因此在S1之前，需要针对每一个业务模块，建立一个相应的JS引擎管理器，所述JS引擎管理器设置于H5容器层，且用于分发相应业务模块的调用请求。

本发明实施例所提供的JS引擎管理器设置于H5容器层，H5容器层能够为调用请求和反馈值提供传递的环境。本发明实施例所提供的JS引擎管理器一对一为业务模块提供传递调用请求和反馈值服务，如图2所示，JSEnginesMgr A只为Model A提供服务，JSEnginesMgr B只为Model B提供服务，JSEnginesMgr C只为Model C提供服务，JSEnginesMgr D只为Model D提供服务,JSEnginesMgr E只为Model E提供服务。因此， 能够避免出现JS引擎管理器同时服务于多个业务模块时，所产生的调用请求和反馈值的 堆积和分发顺序的问题，进而有效保证调用请求和反馈值的传递效率，同时保证传递的 准确率，而且能够通过JS引擎管理器所传递的信息之间相互隔离，进而保证各业务模块 之间相互隔离。

在S2中提到，JS引擎管理器按照预设发送顺序，向各待调用业务模块发送调用请求，以保证调用请求一次只能被发送至一个待调用业务模块。因此，为了保证调用请求 的有序发送，需要预先设定发送顺序。

图3展示了一种生成预设发送顺序的方法，包括：

S101、获取各JS引擎在H5容器层中的注册时间，所述JS引擎用于处理业务模块相应的调用方法；

S102、以所述注册时间从先到后的顺序，生成预设发送顺序。

对应于所要实现的功能，技术人员会设计各种业务模块，并在业务模块中写入相应 的JS引擎，以运行业务模块。对于各个业务模块在设计完成之后，需要被放入H5容器 层中，以方便业务模块之间的相互调用。而在业务模块被放入H5容器层时，同时需要将 该业务模块的JS引擎信息注册于H5容器层，此时，H5容器层中就会对应生成业务模块 的注册时间。因为每个业务模块的注册时间均不相同，因此利用注册时间，能够准确区 分各业务模块，因此，按照注册时间从先到后的顺序，作为预设发送顺序，能够有效保 证调用请求一次只被发送至一个待调用业务模块。可选地，也可以按照注册时间从后到 前的顺序，作为预设发送顺序。

在生成预设发送顺序之后，需要按照所述预设发送顺序，生成发送列表，所述发送列表包括发送次序及其对应的JS引擎。

同时将生成的发送列表存储于JS引擎管理器中，供JS引擎管理器按照发送列表的顺序，将调用请求依次发送至各待调用业务模块。如果更改JS引擎注册时的系统时间， 即可以更改JS引擎的注册时间，这样有可能令实际较晚注册的JS引擎的注册时间在其 他较早注册的JS引擎之前。例如JS引擎A的注册时间为2018年3月21日17:40，JS 引擎B在注册时的实际时间为2018年3月24日17:00，但是此时通过修改系统时间为 2018年2月14日17:40，令JS引擎B的注册时间更改为2018年2月14日17:40，从 而令JS引擎B的注册时间在JS引擎A之前。为了避免这种通过修改系统时间等手段， 扰乱JS引擎实际注册时间的问题，在获取JS引擎的注册时间之后，即生成发送列表， 令JS引擎管理器按照该发送列表发送调用请求，能够有效防止单纯按照注册时间发送调 用请求时，具有不真实注册时间的JS引擎被优先发送的问题。

同时，按照发送列表发送调用请求，能够进一步保证JS引擎管理器的发送逻辑性，防止重发、漏发等现象，提高处理调用请求的准确性。

由S3所得的待调用业务模块的响应结果可知，待调用业务模块的响应结果还包括不 可以处理，即待调用业务模块在接到调用请求之后，通过分析调用请求中的相应业务模块的名称、所需实现的功能等信息，确定不具有处理该调用请求的能力。

如图1所示，S6、如果所述响应结果为不可以处理，则继续向模块层中余下的待调用业务模块发送所述调用请求，直至接收到可以处理的响应结果。

此时，仍然按照预设发送顺序，继续向发送列表中余下的待调用业务模块发送调用 请求，并重复S3-S5的步骤，此处不再赘述。

由于JS引擎管理器按照发送列表发送调用请求至待调用业务模块，因此，需要保证 发送列表的有效性，即需要在发送列表中的待调用业务模块发生变动后，及时更新发送列表。

图4展示了一种更新发送列表的方法，包括：

S601、确定待删除JS引擎，所述待删除JS引擎为不可以处理当前业务模块发送的调用请求的JS引擎；

S602、从所述发送列表中删除所述待删除JS引擎及其对应的发送次序，得到待更新 发送列表，所述待更新发送列表包括余下的可用JS引擎及其对应的发送次序；

S603、以所述注册时间从先到后的顺序，将所述可用JS引擎所对应的发送次序替换 为连续编号，得到更新后的发送列表。

由以上技术方案可知，在H5容器层注册的JS引擎均会在发送列表中，因此，只要JS引擎管理器按照发送列表的顺序，就需要将调用请求逐一发送至每个JS引擎。如果发 送列表中包含大量不具备处理调用请求的JS引擎，那么JS引擎管理器就会进行大量无 效的传递信息的动作，浪费时间，且占用资源。因此，需要及时更新发送列表中的JS引 擎，将不可以处理当前业务模块发送的调用请求的待删除JS引擎删除，同时刷新发送列 表中余下JS引擎的编号，生成更新后的发送列表。如图5所示，左图为更新前的发送列 表，根据当前业务模块的脚本，当前业务模块需要发起调用请求b和调用请求d，其中， JS引擎A和JS引擎C为不可以处理当前业务模块发送的调用请求b或调用请求d的待 删除JS引擎。因此，需要将其删除，删除后刷新余下JS引擎B和JS引擎D的编号，得 到右图所示的更新后的发送列表。

需要注意的是，本实施例中更新发送列表的动作主要针对当前业务模块的脚本，其 中当前业务模块的脚本尤指未发生修改的脚本，因此，在此脚本中的调用请求是固定的， 更新后的发送列表能够与当前业务模块的调用请求良好匹配。一旦当前业务模块的脚本 发生了修改，则需要根据JS引擎的注册时间等条件重新生成发送列表，而不是更新发送列表。

图6为本发明实施例提供的模块间相互调用的装置的结构示意图，所述装置包括：调用请求接收单元1，用于接收当前业务模块发送的调用请求，所述调用请求用于调用 相应的业务模块；分发单元2，用于按照预设发送顺序，向各待调用业务模块发送所述 调用请求，所述待调用业务模块为存储于模块层中的业务模块；响应结果接收单元3， 用于接收所述待调用业务模块的响应结果；终止指令生成单元4，用于如果所述响应结 果为可以处理，则生成终止指令，所述终止指令为终止发送所述调用请求至余下的待调 用业务模块；结果反馈单元5，用于向所述当前业务模块发送目标业务模块返回的反馈 值，所述目标业务模块为可以处理所述调用请求的待调用业务模块。

进一步地，所述装置还包括：管理器建立单元11，用于针对每一个业务模块，建立一个相应的JS引擎管理器，所述JS引擎管理器设置于H5容器层，且用于分发相应业务 模块的调用请求。

进一步地，所述装置还包括：注册时间获取单元12，用于获取各JS引擎在H5容器层中的注册时间，所述JS引擎用于处理业务模块相应的调用方法；发送顺序生成单元 13，用于以所述注册时间从先到后的顺序，生成预设发送顺序。

进一步地，所述装置还包括：发送列表生成单元14，用于按照所述预设发送顺序，生成发送列表，所述发送列表包括发送次序及其对应的JS引擎。

进一步地，所述装置还包括：继续发送单元6，用于如果所述响应结果为不可以处理，则继续向模块层中余下的待调用业务模块发送所述调用请求，直至接收到可以处理 的响应结果。

如图7所示，为本发明实施例提供的一种发送列表的更新装置的结构示意图。所述装置包括：待删除JS引擎确定单元61，用于确定待删除JS引擎，所述待删除JS引擎 为不可以处理当前业务模块发送的调用请求的JS引擎；删除单元62，用于从所述发送 列表中删除所述待删除JS引擎及其对应的发送次序，得到待更新发送列表，所述待更新 发送列表包括余下的可用JS引擎及其对应的发送次序；更新单元63，用于以所述注册 时间从先到后的顺序，将所述可用JS引擎所对应的发送次序替换为连续编号，得到更新 后的发送列表。

图8为本发明实施例提供的电子设备的硬件结构示意图。该电子设备包括：存储器101和处理器102；

存储器101，用于存储计算机程序；

处理器102，用于执行存储器存储的计算机程序，以实现上述实施例中的流量数据监控方法。具体可以参见前述方法实施例中的相关描述。

可选地，存储器101既可以是独立的，也可以跟处理器102集成在一起。

当所述存储器101是独立于处理器102之外的器件时，所述电子设备还可以包括：

总线103，用于连接所述存储器101和处理器102。

本发明实施例提供的电子设备可用于执行上述实施例中任一所示的模块间相互调用 的方法，其实现方式和技术效果类似，本发明实施例此处不再赘述。

本发明实施例还提供一种可读存储介质，可读存储介质中存储有计算机程序，当消 息发送的装置的至少一个处理器执行该计算机程序时，消息发送的装置执行上述实施例 任一所述的训练样本保存方法。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过 程序指令相关的硬件来完成。前述的程序可以存储于以计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、 磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解，其 依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特 征进行等同替换，而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施 例技术方案的范围。

Claims (14)

1.一种模块间相互调用的方法，其特征在于，所述方法包括：

接收当前业务模块发送的调用请求，所述调用请求用于调用相应的业务模块；

按照预设发送顺序，向各待调用业务模块发送所述调用请求，所述待调用业务模块为存储于模块层中的业务模块；

接收所述待调用业务模块的响应结果；

如果所述响应结果为可以处理，则生成终止指令，所述终止指令为终止发送所述调用请求至余下的待调用业务模块；

向所述当前业务模块发送目标业务模块返回的反馈值，所述目标业务模块为可以处理所述调用请求的待调用业务模块。

2.根据权利要求1所述的方法，其特征在于，所述接收当前业务模块发送的调用请求之前包括：

针对每一个业务模块，建立一个相应的JS引擎管理器，所述JS引擎管理器设置于H5容器层，且用于分发相应业务模块的调用请求。

3.根据权利要求1所述的方法，其特征在于，所述接收当前业务模块发送的调用请求之前还包括：

获取各JS引擎在H5容器层中的注册时间，所述JS引擎用于处理业务模块相应的调用方法；

以所述注册时间从先到后的顺序，生成预设发送顺序。

4.根据权利要求3所述的方法，其特征在于，所述以注册时间从先到后的顺序，生成预设发送顺序之后包括：

按照所述预设发送顺序，生成发送列表，所述发送列表包括发送次序及其对应的JS引擎。

5.根据权利要求4所述的方法，其特征在于，接收所述待调用业务模块的响应结果之后还包括：

如果所述响应结果为不可以处理，则继续向模块层中余下的待调用业务模块发送所述调用请求，直至接收到可以处理的响应结果。

6.根据权利要求5所述的方法，其特征在于，所述如果响应结果为不可以处理，则继续向模块层中余下的待调用业务模块发送调用请求，直至接收到可以处理的响应结果之后包括：

确定待删除JS引擎，所述待删除JS引擎为不可以处理当前业务模块发送的调用请求的JS引擎；

从所述发送列表中删除所述待删除JS引擎及其对应的发送次序，得到待更新发送列表，所述待更新发送列表包括余下的可用JS引擎及其对应的发送次序；

以所述注册时间从先到后的顺序，将所述可用JS引擎所对应的发送次序替换为连续编号，得到更新后的发送列表。

7.一种模块间相互调用的装置，其特征在于，所述装置包括：

调用请求接收单元，用于接收当前业务模块发送的调用请求，所述调用请求用于调用相应的业务模块；

分发单元，用于按照预设发送顺序，向各待调用业务模块发送所述调用请求，所述待调用业务模块为存储于模块层中的业务模块；

响应结果接收单元，用于接收所述待调用业务模块的响应结果；

终止指令生成单元，用于如果所述响应结果为可以处理，则生成终止指令，所述终止指令为终止发送所述调用请求至余下的待调用业务模块；

结果反馈单元，用于向所述当前业务模块发送目标业务模块返回的反馈值，所述目标业务模块为可以处理所述调用请求的待调用业务模块。

8.根据权利要求7所述的装置，其特征在于，所述装置还包括：

管理器建立单元，用于针对每一个业务模块，建立一个相应的JS引擎管理器，所述JS引擎管理器设置于H5容器层，且用于分发相应业务模块的调用请求。

9.根据权利要求7所述的装置，其特征在于，所述装置还包括：

注册时间获取单元，用于获取各JS引擎在H5容器层中的注册时间，所述JS引擎用于处理业务模块相应的调用方法；

发送顺序生成单元，用于以所述注册时间从先到后的顺序，生成预设发送顺序。

10.根据权利要求9所述的装置，其特征在于，所述装置还包括：

发送列表生成单元，用于按照所述预设发送顺序，生成发送列表，所述发送列表包括发送次序及其对应的JS引擎。

11.根据权利要求10所述的装置，其特征在于，所述装置还包括：

继续发送单元，用于如果所述响应结果为不可以处理，则继续向模块层中余下的待调用业务模块发送所述调用请求，直至接收到可以处理的响应结果。

12.根据权利要求11所述的装置，其特征在于，所述装置还包括：

待删除JS引擎确定单元，用于确定待删除JS引擎，所述待删除JS引擎为不可以处理当前业务模块发送的调用请求的JS引擎；

删除单元，用于从所述发送列表中删除所述待删除JS引擎及其对应的发送次序，得到待更新发送列表，所述待更新发送列表包括余下的可用JS引擎及其对应的发送次序；

更新单元，用于以所述注册时间从先到后的顺序，将所述可用JS引擎所对应的发送次序替换为连续编号，得到更新后的发送列表。

13.一种电子设备，其特征在于，所述电子设备包括：

处理器，以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行权利要求1-6任一所述的模块间相互调用的方法。

14.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1-6任一所述的模块间相互调用的方法。