应用程序以及应用程序的业务插件使用方法与流程

本发明涉及通信技术领域，特别是涉及一种应用程序以及应用程序的业务插件使用方法。

背景技术

目前，服务类型的应用程序(application，app)主要为平台app，所谓平台app，即，其在提供自身具备的功能的前提下，还可以接入各种业务线(比如旅行、外卖、酒店、电影等等)。一个业务线在平台app中存在的代码组织形式称作业务插件，比如，美团app(一种平台app)中的电影业务就是一个业务插件。当平台app接入了业务插件后，该平台app相对于业务插件来说就是宿主app，比如，电影插件如果接入到美团app，那么美团app就是电影插件的宿主app。

其中，不同的平台app的技术栈(平台app所使用的各种基础技术以及框架)是存在差异的，因此，不同平台app所使用的业务插件的技术栈也是不同的。所以，在现有技术中，在开发各个平台app的业务插件时，需要分别依据各个平台app的技术栈来开发每个平台app所使用的业务插件，但是不同平台app之间往往存在着相同功能的业务插件，例如电影业务插件，如果针对每种平台app都重复的开发同一种业务插件，则不仅会浪费开发资源，还降低了代码开发效率。

如果能够将同一个业务插件的代码复用到不同技术栈的多个平台app上，比如同样一份代码可以作为电影业务插件直接在美团平台app上接入，同时也可以直接在猫眼平台app上接入，则可以大大的降低代码开发成本，提升代码开发效率。

但是如上所述，不同平台app上即便是针对同一个业务插件，该业务插件在不同平台app上的技术栈是与所属平台app的技术栈相对应的，无法使用技术栈a编写的电影业务插件应用到使用技术栈b的平台app1，相反，使用技术栈a编写的电影业务插件只可以应用到使用技术栈a的平台app2中。

因此，针对如何将同一套业务插件的代码直接复用到多个宿主app的需求，目前尚无解决方案。

技术实现要素：

本发明提供了一种应用程序以及应用程序的业务插件使用方法，以解决现有技术中无法将同一份业务插件的代码直接在多个宿主app中使用的问题。

为了解决上述问题，根据本发明的一个方面，本发明公开了一种应用程序的业务插件使用方法。

所述应用程序包括：

宿主应用程序；

抽象层，包括多个服务接口，其中，每个服务接口用于描述所述宿主应用程序能够提供的服务；

至少一个业务插件，用于接入至所述宿主应用程序；

其中，所述宿主应用程序包括接入层；

所述接入层，用于对接入的每个业务插件创建该业务插件需要使用的所有服务接口的实现类，以及创建并保存所述服务接口的名称与所述实现类的名称的对应关系；

所述宿主应用程序，包括所述接入层创建的所述实现类以及所述对应关系；

serviceloader层；

所述方法包括：

所述serviceloader层接收所述至少一个业务插件中目标业务插件对目标服务接口的调用请求；

所述serviceloader层根据所述调用请求查询所述对应关系中与所述目标服务接口的名称对应的目标实现类的名称；

所述serviceloader层根据所述目标实现类的名称，通过反射创建所述目标实现类的实例；

所述serviceloader层响应于所述调用请求，将所述目标实现类的实例通过所述目标服务接口返回至所述目标业务插件。

根据本发明的另一方面，本发明还公开了一种应用程序，包括：

宿主应用程序；

抽象层，包括多个服务接口，其中，每个服务接口用于描述所述宿主应用程序能够提供的服务；

至少一个业务插件，用于接入至所述宿主应用程序；

其中，所述宿主应用程序包括接入层；

所述接入层，用于对接入的每个业务插件创建该业务插件需要使用的所有服务接口的实现类，以及创建并保存所述服务接口的名称与所述实现类的名称的对应关系；

所述宿主应用程序，包括所述接入层创建的所述实现类以及所述对应关系；

serviceloader层；

其中，所述serviceloader层，用于接收所述至少一个业务插件中目标业务插件对目标服务接口的调用请求；

所述serviceloader层，用于根据所述调用请求查询所述对应关系中与所述目标服务接口的名称对应的目标实现类的名称；

所述serviceloader层，用于根据所述目标实现类的名称，通过反射创建所述目标实现类的实例；

所述serviceloader层，用于响应于所述调用请求，将所述目标实现类的实例通过所述目标服务接口返回至所述目标业务插件。

与现有技术相比，本发明包括以下优点：

在本发明实施例中，通过在业务插件和宿主app之间设置抽象层，将宿主app能够提供的服务抽象成服务接口，并在宿主app中设置接入层，以对接入的业务插件所使用的服务接口进行实现，并创建服务接口与实现类的名称之间的对应关系，而在使用某个业务插件时，则只需要借助于serviceloader就可以根据上述对应关系获取到该业务插件需要使用的服务的实现类的实例，并通过该业务插件所访问的服务接口来将该实现类的实例返回给该业务插件，使得同一个业务插件能够应用到使用不同技术栈的多种宿主app，即平台app，大大提高了代码开发效率，降低了代码维护成本。

附图说明

图1是本发明的一种应用程序实施例的结构框图；

图2是本发明的一种应用程序的插件使用方法实施例的步骤流程图；

图3是本发明的另一种应用程序实施例的结构框图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

参照图1，示出了本发明的一种应用程序实施例的结构框图，具体可以包括：

宿主app；

抽象层(即抽象接口层)，包括多个服务接口，其中，每个服务接口用于描述所述宿主app能够提供的服务；

其中，在本发明实施例中，在宿主app和业务插件之间定义了一个抽象层，抽象出来各种接口来描述宿主app能提供的服务。

这里图1的服务接口包括硬件服务接口、图片服务接口、网络服务接口、定位服务接口、其他服务接口等。

至少一个业务插件，用于接入至所述宿主app；

其中，图1的接入至宿主app的业务插件包括插件1、插件2和插件3。

其中，之所以在插件和宿主app之间抽象出各个服务接口，原因在于业务插件的使用过程中需要调用宿主app的服务。例如电影插件的买票功能需要使用定位服务接口，来确定终端设备所处定位，还需要使用图片服务接口来显示电影海报等图片信息。

对于各个服务接口来说，它们可以使用宿主app的技术栈来实现。

那么为了将同一套代码的插件1能够接入至不同的宿主app，这里需要将宿主app的服务接口(该插件1需要使用的服务接口)的实例注入到插件1中，因此，本发明实施例的应用程序还包括了serviceloader层，即serviceloader(java语言的一个工具)。

其中，宿主app的各种能力都是一种服务，本发明实施例通过serviceloader(用于调用服务接口的实现类，并注入到业务插件)将服务接口的实现类注入(能够让业务插件直接使用被实现的接口)到业务插件中来解决业务代码和宿主app之间的解耦问题。

其中，为了能够使宿主app接入业务插件，本发明实施例的所述宿主app还包括配置接入层(即接入层)；

所述配置接入层，用于对接入的每个业务插件创建该业务插件需要使用的所有服务接口的实现类，以及创建所述服务接口的名称与所述实现类的名称的对应关系；

其中，服务接口中包括抽象方法，但是，该抽象方法无具体方法内容；而在对服务接口进行实现时，需要创建该服务接口的实现类，该实现类对该接口中的所有抽象方法进行实现。

举例来说，例如插件1需要使用硬件服务接口和图片服务接口；插件2需要使用图片服务接口和网络服务接口；插件3需要使用定位服务接口和网络服务接口。

而本实例中的宿主app需要接入上述插件1、插件2和插件3。而本发明实施例的配置接入层，主要用于对业务插件需要使用的服务接口进行实现。

所以，配置接入层，需要创建硬件服务接口、图片服务接口、网络服务接口以及定位服务接口的实现类。

其中，需要注意的是，以图片服务接口为例，虽然图片服务接口被插件1和插件2两个插件调用，但是针对不同插件的该图片服务接口的实现类是相同的，即插件1和插件2所调用的图片服务接口的实现类是同一个。

当然，针对同一个抽象接口而言，例如图片服务接口，其实现类并不限于一个，可以是多个(例如类1、类2和类3)。但是不论是插件1还是插件2或是继续接入至该宿主app的需要使用该图片服务接口的插件4，它们所使用的该图片服务接口的实现类都是同一组(例如类1、类2和类3)。

此外，配置接入层，还可以创建每个被实现的服务接口的名称与对应实现类的名称的对应关系，并将该对应关系保存在配置接入层；

继续以上述图片服务接口为例进行说明，在上述示例中对图片服务接口创建了实现该图片服务接口的类1、类2和类3，那么可以创建图片服务接口的名称与类1的名称的对应关系、图片服务接口的名称与类2的名称的对应关系，以及图片服务接口的名称与类3的名称的对应关系。

所述宿主app，包括所述配置接入层创建的所述实现类以及所述对应关系；

也就是说，配置接入层对接入的每个业务插件所创建的需要使用的所有服务接口的实现类都可以保存在宿主app中。其中，由于实现类文件较大，所以，可以保存在宿主app的除配置接入层之外的地方。而配置接入层创建的服务接口的名称与该服务接口的实现类的名称的对应关系则可以保存在宿主app的配置接入层中。

如图1所示，针对硬件服务接口所创建的实现类以硬件环境示出；针对图片服务接口所创建的实现类以图片框架示出；针对网络服务接口所创建的实现类以网络sdk示出；针对定位服务接口所创建的实现类以定位sdk示出；针对其他服务接口所创建的实现类以其他基础sdk示出。

在一个示例中，上述对应关系可以通过配置文件的方式保存在宿主app的配置接入层中。例如在宿主app的apk(安卓安装包)的asset(资产)的services目录下新建文本文件，该文件的文件内容就是上述服务接口的名称和实现类的名称的对应关系。文本文件中的配置样例如下：

服务接口名称1:宿主实现类名称1；

服务接口名称2:宿主实现类名称2。

那么对于该配置文件而言，其数量为一个，当插件1上线(例如使用服务接口1、服务接口2)，则实现服务接口1和服务接口2的实现类；插件2上线(使用服务接口2和服务接口3)，则实现服务接口3的实现类。即便是多个业务插件，配置文件只有一份，只是该配置文件中的内容在不断补充，即不断补充新上线(接入)的插件所使用的未被创建实现类的服务接口的名称与对应实现类的名称的对应关系。

本发明实施例的应用程序中的宿主app具有安卓系统。

参照图2，示出了本发明的图1所示应用程序的业务插件使用方法实施例的步骤流程图，具体可以包括如下步骤：

步骤101，serviceloader层接收至少一个业务插件中目标业务插件对目标服务接口的调用请求；

如图1所示，宿主app目前接入了三个插件，目前该应用程序正在进行买电影票的业务——对应插件1(目标业务插件)，那么插件1需要使用定位服务(目标服务接口)。

其中，面向业务插件的只有服务接口，所以，插件1向定位服务接口发送调用请求，定位服务接口将该调用请求发送至serviceloader，则serviceloader接收到了插件1对定位服务接口的调用请求。

步骤102，所述serviceloader层根据所述调用请求查询对应关系中与所述目标服务接口的名称对应的目标实现类的名称；

可选地，在一个实施例中，所述调用请求包括所述目标服务接口的名称，在执行步骤102时，所述serviceloader层可以根据所述目标服务接口的名称在所述对应关系中查询与所述目标服务接口的名称对应的目标实现类的名称。

可选地，在一个实施例中，所述服务接口的名称与所述实现类的名称的对应关系存储在配置文件中，在执行步骤102时，所述serviceloader层可以根据所述调用请求查询所述配置文件中的对应关系，确定与所述目标服务接口的名称对应的目标实现类的名称。

其中，该配置文件已在图1实施例中进行了描述，详见上述实施例，这里不再赘述。

这样，本发明实施例通过将服务接口的名称与实现类的名称的对应关系存储在配置文件的方式来对该对应关系进行存储，能够有效的对该对应关系进行管理，避免对应关系的紊乱存储，造成查询该对应关系时效率低的问题。

步骤103，所述serviceloader层根据所述目标实现类的名称，通过反射创建所述目标实现类的实例；

其中，由于目标实现类的名称已知，因此，可以根据该名称来创建该目标实现类的实例，而这里的反射技术则是java语言中根据类名称来创建类实例的已知方法，这里不再赘述。

可选地，在步骤103之前，根据本发明实施例的方法还可以包括：

所述serviceloader层判断缓存中是否存在所述目标实现类的实例；

相应的，在执行步骤103时，若缓存中不存在所述目标实现类的实例，则所述serviceloader层根据所述目标实现类的名称，通过反射创建所述目标实现类的实例；

相应的，在步骤103之后，根据本发明实施例的方法还可以包括：

将所述目标实现类的实例缓存在内存中。

这样，本发明实施例对于本次调用的目标实现类的实例在缓存中不存在的情况，在根据该目标实现类的名称创建了该目标实现类的实例后，还可以将该目标实现类的实例缓存到内存，从而可以便于下一个业务插件再次调用该目标服务接口时，无需对该目标服务接口的实现类的实例进行重复创建，而只需要从内存中读取已创建的实例即可，大大节省了业务处理时间。

可选地，在另一个实施例中，所述serviceloader层判断缓存中是否存在所述目标实现类的实例之后，根据本发明实施例的方法还可以包括：

若缓存中存在所述目标实现类的实例，则所述serviceloader层响应于所述调用请求，将缓存中所述目标实现类的实例通过所述目标服务接口返回至所述目标业务插件。

这样，本发明实施例在创建业务插件需要使用的服务接口的目标实现类的实例之前，首先看内存中是否存在该目标实现类的实例，如果存在，则说明该目标实现类已经被其他插件调用过，所以，为了节省时间，所述serviceloader可以直接读取缓存中的该目标实现类的实例，并响应于该调用请求，将该实例通过目标服务接口返回给目标业务插件，可以提升业务插件的业务性能。

步骤104，所述serviceloader层响应于所述调用请求，将所述目标实现类的实例通过所述目标服务接口返回至所述目标业务插件。

在本发明实施例中，通过在业务插件和宿主app之间设置抽象层，将宿主app能够提供的服务抽象成服务接口，并在宿主app中设置接入层，以对接入的业务插件所使用的服务接口进行实现，并创建服务接口与实现类的名称之间的对应关系，而在使用某个业务插件时，则只需要借助于serviceloader就可以根据上述对应关系获取到该业务插件需要使用的服务的实现类的实例，并通过该业务插件所访问的服务接口来将该实现类的实例返回给该业务插件，使得同一个业务插件能够应用到使用不同技术栈的多种具有安卓系统的宿主app，即平台app，大大提高了代码开发效率，降低了代码维护成本。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明实施例并不受所描述的动作顺序的限制，因为依据本发明实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本发明实施例所必须的。

与上述本发明实施例所提供的方法相对应，参照图3，示出了本发明一种应用程序实施例的结构框图，具体可以包括如下模块：

宿主应用程序31；

抽象层32，包括多个服务接口321，其中，每个服务接口321用于描述所述宿主应用程序31能够提供的服务；

至少一个业务插件33，用于接入至所述宿主应用程序31；

其中，所述宿主应用程序31包括接入层311；

所述接入层311，用于对接入的每个业务插件33创建该业务插件33需要使用的所有服务接口的实现类，以及创建并保存所述服务接口的名称与所述实现类的名称的对应关系；

所述宿主应用程序31，包括所述接入层创建的所述实现类以及所述对应关系；

serviceloader层35；

其中，所述serviceloader层35，用于接收所述至少一个业务插件33中目标业务插件对目标服务接口的调用请求；

所述serviceloader层35，用于根据所述调用请求查询所述对应关系中与所述目标服务接口的名称对应的目标实现类的名称；

所述serviceloader层35，用于根据所述目标实现类的名称，通过反射创建所述目标实现类的实例；

所述serviceloader层35，用于响应于所述调用请求，将所述目标实现类的实例通过所述目标服务接口返回至所述目标业务插件。

可选地，所述调用请求包括所述目标服务接口的名称；

所述serviceloader层35，用于根据所述目标服务接口的名称在所述对应关系中查询与所述目标服务接口的名称对应的目标实现类的名称。

可选地，所述接入层311，用于将创建的所述服务接口的名称与所述实现类的名称的对应关系存储在配置文件中；

所述serviceloader层35，用于根据所述调用请求查询所述配置文件中的对应关系，确定与所述目标服务接口的名称对应的目标实现类的名称。

可选地，

所述serviceloader层35，用于判断缓存中是否存在所述目标实现类的实例；

所述serviceloader层35，用于若缓存中不存在所述目标实现类的实例，则根据所述目标实现类的名称，通过反射创建所述目标实现类的实例；

所述serviceloader层35，用于将所述目标实现类的实例缓存在内存中。

可选地，所述serviceloader层35，用于若缓存中存在所述目标实现类的实例，则响应于所述调用请求，将缓存中所述目标实现类的实例通过所述目标服务接口返回至所述目标业务插件。

对于产品实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本发明实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本发明实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本发明实施例是参照根据本发明实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

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