CN107526605B - 实现应用程序加载服务组件的方法和装置 - Google Patents

Abstract

本公开揭示了一种应用程序加载服务组件的方法和装置。所述方法包括：获取应用程序中被触发生成的服务指令；根据所述服务指令触发所述应用程序自身集成的插件框架读取配置文件；加载所述配置文件指定的软件开发工具包插件，得到所述软件开发工具包插件集成的软件开发工具包；通过所述集成的软件开发工具包调用服务组件。此外，还提供了一种应用程序加载服务组件的装置。上述应用程序加载服务组件的方法和装置能够动态切换服务组件，避免了一旦服务组件出现缺陷便导致应用程序无法正常运行的局限性。

Description

实现应用程序加载服务组件的方法和装置

技术领域

本公开涉及计算机应用技术领域，特别涉及一种实现应用程序加载服务组件的方法和装置。

背景技术

应用程序的运行中，大都是通过加载服务组件来实现其所提供的服务。例如，对于实现网页浏览功能的应用程序而言，所指的服务组件即为浏览器内核。

以浏览器内核为例，终端设备中部署的浏览器允许应用程序调用其自身的浏览器内核，以实现应用程序中的网页浏览服务。在此实现中，需要应用程序集成浏览器提供的软件开发工具包，应用程序通过集成的软件开发工具包方能够调用浏览器内核。

但是，在此实现中，由于浏览器提供的软件开发工具包内嵌在应用程序中，只能调用单一的浏览器内核。一旦浏览器内核出现缺陷便会使得应用程序无法正常运行，并且只能够通过更换应用程序来得到解决。

由此可知，现有的应用程序加载服务组件中，存在着无法动态切换服务组件的局限性。

发明内容

为了解决相关技术中存在的无法动态切换服务组件的技术问题，本公开提供了一种实现应用程序加载服务组件的方法和装置。

一种实现应用程序加载服务组件的方法，包括：

获取应用程序中被触发生成的服务指令；

根据所述服务指令触发所述应用程序自身集成的插件框架读取配置文件；

加载所述配置文件指定的软件开发工具包插件，得到所述软件开发工具包插件集成的软件开发工具包；

通过所述集成的软件开发工具包调用服务组件。

一种实现应用程序加载服务组件的方法，包括：

当应用程序被触发启动时，根据所述应用程序自身支持的服务组件动态部署服务器配置的软件开发工具包插件，获得所述软件开发工具包插件支持的服务组件；

获取应用程序中被触发生成的服务指令；

根据所述服务指令动态加载指定的软件开发工具包插件，通过所述软件开发工具包插件的动态加载获得集成的软件开发工具包；

通过所述集成的软件开发工具包调用服务组件。

一种实现应用程序加载服务组件的装置，所述装置包括：

指令获取模块，用于获取应用程序中被触发生成的服务指令；

配置读取模块，用于根据所述服务指令触发所述应用程序自身集成的插件框架读取配置文件；

插件加载模块，用于加载所述配置文件指定的软件开发工具包插件，得到所述软件开发工具包插件集成的软件开发工具包；

调用模块，用于通过所述集成的软件开发工具包调用服务组件。

一种实现应用程序加载服务组件的装置，所述装置包括：

部署模块，用于当应用程序被触发启动时，根据所述应用程序自身支持的服务组件动态部署服务器配置的软件开发工具包插件，获得所述软件开发工具包插件支持的服务组件；

服务发起模块，用于获取应用程序中被触发生成的服务指令；

指定加载模块，用于根据所述服务指令动态加载指定的软件开发工具包插件，通过所述软件开发工具包插件的动态加载获得集成的软件开发工具包；

组件调用模块，用于通过所述集成的软件开发工具包调用服务组件。

一种实现应用程序加载服务组件的装置，所述装置包括：

处理器；

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

其中，所述处理器被配置：

获取应用程序中被触发生成的服务指令；

根据所述服务指令触发所述应用程序自身集成的插件框架读取配置文件；

加载所述配置文件指定的软件开发工具包插件，得到所述软件开发工具包插件集成的软件开发工具包；

通过所述集成的软件开发工具包调用服务组件。

一种实现应用程序加载服务组件的装置，所述装置包括：

处理器；

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

其中，所述处理器被配置：

当应用程序被触发启动时，根据所述应用程序自身支持的服务组件动态部署服务器配置的软件开发工具包插件，获得所述软件开发工具包插件支持的服务组件；

获取应用程序中被触发生成的服务指令；

根据所述服务指令动态加载指定的软件开发工具包插件，通过所述软件开发工具包插件的动态加载获得集成的软件开发工具包；

通过所述集成的软件开发工具包调用服务组件。

本公开的实施例提供的技术方案可以包括以下有益效果：

在获得应用程序被触发生成的服务指令时，根据服务指令触发应用程序自身集成的插件框架读取配置文件，加载配置文件指定的软件开发工具包插件，得到软件开发工具包插件集成的软件开发工具包，再通过所集成的软件开发工具包调用服务组件，在此实现中，用于调用服务组件的软件开发工具包是通过插件的形式集成在软件开发工具包中，软件开发工具包与应用程序相互独立，并且通过应用程序中进行的动态加载实现指定的软件开发工具包插件的加载，因此，能够通过动态加载所需要的软件开发工具包来实现服务组件的动态切换，一旦服务组件出现缺陷也只需要升级软件开发工具包插件就能够得到解决，不需要更换整个应用程序，进而避免了由此所导致的诸多问题。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并于说明书一起用于解释本发明的原理。

图1是根据本公开所涉及的实施环境的示意图；

图2是根据一示例性实施例示出的一种装置的框图；

图3是根据一示例性实施例示出的一种实现应用程序加载服务组件的方法的流程图；

图4是根据另一示例性实施例示出的一种实现应用程序加载服务组件的方法的流程图；

图5是根据另一示例性实施例示出的一种实现应用程序加载服务组件的方法的流程图；

图6是图5对应实施例的当应用程序被触发启动时，根据应用程序自身支持的服务组件动态部署服务器配置的软件开发工具包插件步骤的流程图；

图7是根据另一示例性实施例示出的一种实现应用程序加载服务组件的方法的流程图；

图8是根据另一示例性实施例示出的一种实现应用程序加载服务组件的方法的流程图；

图9是根据另一示例性实施例示出的一种实现应用程序加载服务组件的方法在服务器侧的流程图；

图10是图9对应实施例的根据服务组件信息进行匹配处理生成处理结果，向应用程序返回处理结果步骤的流程图；

图11是图10对应实施例的根据未命中的服务组件生成处理结果，向应用程序返回处理结果步骤的流程图；

图12是根据一示例性实施例求出的一应用程序示意图；

图13是根据一示例性实施例示出的动态部署的流程图；

图14是根据一示例性实施例示出的使用软件开发工个包插件的调用服务组件的流程图；

图15是根据一示例性实施例示出的动态加载实现的流程图；

图16是根据一示例性实施例示出的应用程序调用软件开发工具包插件的实现的流程图；

图17是根据一示例性实施例示出的软件开发工具包插件的实现的流程图；

图18是根据一示例性实施例示出的一种实现应用程序加载服务组件的装置的框图；

图19是根据另一示例性实施例示出的一种实现应用程序加载服务组件的装置的框图；

图20是根据另一示例性实施例示出的一种实现应用程序加载服务组件的装置的框图；

图21是图20对应实施例的动态部署模块的框图；

图22是根据另一示例性实施例示出的一种实现应用程序加载服务组件的装置的框图；

图23是根据另一示例性实施例示出的一种实现应用程序加载服务组件的装置的框图；

图24是图23对应实施例的匹配处理模块的框图；

图25是图24对应实施例的结果生成单元的框图。

具体实施方式

这里将详细地对示例性实施例执行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。

图1是根据本公开所涉及的实施环境的示意图。该实施环境包括：服务器110和至少一个终端设备130。

服务器110与终端设备130之间的关联方式，包括硬件的网络关联方式和/或协议，以及二者之间往来的数据关联方式。

可选的，终端设备130可以是各种移动终端，也可以是各种智能设备。

图2是根据一示例性实施例示出的一种装置200的框图。例如，装置200可以是图1所示实施环境中的终端设备。终端设备比如可以是智能手机、平板电脑等移动终端。比如也可以是智能电视、智能电视机顶盒、智能空调以及智能摄像头等各种智能设备。

参照图2，装置200可以包括以下一个或多个组件：处理组件202，存储器204，电源组件206，多媒体组件208，音频组件210，传感器组件214以及通信组件216。

处理组件202通常控制装置200的整体操作，诸如与显示，电话呼叫，数据通信，相机操作以及记录操作相关联的操作等。处理组件202可以包括一个或多个处理器218来执行指令，以完成上述的方法的全部或部分步骤。此外，处理组件202可以包括一个或多个模块，便于处理组件202和其他组件之间的交互。例如，处理组件202可以包括多媒体模块，以方便多媒体组件208和处理组件202之间的交互。

存储器204被配置为存储各种类型的数据以支持在装置200的操作。这些数据的示例包括用于在装置200上操作的任何应用程序或方法的指令。存储器204可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器（SRAM），电可擦除可编程只读存储器（EEPROM），可擦除可编程只读存储器（EPROM），可编程只读存储器（PROM），只读存储器（ROM），磁存储器，快闪存储器，磁盘或光盘。存储器204中还存储有一个或多个模块，该一个或多个模块被配置成由该一个或多个处理器218执行，以完成下述任一所示方法中的全部或者部分步骤。

电源组件206为装置200的各种组件提供电力。电源组件206可以包括电源管理***，一个或多个电源，及其他与为装置200生成、管理和分配电力相关联的组件。

多媒体组件208包括在所述装置200和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器（LCD）和触摸面板（TP）。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。

音频组件210被配置为输出和/或输入音频信号。例如，音频组件210包括一个麦克风（MIC），当装置200处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器204或经由通信组件216发送。在一些实施例中，音频组件210还包括一个扬声器，用于输出音频信号。

传感器组件214包括一个或多个传感器，用于为装置200提供各个方面的状态评估。例如，传感器组件214可以检测到装置200的打开/关闭状态，组件的相对定位，传感器组件214还可以检测装置200或装置200一个组件的位置改变以及装置200的温度变化。在一些实施例中，该传感器组件214还可以包括磁传感器，压力传感器或温度传感器。

通信组件216被配置为便于装置200和其他设备之间有线或无线方式的通信。装置200可以接入基于通信标准的无线网络，如WiFi，2G或3G，或它们的组合。在一个示例性实施例中，通信组件216经由广播信道接收来自外部广播管理***的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件216还包括近场通信（NFC）模块，以促进短程通信。例如，在NFC模块可基于射频识别（RFID）技术，红外数据协会（IrDA）技术，超宽带（UWB）技术，蓝牙（BT）技术和其他技术来实现。

在示例性实施例中，装置200可以被一个或多个应用专用集成电路（ASIC）、数字信号处理器（DSP）、数字信号处理设备（DSPD）、可编程逻辑器件（PLD）、现场可编程门阵列（FPGA）、控制器、微控制器、微处理器或其他电子元件实现，用于执行下述方法。

图3是根据一示例性实施例示出的一种实现应用程序加载服务组件的方法。该实现应用程序加载服务组件的方法用于图1所示实施环境的移动终端110，如图3所示，该实现应用程序加载服务组件的方法，可以由终端设备执行，可以包括以下步骤。

在步骤310中，获取应用程序中被触发生成的服务指令。

其中，应用程序指的是安装于终端设备中，需要实现服务的程序。比如，应用程序可以是通过网页实现浏览服务的程序，则网页浏览服务即为其所实现的服务；又比如，应用程序可以是附带了支付服务的程序，则支付服务即为其所实现的服务。换而言之，应用程序可以是任意程序，包括具备通用服务功能的程序。

服务指令用于在应用程序中触发执行相应的操作，以在应用程序中实现其所提供的服务，比如，如上所述的网络浏览服务、支付服务等。

服务指令是随着应用程序中服务的发起而触发生成的。比如，应用程序中触发进行了网络地址的加载，以发起网页浏览服务，此时，应用程序被触发生成服务指令，以便于执行网页浏览服务相关的操作。

需要进一步准确说明的是，应用程序指的是应用的主体程序。

在步骤330中，根据服务指令触发应用程序自身集成的框架插件读取配置文件。

其中，插件框架是指具有调用插件能力的模块，应用程序集成该模块，从而可以去调用插件。配置文件是控制应用程序中动态加载的软件开发工具包插件。通过配置文件中可用的软件开发工具包插件的声明在应用程序的动态加载中加载这一可用的软件开发工具包插件。

配置文件可以是服务器端配置的，也可以是软件端配置，在此不进行限定。对于服务器端配置的配置文件，将是服务器根据运营需要完成配置后向应用程序下发的配置文件。另一方面，应用程序通过配置文件来选择使用的软件开发工具包插件，并在配置文件中声明，由此便可以使用所选择的软件开发工具包插件。

应用程序自身集成的插件框架在服务指令被触发时，读取配置文件，以便于获知指定了哪一软件开发工具包插件进行加载。

在步骤350中，加载配置文件指定的软件开发工具包插件，得到软件开发工具包插件集成的软件开发工具包。

其中，软件开发工具包插件是集成了软件开发工具包的插件。软件开发工具包插件与应用程序两者之间是相互独立的。软件开发工具包插件寄存于应用程序的安装目录，换而言之，应用程序作为软件开发工具包插件的宿主，软件开发工具包插件实现应用程序中的一部分功能。

例如，软件开发工具包插件可以是浏览器软件开发工具包插件，自身集成了浏览器开发工具包。由于所对应的网页浏览服务组件，即浏览器内核的类型和版本的不同，存在着多种可供调用的浏览器内核，由此也相应部署了多种浏览器开发工具包插件。

一软件开发工具包插件中集成了一软件开发工具包。应用程序部署了多个软件开发工具包插件，在应用程序的运行中，通过动态加载来实现指定软件开发工具包插件的加载，进而获得集成的软件开发工具包。指定的软件开发工具包插件是与当前期望调用的服务组件唯一对应的。

通过动态加载使得应用程序不再仅限于加载单一的软件开发工具包，能够根据需要获得任一软件开发工具包。

在步骤350中，通过集成的软件开发工具包调用服务组件。

其中，软件开发工具包与服务组件之间是唯一对应的，一软件开发工具包用于调用一服务组件。因此，通过动态加载的软件开发工具包插件，将实现其自身集成的软件开发工具包唯一对应的服务组件的调用。

由此通过相对应用程序独立的软件开发工具包插件，来使得软件开发工具包相对应用程序也是独立存在的，因此，即便软件开发工具包所唯一对应的浏览器内核出现缺陷，也不需要更换整个应用程序，而只需要变换软件开发工具包插件即可。

也就是说，不再需要通过更换整个应用程序才能升级，能够支持软件开发工具包的独立升级，进而带来低成本、低流量、覆盖速度快和应用范围广等诸多优势。

具体的，应用程序将指定软件开发工具包插件的相关数据和代码信息均载入到内存块中，为应用程序和软件开发工具包插件之间的相互调用奠定基础。软件开发包工具包插件自身定义了代理视图类，代理视图类作为不同软件开发工具包的调用接口，是在应用程序和软件开发工具包之间定义的通用接口，从而实现应用程序具备调用不同软件开发工具包的能力。

配置文件指定的软件开发工具包插件的相关数据和代码信息被载入到内存块中，得到加载到内存块的软件开发工具包插件，此时，应用程序通过软件开发工具包插件自身定义的代理视图类访问集成的软件开发工具包。

由此，对于步骤350的具体实现细节，可以包括：调用访问的软件开发工具包，通过调用的软件开发工具包调用服务组件。

通过软件开发工具包插件以及软件开发工具包插件的动态加载，得以实现了应用程序中软件开发工具包插件的动态切换，进而使得服务组件的切换不再需要重新更换应用程序，例如，现有的实现中，如果需要替换浏览器内核，则相当于重新更换应用程序。

通过如上所述的实现过程，使得同一个线上版本的应用程序能够使用多种服务组件，例如，多种浏览器内核，进而能够对比多种服务组件的数据效果，也进一步提高了应用程序的稳定性和可靠性。

图4是根据一示例性实施例示出的一种实现应用程序加载服务组件的方法，该方法用于图1所示实施环境的终端设备中应用程序的运行过程。如图4所示，该实现应用程序加载服务组件的方法，可以包括以下步骤。

在步骤410中，当指定的软件开发工具包插件加载失败时，加载默认软件开发工具包插件，通过默认软件开发工具包插件的加载获得集成的软件开发工具包。

首先需要说明的是，应用程序部署了默认软件开发工具包插件，默认软件开发工具包插件的部署用于应用程序未能成功进行软件开发工具包插件的动态加载时也能够通过加载默认软件开发工具包来实现所需要的服务。

也就是说，将判断动态加载是否成功，若为是，则直接通过动态加载的软件开发工具包插件进行服务组件调用即可，若为是，则通过应用程序自身集成的插件框架加载默认软件开发工具包插件，进而即便动态加载失败也能够实现应用程序中的服务，提高了应用程序运行的可靠性。

默认软件开发工具包插件，与前述软件开发工具包插件相类似的，区别仅在于集成的软件开发工具包的不同。默认软件开发工具包插件也具备代理视图类，以便于实现应用程序和默认开发工具包插件的相互调用。

在步骤430中，通过集成的软件开发工具包调用默认服务组件。

其中，默认软件开发工具包插件所集成的软件工具包也有其所唯一调用的默认服务组件，与前述服务组件相类似的，通过默认服务组件的调用实现应用程序中的服务，进而确保应用程序能够有默认服务组件支撑应用程序的服务，例如，基本网页页面访问能力。

由此可知，在本公开的应用程序加载服务组件的实现中，无论是对于动态部署的软件开发工具包插件，还对于默认软件开发工具包插件而言，都不需要关注各种集成了何种软件开发工具包，都是根据其所支持的服务组件来动态加载软件开发工具包插件即可调用所希望的服务组件，能够实现服务组件的切换，且不需要重新更换整个应用程序，进而能够支持软件开发工具包的高效动态更新。

图5是根据一示例性实施例示出的一种实现应用程序加载服务组件的方法的流程图。该实现应用程序加载服务组件的方法用于图1所示实施环境的终端设备130，如图5所示，该实现应用程序加载服务组件的方法，由终端设备130执行，可以包括以下步骤。

在步骤510中，当应用程序被触发启动时，根据应用程序自身支持的服务组件动态部署服务器配置的软件开发工具包插件。

其中，应用程序被触发启动时，进行应用程序中软件开发工具包插件的动态部署。所指的动态部署是在服务器的配合下实现的，进而为应用程序部署服务器所配置的软件开发工具包插件，由此将能够根据运营的需要进行软件开发工具包插件的动态部署，应用程序中服务组件的加载能够适应于运营的需要，提高了应用程序中进行服务组件加载的自适应性。

步骤530，接收服务器下发的服务组件，该服务组件为服务器配置的软件开发工具插件自身支持的。

其中，应用程序中完成了软件开发工具包插件的动态部署之后，即可通过软件开发工具包插件从服务器获得服务组件，并安装部署该服务组件。

具体的，实现应用程序中软件开发工具包插件动态部署的服务器为应用程序的运营服务器，其作为应用程序云端来为应用程序进行动态更新；下发服务组件的服务器在具体实现时，是区别于运营服务器的其它服务器。以浏览器内核为例，下发浏览器内核的服务器则是浏览器所对应的服务器，即浏览器的运营服务器，不同类型的浏览器内核都有其所唯一对应的服务器，软件开发工具包插件通过唯一对应的服务器获得浏览器内核。

也就是说，对于应用程序的运营而言，通过服务器的配置动态部署了软件开发工具包插件，即可自动获得下发的服务组件，一方面保证了有效控制，另一方面又在有效控制下提高了效率。

图6是根据一示例性实施例示出的对步骤510的细节的描述。该步骤510可以包括以下步骤。

步骤511，应用程序被触发启动时，获取应用程序自身支持服务组件所对应的服务组件信息。

其中，应用程序启动时，将进行软件开发工具包插件的动态部署。根据应用程序的初始化和运营过程，应用程序自身已经支持了至少一个服务组件，需要获得应用程序自身支持服务组件的情况，以便于进行与此情况相适应的软件开发工具包插件的动态部署。

因此，将获取应用程序自身支持服务组件所对应的服务组件信息，服务组件信息中标识了应用程序自身支持的服务组件和服务组件的版本号等信息。例如，对于浏览器内核而言，所指的服务组件信息为浏览器内核信息，其标识了应用程序自身支持的浏览器内核以及浏览器内核的版本号。

步骤513，向服务器上报服务组件信息。

其中，所指的服务器为运营服务器。应用程序在获得服务组件信息之后，向自身的运营服务器上报服务组件信息。

步骤515，通过服务器根据服务组件信息返回的处理结果，下载服务器配置的软件开发工具包插件，安装部署下载的软件开发工具包插件。

其中，应用程序获取服务器返回的处理结果，处理结果用于标示服务器配置的服务组件中应用程序未支持服务组件所分别对应的软件开发工具包插件，并提供软件开发工具包插件的下载地址，对于所标示的每一软件开发工具包插件而言，处理结果包含标志位和下载地址两大内容。

标示位用于标识软件开发工具包插件相对应用程序是新增还是更新。新增则说明软件开发工具包插件是新类型的软件开发工具包插件，更新则是说明软件开发工具包插件是进行版本迭代更新所得到的，对于应用程序而言，此软件开发工具包插件的部署即为版本的更新过程。

下载地址则用于实现软件开发工具包插件的下载，以便于进行部署。

因此，应用程序通过服务器所返回的处理结果，即可实现服务器配置的软件开发工具包插件的下载和安装部署，进而在服务器的控制下实现了应用程序中软件开发工具包插件的动态部署，由此使得应用程序中部署的软件开发工具包插件是与服务器的配置相适配的，进而极大地增强了应用程序的性能。

图7是根据一示例性实施例示出的一种实现应用程序加载服务组件的方法的流程图。该实现应用程序加载服务组件的方法，在步骤510之前，可以包括以下步骤。

在步骤610中，触发启动应用程序，并判断应用程序的触发启动是否为初次启动，若为是，则执行步骤630，若为否，则执行步骤510。

其中，终端设备中，当应用程序被触发启动时，当前所进行的应用程序启动是否为初次启动，如果是，则需要首先部署默认软件开发工具包插件，以便于支撑应用程序的基本服务。

在步骤630中，部署默认软件开发工具包插件。

其中，无法是否为应用程序的初次启动，都需要进行软件开发工具包插件的动态部署，以使得应用程序所能够支持的服务组件是与服务器配置的服务组件相一致的，进而在应用程序运营中，即便一服务组件出现缺陷，也能够通过服务器配置实现所有应用程序中服务组件的切换，进而使得广泛运营的应用程序具备非常高的稳定性。

并且通过此方式，由于并不需要用户确认，也不需要安装操作的配合，即后台静默安装即中；相对现有方案中重新更换整个应用程序的方式，所对应的安装包也较小，例如，如果应用程序为10M，更新的软件开发工具包插件为200K，则根据现有的方案，所对应的安装包则有10.2M，而本公开所使用的安装包则仅有200K，极大地减少了耗费的流量，成本得到最大程度的降低，覆盖速度快。

图8是根据一示例性实施例示出的一种实现应用程序加载服务组件的方法。该实现应用程序加载服务组件的方法可以包括以下步骤。

在步骤710中，当应用程序被触发启动时，根据应用程序自身支持的服务组件动态部署服务器配置的软件开发工具包插件，获得软件开发工具包插件支持的服务组件。

其中，终端设备中，应用程序被触发启动时根据自身所支持的服务组件来进行动态部署，以使得应用程序中部署的软件开发工具包插件能够与服务器配置的软件开发工具包插件相适配。

动态部署的软件开发工具包插件通过自身集成的软件开发工具包自动进行服务组件的下载，以在完成软件开发工具包插件的动态部署之后自动获得支持的服务组件。

在步骤730中，获取应用程序中被触发生成的服务指令。

其中，在完成软件开发工具包插件的动态部署，获得与服务器的配置相适配的服务组件之后，即可进行应用程序中的服务。

服务指令用于触发进行应用程序中相应服务指令的调用，以发起应用程序中的服务。

在步骤750中，根据服务指令动态加载指定的软件开发工具包插件，通过软件开发工具包插件的动态加载获得集成的软件开发工具包。

其中，动态加载与服务指令相符的软件开发工具包插件。在应用程序中发起服务的过程中，通过进行软件开发工具包插件的动态加载，以使用最为适用的软件开发工具包插件，获得此软件开发工具包插件中集成的软件开发工具包。

在步骤770中，通过集成的软件开发工具包调用服务组件。

通过所进行的服务组件调用，便得以实现了应用程序中的服务。如前所述的，服务组件的不同，便能够为应用程序提供不同的服务，例如网页浏览服务、支付服务等。

图9是根据一示例性实施例示出的一种实现应用程序加载服务组件的方法。该实现应用程序加载服务组件的方法适用于图1所示实施环境的服务器110，如图9所示，该实现应用程序加载服务组件的方法，可以由服务器110执行，可以包括以下步骤。

在步骤810中，服务器接收应用程序被触发启动时上报的服务组件信息，服务组件信息对应于应用程序自身支持的服务组件。

其中，任一应用程序被触发启动时，将进行自身服务组件信息的上报，以通过自身服务组件信息的上报告之服务器自身所支持的服务组件，进而方便服务器对应用程序进行精准的动态部署。

在步骤830中，根据服务组件信息进行匹配处理生成处理结果，向应用程序返回处理结果。

其中，服务组件信息的匹配处理指的是对服务器配置的服务组件和应用程序自身支持的服务组件进行匹配，以得到未命中的服务组件，生成相应的处理结果，向上报服务组件的应用程序相应返回此处理结果。

在步骤850中，向应用程序动态部署处理结果中的软件开发工具包插件和软件开发工具包插件支持的服务组件。

服务器通过生成的处理结果，向应用程序动态部署处理结果中标识的软件开发工具包插件，随着软件开发工具包插件的动态部署，也在应用程序中部署了此软件开发工具包插件支持的服务组件，使得应用程序当前支持的服务组件与服务器的配置相符。

通过如上所述的服务器实现过程，对应用程序的运营进行控制，使得应用程序能够支持多个服务组件，在所进行的应用程序运营中，不再需要通过发布新版本的应用程序来消除服务组件出现的缺陷，降低了应用程序迭代更新的频率，因此能够最大限度地降低成本。

图10是根据一示例性实施例示出的对步骤830的细节的描述。该步骤830，可以由服务器110执行，可以包括以下步骤。

在步骤831中，服务器将服务组件信息与设定的服务组件配置相匹配，获得设定的服务组件配置中未命中的服务组件。

其中，如前所述的，服务组件信息标识了应用程序自身支持的服务组件。服务器中设定的服务组件配置则标识了服务器为应用所配置的各服务组件。

因此，服务器在获得应用程序上报的服务组件信息之后，进行服务组件信息和设定的服务组件配置之间的匹配处理，获得设定的服务组件配置中未命中的服务组件。

以浏览器内核为例，服务器配置了浏览器内核的优先级列表，在此优先级列表中，按照优先级从高到低的顺序标识了各浏览器内核，即浏览器内核B、浏览器内核C和浏览器内核A。

服务组件信息，即浏览器内核信息中，上报了应用程序自身支持浏览器内核C和浏览器内核A。

则通过匹配可知，设定的服务器组件配置中未命中的浏览器内核为浏览器内核B，此时，将根据未命中的浏览器内核B下发支持该浏览器内核B的软件开发工具包插件。

在步骤833中，根据未命中的服务组件生成处理结果，向应用程序返回处理结果。

其中，根据未命中的服务组件得到支持该服务组件的软件开发工具包插件，生成与此软件开发工具包插件相符的处理结果。

具体的，生成此软件开发工具包插件的标志位和下载地址，该标志位和下载地址便构成处理结果。

通过此过程，实现了服务器与应用程序之间的交互，为应用程序中动态部署的实现提供有效信息，以保障服务器对应用程序的有效控制。

图11是根据一示例性实施例示出的对步骤833的细节的描述。该步骤833，可以由服务器110执行，可以包括以下步骤。

在步骤8331中，获得支持未命中服务组件的软件开发工具包插件，支持未命中服务组件的软件开发工具包插件为服务器向应用程序动态部署的软件开发工具包插件。

在步骤8333中，生成软件开发工具包插件的标志位和下载地址，通过软件开发工具包插件的标志位和下载地址生成处理结果。

其中，对获得的支持未命中服务组件的软件开发工具包插件，都分别生成相应的标志位和下载地址，所有软件开发工具包插件相应的标志位和下载地址即构成处理结果。

除此之外，生成的处理结果中，还可附带命中服务组件的软件开发工具包插件所相关的信息。

在步骤8335中，向应用程序返回处理结果。

通过上述本公开提供的实施例，分别提供了实现应用程序加载服务组件的应用程序侧和服务器侧的解决方案，进而能够应用于需要通过服务组件提供服务的应用场景，也能够应用于需要对比各服务组件的应用场景。

各种通用的服务组件都能够通过上述实现过程部署于其它应用程序中，例如，相对服务组件而言的第三方应用程序中。比如，对于浏览器内核，所指的应用程序即为相对于浏览器内核和浏览器而言的第三方应用程序。

下述以终端设备为智能手机为例，结合具体应用场景，描述该实现应用程序加载服务组件的方法。例如，图12是整个实现过程的示意图。

首先需要简要说明的是，通过上述描述清楚地知道，该实现应用程序加载服务组件的方法包括两大部分，一为软件开发工具包插件的动态部署，二为使用软件开发工具包插件的调用服务组件。

参见图12，应用程序910通过应用程序云端920实现软件开发工具包插件的动态更新，以动态部署多个软件开发工具包插件930，即软件开发工具插件包1、软件开发工具插件包2，……，和软件开发工具包插件N。（软件开发工具包插件在图13中简单标识为插件）

应用程序910中集成了插件框架911。部署的软件开发工具包插件中集成软件开发工具包931，通过集成的软件开发工具包931方能够调用支持的浏览器内核940。（集成的软件开发工具包931在图13中简单标识为SDK）

由于应用程序910中动态部署了多个软件开发工具包插件930，使得应用程序具备了能够调用多种浏览器内核940，即浏览器内核1、浏览器内核2、……和浏览器内核N的能力，进而能够进行浏览器内核940的选择和切换，即通过插件框架911和配置文件950实现软件开发工具包插件930的动态加载，进而调用所选择的浏览器内核940，其中，该浏览器内核是由对应的浏览器云端960下发的。

具体的，图13是根据一示例性实施例示出的动态部署流程。该动态部署流程由智能手机和服务器配合执行。图13对应于图5、图6、图7、图8、图9、图10和图11实施例的某一或几个步骤。

应用程序在启动后，初次会部署默认浏览器软件开发工具包插件，确保有浏览器内核可以支持应用程序的基本网页页面访问能力，即执行步骤1010至步骤1030。

上报应用程序本地支持浏览器内核列表至服务器，即上报列表形式存在的服务组件信息服务器将该应用程序本地支持浏览器内核列表与设定的配置相匹配，再将匹配后的处理结果返回给应用程序，即执行步骤1040和步骤1050。

应用程序获得服务器下发的处理结果，判断是否有新增或更新，如果有，则进行软件开发工具包插件的下载，并安装部署生效，即执行步骤1060至步骤1080。

在此需要特别说明的是，对于新增的软件开发工具包插件，则直接进行安装部署；对于更新的软件开发工具包插件，则覆盖旧版本的软件开发工具包插件。

图14是根据一示例性实施例示出的使用软件开发工具包插件的调用服务组件流程。该调用服务组件流程由智能手机中运行的应用程序执行。图14对应于图3、图4实施例的某一或几个步骤。

应用程序加载一网络地址时，会先配置文件，以获知配置适合的软件开发工具包插件，即执行步骤1110和步骤1120。通过读取配置文件后，选择加载指定的软件开发工具包插件，即执行步骤1130。

如果软件开发工具包插件加载成功，则使用该指定软件开发工具包插件中集成的软件开发工具包调用浏览器内核，以访问网页页面，否则使用默认软件开发工具包插件，即执行步骤1140至步骤1180。

需要进一步说明的，对于使用软件开发工具包插件的调用服务组件流程中涉及的动态加载，即软件开发工具包的获得是采用动态加载技术实现的，具体如下：

图15是根据一示例性实施例示出的动态加载实现。在启动应用程序时，***将分配一块内存，将应用程序的相关数据和宿主代码信息1231载入到内存块1200，即步骤1210和步骤1230。

在需要用到软件开发工具包插件功能时进行动态加载，将软件开发工具的相关数据和SDK插件代码信息1251载入到内存块1200中，即步骤1250。

由于宿主代码信息1231和SDK插件代码信息1251都已经在内存中，可以实现相互的调用，即步骤1270。

在SDK插件代码信息1251和宿主代码信息1231实现的相互调用中，特别是对于应用程序所进行的软件开发工具包插件的调用，是通过定义统一的代理社交类使得应用程序具备调用不同软件开发工具包插件的能力。

图16是根据一示例性实施例示出的应用程序调用软件开发工具包插件的实现。对于软件开发工具包插件930，定义一个统一的代理视图类933，应用程序910通过代理视图类933访问软件开发工具包931。

由此使得应用程序910不需要关注软件开发工具包931的具体实现，也就是说，可以适配各个软件开发工具包931，仅需要生成一个新的插件即可。

具本的，图17是根据一示例性实施例示出的软件开发工具包插件的实现。即在定义了代理视图类933的代理工程中集成软件开发工具包931，并打包发布即可得到所需要的软件开发工具包插件930。

进一步优选的，为便于区分不同的软件开发工具包插件，将在生成的软件开发工具包插件附带以下信息：

（1）包名，其是唯一表示符，用于区分不同软件开发工具包插件；

（2）版本号，其是同一种软件开发工具包插件的版本信息，以供更新升级使用。

通过如上涉及的软件开发工具包插件化和动态部署、云端高效动态地切换服务组件，将使得应用程序中即便随意更新服务组件也不会对用户造成干扰，服务组件的更新仅需要更新相应软件开发工具包插件，且静默安装，效率更高，提高了覆盖面，对用户的干扰程度降低到0。

下述为本公开装置实施例，可以用于执行本公开上述服务器110和终端设备130执行的实现应用程序加载服务组件的方法实施例。对于本公开装置实施例未披露的细节，请参照本公开实现应用程序加载服务组件的方法实施例。

图18是根据一示例性实施例示出的一种实现应用程序加载服务组件的装置的框图。该实现应用程序加载服务组件的装置可以用于图1所示实施环境的终端设备130中，执行图3所示的实现应用程序加载服务组件的方法的全部步骤。

如图18所示，该实现应用程序加载服务组件的装置包括但不限于：指令获取模块1310、配置读取模块1330、插件加载模块1350和调用模块1370。

指令获取模块1310，用于获取应用程序中被触发生成的服务指令。

配置读取模块1330，用于根据指令触发应用程序自身集成的插件框架读取配置文件。

插件加载模块1350，用于加载配置文件指令的软件开发工具包插件，得到软件开发工具包插件集成的软件开发工具包。

调用模块1370，用于通过集成的软件开发工具包调用服务组件。

上述装置中各个模块的功能和作用的实现过程具体详见上述应用程序加载服务组件的方法中对应步骤的实现过程，在此不再赘述。

图19是根据另一示例性实施例示出的一种实现应用程序加载服务组件的装置的框图。该实现应用程序加载服务组件的装置包括但不限于：默认插件加载模块1410和默认组件调用模块1430。

默认插件加载模块1410，用于当指定的软件开发工具包插件加载失败时，加载默认软件开发工具包插件，通过默认软件开发工具包插件的加载获得集成的软件开发工具包。

默认组件调用模块1430，用于通过集成的软件开发工具包调用默认服务组件。

图20是根据另一示例性实施例示出的一种实现应用程序加载服务组件的装置的框图。该实现应用程序加载服务组件的装置包括但不限于：动态部署模块1510和组件接收模块1530。

动态部署模块1510，用于当应用程序被触发启动时，根据应用程序自身支持的服务组件动态部署服务器配置的软件开发工具包插件。

组件接收模块1530，用于接收服务器下发的服务组件，服务组件为服务器配置的软件开发工具包插件自身支持的。

可选的，动态部署模块1510参见图21，包括但不限于：组件信息获取单元1511、信息上报单元1513和下载单元1515。

组件信息获取单元1511，用于应用程序被触发启动时，获取应用程序自身支持服务组件所对应的服务组件信息。

信息上报单元1513，用于向服务器上报服务组件信息。

下载单元1515，用于通过服务器根据服务组件信息返回的处理结果，下载服务器配置的软件开发工具包插件，安装部署下载的软件开发工具包插件。

可选的，动态部署模块1510还包括启动判断单元和默认插件部署单元。

启动判断单元，用于触发启动应用程序，并判断应用程序的触发启动是否为初次启动，若为是，则通知默认插件部署单元。

默认插件部署单元用于部署默认软件开发工具包插件。

图22是根据另一示例性实施例示出的一种实现应用程序加载服务组件的装置的框图。该实现应用程序加载服务组件的装置包括但不限于：部署模块1610、服务发起模块1630、指定加载模块1650和组件调用模块1670。

部署模块1610，用于当应用程序被触发启动时，根据应用程序自身支持的服务组件动态部署服务器配置的软件开发工具包插件，获得软件开发工具包插件支持的服务组件。

服务发起模块1630，用于获取应用程序中被触发生成的服务指令。

指定加载模块1650，用于根据服务指令动态加载指定的软件开发工具包插件，通过软件开发工具包插件的动态加载获得集成的软件开发工具包。

组件调用模块1670，用于通过集成的软件开发工具包调用服务组件。

图23是根据另一示例性实施例示出的一种实现应用程序加载服务组件的装置的框图。该实现应用程序加载服务组件的装置包括但不限于：信息接收模块1710、匹配处理模块1730和服务器配置部署模块1750。

信息接收模块1710，用于接收应用程序被触发启动时上报的服务组件信息，服务组件信息对应于应用程序自身支持的服务组件。

匹配处理模块1730，用于根据服务组件信息进行匹配处理生成处理结果，向应用程序返回处理结果。

服务器配置部署模块1750，用于向应用程序动态部署处理结果中的软件开发工具包插件和软件开发工具包插件支持的服务组件。

可选的，匹配处理模块1730如图24所示，包括但不限于：匹配单元1731和结果生成单元1733。

匹配单元1731，用于将服务组件信息与设定的服务组件配置相匹配，获得设定的服务组件配置中未命中的服务组件。

结果生成单元1733，用于根据未命中的服务组件生成处理结果，向应用程序返回处理结果。

可选的，结果生成单元1733如图25所示，包括但不限于：插件获取子单元17331、内容生成子单元17333和结果返回子单元17335。

插件获取子单元17331，用于获得支持未命中服务组件的软件开发工具包插件，支持未命中服务组件的软件开发工具包插件为服务器向应用程序动态部署的软件开发工具包插件。

内容生成子单元17333，用于生成软件开发工具包插件的标志位和下载地址，通过软件开发工具包插件的标志位和下载地址生成处理结果。

结果返回子单元17335，用于向应用程序返回处理结果。

可选的，本公开还提供一种实现应用程序加载服务组件的装置，该实现应用程序加载服务组件的装置可以用于图1所示实施环境的终端设备130中，所述装置包括：

处理器；

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

其中，所述处理器被配置为执行：

获取应用程序中被触发生成的服务指令；

根据所述服务指令动态加载指定的软件开发工具包插件，通过所述软件开发工具包插件的动态加载获得集成的软件开发工具包；

通过所述集成的软件开发工具包调用服务组件。

该实施例中的装置的处理器执行操作的具体方式已经在有关该实现应用程序加载服务组件的方法的实施例中执行了详细描述，此处将不做详细阐述说明。

可选的，本公开还提供一种实现应用程序加载服务组件的装置，该实现应用程序加载服务组件的装置可以用于图1所示实施环境的终端设备130中，所述装置包括：

处理器；

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

其中，所述处理器被配置为执行：

当应用程序被触发启动时，根据所述应用程序自身支持的服务组件动态部署服务器配置的软件开发工具包插件，获得所述软件开发工具包插件支持的服务组件；

获取应用程序中被触发生成的服务指令；

根据所述服务指令动态加载指定的软件开发工具包插件，通过所述软件开发工具包插件的动态加载获得集成的软件开发工具包；

通过所述集成的软件开发工具包调用服务组件。

在示例性实施例中，还提供了一种存储介质，该存储介质为计算机可读存储介质，例如可以为包括指令的临时性和非临时性计算机可读存储介质。该存储介指例如包括指令的存储器204，上述指令可由装置200的处理器218执行以完成上述实现应用程序加载服务组件的方法。

应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围执行各种修改和改变。本发明的范围仅由所附的权利要求来限制。

Claims (15)

1.一种实现应用程序加载服务组件的方法，包括：

获取应用程序中被触发生成的服务指令；

根据所述服务指令触发所述应用程序自身集成的插件框架读取配置文件；

加载所述配置文件指定的软件开发工具包插件；

若所述指定的软件开发工具包插件加载成功，通过所述指定的软件开发工具包插件的加载所获得集成的软件开发工具包调用服务组件；

若所述指定的软件开发工具包插件加载失败，加载默认软件开发工具包插件，通过所述默认软件开发工具包插件的加载所获得集成的软件开发工具包调用默认服务组件，所述默认软件开发工具包插件是在所述应用程序被初次触发启动时所部署的。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

当所述应用程序被触发启动时，根据所述应用程序自身支持的服务组件动态部署服务器配置的软件开发工具包插件；

接收服务器下发的服务组件，所述服务组件为所述服务器配置的软件开发工具包插件自身支持的。

3.根据权利要求2所述的方法，其特征在于，所述当所述应用程序被触发启动时，根据所述应用程序自身支持的服务组件动态部署服务器配置的软件开发工具包插件的步骤包括：

所述应用程序被触发启动时，获取所述应用程序自身支持服务组件所对应的服务组件信息；

向服务器上报所述服务组件信息；

通过服务器根据所述服务组件信息返回的处理结果，下载所述服务器配置的软件开发工具包插件，安装部署所述下载的软件开发工具包插件。

4.根据权利要求2所述的方法，其特征在于，所述当所述应用程序被触发启动时，根据所述应用程序自身支持的服务组件动态部署服务器配置的软件开发工具包插件的步骤之前，所述方法还包括：

触发启动应用程序，并判断所述应用程序的触发启动是否为初次启动，若为是，则

部署默认软件开发工具包插件。

5.一种实现应用程序加载服务组件的方法，包括：

服务器接收应用程序被触发启动时上报的服务组件信息，所述服务组件信息对应于所述应用程序自身支持的服务组件；

根据所述服务组件信息与设定的服务组件配置进行匹配处理生成处理结果，向所述应用程序返回处理结果，所述处理结果指示了设定的服务组件配置中未命中的服务组件所对应软件开发工具包插件；

向所述应用程序动态部署所述处理结果中所述未命中的服务组件所对应软件开发工具包插件和所述软件开发工具包插件支持的服务组件。

6.根据权利要求5所述的方法，其特征在于，所述根据所述服务组件信息向所述应用程序返回处理结果的步骤包括：

所述服务器将服务组件信息与设定的服务组件配置相匹配，获得设定的服务组件配置中未命中的服务组件；

根据所述未命中的服务组件生成处理结果，向所述应用程序返回所述处理结果。

7.根据权利要求6所述的方法，其特征在于，所述根据所述未命中的服务组件生成处理结果，返回所述处理结果的步骤包括：

获得支持未命中服务组件的软件开发工具包插件，所述支持未命中服务组件的软件开发工具包插件为服务器向所述应用程序动态部署的软件开发工具包插件；

生成所述软件开发工具包插件的标志位和下载地址，通过所述软件开发工具包插件的标志位和下载地址生成处理结果；

向所述应用程序返回所述处理结果。

8.一种实现应用程序加载服务组件的装置，其特征在于，所述装置包括：

指令获取模块，用于获取应用程序中被触发生成的服务指令；

配置读取模块，用于根据所述服务指令触发所述应用程序自身集成的插件框架读取配置文件；

插件加载模块，用于加载所述配置文件指定的软件开发工具包插件；

调用模块，用于若所述指定的软件开发工具包插件加载成功，通过所述指定的软件开发工具包插件的加载所获得集成的软件开发工具包调用服务组件；

默认插件加载模块，用于若所述指定的软件开发工具包插件加载失败，加载默认软件开发工具包插件，通过所述默认软件开发工具包插件的加载所获得集成的软件开发工具包调用默认服务组件，所述默认软件开发工具包插件是在所述应用程序被初次触发启动时所部署的。

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

动态部署模块，用于当所述应用程序被触发启动时，根据所述应用程序自身支持的服务组件动态部署服务器配置的软件开发工具包插件；

组件接收模块，用于接收服务器下发的服务组件，所述服务组件为所述服务器配置的软件开发工具包插件自身支持的。

10.根据权利要求9所述的装置，其特征在于，所述动态部署模块包括：

组件信息获取单元，用于所述应用程序被触发启动时，获取所述应用程序自身支持服务组件所对应的服务组件信息；

信息上报单元，用于向服务器上报所述服务组件信息；

下载单元，用于通过服务器根据所述服务组件信息返回的处理结果，下载所述服务器配置的软件开发工具包插件，安装部署所述下载的软件开发工具包插件。

11.根据权利要求9所述的装置，其特征在于，所述动态部署模块包括：

启动判断单元，用于触发启动应用程序，并判断所述应用程序的触发启动是否为初次启动，若为是，则通知默认插件部署单元；

所述默认插件部署单元用于部署默认软件开发工具包插件。

12.一种实现应用程序加载服务组件的装置，其特征在于，所述装置包括：

信息接收模块，用于接收应用程序被触发启动时上报的服务组件信息，所述服务组件信息对应于应用程序自身支持的服务组件；

匹配处理模块，用于根据所述服务组件信息与设定的服务组件配置进行匹配处理生成处理结果，向所述应用程序返回处理结果，所述处理结果指示了设定的服务组件配置中未命中的服务组件所对应软件开发工具包插件；

服务器配置部署模块，用于向所述应用程序动态部署所述处理结果中所述未命中的服务组件所对应软件开发工具包插件和所述软件开发工具包插件支持的服务组件。

13.根据权利要求12所述的装置，其特征在于，所述匹配处理模块包括：

匹配单元，用于将服务组件信息与设定的服务组件配置相匹配，获得设定的服务组件配置中未命中的服务组件；

结果生成单元，用于根据所述未命中的服务组件生成处理结果，向所述应用程序返回所述处理结果。

14.根据权利要求13所述的装置，其特征在于，所述结果生成单元包括：

插件获取子单元，用于获得支持未命中服务组件的软件开发工具包插件，所述支持未命中服务组件的软件开发工具包插件为服务器向所述应用程序动态部署的软件开发工具包插件；

内容生成子单元，用于生成所述软件开发工具包插件的标志位和下载地址，通过所述软件开发工具包插件的标志位和下载地址生成处理结果；

结果返回子单元，用于向所述应用程序返回所述处理结果。

15.一种实现应用程序加载服务组件的装置，其特征在于，所述装置包括：

处理器；

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

其中，所述处理器被配置：

获取应用程序中被触发生成的服务指令；

根据所述服务指令触发所述应用程序自身集成的插件框架读取配置文件；

加载所述配置文件指定的软件开发工具包插件；

若所述指定的软件开发工具包插件加载成功，通过所述指定的软件开发工具包插件的加载所获得所集成的软件开发工具包调用服务组件；

若所述指定的软件开发工具包插件加载失败，加载默认软件开发工具包插件，通过所述默认软件开发工具包插件的加载所获得集成的软件开发工具包调用默认服务组件，所述默认软件开发工具包插件是在所述应用程序被初次触发启动时所部署的。

Images