移动服务升级方法、装置和终端

技术领域

本申请涉及计算机技术，尤其涉及一种移动服务升级方法、装置和终端等。

背景技术

近年来，移动终端设备，例如智能手机、平板电脑、穿戴式设备等急速发展，用户对移动终端设备的需求越来越丰富，应用终端设备上的应用类型越来越多。为了方便多种的应用的开发，移动服务厂商提供了移动服务，例如谷歌(google)提供的google移动服务(google mobile service,GMS)。GMS中包括公共框架以及多种服务(或称子应用或kit)等多个组件，并向应用开发者提供调用接口，这样应用开发者就可以在开发的过程中通过调用接口直接使用这多种服务中的任意一种或多种，而不需要重新开发。这里的多种服务例如地图服务、广告服务、定位服务、运动健康服务、机器学习服务等。

移动服务厂商将移动服务集成在操作系统中，并将操作系统提供给移动设备制造商预置在移动设备中，各个应用开发完成后也被预置在移动或被用户安装在移动设备中，这些软件协作以满足用户在日常生活中的各种需求。但是，目前一台移动设备中的移动服务的升级会导致移动服务中的各个组件一起升级，升级耗时较长，而且升级之后需要重启移动设备。这种升级方式不仅效率低，而且缺乏灵活性，比如因为升级后要重启设备，所以移动设备中的升级会设置为后台静默升级，比如在晚间且电量充足或充电的时间段升级，以免影响用户的使用。

发明内容

本申请提供一种移动服务升级方法，可以实现移动服务中的各个组件独立升级。进一步的，升级之后不需要重新启动移动设备。通过这种方式降低移动服务的升级时长，并且提供移动服务升级的灵活性，例如在应用需要的时候实时升级，应用需要哪个组件升级，就独立升级哪个组件，而且不需要重启设备，应用可以实时使用升级后的组件。

另外，本申请还提供实现以上方法的各种装置、计算机程序产品(例如移动服务软件或操作系统软件)、存储介质以及计算机设备等。

下面将从多个方面介绍本申请，容易理解的是，该以下多个方面可以单独实施，也可以选择其中任意两个或更多联合实施。该以下多个方面的具体实现方式和有益效果可互相参考。

第一方面，本申请提供一种移动服务升级方法，该方法包括：接收应用发送的对目标服务的调用请求，所述目标服务为移动服务包括的多个服务中的一个服务；根据所述服务调用请求确定所述目标服务需要升级时，从远程计算机下载所述目标服务的新版本，所述新版本是指满足所述调用请求的需求的版本；加载并运行所述目标服务的新版本。

应理解的是，上述方法也适用于升级多个服务。

所述服务可以理解下述实施例中的kit。当然kit中也可以包括多个组件，这多个组件也可以认为是kit。一个kit中也可能会调用其他的kit。这就可能会使用后续方法将介绍的依赖升级。

通过以上方法，可以实现在应用触发下根据应用的调用需求升级移动服务中的一个或多个服务，升级耗时短，也比单纯的后台静默升级要更灵活，能够更及时地满足用户的需求。

上述方法也可以应用在静默升级的场景下，在静默升级的时候独立升级所述移动服务中的一个或多个服务，而不是整体升级移动服务，降低了升级时长。

在一些实现方式下，所述根据所述服务调用请求确定所述目标服务需要升级时，从远程计算机下载所述目标服务的新版本包括：根据所述目标服务的应用程序包中存储的依赖信息确定所述目标服务依赖于另一服务，且确定所述另一服务需要升级时，从所述远程计算机下载所述目标服务的新版本以及所述另一服务的新版本，其中，所述依赖信息包括所述目标服务与其它一个或多个服务的依赖关系。

在一些实现方式下，所述依赖信息存储在manifest文件中，所述依赖信息是在编译所述目标服务的所述应用程序包的阶段被加入到所述manifest文件中的。

通过上述方式，升级某个服务的时候可以根据该服务的APK中所包含的依赖信息升级该服务所依赖的其他服务(根据需求升级，如果没有需求，也可以不升级)，避免了因依赖的服务版本不满足需求而造成的应用调用失败。

在一些实现方式下，所述加载所述目标服务的新版本包括：查找类加载器路由表以确定类加载器，通过查找到的所述类加载器加载所述目标服务的类文件或所述目标服务的子服务的类文件，所述类加载器路由表中包括存储有服务名称、包名以及类加载器的对应关系。

在一些实现方式下，所述查找类加载器路由表以确定类加载器，通过查找到的所述类加载器加载所述目标服务的子服务的类文件包括：创建所述目标服务的第一类加载器和第二类加载器，并将所述目标服务与所述第一类加载器的对应信息存储在所述类加载器路由表中，述类加载器路由表中包括存储有包名与服务名称的对应关系，所述类加载器路由表存储的服务包括所述子服务；通过所述第一类加载器的加载类loadClass方法调用所述第二类加载器的加载类loadClass方法，以提取所述子服务的包名，并从所述类加载器路由表中查找与所述包名匹配的子服务名称以及类加载器；通过查找到的所述类加载器加载所述子服务的类文件。

应理解的是，loadClass只是本领域在此处惯用的实现方法名称，本申请的其他实施例中也可以不用该名称。

JAVA(一种高级程序语言)程序在加载类文件时通常使用的是双亲委托机制，但是在移动服务框架中，类加载器众多，双亲委托机制容易造成类加载的版本不正确，不利于管理。本申请提出了路由表，通过路由表记录包名服务名称、包名以及类加载器的对应关系，然后在加载类文件的时候查询所述路由表，获得对应的类加载器，而不是使用传统的双亲委托机制。这样，多个类加载器由路由表集中指派，管理起来更方便，查找变得扁平化，也可以实现应用间的解耦，集中管控类路由,依赖更加清晰。

应理解的是，以上类加载器的选择方法在后台静默升级的时候也可以使用。

在一些实现方式下，所述运行所述目标服务的新版本包括：查询所述目标服务的配置文件，从不同优先级的多个进程中选择所述配置文件指示的目标进程运行所述目标服务。

由于每个kit都有自己的业务需求，所以本实施例提供了不同优先级的进程池，根据kit的配置文件的指示选择与业务需求匹配的优先级的进程来运行这个kit，增加了进程选择的灵活性的同时满足了业务需求。

在一些实现方式下，所述运行所述目标服务的新版本包括：根据进程负载情况从多个同等优先级的进程中选择目标进程运行所述目标服务，其中所述目标进程的负载小于或等于所述多个同等优先级的进程中的其他进程。

该方法根据负载情况选择负载较低的进程来运行当前的kit，能够提高kit的运行效率。

以上不管是优先级的方法，还是选择负载较低的进程，都可以认为是建立了进程池，从进程池中选择合适的进程来运行kit，避免了一个kit开启一个独立的进程导致的进程数量过多的问题。以上涉及优先级的方法也可以与负载方法联合起来使用，比如先根据优先级选择合适的优先级，再在同一优先级的进程中根据负载选择负载相对较低的进程。

除了方法之外，本申请还实现方法的装置、计算机存储介质和计算机程序产品等。

第二方面，本申请还提供一种移动服务升级装置。该装置中包括一个或多个模块，用于实现前述第一方面任意一种实现方式的方法。应理解的是，模块可以与方法步骤一一对应，也可以不一一对应。模块的名称不做限定。该升级装置例如可以是实施例中描述的HMS framework。

第三方面，本申请还提供一种终端设备，该终端设备包括处理器和存储器，所述存储器用于存储计算机可读指令，所述处理器用于执行所述计算机可读指令以实现前述方面任意一项所述的方法。

第四方面，本申请还提供一种计算机程序介质，该计算机程序介质包括计算机可读指令，当所述计算机可读指令被一个或多个处理器执行时实现前述方面任意一项所述的方法。

第五方面，本申请还提供一种计算机程序产品(或称计算机程序)，该计算机程序产品包括计算机可读指令，当所述计算机可读指令被一个或多个处理器执行时实现前述方面任意一项所述的方法。

附图说明

下面将对本申请附图作简单地介绍。显而易见地，下面描述的附图仅仅是本申请的一些实施例。

图1为本实施例提供的HMS的架构示意图；

图2为HMS Framework的应用示意图；

图3为本实施例实现免安装apk的主要设计思想；

图4为本实施例提供的HMS framework的逻辑架构图；

图5为kit的打包示例图；

图6为本实施例提供的HMS Framework中各模块之间的调用关系示意图；

图7为本实施例提供的API Level的示例图；

图8为本实施例提供的升级流程的示例图；

图9为本实施例提供的类加载器选择方案的模块示意图；

图10为本实施例提供的类加载器的关系示意图；

图11为本实施例提供的不同优先级进程的分配侧率示意图；

图12为本实施例提供的进程选择流程示意图；

图13为本实施例提供的终端设备的逻辑结构示意图。

具体实施方式

移动服务(mobile service,MS)包括MS核心(core)和多个应用app组成。为了和现有的移动服务区分开以便于表述，下面将本实施例提出的MS命名为HMS，相应的，MS core命名为HMS core。HMS core又包括HMS框架(framework)和子应用。子应用是能被第三方应用调用或集成的功能或能力模块的统称，在下面的实施例中也可以成为kit。HMS framework也可以作为一个kit存在，称为HMS framework kit。第三方应用调用kit的时候需要集成一些库(library)等模块，这些模块中包含调用接口，这些模块称为kit的SDK(SoftwareDevelopment Kit)。HMS中包含的所有kit的SDK以及一些公共模块的集合称之为HMS SDK。一个kit中可以包含多个组件，每个组件也可以称之为一个kit。一个kit可以集成其他kit的SDK，用于调用其他kit。

需要说明的是，为了方便应用和理解，本申请实施例为提到的一些系统、模块、器件、元素、数据结构以及指令等进行了英文命名，这些命名的大写或小写在无特殊说明的情况下均是相同的含义。同时，这些命名可以根据需求变更，不应作为对本申请所提供方案的限定。

图1为本实施例提供的HMS的架构示意图。HMS部署在端侧的android操作系统上。应用层包括第三方应用(3

图2为HMS Framework的应用示意图。HMS Framework支持第三方应用/自研应用能便利地调用到各个HMS Kit。HMS Framework的边界包括：集成在第三方应用/自研应用中的HMS SDK与HMS Framework接口，实现对应用程序接口(application program interface,API)的鉴权、对Kit的调用等；HMS Framework管理各个HMS Kit，包括加载、调用等；HMSFramework与云服务器交互，完成对Kit的更新、API鉴权等。

本实施例提供的方案主要实现在HMS Framework中，当然也有部分功能需要其他模块例如HMS SDK等与HMS Framework配合完成。本实施例中HMS中的各个kit以插件化的思路设计，即每个kit独立打包成安卓应用程序包(Android application package，apk)，独立发布，这些独立发布的kit也可以看做是独立的app。进一步的，通过本实施例提供的方法实现这些APK在安卓系统上免安装，同时又能保证应用访问到这些apk，从而进一步实现kit升级时无需重新启动终端设备等功能。在其他实施例中，一个apk中也可以包含多个kit，本申请不做限定。

图3为本实施例实现免安装apk的主要设计思想。如图所示，免安装的app，由于在Android系统中没有相应的注册，对第三方应用和系统均不可见，所以调用不到它，也没法让其加载运行。本实施例提供的HMS framework就相当于一个动态插件框架，其负责管理免安装的APP，并根据系统或第三方应用的调用，动态地将免安装的插件APP加载起来，使得第三方应用或系统能够调用到插件。

图4为本实施例提供的HMS framework的逻辑架构图。如图所示，该框架主要包括：框架服务(FrameworkService)模块、Kit包管理服务(Kit package management service,KPMS)模块、Kit活动管理服务(Kit Activity Management Service,KAMS)模块以及Kit应用容器(Kit application container,KAC)模块。框架服务模块提供HMS SDK接口的服务端，用于对用用调用HMS API鉴权，并用于将HMS SDK的调用路由到对应的Kit调用。KPMS模块主要用于：kit包的解析、以及kit元数据信息的管理和查询；Kit的下载、安装；Kit和框架模块的更新(包括静默更新、应用调用触发的更新、依赖更新、强制更新等)。KAMS模块主要用于：Kit进程的管理；桩(stub)资源的管理和调度；Kit进程调度；广播处理委托：各Kit静态广播的注册和接收广播后的分发等。KAC模块主要用于将kit装载到容器进程，并运行起来。KAC模块中包括类加载模块(DclassLoader)，用于为kit选择合适的类加载器。KAC模块中还包括kit运行时(runtime)模块，用于kit运行时管理。HMS framework中还包括测试模块、框架服务模块等图中未示出的其他模块。

前面已经提到过本实施例将一个或多个kit打包成独立的apk，从而支持kit的独立发布和升级。图5为kit打包的示例图。Kit打包分两种：一种是单个Kit独立打包为apk，其manifest为Kit自身的信息，主要包括组件和元数据(meta-data)；另外一种是KitBin APK形式，多个Kit在dex中，打包成一个apk，此时该apk的manifest中包含其内所有Kit的组件信息，和meta-data信息。由于meta-data需要按Kit进去区分，故用Tag区分。注意Kit的metadata信息是给HMS Framework中的KPMS用，尤其解析后存储DB。所以KPMS的解析器需要按来解析Kit的meta-data。

图6为HMS框架中各模块之间的调用关系示意图。如图所示，第三方应用/自研APP通过HMS SDK的API调用框架服务，进行API鉴权、kit调用等。框架服务通过KPMS和KAMS的sdk调用KPMS查询kit的相关信息，并让KAMS调度stub资源。KAC可以从KPMS查询kit相关信息。KAMS可以分发广播给KAC中的kit。框架服务可以加载kit，并通过反射调用其中的类方法。KAC可以通过调用AMS的接口启动Kit中的组件(StartActivity、StartService等)。KPMS还可以接受kit的安装和更新通知等。

基于以上HMS framework，下面介绍本实施例提供的kit升级方法，该方法可以在应用调用某个kit时，完成对该kit的独立升级、以及后续的独立加载和运行，无需等待后台静默升级。进一步的，若该kit对其它kit存在依赖，本实施例提供的方法还可以检测该依赖，并在需要升级其它kit时一并升级。进一步的，当所有kit升级完成后，无需重启系统，仅重启应用就可以继续使用升级后的kit执行功能。另外，在kit的升级过程中为了减少对用户的干扰，本实施例提供一个统一的界面。

本升级方法的主要思想是利用应用编译阶梳理依赖的kit集合，扩展kit的Manifest文件存储依赖的kit集合，运行时查找kit的嵌套依赖kit，以统一的UI界面管理所有kit的升级，解决用户不能及时体验kit新功能的问题。

为了便于本方法，先介绍一个API级别(level)的概念。如图7所示，Kit APK和KitSDK可以分别独立升版本号，只要APK提供给SDK的API能力没有变化，那么API Level是不变的，一旦API能力有变化，API Level必须往上升。API Level和Kit APK是一对多的关系，APILevel和Kit SDK也是一对多的关系，Kit SDK会要求Kit APK提供最小的API Level，如上图所示，Kit SDK的版本3.0、4.0和5.0就要求Kit APK提供的API Level至少为2，对应的KitAPK的版本号可以为4.0或5.0。

每个Kit和框架会发布自己的APK和对应的SDK(以.aar形式提供，android SDK库的一种打包方式)，在编译APK或SDK前分别在manifest.xml中配置元数据(即meta-data，下同)，APK通过implementation编译依赖其它APK提供的SDK时自动将SDK配置的元数据带入到APK的manifest.xml中，即APK自动生成了对其它APK的依赖关系，当APK从应用市场下载下来之后通过解析APK的manifest.xml就可以得到APK的依赖模块列表，通过依赖的模块名查询对应的包名，再通过包名从应用市场下载最新版本的APK，通过循环解析APK的依赖模块列表就可以下载到所有依赖的APK，对这些APK进行安装后，就完成了这个Kit的升级过程。

图8给出了一个升级流程的示例图，以第三方应用调用为例，详细步骤如下。

1)第三方应用集成了框架和fido提供的SDK，第三方应用APK的manifest.xml会自动带入对fido APK和框架APK的依赖API Level，第三方应用通过用户操作会触发调用到fido SDK提供的API，如图中①所示；

2)框架接收到第三方应用的API调用请求，会根据模块名(module name)和对应的API Level到本地数据库查询是否有满足条件的模块，如果不满足条件，触发升级对话框(upgrade dialog)，如图中②所示；

3)用户在升级对话框中点击确认后，根据框架传递的第三方应用包名解析第三方APK的元数据信息，获得所有依赖的module name和对应的API Level，并从本地数据库查询出所有不满足条件的包名，进入下一步升级操作，如图中③所示；

4)对于所有需要升级的每一个包，从应用市场(app store)检测是否有对应包的新版本，如图中④所示，如果有新版本，进入下一步下载流程；

5)从应用市场下载对应包的最新版本，如图中⑤所示，并从APK解析出所有依赖的module name和对应的API Level；

6)根据上一步解析出的module name和API Level从本地数据库查询是否有满足条件的module，如果没有，就需要升级该module对应的APK包；

7)重复步骤4)到步骤6)，直至本地满足所有要求升级APK的依赖条件；

8)下载完所有的APK包后进入安装步骤，安装时会解析每一个APK元数据中的module name和API Level，并保持到本地数据库中，如图中⑧所示。

为了实现以上升级过程，在开发和配置kit阶段可以做如下操作。

(一)每个Kit和框架在APK和对应的SDK的manifest.xml中分别配置元数据。对于APK来说，需要在manifest.xml中配置APK本身的模块名和当前提供的API Level(API能力)。

标准格式：

android:value＝"{api_level}"/>

以fido为例：

android:value＝"3"/>

说明：

1)com.huawei.hms.kit.api_level为固定前缀

2)fido为模块名，模块名必须唯一，不能重复，每个Kit可以配置多个模块名

3)android:value＝"3"中的"3"表示API Level

对于SDK来说，需要配置SDK要求对应APK的最低API Level。为此，SDK可以以.aar形式提供，因为.aar能被其它APK通过implementation编译依赖。

标准格式：

android:name＝"com.huawei.hms.min_api_level:{artifactId}:{kit_name}"

android:value＝"{kit_api_level}"/>

以fido提供的SDK为例：

android:value＝"3"/>

说明：

1)com.huawei.hms.min_api_level为固定前缀

2){artifactId}：因为meta-data的key不能重复，所以增加此标识对应每个kit的marven仓地址，每个kit的marven仓地址是唯一的，不重复。

3)fido为模块名，各个Kit的模块名必须唯一，不重复。

4)android:value＝"3"中的"3"表示这个SDK要求对应的APK的API Level至少为3。

(二)Kit或第三方应用(也称content provider,CP，下同)的APK在编译阶段集成其它Kit或框架提供的SDK时自动生成依赖关系。

Kit会依赖框架提供的SDK，也可能依赖其它的Kit，这样Kit的APK需要在编译阶段集成框架和其它Kit提供的SDK，集成时通过implementation编译依赖，这样打包生成APK时就会自动将SDK配置的元数据插入到APK的manifest.xml中，也就生成了对框架和其它Kit的依赖关系。

举例说明，假设有3个Kit，对应模块名分别为fido、map和framework，其中fido依赖了map和framework，fido、map和framework对应的APK为fido.apk、map.apk和framework.apk，map和framework提供的SDK分别为com.huawei.android.hms:map:1.0.0.1和com.huawei.android.hms:framework:1.1.0.2。

那么按(一)所述，map.aar和framework.aar的manifest.xml会分别配置以下元数据。

com.huawei.android.hms:map:1.0.0.1.aar的元数据配置：

com.huawei.android.hms:framework:1.1.0.2.aar的元数据配置：

fido.apk的元数据配置：

在fido.apk的build.gradle通过implementation配置依赖对map和framework的依赖

编译后生成的fido.apk自动生成了对map和framework的依赖，如下所示，fido.apk本身提供的API Level为3，它依赖要求map.apk的API Level至少为2，framwork.apk的API Level至少为3。

同理，CP也会集成Kit或框架提供的SDK，CP编译生成APK后其中的manifest.xml也会自动带上Kit SDK和框架SDK配置的元数据信息，其中包含了对Kit APK和框架APK的所有依赖的module name和对应的API Level。

(三)用户通过CP调用API触发升级时，从CP解析所有依赖并获得需要升级的包。

为了减小多次升级弹框对用户体验的影响，在用户通过CP调用API触发升级时需要获得当前CP依赖的所有module和框架的API Level，具体步骤如下：

1)框架首次启动时会安装所有Kit和动态加载框架对应的APK，解析出所有APK对应的module name和API Level，并存到本地数据库；

2)当CP通过Kit SDK触发调用到Kit的API时，向框架传递三部分信息，即modulename、要求的API Level和第三方调用者的包名；

3)框架根据module name和API Level在本地数据库中查询是否有满足条件的module，如果没有就触发升级弹框让用户确认；

4)用户确认升级的情况下，框架根据三方调用者的包名从系统中解析第三方调用者的元数据信息，即CP依赖的所有module name和对应的API Level；

5)根据解析出的所有module name和API Level从本地数据库查询是否有满足条件的模块，如果不满足，那么就要升级该模块对应的包，以此获得所有需要升级的包名。

(四)对需要升级的包循环检测更新、下载、解依赖直至本地满足所有依赖。经过步骤(三)获得了所有需要升级的包名，根据包名进行升级的步骤如下：

1)根据包名去应用市场检测该包名对应的最新APK版本号，如果最新版本号比本地安装的APK高，那么就要触发从应用市场下载；

2)根据包名从应用市场下载最新的APK；

3)下载完毕后从已经下载的APK中解析出其依赖的所有module name和对应的APILevel；

4)根据解析出的所有module name和对应的API Level从本地数据库中查询是否有满足条件的包，如果不满足就需要升级，以此根据依赖获得新一轮需要升级的包；

5)重复步骤1)到步骤4)，直至本地满足所有要求升级APK的依赖条件。

(五)安装所有下载的包

经过步骤(四)下载到所有升级的APK，将这些APK安装，并从中解析出APK对应的module name和API Level，保存至本地数据库。

综上所述，APK通过implementation编译时自动将SDK配置的元数据带入该APK的manifest.xml中，即APK自动生成了对其它APK的依赖关系，当APK从应用市场下载下来之后通过解析APK的manifest.xml就可以得到APK的依赖模块列表，通过依赖的模块名查询对应的包名，再通过包名从应用市场下载最新版本的APK，通过循环解析APK的依赖模块列表就可以下载到所有依赖的APK，对这些APK进行安装后，就完成了这个Kit的升级过程。

kit升级完成之后，对升级后的kit执行加载和运行操作。加载或运行kit的过程中可能会遇到下面的问题。

应用通过自己集成的kit SDK访问kit，此应用可以认为是kit的宿主应用，当宿主应用和kit同时调用某个库的不同版本时，例如：宿主应用调用json库1.0版本，kit应用调用json库的2.0版本；在类加载过程中会造成kit应用不能加载json正确的版本。

为了便于理解该问题，这里首先介绍一下JAVA中常见的类加载机制-双亲委托机制。双亲委托机制主要的加载原则时当一个类加载器需要加载某个类的时候，首先从自己的加载缓存中查询该类是否被加载，如果已经被加载就返回该类，如果没有被加载，则委托父类加载器去加载。父类加载器采用相同的策略。如果一直到祖先加载器(bootstrpclassLoader)都没有加载过该类，再由当前的类加载器加载，并将该类放入自己的加载缓存中，以便下次有加载请求的时候直接返回。

kit被宿主应用集成之后，对于HMS framework而言，两者构成父子关系，宿主应用是kit的父亲，根据双亲委派方式的运作机制，如果kit本身没有加载过json类，则先找宿主应用中是否有json类，若有，则返回宿主应用中json的1.0版本，而kit实际是希望加载json2.0的版本。这就造成了需求和结果不一致。应理解的是，应用在以JAVA语言实现时，本质是一个或多个类(class)构成的软件程序。

为了解决这个问题，本实施例提供一种类加载器的选择方法。本方案的核心思想是在kit加载时主动创建kit本身的类加载器和父类加载器，把kit的名称和类加载器存储到类加载路由表中，之后加载某个类时，通过类名提取包名，然后通过包名找到Kit的名称，最后通过kit名称找到对应的类加载器。

图9为该方案的架构图。Runtime模块作为Android四大组件(Activity、Provide、Service和Receiver)的运行环境，其中主要的功能是通过kit的名称(例如：情景感知kit的名称是：awareness_kit)加载kit应用包(apk)中的dex文件，使得kit应用包中基于Android四大组件开发的扩展组件类能插入到Runtime模块中对应的委托类中，可以被第三方的应用调用。Runtime模块中关于类加载的主要的子模块是：ContainerService、ClassLoaderManager、ProxyClassLoader、ClassLoaderRouter和ServiceDelegateImpl。

ContainerService模块：本身是Android的一个标准服务类，为应用调用kit应用中的服务组件提供代理支持。应用通过HMS framework提供的SDK调用此服务类中的各个接口函数。框架SDK使用Android系统标准的API函数StartService与ContainerService类交互，系统依次会调用ContainerService类的中OnCreate、onStarteCommand函数。此模块中还定义了Android系统中服务类的其他标准接口函数。

ServiceDelegateImpl模块：服务类代理的各个接口函数的具体业务逻辑在此模块中实现。主要包括Kit应用包的加载、桩的选择等。

ClassLoaderManager模块：管理类加载的创建和路由，初始化时从数据库或者文件中读取已经存在的类加载器路由信息，创建HMS framework关键模块(例如manager或runtime)的类加载器；动态生成kit的父类加载器和代理类加载器。

ProxyClassLoader模块：继承Android系统的ClassLoader类，扩展loadClass方法，从要加载的类名称中提取包名，通过包名从类加载器路由表中找到对应的类加载器。

ClassLoaderRouter模块：提供类加载路由信息初始化、查询和更新。类加载路由信息中包含了包名、kit名称以及类加载器的对应关系。示例如下：

表1

表2

应理解的是，以上示例也可以为一张表或一种数据结构实现。kit中也可以

具体工作流程如下：

1)应用要启动某个Kit的某个子服务(也可以称为子kit)时，例如LocationService，通过framework的SDK调用系统的StartService函数，调用框架中runtime模块的各个函数。

应理解的是，本实施例中该子服务是这个kit中调用的服务，但是该子服务自己也可以作为一个独立的服务，被应用直接调用。

2)ContainerService模块的OnStartCommand被系统调用后，调用ClassLoaderManager的newKitClassLoader函数。newKitClassLoader函数创建kit的类加载器、父类加载器和代理(proxy)类加载器。

3)把kit名称和对应的类加载器存储到ClassLoaderRouter模块的类加载器路由表中。

4)ContainerService模块在创建好kit的类加载器后，把类加载器传递给ServiceDelegateImpl模块，然后调用ServiceDelegateImpl模块的方法启动服务类LocationService的加载。

5)ServiceDelegateImpl模块先获得需要启动的服务类的名称即LocationService，然后调用kit的类加载器的loadClass方法，此loadClass方法调用父类加载器的loadClass方法，该方法又调用ProxyClassLoader的loadClass方法，该方法先提取LocationService服务类的包名，通过包名查找到该包名对应的kit的名称(该kit可以理解为第1)步中那个kit的子kit，它是提供LocationService服务的kit)，再通过该kit名称从类加载路由表中选择类加载器，若找到，返回类加载器，就使用该类加载器加载类文件。若没有找到，继续利用Android系统的双亲委托机制选择类加载器。

图10展示了上述实施例中类加载器关系的示例图。各个类加载器都有各自的父类加载器。父类加载器中包含代理类加载器，代理类加载器负责将类加载的需求导向ClassLoaderRouter模块，之后通过该模块中的路由表获得该类对应的类加载器。相对于现有技术的双亲委托机制，这种方法对类加载器实现了集中管控，一定程度上避免了双亲委托机制可能带来的类加载错误问题，也一定程度上避免了双亲委托带来的类加载器之间复杂的依赖关系。

现有技术在加载kit时，每启动一个kit会单独开启一个独立的进程，当kit数量增多时，会导致进程数量增多，消耗更多的系统资源。另外，kit进程的调度没有区别对待，无法满足不同业务的响应需求。

为了解决这个问题，本实施例提供一种kit进程管理方法，该方法基于业务对响应速度的需求，区分多个等级的进程池，加载kit时结合云端配置规则和本地负载均衡原则在不同优先级的进程池中选择合适的进程，解决不同业务响应需求无区别对待导致用户体验不好的问题。

本实施例中将进程类型分为三种：常驻(persist)进程，该类型的进程不容易被系统按照已有的规则主动杀掉，也不容易被LMK(low memory killer)杀掉；HP进程，不容易被系统按照已有的规则主动杀掉，但可被LMK杀掉；Normal进程，可被

分配策略示例如图11所示。

为了不让系统主动kill机制杀到HP进程，需要提高HP进程的优先级，让HP进程的优先级不低于某些前台进程的优先级。本实施例提供一种提高HP进程优先级的方法：HP进程和persist进程间建立双向Binder，让persist进程同步binder依赖HP进程。

Kit加载时选择宿主进程的工作流程如图12所示。首先读取kit的配置文件，如果配置文件指示选择persist进程，则进入persist进程，如果不是，是否是HP进程，如果是，则进入HP进程。如果不是persist进程也不是HP进程，则进入Normal进程的选择。Kit由多个子部分(可以称之为组件)构成，在选择Normal进程时是以组件为分配对象，其选择的原则如下：

a.在Normal进程中查找与待分配组件同属一个kit，且配置的进程属性相同的运行中组件，如果找到，则待分配组件将运行在该进程中，避免进程数量过多。

b.规则a不满足时，在各进程中查找与待分配组件同属一个kit，但进程属性不同的运行中组件，如果找到，则该进程将从当次可用进程中排除。

c.在可用进程中，根据进程负载寻找负载相对较小的进程，待分配组件将运行于该进程。负载计算基于实际运行的组件数量和内存占用来定，具体的结合规则可以是：

1)将内存占用分成几档，每200MB一档，高一档的认为负载较高。

2)在同档中，看活跃组件数，较多的认为负载较高。

通过上述方案，将进程分成三种不同的类型，并通过kit配置文件将重要的、业务需求高的kit调度到优先级较高的进程上，对于其他的kit还可以根据负载选择进程，在保证业务需求的前提下，提高了进程选择的灵活性，同时避免了进程数量过多。

需要说明的是，以上提到的应用可以是第三方应用，也可以是自研应用，或可以是第三方和自研的组合应用等。

本实施例提供的方案可以应用于终端设备或服务器等。这里的终端设备包括但不限于智能手机、车载装置、个人计算机、人工智能设备、平板电脑、个人数字助理、智能穿戴式设备(例如智能手表或手环、智能眼镜)、智能语音设备(例如智能音箱等)、虚拟现实/混合现实/增强显示设备或网络接入设备(例如网关等)等。服务器可以包括存储服务器或计算服务器等。

图13为本申请提供的一种终端设备的结构示意图。该终端设备可以为智能手机、智能电视、音箱、或扫地机器人等。如图所示，该终端设备包括通信模块510、传感器520、用户输入模块530、输出模块540、处理器550、音视频输入模块560、存储器570以及电源580。

通信模块510包括Wi-Fi模块和Wi-FiP2P模块，这两个模块可以集成在一个硬件上，也可以独立设置。通信模块510还可以包括其他的能使该计算机系统与通信系统或其他计算机系统之间进行通信的模块。例如，通信模块510还可以包括有线网络接口、广播接收模块、移动通信模块、无线因特网模块、局域通信模块和位置(或定位)信息模块等其中的一个或多个。这多种模块均在现有技术中有多种实现，本实施例不再一一描述。

传感器520可以感测系统的当前状态，诸如打开/闭合状态、位置、与用户是否有接触、方向、和加速/减速，并且传感器520可以生成用于控制系统的操作的感测信号。

用户输入模块530，用于接收输入的数字信息、字符信息或接触式触摸操作/非接触式手势，以及接收与系统的用户设置以及功能控制有关的信号输入等。用户输入模块530包括触控面板和/或其他输入设备。

输出模块540包括显示面板，用于显示由用户输入的信息、提供给用户的信息或系统的各种菜单界面等。可选的，可以采用液晶显示器(liquid crystal display，LCD)或有机发光二极管(organic light-emitting diode,OLED)等形式来配置显示面板。在其他一些实施例中，触控面板可覆盖显示面板上，形成触摸显示屏。另外，输出模块540还可以包括音频输出模块、告警器以及触觉模块等。

音视频输入模块560，用于输入音频信号或视频信号。音视频输入模块560可以包括摄像头和麦克风。另外，该计算机系统还可以包括音视频输出模块，用于输出音频信号或视频信号。

电源580可以在处理器550的控制下接收外部电力和内部电力，并且提供该计算机系统的各个组件的操作所需的电力。

处理器550可以指示一个或多个处理器，例如，处理器550可以包括一个或多个中央处理器，或者包括一个中央处理器和一个图形处理器，或者包括一个应用处理器和一个协处理器(例如微控制单元或神经网络处理器)。当处理器550包括多个处理器时，这多个处理器可以集成在同一块芯片上，也可以各自为独立的芯片。一个处理器可以包括一个或多个物理核，其中物理核为最小的处理单元。

存储器570存储计算机程序(或称计算机可读指令)，该计算机程序包括操作系统程序572和应用程序571等。典型的操作系统如微软公司的Windows，苹果公司的MacOS等用于台式机或笔记本的系统；又如谷歌公司开发的基于

存储器570可以是以下类型中的一种或多种：闪速(flash)存储器、硬盘类型存储器、微型多媒体卡型存储器、卡式存储器(例如SD或XD存储器)、随机存取存储器(randomaccess memory,RAM)、静态随机存取存储器(static RAM,SRAM)、只读存储器(read onlymemory,ROM)、电可擦除可编程只读存储器(electrically erasable programmable read-only memory，EEPROM)、可编程只读存储器(programmable ROM,PROM)、磁存储器、磁盘或光盘。在其他一些实施例中，存储器570也可以是因特网上的网络存储设备，系统可以对在因特网上的存储器570执行更新或读取等操作。

处理器550用于读取存储器570中的计算机程序，然后执行计算机程序定义的方法。本申请提供的设备发现方案主要实现在操作系统程序572中，也不排除有部分功能被应用程序571集成。

存储器570还存储有除计算机程序之外的其他数据573。

以上各个模块的连接关系仅为一种示例，本申请任意实施例提供的方法也可以应用在其它连接方式的终端设备中，例如所有模块通过总线连接。各个模块的划分仅是逻辑上的划分，并不代表硬件上一定是分开的。各个模块在本申请的一些实施例中未必是必要的。

另外，本申请还提供一种移动服务升级装置。该装置中包括一个或多个模块，用于实现前述第一方面任意一种实现方式的方法。应理解的是，模块可以与方法步骤一一对应，也可以不一一对应。模块的名称不做限定。该升级装置例如可以是实施例中描述的HMSframework。本申请还提供一种计算机程序介质，该计算机程序介质包括计算机可读指令，当所述计算机可读指令被一个或多个处理器执行时实现前述的方法。本申请还提供一种计算机程序产品(或称计算机程序)，该计算机程序产品包括计算机可读指令，当所述计算机可读指令被一个或多个处理器执行时实现前述的方法。

需要说明的是，前述实施例中提出模块或单元的划分仅作为一种示例性的示出，所描述的各个模块的功能仅是举例说明，本申请并不以此为限。本领域普通技术人员可以根据需求合并其中两个或更多模块的功能，或者将一个模块的功能拆分从而获得更多更细粒度的模块，以及其他变形方式。

以上描述的各个实施例之间相同或相似的部分可相互参考。本申请中的“多个”若无特殊说明，指两个或两个以上，或“至少两个”。本申请中的“A/B”包括三种情况：“A”、“B”和“A和B”。本申请中“第一”、“第二”、“第三”等仅为了区分表述，没有限定顺序的意思；另外，第一对象和第二对象在某些情况下有可能合并或指同一对象；再者，由于没有限定顺序，所以没有第一，也可以有第二或第三。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。另外，本申请提供的装置实施例附图中，模块之间的连接关系表示它们之间具有通信连接，具体可以实现为一条或多条通信总线或信号线。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述，仅为本申请的一些具体实施方式，但本申请的保护范围并不局限于此。