组件框架系统以及组件框架系统的使用方法与流程

本发明涉及通信技术领域，特别是涉及一种组件框架系统以及组件框架系统的使用方法。

背景技术：

目前，服务类型的应用程序(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的技术栈相对应的，业务组件与平台app的耦合性高，对平台依赖严重，无法使用技术栈a编写的电影业务组件应用到使用技术栈b的平台app1，相反，使用技术栈a编写的电影业务组件只可以应用到使用技术栈a的平台app2中。

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

技术实现要素：

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

为了解决上述问题，根据本发明的一个方面，本发明公开了一种组件框架系统的使用方法。

所述组件框架系统包括：

业务组件层，包括至少一个业务组件，其中，所述至少一个业务组件用于接入至多个宿主应用程序；

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

平台组件层，包括多个平台组件模块，其中，所述多个平台组件模块分别对应所述多个宿主应用程序，每个平台组件模块包括对应的宿主应用程序的多个封装方法和资源，其中，所述多个封装方法包括所述对应的宿主应用程序针对所述至少一个业务组件需要使用的所有公共服务接口的实现方法，所述资源包括所述对应的宿主应用程序在调用所述至少一个业务组件时需要使用的所有资源；

其中，不同的平台组件模块包括不同的配置文件，所述配置文件用于描述业务组件层、所述接口组件层以及所述平台组件层之间的调用关系；

每个所述配置文件对应一个平台组件模块的标识；

每个平台组件模块的配置文件包括业务组件的名称、公共服务接口的名称、以及该平台组件模块实现所述公共服务接口的封装方法的名称的对应关系；

所述方法包括：

将所述组件框架系统接入至所述多个宿主应用程序中的目标宿主应用程序；

目标公共服务接口接收所述至少一个业务组件中目标业务组件对目标公共服务接口的调用请求，所述调用请求包括所述目标宿主应用程序的目标平台组件模块的标识、所述目标业务组件的名称、所述目标公共服务接口的名称；

所述目标公共服务接口根据所述调用请求确定与所述目标平台组件模块的标识对应的目标平台组件模块的目标配置文件；

所述目标公共服务接口根据所述目标配置文件确定与所述目标业务组件的名称以及所述目标公共服务接口的名称对应的目标封装方法的名称；

所述目标公共服务接口根据所述目标封装方法的名称从所述目标平台组件模块获取目标封装方法；

所述目标公共服务接口响应于所述调用请求，将所述目标封装方法返回至所述目标业务组件。

根据本发明的另一方面，本发明还公开了一种组件框架系统，包括：

业务组件层，包括至少一个业务组件，其中，所述至少一个业务组件用于接入至多个宿主应用程序；

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

平台组件层，包括多个平台组件模块，其中，所述多个平台组件模块分别对应所述多个宿主应用程序，每个平台组件模块包括对应的宿主应用程序的多个封装方法和资源，其中，所述多个封装方法包括所述对应的宿主应用程序针对所述至少一个业务组件需要使用的所有公共服务接口的实现方法，所述资源包括所述对应的宿主应用程序在调用所述至少一个业务组件时需要使用的所有资源；

其中，不同的平台组件模块包括不同的配置文件，所述配置文件用于描述业务组件层、所述接口组件层以及所述平台组件层之间的调用关系；

每个所述配置文件对应一个平台组件模块的标识；

每个平台组件模块的配置文件包括公共服务接口的名称与该平台组件模块实现公共服务接口的封装方法的名称的对应关系；

目标公共服务接口，用于若所述组件框架系统接入至所述多个宿主应用程序中的目标宿主应用程序，则接收所述至少一个业务组件中目标业务组件对目标公共服务接口的调用请求，所述调用请求包括所述目标宿主应用程序的目标平台组件模块的标识、所述目标业务组件的名称、所述目标公共服务接口的名称；

所述目标公共服务接口，用于根据所述调用请求确定与所述目标平台组件模块的标识对应的目标平台组件模块的目标配置文件；

所述目标公共服务接口，用于根据所述目标配置文件确定与所述目标业务组件的名称以及所述目标公共服务接口的名称对应的目标封装方法的名称；

所述目标公共服务接口，用于根据所述目标封装方法的名称从所述目标平台组件模块获取目标封装方法；

所述目标公共服务接口，用于响应于所述调用请求，将所述目标封装方法返回至所述目标业务组件。

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

这样，在本发明实施例中，通过在业务组件层和平台组件层之间设置抽象的接口组件层，将各个宿主app共同能够提供的服务抽象成接口组件层中的公共服务接口，并在平台组件层中各个宿主app的平台组件模块中设置针对各个接口组件需要使用的各个公共服务接口的封装方法和资源；以及在各个平台组件模块中设置配置文件，该配置文件包括业务组件的名称、公共服务接口的名称、以及该平台组件模块实现所述公共服务接口的封装方法的名称的对应关系，从而能够在使用某个业务组件时，则只需要借助于配置文件，就可以获取到该业务组件需要使用的服务的封装方法，并通过该业务组件所访问的公共服务接口来将该封装方法返回给该业务组件，使得同一个业务组件能够应用到使用不同技术栈的多种宿主app，即平台app，大大提高了代码开发效率，降低了代码维护成本。

附图说明

图1是本发明的一种组件框架系统实施例的结构框图；

图2是本发明的一种组件框架系统的使用方法实施例的步骤流程图；

图3是本发明的另一种组件框架系统实施例的结构框图。

具体实施方式

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

参照图1，示出了本发明的一种组件框架系统实施例的结构框图，该组件框架系统可以应用于具有ios系统的平台app，该组件框架系统具体可以包括：

业务组件层(即图1中的业务组件)，包括至少一个业务组件，这里包括业务组件1、业务组件2、业务组件3和业务组件4。其中，所述至少一个业务组件用于接入至多个宿主应用程序，也就是说，该组件框架系统中业务组件层中的每个业务组件都是可以接入各个平台应用程序的，例如猫眼app、大众点评app、美团app等。

且业务组件层是可扩展的，在实际开发过程中，可以根据应用需求，在业务组件层添加可以平铺到各个平台app的新的业务组件，例如扩展到业务组件5。

接口组件层(即图1中的接口组件)，包括多个公共服务接口，其中，每个公共服务接口用于描述所述多个宿主应用程序共同能够提供的服务；

其中，接口组件层是连接平台app(即宿主应用程序)的重要部分，因为各个平台会使用一些公共组件，但是，这些公共组件的使用方式千差万别(例如分享组件将标题、内容等字段值进行分享时的不同的处理方式，或者登录组件的不同登录方式等等)。因此，本发明实施例中，首先，确定需要平铺同一业务组件的各个平台app所能够提供的服务，然后在各个平台app所能够提供的服务中确定共同的服务，然后，将各个平台app的共同的服务抽象为接口，即这里的公共服务接口。其中，宿主app(即平台app)的各种能力都是一种服务。

本发明实施例中，各个宿主app都是ios系统，即，本发明实施例的组件框架系统是应用于ios系统的，来实现ios系统上跨平台app的组件化方案。本发明实施例利用ios平台运行时的特性对各个平台app的公共组件部分封装成统一接口，使得业务层开发人员通过统一接口可以快速实现自己业务而无需关心底层实现。

其中，在不同实施例中，该公共服务接口包括但不限于硬件服务接口、图片服务接口、网络服务接口、定位服务接口等。

平台组件层，包括多个平台组件模块，这里包括对应宿主app1的平台组件模块1、对应宿主app2的平台组件模块2、对应宿主app3的平台组件模块3、对应宿主app4的平台组件模块4。其中，平台组件层是可扩展的，在实际开发过程中，可以根据应用需求，在平台组件层添加更多需要将上述业务组件层中的业务组件平铺到的平台app，例如扩展到平台组件模块5。

其中，所述多个平台组件模块分别对应所述多个宿主应用程序，即，业务组件需要接入的多个宿主应用程序。例如本发明实施例开发的组件框架系统需要应用到猫眼app、大众点评app、美团app，那么平台组件层则包括猫眼app的平台组件模块、大众点评app的平台组件模块、美团app的平台组件模块。

平台组件模块主要用于存放和平台相关的资源文件(例如图片资源)以及一些特殊处理代码(即封装方法)。平台组件模块的具体实现完全依赖于平台差异性，与平台依赖性较高。

如上所述，接口组件层中的公共服务接口只是抽象的接口，没有对服务的具体实现，而各个平台针对同一个公共服务接口的具体实现方式又都是存在差异的，因此，本发明实施例将对各个平台对公共服务接口的差异化实现封装在平台组件层中的各个平台组件模块中。举例来说，对应宿主app1的的平台组件模块1中存放了宿主app1针对硬件服务接口的具体实现方法，即封装方法；对应宿主app2的的平台组件模块2中存放了宿主app2针对接口组件层中同一个硬件服务接口的具体实现方法，即封装方法。

每个平台组件模块包括对应的宿主应用程序的多个封装方法和资源，其中，所述多个封装方法包括所述对应的宿主应用程序针对所述至少一个业务组件需要使用的所有公共服务接口的实现方法，所述资源包括所述对应的宿主应用程序在调用所述至少一个业务组件时需要使用的所有资源；

以业务组件层中的业务组件1为例进行说明，业务组件1需要使用的公共服务接口包括图片服务接口、网络服务接口以及定位服务接口，那么平台组件模块1中需要对上述三个服务接口进行实现，而实现方法则是与宿主app1的技术栈相关的实现方法，该实现方法与宿主app1的依赖性较高，耦合性较高。其中，以图片服务接口为例，宿主app1对业务组件1使用的图片服务接口的封装方法可以是一个或多个。此外，如果业务组件2也需要使用图片服务接口，那么宿主app1对业务组件2使用的该图片服务接口的封装方法可以与业务组件1使用的该图片服务接口的封装方法相同或不同。

也就是说，某个宿主app对不同业务组件所使用的同一个公共服务接口的实现方法可以相同或不同。即，针对某个平台组件模块中的封装方法而言，其是与公共服务接口和业务组件均关联对应的。

其中，接口组件中包括各个平台共同能够提供的服务，但是每个平台对服务的实现方式不同，所以，在平台组件层需要对公共服务的实现方法分别按照平台特性进行封装。

此外，每个宿主app的平台组件模块还包括资源，该资源包括宿主app在调用所述至少一个业务组件时需要使用的所有资源；

例如宿主app1的平台组件模块包括宿主app1在调用业务组件层中的任意一个业务组件时需要使用的所有资源。

其中，不同的平台组件模块包括不同的配置文件；

所述配置文件用于描述业务组件层、所述接口组件层以及所述平台组件层之间的调用关系；

每个所述配置文件对应一个平台组件模块的标识，也就是说，每个宿主app的平台组件模块都分配了唯一的配置文件，且各个平台组件模块的配置文件之间无关联。

每个平台组件模块的配置文件包括业务组件的名称、公共服务接口的名称、以及该平台组件模块实现所述公共服务接口的封装方法的名称的对应关系；

以宿主app1的平台组件模块1的配置文件为例进行说明：

业务组件1名称～公共服务接口1名称～宿主app1实现的封装方法1的名称；

业务组件1名称～公共服务接口1名称～宿主app1实现的封装方法2的名称；

业务组件2名称～公共服务接口1名称～宿主app1实现的封装方法3的名称；

业务组件2名称～公共服务接口1名称～宿主app1实现的封装方法4的名称。

可选地，所述组件框架系统还包括：

资源管理组件，用于对所述多个平台组件模块中的资源进行管理；

其中，资源管理组件主要实现资源文件的加载和获取，保证不同宿主app都能获取到自己需要的资源文件。

因为，不同的宿主app对同一个业务页面中同一个区域所展示的资源文件也是各不相同的，例如宿主app1对影片购票页面中的购票按钮展示的颜色是颜色1，宿主app2对影片购票页面中处于同一位置的购票按钮展示的颜色是颜色2。因此，针对不同宿主app的同一个业务组件来说，其展示的资源(例如图片资源，色值样式等)也是各不相同。所以，这里需要设置资源管理组件，来实现对不同宿主app获取不同的资源。

其中，每个所述配置文件还对应一个平台组件模块的资源包名；

其中，每个宿主app之间针对同一业务组件的个性化展示资源都存储在具有该资源包名的资源包中。

可选地，所述业务组件层中的不同业务组件之间通过预设协议进行跳转。

例如业务组件1为影片购票页面，业务组件为影片详情页面，在业务组件层中在影片购票页面展示完成后，可以通过预设协议来跳转到对影片详情页面的展示业务，则不同业务组件之间通过预设协议(例如scheme跳转协议)来进行业务组件之间的跳转。

例如"maoyan://maoyan.com/movies？goodsid＝8897"；

maoyan代表scheme协议名称；

maoyan.com代表scheme作用的地址域；

/movies代表的是指定页面(路径)。

这样，本发明实施例可以实现业务组件层中各个业务组件的独立添加与移除，并实现业务组件之间的横向跳转。

可选地，如图1所示，该组件框架系统还可以包括：基础组件。

其中，本发明实施例可以将各个宿主app中与平台无依赖关系的基础组件抽取出来，例如独立的ui组件、工具组件、通用处理(日期处理、安全检查等)，基础组件都是被实现好的且能够通用任何平台app的组件，而非抽象接口。其不会依赖平台相关组件，是独立一部分。

其中，如图1所示，业务组件层可以直接访问基础组件、接口组件、资源管理组件，但是无法直接访问平台组件层。

基于上述实施例中的组件框架系统，参照图2，示出了本发明的一种组件框架系统的使用方法实施例的步骤流程图，具体可以包括如下步骤：

步骤101，将所述组件框架系统接入至所述多个宿主应用程序中的目标宿主应用程序；

其中，在开发了如图1所示的组件框架系统后，就可以将该组件框架系统接入到上述宿主app1、宿主app2、宿主app3和宿主app4中的任意一个app中，例如将该组件框架系统接入到上述宿主app1中。

在一个示例中，可以利用包管理器(cocoapods)来将本发明实施例的组件框架系统接入到宿主app1中，并针对该宿主app1建立上述配置文件。这个配置文件主要用于获取图1所示的组件框架系统的组件代码、资源文件以及对组件框架系统的版本号管理。

需要说明的是，随着业务组件层、接口组件层以及平台组件层的扩展，本发明实施例的组件框架系统可以由很多种版本，因此，可以根据组件框架系统的版本号来对宿主app1上接入的组件框架系统进行版本更新，从而能够接入具有更多业务组件的组件框架系统。

步骤102，目标公共服务接口接收所述至少一个业务组件中目标业务组件对目标公共服务接口的调用请求，所述调用请求包括所述目标宿主应用程序的目标平台组件模块的标识、所述目标业务组件的名称、所述目标公共服务接口的名称；

其中，例如业务组件1(即目标业务组件)被宿主app1(即目标宿主应用程序)调用，则业务组件1需要使用接口组件层中的公共服务接口1(即目标公共服务接口)，所以业务组件1可以向公共服务接口1发送调用请求，其中，该调用请求中携带了宿主app1的平台组件模块1的标识、业务组件1的名称以及公共服务接口1的名称。那么公共服务接口1就可以接收到来自业务组件1的该调用请求。

步骤103，所述目标公共服务接口根据所述调用请求确定与所述目标平台组件模块的标识对应的目标平台组件模块的目标配置文件；

由于公共服务接口1中没有对该公共服务1的具体实现方法，所以公共服务接口1首先需要根据所述调用请求中的平台组件模块1的标识，来确定与平台组件模块1的标识对应的平台组件模块1的配置文件1。

步骤104，所述目标公共服务接口根据所述目标配置文件确定与所述目标业务组件的名称以及所述目标公共服务接口的名称对应的目标封装方法的名称；

可选地，在一个实施例中，在执行步骤104时，所述目标公共服务接口可以在所述目标配置文件中的所述对应关系中，查找与所述目标业务组件的名称以及所述目标公共服务接口的名称均对应的目标封装方法的名称。

其中，根据图1所述的实施例可知，配置文件1中记载了业务组件层中各个业务组件的名称、公共服务接口的名称、以及该平台组件模块1实现所述公共服务接口的封装方法的名称的对应关系；

宿主app1的平台组件模块1的配置文件包括如下对应关系：

业务组件1名称～公共服务接口1名称～宿主app1实现的封装方法1的名称；

业务组件1名称～公共服务接口1名称～宿主app1实现的封装方法2的名称；

业务组件2名称～公共服务接口1名称～宿主app1实现的封装方法3的名称；

业务组件2名称～公共服务接口1名称～宿主app1实现的封装方法4的名称。

那么在上述配置文件中的所述对应关系中可以查找到与所述业务组件1名称以及所述公共服务接口1名称均对应的目标封装方法的名称包括封装方法1的名称和封装方法2的名称。也就是说，在宿主app1中，在执行业务组件1的业务时，需要使用封装方法1和封装方法2还实现该公共服务接口1。

这里的目标封装方法的数量为两个，在其他实施例中，该目标封装方法可以是一个或多个。

步骤105，所述目标公共服务接口根据所述目标封装方法的名称从所述目标平台组件模块获取目标封装方法；

其中，该调用请求中携带了平台组件模块1的标识，因此，该公共服务接口1可以直接去平台组件模块1中去获取封装方法1的名称对应的封装方法1，以及封装方法2的名称对应的封装方法2。

步骤106，所述目标公共服务接口响应于所述调用请求，将所述目标封装方法返回至所述目标业务组件。

其中，该公共服务接口1在接收到来自平台组件模块1的封装方法1和封装方法2后，就可以响应于业务组件1的调用请求，来将封装方法1和封装方法2返回给业务组件1。

这样，在本发明实施例中，通过在业务组件层和平台组件层之间设置抽象的接口组件层，将各个宿主app共同能够提供的服务抽象成接口组件层中的公共服务接口，并在平台组件层中各个宿主app的平台组件模块中设置针对各个接口组件需要使用的各个公共服务接口的封装方法和资源；以及在各个平台组件模块中设置配置文件，该配置文件包括业务组件的名称、公共服务接口的名称、以及该平台组件模块实现所述公共服务接口的封装方法的名称的对应关系，从而能够在使用某个业务组件时，则只需要借助于配置文件，就可以获取到该业务组件需要使用的服务的封装方法，并通过该业务组件所访问的公共服务接口来将该封装方法返回给该业务组件，使得同一个业务组件能够应用到使用不同技术栈的多种宿主app，即平台app，大大提高了代码开发效率，降低了代码维护成本。

可选地，如图1所示，所述组件框架系统还可以包括：

资源管理组件，用于对所述多个平台组件模块中的资源进行管理；

其中，每个所述配置文件还对应一个平台组件模块的资源包名；

其中，每个所述配置文件包括资源标识和与宿主应用程序相关联的资源名称的对应关系。

也就是说，对于不同宿主app来说，同一个业务组件中同一展示区域的资源文件的资源标识都是相同的，但是在不同平台组件模块中该资源标识对应的资源名称是不同的，使得不同宿主app可以对同一业务组件中同一展示区域的资源不同，例如宿主app1对页面1中位置1显示的图片a的颜色是颜色1，宿主app2对页面1中位置1显示的图片a的颜色是颜色2。所以，同一个业务组件在不同的平台上，在同一位置上所展示的资源可能不一样，但是该资源的标识是不变的。在宿主app1的平台组件模块1中对该图片a的颜色资源的名称是名称1，对应的颜色资源为红色；在宿主app2的平台组件模块2中对该图片a的颜色资源的名称是名称2，对应的颜色资源为绿色；

也就是说，资源标识是与平台无关的，但是资源名称是与平台(即宿主app)有关的。

那么根据本发明实施例的方法还可以包括：

所述资源管理组件接收所述目标业务组件的资源请求，所述资源请求包括目标资源标识、目标资源所在的目标资源包名；

也就是说，该业务组件1还可以从平台组件模块1中获取所需要的与平台相关的资源，该资源请求可以与上述调用请求相关或不相关，本发明对此并不限定。

其中，业务组件1可以向资源管理组件发送资源请求，其中，所述资源请求包括想要获取的目标资源标识、目标资源所在的目标资源包名；

其中，每个平台组件模块都有一个资源包，不同平台组件模块的资源包的资源包名不同。

所述资源管理组件确定与所述资源请求中的所述目标资源包名对应的目标平台组件模块的目标配置文件；

其中，资源管理组件在接收到业务组件1发送的资源请求后，可以首先确定与资源请求中的目标资源包名对应的目标平台组件模块，即平台组件模块1，然后，再确定该平台组件模块1的配置文件1。

所述资源管理组件根据所述目标配置文件确定与所述目标资源标识对应的目标资源名称；

其中，由于配置文件1写有该宿主app1所使用的所有与平台相关的资源的资源标识与资源名称的对应关系，因此，可以从该对应关系中查找该目标资源标识对应的目标资源名称。

所述资源管理组件根据所述目标资源名称从所述目标平台组件模块的资源中获取目标资源；

其中，由于平台组件模块1中包括与宿主app依赖相关的资源，所以，可以从平台组件模块1的资源包中获取与该目标资源名称对应的资源。

所述资源管理组件响应于所述资源请求，将所述目标资源返回至所述目标业务组件。

其中，资源管理组件从平台组件模块1中获取到目标资源后，可以响应于该资源请求，将目标资源返回给业务组件1。

其中，在一个实施例中，如果上述调用请求和该资源请求是针对同一个页面的，则该目标资源就可以应用到上述封装方法1和/或封装方法2中，从而展示出业务组件1对应的业务页面，而该业务网页中所展示的资源则是与该宿主app1相同的资源。

可选地，在一个实施例中，在业务组件1被宿主app1调用时，该业务组件也可能使用到基础组件，例如通用任何平台的共用的ui组件(例如一个按钮或者一个标签等)，则业务组件1可以直接向基础组件1发起对目标基础组件的调用请求，则该基础组件中的目标基础组件就可以根据该调用请求获取例如请求的按钮或者标签，然后直接返回给业务组件1，无需与平台组件层通信。

可选地，所述业务组件层中的不同业务组件之间通过预设协议进行跳转。

例如业务组件1经过上述对基础组件、接口组件以及资源管理组件的调用后，获取到所需要的基础组件、封装方法、资源后，就可以完成业务处理，例如展示一个电影购票页面，在业务组件1执行完成之后，由于业务组件1预先可以注册协议地址，然后，就可以根据该协议地址来在业务组件层中进行横向跳转，例如跳转到业务组件2进行电影详情页面的展示。然后，业务组件2又会向图1中的接口组件层、或进一步包括基础组件和/或资源管理组件发起请求，以便展示该电影详情页面，具体的方法与上述实施例中对业务组件1的请求的执行方法类似，这里不再赘述。

借助于本发明上述实施例的技术方案，本发明实施例提供了组件框架系统，该组件框架系统中提供了统一接口组件来抹平ios系统的各个app平台之间的差异性。并利用包管理器特性为不同app平台提供不同版本的组件框架系统；此外，本发明实施例创建了一套管理资源的方式，通过此方案可以保证获取资源时达到不同平台只需根据资源标识既可以获取不同资源。另外，对各个组件通过分层方式进行管理，同时各个组件都是相对独立部分。业务组件层只对接中间的接口组件层，基础组件层、资源管理组件，不与平台组件层进行任何直接通信。另外，本发明实施例的组件框架系统集成方便，平台app只需在自己的包管理器中引入该组件框架系统的名称和版本号即可在项目中通过协议方式进行调用。另外，该组件框架系统的扩展方便，各个层都可以快速扩展。

本发明实施例的组件框架系统通过底层统一接口隔离app平台差异性，上层结构只需关心具体业务的实现，同时所有不同业务组件和基础组件都通过同一层的组件方式进行开发集成，从而实现了一种层次结构清晰，可模块化开发，易扩展，代码复用率高，一次修改多端快速部署的方案。

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

与上述本发明实施例所提供的方法相对应，参照图3，示出了本发明一种组件框架系统实施例的结构框图，具体可以包括：

业务组件层31，包括至少一个业务组件，其中，所述至少一个业务组件用于接入至多个宿主应用程序；

接口组件层32，包括多个公共服务接口，其中，每个公共服务接口用于描述所述多个宿主应用程序共同能够提供的服务；

平台组件层33，包括多个平台组件模块，其中，所述多个平台组件模块分别对应所述多个宿主应用程序，每个平台组件模块包括对应的宿主应用程序的多个封装方法和资源，其中，所述多个封装方法包括所述对应的宿主应用程序针对所述至少一个业务组件需要使用的所有公共服务接口的实现方法，所述资源包括所述对应的宿主应用程序在调用所述至少一个业务组件时需要使用的所有资源；

其中，不同的平台组件模块包括不同的配置文件，所述配置文件用于描述业务组件层、所述接口组件层以及所述平台组件层之间的调用关系；

每个所述配置文件对应一个平台组件模块的标识；

每个平台组件模块的配置文件包括公共服务接口的名称与该平台组件模块实现公共服务接口的封装方法的名称的对应关系；

目标公共服务接口，用于若所述组件框架系统接入至所述多个宿主应用程序中的目标宿主应用程序，则接收所述至少一个业务组件中目标业务组件对目标公共服务接口的调用请求，所述调用请求包括所述目标宿主应用程序的目标平台组件模块的标识、所述目标业务组件的名称、所述目标公共服务接口的名称；

所述目标公共服务接口，用于根据所述调用请求确定与所述目标平台组件模块的标识对应的目标平台组件模块的目标配置文件；

所述目标公共服务接口，用于根据所述目标配置文件确定与所述目标业务组件的名称以及所述目标公共服务接口的名称对应的目标封装方法的名称；

所述目标公共服务接口，用于根据所述目标封装方法的名称从所述目标平台组件模块获取目标封装方法；

所述目标公共服务接口，用于响应于所述调用请求，将所述目标封装方法返回至所述目标业务组件。

可选地，所述目标公共服务接口，用于在所述目标配置文件中的所述对应关系中，查找与所述目标业务组件的名称以及所述目标公共服务接口的名称均对应的目标封装方法的名称。

可选地，所述组件框架系统还包括：

资源管理组件，用于对所述多个平台组件模块中的资源进行管理；

其中，每个所述配置文件还对应一个平台组件模块的资源包名；

每个所述配置文件包括资源标识和与宿主应用程序相关联的资源名称的对应关系；

所述资源管理组件，用于接收所述目标业务组件的资源请求，所述资源请求包括目标资源标识、目标资源所在的目标资源包名；

所述资源管理组件，用于确定与所述资源请求中的所述目标资源包名对应的目标平台组件模块的目标配置文件；

所述资源管理组件，用于根据所述目标配置文件确定与所述目标资源标识对应的目标资源名称；

所述资源管理组件，用于根据所述目标资源名称从所述目标平台组件模块的资源中获取目标资源；

所述资源管理组件，用于响应于所述资源请求，将所述目标资源返回至所述目标业务组件。

可选地，所述业务组件层中的不同业务组件之间通过预设协议进行跳转。

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

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

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

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

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

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

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

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

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