应用程序中的模块间调用方法、装置及系统与流程

本申请涉及应用程序开发技术领域，特别是涉及应用程序中的模块间调用方法、装置及系统。

背景技术：

随着移动通信和互联网技术的不断发展，各种移动终端应用程序（通常称为app）不断涌现，在各行各业为用户的生活、工作等提供着便利，其中就包括电子商务类app，例如，淘宝、天猫、聚划算，等等。

在移动终端应用程序开发领域，常见的移动终端操作系统包括ios（由苹果公司开发的移动操作系统）、android（基于linux的自由及开放源代码的操作系统）等等。针对不同的操作系统，需要通过不同的方式进行app开发。其中，ios系统下的应用程序都有一个uiapplication，uiapplication是ios应用程序的开始并且负责初始化、显示uiwindow，并加载应用程序的第一个uiview到uiwindow窗体中。uiapplication的另一个任务是帮助管理应用程序的生命周期，而uiapplication通过一个名字为uiapplicationdelegate的代理类来履行这个任务。尽管uiapplication会负责接收事件，但是，如何去响应这些事件则是由uiapplicationdelegate决定的，uiapplicationdelegate可以处理的事件包括应用程序的生命周期事件（比如程序启动和关闭等）、系统事件（比如来电、记事项警告等），等等。

为了实现代码复用，降低开发成本，在现有的ios开发框架下，可以实现模块化的开发。例如，可以将应用程序划分为多个基础功能模块以及多个业务模块。其中，基础功能模块可以包括用于登录的模块、用于记录用户操作行为轨迹的模块等等。而业务模块则多为面向用户角度进行定义，例如，对于“天猫”的app客户端，具体的业务模块可以包括“天猫”首页、“购物车”页面等等。这样，假设“天猫”首页以及“购物车”页面都需要使用登录功能，则都可以通过调用登录模块的来实现，从而实现同一基础功能模块的代码在不同 业务模块之间的复用。

在现有技术中，业务模块需要通过操作系统的原生接口来感知具体的系统事件，在感知到某个事件后，则需要直接调用具体的基础功能模块来实现某项具体功能。例如，“首页”模块在需要使用登录功能时，可以通过系统的原生接口确定用户是否已登录等等，如果未登录，则直接调用登录模块，以便用户进行登录，等等。

为了实现业务模块对基础功能模块的调用以处理系统事件，通常需要编写一个继承自uiapplicationdelegate接口的类，使得uiapplicationdelegate里面掺杂着很多业务模块自身的代码。也就是说，假设“购物车”模块需要使用登录功能，则用于调用登录模块的部分代码需要与购物车模块关联，一旦基础模块发生更新或者大范围的代码修改，则可能会需要修改模块的调用代码，等等。总之，这种业务模块与基础功能模块之间强关联的方式，可能会使得模块之间的调用顺序混乱，模块之间的耦合度也相对很高，模块的复用成本很高。

因此，如何降低模块的复用成本，提高模块的灵活性，成为需要本领域技术人员解决的技术问题。

技术实现要素：

本申请提供了应用程序中的模块间调用方法、装置及系统，能够降低模块的复用成本，提高模块的灵活性。

本申请提供了如下方案：

一种应用程序中的模块间调用系统，所述系统包括：框架核心模块、模块资源以及服务接口，所述模块资源包括基础功能模块以及业务模块，所述基础功能模块与所述服务接口相对应；其中：

所述框架核心模块，用于维护应用程序相关的上下文信息，并提供事件感知接口；所述上下文信息包括应用程序的运行环境信息、配置参数信息以及模块资源、服务接口的注册信息，所述上下文信息用于在各个模块资源之间共享；

所述业务模块，用于通过实现所述框架核心模块的事件感知接口进行事件 感知，并在感知到目标事件时，向该目标事件对应的服务接口发起调用请求；

所述服务接口，用于根据业务模块的调用请求，调用对应的基础功能模块，并将调用请求中的参数传递给所述基础功能模块，在接收到所述基础功能模块返回的处理结果后，将所述处理结果返回给所述业务模块；

所述基础功能模块，用于根据所述服务接口传入的参数执行相应的处理，并将处理结果返回给所述服务接口。

一种应用程序中的模块间调用方法：

所述应用程序内包括：框架核心模块、模块资源以及服务接口，所述模块资源包括基础功能模块以及业务模块，所述基础功能模块与所述服务接口相对应；

所述方法包括：

框架核心模块维护应用程序相关的上下文信息，并提供事件感知接口；所述上下文信息包括应用程序的运行环境信息、配置参数信息以及模块资源、服务接口的注册信息，所述上下文信息用于在各个模块资源之间共享；

在感知到目标事件时，向实现了该目标事件的事件感知接口的已注册业务模块提供该目标事件信息，以便业务模块在感知到目标事件后，向该目标事件对应的服务接口发起调用请求，由服务接口调用对应的基础功能模块，并将调用请求中的参数传递给所述基础功能模块，在接收到所述基础功能模块返回的处理结果后，将所述处理结果返回给所述业务模块。

一种应用程序中的模块间调用方法：

所述应用程序内包括：框架核心模块、模块资源以及服务接口，所述模块资源包括基础功能模块以及业务模块，所述基础功能模块与所述服务接口相对应；所述框架核心模块用于维护应用程序相关的上下文信息，并提供事件感知接口；所述上下文信息包括应用程序的运行环境信息、配置参数信息以及模块资源、服务接口的注册信息，所述上下文信息用于在各个模块资源之间共享；

所述方法包括：

业务模块通过实现所述框架核心模块的事件感知接口进行事件感知；

在感知到目标事件时，根据所述上下文信息判断该目标事件对应的服务接口是否已注册；

如果所述服务接口已注册，则向该服务接口发起调用请求，以便服务接口调用对应的基础功能模块，并将调用请求中的参数传递给所述基础功能模块，在接收到所述基础功能模块返回的处理结果后，将所述处理结果返回给所述业务模块。

一种应用程序中的模块间调用方法：

所述应用程序内包括：框架核心模块、模块资源以及服务接口，所述模块资源包括基础功能模块以及业务模块，所述基础功能模块与所述服务接口相对应；所述框架核心模块用于维护应用程序相关的上下文信息，并提供事件感知接口；所述上下文信息包括应用程序的运行环境信息、配置参数信息以及模块资源、服务接口的注册信息，所述上下文信息用于在各个模块资源之间共享；

所述方法包括：

服务接口接收业务模块的调用请求，根据所述上下文信息判断对应的基础功能模块是否已注册；

如果所述基础功能模块已注册，则调用所述基础功能模块，并将调用请求中的参数传递给所述基础功能模块，在接收到所述基础功能模块返回的处理结果后，将所述处理结果返回给所述业务模块。

一种应用程序中的模块间调用装置：

所述应用程序内包括：框架核心模块、模块资源以及服务接口，所述模块资源包括基础功能模块以及业务模块，所述基础功能模块与所述服务接口相对应；

所述装置应用于框架核心模块，包括：

上下文信息维护单元，用于维护应用程序相关的上下文信息，并提供事件 感知接口；所述上下文信息包括应用程序的运行环境信息、配置参数信息以及模块资源、服务接口的注册信息，所述上下文信息用于在各个模块资源之间共享；

交互单元，用于在感知到目标事件时，向实现了该目标事件的事件感知接口的已注册业务模块提供该目标事件信息，以便业务模块在感知到目标事件后，向该目标事件对应的服务接口发起调用请求，由服务接口调用对应的基础功能模块，并将调用请求中的参数传递给所述基础功能模块，在接收到所述基础功能模块返回的处理结果后，将所述处理结果返回给所述业务模块。

一种应用程序中的模块间调用装置：

所述应用程序内包括：框架核心模块、模块资源以及服务接口，所述模块资源包括基础功能模块以及业务模块，所述基础功能模块与所述服务接口相对应；所述框架核心模块用于维护应用程序相关的上下文信息，并提供事件感知接口；所述上下文信息包括应用程序的运行环境信息、配置参数信息以及模块资源、服务接口的注册信息，所述上下文信息用于在各个模块资源之间共享；

所述装置应用于业务模块，包括：

事件感知单元，用于通过实现所述框架核心模块的事件感知接口进行事件感知；

判断单元，用于在感知到目标事件时，根据所述上下文信息判断该目标事件对应的服务接口是否已注册；

调用单元，用于如果所述服务接口已注册，则向该服务接口发起调用请求，以便服务接口调用对应的基础功能模块，并将调用请求中的参数传递给所述基础功能模块，在接收到所述基础功能模块返回的处理结果后，将所述处理结果返回给所述业务模块。

一种应用程序中的模块间调用装置：

所述应用程序内包括：框架核心模块、模块资源以及服务接口，所述模块资源包括基础功能模块以及业务模块，所述基础功能模块与所述服务接口相对 应；所述框架核心模块用于维护应用程序相关的上下文信息，并提供事件感知接口；所述上下文信息包括应用程序的运行环境信息、配置参数信息以及模块资源、服务接口的注册信息，所述上下文信息用于在各个模块资源之间共享；

所述装置应用于服务接口，包括：

调用请求接收单元，用于接收业务模块的调用请求，根据所述上下文信息判断对应的基础功能模块是否已注册；

调用单元，用于如果所述基础功能模块已注册，则调用所述基础功能模块，并将调用请求中的参数传递给所述基础功能模块，在接收到所述基础功能模块返回的处理结果后，将所述处理结果返回给所述业务模块。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，可以提供应用程序框架，并通过框架核心模块为各模块提供应用程序中的上下文信息，框架核心模块与业务模块之间可以通过事件感知接口进行交互，使得业务模块可以通过实现框架核心模块的事件感知接口来感知各类事件。在感知到事件后，如果需要使用基础功能模块的功能，则可以通过该基础功能模块对应的服务接口，实现对基础功能模块的间接调用，这样，业务模块与基础功能模块之间不再具有强关联，降低两者之间的耦合度，在不同的业务模块复用基础功能模块代码的过程中，可以降低复用成本。另外，由于可以实现对各个模块的插件化管理，因此，可以在不影响其他模块的情况，进行模块的增加或者删除，模块的灵活度得到提高。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

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

图1是本申请实施例提供的系统的示意图；

图2是应用程序生命周期事件示意图；

图3是应用程序另一生命周期事件示意图；

图4是本申请实施例提供的第一方法的流程图；

图5是本申请实施例提供的第二方法的流程图；

图6是本申请实施例提供的第三方法的流程图；

图7是本申请实施例提供的第一装置的示意图；

图8是本申请实施例提供的第二装置的示意图；

图9是本申请实施例提供的第三装置的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

在本申请实施例中，首先提供了一种的模块化编程解决框架方案，可运行在ios系统下，该框架可以称为beehive。其可以用于实现大规模应用的模块化，降低编程复杂度以及依赖耦合度，模块的灵活度更高，应用程序可以轻易的增加或删除模块。具体而言，该框架处于操作系统与应用程序之间，应用程序中的业务模块在感知事件时，不再需要通过操作系统的原生接口来实现，而只需要通过与该框架的核心提供的接口来实现。在其他基础功能模块之间进行调用操作时，也不必通过继承操作系统原生的uiapplicationdelegate接口的类，去调用其他基础功能模块，而是为每个基础功能模块实现了各自的服务接口，业务模块在需要使用某项功能时，可以对相应基础功能模块的服务接口发出请求，相应的，服务接口再将请求转发给基础功能模块，基础功能模块在收到请求后进行处理，并将处理结果返回给服务接口，再由服务接口返回给业务模块。这各个模块资源可以实现插件化编程，并且各模块资源之间没有任何依赖或者强关联，框架内容和模块资源之间通过事件交互，也实现了插件隔离。另外， 通过服务接口进行访问的优点还在于，可以在编译时检查发现服务接口的变化，从而及时修正服务接口的问题。

可见，在本申请实施例中，应用程序中的资源除了模块资源之外，还包括服务接口资源，其中，服务接口资源是与基础功能模块相对应的，在具体实现时，一个基础功能模块可以对应多个服务接口，分别对应不同的调用方式，也就是说，可以通过不同的服务接口，以不同的调用方式调用基础功能模块。其中，模块资源与服务接口资源都可以是在beehive框架下定义的，并向框架核心模块进行注册，注册成功后，业务模块获得感知相应事件的能力，服务接口可以被业务模块调用，等等。并且，可以任意地向框架中增加新的模块资源或者服务接口资源，例如，应用程序中可以增加新的业务模块，以向用户提供更多的服务，或者，也可以在基础功能模块出现新的调用方式时，增加新的服务接口，等等，在此过程中，无需修改其他模块的处理逻辑，因此，可以降低开发成本。

实施例一

参见图1，本申请实施例一首先提供了一种应用程序中的模块间调用系统，所述系统包括：框架核心模块101、模块资源102以及服务接口103，所述模块资源102包括基础功能模块1021以及业务模块1022，所述基础功能模块1021与所述服务接口103相对应。具体实现时，可以将框架核心模块添加到应用程序中，并根据实际的需要，基于该框架核心模块编写各个业务模块、基础功能模块以及服务接口。其中：

所述框架核心模块101，用于维护应用程序相关的上下文信息，并提供事件感知接口；所述上下文信息包括应用程序的运行环境信息、配置参数信息以及模块资源、服务接口的注册信息。

首先，框架核心模块101可以提供一份全局的上下文信息，该信息中可以包括应用程序的运行环境信息、配置参数信息以及模块资源、服务接口的注册信息，等等。也就是说，框架核心模块可以对应用程序的运行环境、配置参数等信息进行记录及维护，并且，应用程序的业务模块、基础功能模块、服务接 口等都可以注册到该框架核心模块，框架核心模块还可以记录各个模块、服务的注册信息，等等。这样，这些上下文信息可以在各个模块之间共享，使得各个模块可以获取到相应的信息。具体实现时，初始化应用的上下文时，可以是在uiapplicationdelegate中的didfinishlaunchingwithoption中实现，具体可以执行设置上下文初始化时候的相关参数，并启动对应的beehive框架等操作。

其中，模块资源以及服务接口的注册方式可以有多种，其中一种实现方式下，开发者可以直接将模块资源或者服务接口的名称等标识写入框架核心模块内部的静态注册文件，这样，框架核心模块可以直接根据该文件中记录的模块名或者服务名，对模块资源或者服务接口进行静态注册。例如，静态注册文件可以称为beehive.plist。

或者，在另一种实现方式下，也可以是在模块资源或服务接口初始化时，通过调用框架核心模块的注册接口发起注册请求，相应的，框架核心模块可以根据接收到的注册请求，对对应的模块资源或服务接口进行动态注册。例如，模块资源可以在模块入口实现用bh_export_module()宏，声明该类为模块入口实现类，如果需设置模块为异步加载，可以将bh_export_module(yes)设置为yes，则会在应用程序启动之后第一屏内容展示之间异步执行模块的初始化，这样可以优化启动时间消耗。

框架核心模块与业务模块之间的交互，是通过事件感知接口来实现的。具体实现时，框架核心模块还可以提供事件感知接口给各个业务模块，业务模块可以通过实现事件感知接口来获知具体事件的发生。例如，具体的事件接口可以包括但不限于：

-(void)modinit:(bhcontext*)context（初始化业务模块事件）

-(void)modsetup:(bhcontext*)context（设置业务模块参数事件）

-(void)modteardown:(bhcontext*)context（当应用程序被销毁时调用的事件）

-(void)modwillresignactive:(bhcontext*)context（当应用程序将要进入非活动状态执行时调用的事件）

-(void)moddidenterbackground:(bhcontext*)context(当应用程序被推送到后台的时候调用的事件)

-(void)modwillenterforeground:(bhcontext*)context(当应用程序从后台将要回到前台时调用的事件)

其中，具体的事件可以包括基础的系统事件，也即，应用程序的生命周期事件。例如，参见图2，在应用程序正常被启动的情况下，生命周期内的系统事件通常包括：将要启动(willlaunch)事件，已经启动(didlaunch)事件，进入前台阶段(eventloop)事件，将要进入非活动状态时执行(willresignactive)事件，已经进入后台阶段(didenterbackground)事件，将要进入活动状态(willenterforeground)，已进入前台处于活动状态(didbecomeactive)事件，将要退出(willterminate)事件。具体实现时，框架核心模块可以提供对各种系统事件进行感知的接口，业务模块可以根据自己的需求，实现其中的部分或者全部接口，这样，在业务模块注册到框架核心模块后，就可以具有感知对应事件的能力。当然，对于框架内核而言，可以通过对系统接口的封装，提供上述对系统事件进行感知的接口，也就是说，框架内核在系统接口的基础上做了一层封装，使得应用程序中的业务模块不需要直接调用系统接口来进行事件感知，而是可以通过实现框架内核提供的接口即可感知。

例如，某业务模块为订单模块，该模块的作用是提供已经生成的订单列表信息，其中包括各订单的状态等信息。在应用程序从后台状态切换到前台状态后，通常需要重新从服务器获取最新的订单信息，以便对订单列表信息进行更新。因此，订单模块就可以实现感知将要进入活动状态事件的感知接口，这样，在订单模块被注册后，如果应用程序发生了从后台切换到前台的事件，则订单模块就可以感知到该事件，进而对该事件执行相应的处理(具体的处理操作在后文中会有介绍)。

在实际应用中，应用程序生命周期内的系统事件是非常有限的，通常不足以满足具体业务模块的各种需求。为此，在本申请实施例中，框架核心模块还可以提供通用事件感知接口，所谓的通用事件就是指在系统事件基础上扩展的事件，并在各个业务模块之间共享，也就是说，所有业务模块可能都会有感知 这种事件的需求，但这种事件并不是系统事件，因此，称为通用事件。

其中，通用事件具体可以包括系统提供的一些通知事件，例如，系统内存不足(didreceivememorywarning)事件，系统时间发生改变(significanttimechange)事件，状态栏方向将要发生变化(willchangestatusbarframe)事件，状态栏方向已经发生变化(didchangestatusbarorientation)，通过url启动(handleopenurl)事件，等等。这种通用事件通常是用于业务模块在启动或者初始化过程中进行感知，并对相应的事件执行相关的处理。例如，参见图3，相对于图2中的常规启动状态，在应用程序的生命周期内，在应用程序的启动阶段，还可以包括模块设置(modsetup)，模块初始化(modinit)和窗体挂接(modsplash)等状态。

具体如，有些应用程序可能是由其他应用程序启动的，例如，假设本申请实施例中的应用程序为a，用户在使用另一应用程序b的过程中，通过链接等方式进入到应用程序a，等等。针对这种情况，有些业务模块可能需要执行一些特殊的处理。例如，支付模块可能需要根据应用程序b传入的参数执行结算操作，等等。在这种情况下，支付模块就可以通过实现“通过url启动”事件感知接口，感知到应用程序的这种特殊的启动方式，并获取到传入的参数，然后再执行相关的处理即可。

另外，如果系统事件、通用事件都不足以满足业务模块的实际需求，在本申请实施例中，框架核心模块还可以提供自定义事件感知接口。其中，所谓的自定义事件，是指业务模块可以根据自身的特殊需求定义的事件。例如，应用程序可能是从搜索系统启动的，具体如，假设用户在使用搜索引擎进行关键词搜索的过程中，从搜索结果中点击了某链接，通过该链接跳转到应用程序“天猫”，等等。针对这种从搜索引擎启动的启动方式，某业务模块需要执行一些特殊处理，等等。而“从搜索引擎启动”这一事件，不属于系统事件，也不属于通用事件，因此，业务模块可以通过自定义的方式来实现对该事件的感知。

具体实现时，框架核心模块还可以提供用于进行事件扩展的接口，例如，可以称为bhappdelgate，业务模块可以通过继承bhappdelegate来扩展自己的事件，这样就可以通过系统核心感知这种自定义事件。另外，还可以通过上 下文中的modulesbyname访问各个模块entry类，来增加触发点。其中，上下文信息中可以有一个modulesbyname的列表，通过该列表可以找到目前所有已注册的模块资源，一个模块资源可以暴露一些属性给其他模块资源使用，比如登录模块需要获知配置模块是否加载完成并返回指定的登录配置，那么登录模块可以在其内部直接通过这种方式去获知配置模块的状态。又如，当业务模块为下载页面并执行对应的自定义操作，当下载完页面，bhappdelgate帮助bhapplication完成didfinishlaunchingwithoptions动作，相应地，在这个方法里面执行对应的自定义的操作。bhapplication委托bhappdelegate，bhappdelegate实现定义的协议(bhmoduleprotocol)。

所述业务模块1022，用于通过实现所述框架核心模块的事件感知接口进行事件感知，并在感知到目标事件时，向该目标事件对应的服务接口发起调用请求；

业务模块通过实现框架核心模块提供的事件感知接口，来感知具体事件的发生，其中包括系统事件、通用事件、自定义事件，等等。在感知到具体某个事件后，如果需要执行某种具体处理操作，则可以通过调用对应的服务接口来实现。其中，关于感知到某个事件后具体该调用哪个服务接口，可以是预先在业务模块中定义好的，也就是说，对于开发人员而言，系统中有哪些基础功能模块，每个功能模块对应哪些服务接口，都是已知的，因此，可以将事件感知作为具体服务接口被调用的触发条件。

例如，在前述例子中，订单模块在感知到应用程序从后台切换到前台执行的事件时，可以调用下发配置模块的服务接口，因为需要使用下发配置模块的信息下发功能。又如，支付模块在感知到从其他应用程序启动的事件时，可以调用结算模块的服务接口，因为需要使用结算结果的结算功能，等等。其中，业务模块在调用服务接口时，可以在请求中携带一些参数，例如，在调用下发配置模块的服务接口时，可以携带上需要请求下发的内容等参数，这样，服务接口可以将这些信息传递给下发配置模块，这样，下发配置模块才可以获知需要下发具体什么内容。

需要说明的是，有些场景下，业务模块在访问每个声明为服务接口的对象时，如果希望服务接口对象能保留一些状态，那么可以声明这个服务接口对象为单例对象。

当然，业务模块具体在调用服务接口之前，还可以首先根据框架核心模块提供的上下文信息，判断对应的服务接口是否已经注册，如果已经注册，则可以进行调用，如果尚未注册，则可能由于服务接口不符合框架协议等方式，无法发起调用。另外，在应用程序运行的过程中，如果业务模块需要获知应用程序运行环境、配置参数等信息，也都可以从框架核心模块提供的上下文信息中获取。

所述服务接口103，用于接收到业务模块的调用请求后，调用对应的基础功能模块，并将调用请求中的参数传递给所述基础功能模块，在接收到所述基础功能模块返回的处理结果后，将所述处理结果返回给所述业务模块；

服务接口是与基础功能模块相对应的，根据基础功能模块的不同调用方式，可以提供多种不同的服务接口，在注册到框架核心模块后，就可以被业务模块调用。服务接口在接收到调用请求时，就可以按照该服务接口对应的调用方式，向对应的基础功能模块发起调用，并将业务模块的调用请求中携带的参数传递给基础功能模块，这样，基础功能模块就可以进行相应的处理，并将处理结果返回给服务接口，服务接口接收到处理结果后，再将处理结果返回给业务模块。

也就是说，业务模块可以通过服务接口实现对基础功能模块的间接调用，业务模块不需要关心基础功能模块内部的具体实现，即使基础功能模块的代码发生更新，甚至整个基础功能模块发生更新，业务模块都可以不感知，并且，也不需要修改相关的调用代码，因此，基础功能模块的代码在不同业务模块之间的复用成本得到控制。

所述基础功能模块1021，用于根据所述服务接口传入的参数执行相应的处理，并将处理结果返回给所述服务接口。

如前文所述，基础功能模块主要用于在接收到服务接口传入的参数后，执行相应的处理，并将处理结果返回给所述服务接口，以便服务接口将处理结果返回给业务模块。

总之，在本申请实施例中，可以提供应用程序框架，并通过框架核心模块为各模块提供应用程序中的上下文信息，框架核心模块与业务模块之间可以通过事件感知接口进行交互，使得业务模块可以通过实现框架核心模块的事件感知接口来感知各类事件。在感知到事件后，如果需要使用基础功能模块的功能，则可以通过该基础功能模块对应的服务接口，实现对基础功能模块的间接调用，这样，业务模块与基础功能模块之间不再具有强关联，降低两者之间的耦合度，在不同的业务模块复用基础功能模块代码的过程中，可以降低复用成本。另外，由于可以实现对各个模块的插件化管理，因此，可以在不影响其他模块的情况，进行模块的增加或者删除，模块的灵活度得到提高。

实施例二

在该实施例二中，从框架核心模块的角度提供了一种应用程序中的模块间调用方法，首先需要说明的是，所述应用程序内包括：框架核心模块、模块资源以及服务接口，所述模块资源包括基础功能模块以及业务模块，所述基础功能模块与所述服务接口相对应；

参见图4，该方法可以包括以下步骤：

s401：框架核心模块维护应用程序相关的上下文信息，并提供事件感知接口；所述上下文信息包括应用程序的运行环境信息、配置参数信息以及模块资源、服务接口的注册信息，所述上下文信息用于在各个模块资源之间共享；

s402：在感知到目标事件时，向实现了该目标事件的事件感知接口的已注册业务模块提供该目标事件信息，以便业务模块在感知到目标事件后，向该目标事件对应的服务接口发起调用请求，由服务接口调用对应的基础功能模块， 并将调用请求中的参数传递给所述基础功能模块，在接收到所述基础功能模块返回的处理结果后，将所述处理结果返回给所述业务模块。

实施例三

在该实施例三中，从业务模块的角度，提供了一种应用程序中的模块间调用方法，首先需要说明的是，所述应用程序内包括：框架核心模块、模块资源以及服务接口，所述模块资源包括基础功能模块以及业务模块，所述基础功能模块与所述服务接口相对应；所述框架核心模块用于维护应用程序相关的上下文信息，并提供事件感知接口；所述上下文信息包括应用程序的运行环境信息、配置参数信息以及模块资源、服务接口的注册信息，所述上下文信息用于在各个模块资源之间共享；

参见图5，该方法可以包括以下步骤：

s501：业务模块通过实现所述框架核心模块的事件感知接口进行事件感知；

s502：在感知到目标事件时，根据所述上下文信息判断该目标事件对应的服务接口是否已注册；

s503：如果所述服务接口已注册，则向该服务接口发起调用请求，以便服务接口调用对应的基础功能模块，并将调用请求中的参数传递给所述基础功能模块，在接收到所述基础功能模块返回的处理结果后，将所述处理结果返回给所述业务模块。

实施例四

该实施例四从业务模块的角度，提供了一种应用程序中的模块间调用方法，同样，所述应用程序内可以包括：框架核心模块、模块资源以及服务接口，所述模块资源包括基础功能模块以及业务模块，所述基础功能模块与所述服务接口相对应；所述框架核心模块用于维护应用程序相关的上下文信息，并提供事件感知接口；所述上下文信息包括应用程序的运行环境信息、配置参数信息以及模块资源、服务接口的注册信息，所述上下文信息用于在各个模块资源之间共享；

参见图6，所述方法具体可以包括：

s601：服务接口接收业务模块的调用请求，根据所述上下文信息判断对应的基础功能模块是否已注册；

s602：如果所述基础功能模块已注册，则调用所述基础功能模块，并将调用请求中的参数传递给所述基础功能模块，在接收到所述基础功能模块返回的处理结果后，将所述处理结果返回给所述业务模块。

需要说明的是，关于上述实施例二至四中各步骤的具体实现方式，可以参见实施例一中的介绍，这里不再赘述。

与实施例二相对应，本申请实施例还提供了一种应用程序中的模块间调用装置，所述应用程序内包括：框架核心模块、模块资源以及服务接口，所述模块资源包括基础功能模块以及业务模块，所述基础功能模块与所述服务接口相对应；

参见图7，所述装置应用于框架核心模块，包括：

上下文信息维护单元701，用于维护应用程序相关的上下文信息，并提供事件感知接口；所述上下文信息包括应用程序的运行环境信息、配置参数信息以及模块资源、服务接口的注册信息，所述上下文信息用于在各个模块资源之间共享；

交互单元702，用于在感知到目标事件时，向实现了该目标事件的事件感知接口的已注册业务模块提供该目标事件信息，以便业务模块在感知到目标事件后，向该目标事件对应的服务接口发起调用请求，由服务接口调用对应的基础功能模块，并将调用请求中的参数传递给所述基础功能模块，在接收到所述基础功能模块返回的处理结果后，将所述处理结果返回给所述业务模块。

与实施例三相对应，本申请实施例还提供了一种应用程序中的模块间调用装置，所述应用程序内包括：框架核心模块、模块资源以及服务接口，所述模块资源包括基础功能模块以及业务模块，所述基础功能模块与所述服务接口相 对应；所述框架核心模块用于维护应用程序相关的上下文信息，并提供事件感知接口；所述上下文信息包括应用程序的运行环境信息、配置参数信息以及模块资源、服务接口的注册信息，所述上下文信息用于在各个模块资源之间共享；

参见图8，所述装置应用于业务模块，包括：

事件感知单元801，用于通过实现所述框架核心模块的事件感知接口进行事件感知；

判断单元802，用于在感知到目标事件时，根据所述上下文信息判断该目标事件对应的服务接口是否已注册；

调用单元803，用于如果所述服务接口已注册，则向该服务接口发起调用请求，以便服务接口调用对应的基础功能模块，并将调用请求中的参数传递给所述基础功能模块，在接收到所述基础功能模块返回的处理结果后，将所述处理结果返回给所述业务模块。

与实施例四相对应，本申请实施例还提供了一种应用程序中的模块间调用装置，所述应用程序内包括：框架核心模块、模块资源以及服务接口，所述模块资源包括基础功能模块以及业务模块，所述基础功能模块与所述服务接口相对应；所述框架核心模块用于维护应用程序相关的上下文信息，并提供事件感知接口；所述上下文信息包括应用程序的运行环境信息、配置参数信息以及模块资源、服务接口的注册信息，所述上下文信息用于在各个模块资源之间共享；

参见图9，所述装置应用于服务接口，包括：

调用请求接收单元901，用于接收业务模块的调用请求，根据所述上下文信息判断对应的基础功能模块是否已注册；

调用单元902，用于如果所述基础功能模块已注册，则调用所述基础功能模块，并将调用请求中的参数传递给所述基础功能模块，在接收到所述基础功能模块返回的处理结果后，将所述处理结果返回给所述业务模块。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申 请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的应用程序中的模块间调用方法、装置及系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。