移动服务升级方法、装置和终端制造方法及图纸

本申请提供一种移动服务升级方法，该方法通过插件化思想将移动服务中的每个服务kit独立打包成apk，然后在用户使用应用且该应用调用该kit时实时升级该kit，相对于移动服务的全量静默升级，降低了升级耗时，提高了升级的灵活性。进一步的，该kit的apk中包含了kit与所依赖的kit之间的依赖关系，升级的时候可以一并升级，避免了版本不能满足需求造成的调用不成功。另外，在加载kit的过程中，本申请还提供一种类加载器的选择方法，使用路由表记录kit和类加载器的对应关系，在选择类加载器的时候根据该路由表来选择，避免了现有技术双亲委托机制可能造成的类加载不正确的问题。制可能造成的类加载不正确的问题。制可能造成的类加载不正确的问题。

【技术实现步骤摘要】
移动服务升级方法、装置和终端


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

技术介绍

[0002]近年来，移动终端设备，例如智能手机、平板电脑、穿戴式设备等急速发展，用户对移动终端设备的需求越来越丰富，应用终端设备上的应用类型越来越多。为了方便多种的应用的开发，移动服务厂商提供了移动服务，例如谷歌(google)提供的google移动服务(google mobile service,GMS)。GMS中包括公共框架以及多种服务(或称子应用或kit)等多个组件，并向应用开发者提供调用接口，这样应用开发者就可以在开发的过程中通过调用接口直接使用这多种服务中的任意一种或多种，而不需要重新开发。这里的多种服务例如地图服务、广告服务、定位服务、运动健康服务、机器学习服务等。
[0003]移动服务厂商将移动服务集成在操作系统中，并将操作系统提供给移动设备制造商预置在移动设备中，各个应用开发完成后也被预置在移动或被用户安装在移动设备中，这些软件协作以满足用户在日常生活中的各种需求。但是，目前一台移动设备中的移动服务的升级会导致移动服务中的各个组件一起升级，升级耗时较长，而且升级之后需要重启移动设备。这种升级方式不仅效率低，而且缺乏灵活性，比如因为升级后要重启设备，所以移动设备中的升级会设置为后台静默升级，比如在晚间且电量充足或充电的时间段升级，以免影响用户的使用。

技术实现思路

[0004]本申请提供一种移动服务升级方法，可以实现移动服务中的各个组件独立升级。进一步的，升级之后不需要重新启动移动设备。通过这种方式降低移动服务的升级时长，并且提供移动服务升级的灵活性，例如在应用需要的时候实时升级，应用需要哪个组件升级，就独立升级哪个组件，而且不需要重启设备，应用可以实时使用升级后的组件。
[0005]另外，本申请还提供实现以上方法的各种装置、计算机程序产品(例如移动服务软件或操作系统软件)、存储介质以及计算机设备等。
[0006]下面将从多个方面介绍本申请，容易理解的是，该以下多个方面可以单独实施，也可以选择其中任意两个或更多联合实施。该以下多个方面的具体实现方式和有益效果可互相参考。
[0007]第一方面，本申请提供一种移动服务升级方法，该方法包括：接收应用发送的对目标服务的调用请求，所述目标服务为移动服务包括的多个服务中的一个服务；根据所述服务调用请求确定所述目标服务需要升级时，从远程计算机下载所述目标服务的新版本，所述新版本是指满足所述调用请求的需求的版本；加载并运行所述目标服务的新版本。
[0008]应理解的是，上述方法也适用于升级多个服务。
[0009]所述服务可以理解下述实施例中的kit。当然kit中也可以包括多个组件，这多个组件也可以认为是kit。一个kit中也可能会调用其他的kit。这就可能会使用后续方法将介
绍的依赖升级。
[0010]通过以上方法，可以实现在应用触发下根据应用的调用需求升级移动服务中的一个或多个服务，升级耗时短，也比单纯的后台静默升级要更灵活，能够更及时地满足用户的需求。
[0011]上述方法也可以应用在静默升级的场景下，在静默升级的时候独立升级所述移动服务中的一个或多个服务，而不是整体升级移动服务，降低了升级时长。
[0012]在一些实现方式下，所述根据所述服务调用请求确定所述目标服务需要升级时，从远程计算机下载所述目标服务的新版本包括：根据所述目标服务的应用程序包中存储的依赖信息确定所述目标服务依赖于另一服务，且确定所述另一服务需要升级时，从所述远程计算机下载所述目标服务的新版本以及所述另一服务的新版本，其中，所述依赖信息包括所述目标服务与其它一个或多个服务的依赖关系。
[0013]在一些实现方式下，所述依赖信息存储在manifest文件中，所述依赖信息是在编译所述目标服务的所述应用程序包的阶段被加入到所述manifest文件中的。
[0014]通过上述方式，升级某个服务的时候可以根据该服务的APK中所包含的依赖信息升级该服务所依赖的其他服务(根据需求升级，如果没有需求，也可以不升级)，避免了因依赖的服务版本不满足需求而造成的应用调用失败。
[0015]在一些实现方式下，所述加载所述目标服务的新版本包括：查找类加载器路由表以确定类加载器，通过查找到的所述类加载器加载所述目标服务的类文件或所述目标服务的子服务的类文件，所述类加载器路由表中包括存储有服务名称、包名以及类加载器的对应关系。
[0016]在一些实现方式下，所述查找类加载器路由表以确定类加载器，通过查找到的所述类加载器加载所述目标服务的子服务的类文件包括：创建所述目标服务的第一类加载器和第二类加载器，并将所述目标服务与所述第一类加载器的对应信息存储在所述类加载器路由表中，述类加载器路由表中包括存储有包名与服务名称的对应关系，所述类加载器路由表存储的服务包括所述子服务；通过所述第一类加载器的加载类loadClass方法调用所述第二类加载器的加载类loadClass方法，以提取所述子服务的包名，并从所述类加载器路由表中查找与所述包名匹配的子服务名称以及类加载器；通过查找到的所述类加载器加载所述子服务的类文件。
[0017]应理解的是，loadClass只是本领域在此处惯用的实现方法名称，本申请的其他实施例中也可以不用该名称。
[0018]JAVA(一种高级程序语言)程序在加载类文件时通常使用的是双亲委托机制，但是在移动服务框架中，类加载器众多，双亲委托机制容易造成类加载的版本不正确，不利于管理。本申请提出了路由表，通过路由表记录包名服务名称、包名以及类加载器的对应关系，然后在加载类文件的时候查询所述路由表，获得对应的类加载器，而不是使用传统的双亲委托机制。这样，多个类加载器由路由表集中指派，管理起来更方便，查找变得扁平化，也可以实现应用间的解耦，集中管控类路由,依赖更加清晰。
[0019]应理解的是，以上类加载器的选择方法在后台静默升级的时候也可以使用。
[0020]在一些实现方式下，所述运行所述目标服务的新版本包括：查询所述目标服务的配置文件，从不同优先级的多个进程中选择所述配置文件指示的目标进程运行所述目标服
务。
[0021]由于每个kit都有自己的业务需求，所以本实施例提供了不同优先级的进程池，根据kit的配置文件的指示选择与业务需求匹配的优先级的进程来运行这个kit，增加了进程选择的灵活性的同时满足了业务需求。
[0022]在一些实现方式下，所述运行所述目标服务的新版本包括：根据进程负载情况从多个同等优先级的进程中选择目标进程运行所述目标服务，其中所述目标进程的负载小于或等于所述多个同等优先级的进程中的其他进程。
[0023]该方法根据负载情况选择负载较低的进程来运行当前的kit，能够提高kit的运行效率。
[0024]以上不管是优先级的方法，还是选择负载较低的进程，都可以认为是建立了进程池，从进程池中选择合适的进程来运行kit，避免本文档来自技高网...

【技术保护点】

【技术特征摘要】
1.一种移动服务升级方法，其特征在于，包括：接收应用发送的对目标服务的调用请求，所述目标服务为移动服务包括的多个服务中的一个服务；根据所述服务调用请求确定所述目标服务需要升级时，从远程计算机下载所述目标服务的新版本，所述新版本是指满足所述调用请求的需求的版本；加载并运行所述目标服务的新版本。2.根据权利要求1所述的方法，其特征在于，所述根据所述服务调用请求确定所述目标服务需要升级时，从远程计算机下载所述目标服务的新版本包括：根据所述目标服务的应用程序包中存储的依赖信息确定所述目标服务依赖于另一服务，且确定所述另一服务需要升级时，从所述远程计算机下载所述目标服务的新版本以及所述另一服务的新版本，其中，所述依赖信息包括所述目标服务与其它一个或多个服务的依赖关系。3.根据权利要求2所述的方法，其特征在于，所述依赖信息存储在manifest文件中，所述依赖信息是在编译所述目标服务的所述应用程序包的阶段被加入到所述manifest文件中的。4.根据权利要求1-3任意一项所述的方法，其特征在于，所述加载所述目标服务的新版本包括：查找类加载器路由表以确定类加载器，通过查找到的所述类加载器加载所述目标服务的类文件或所述目标服务的子服务的类文件，所述类加载器路由表中包括存储有服务名称以及类加载器的对应关系。5.根据权利要求4所述的方法，其特征在于，所述查找类加载器路由表以确定类加载器，通过查找到的所述类加载器加载所述目标服务的子服务的类文件包括：创建所述目标服务的第一类加载器和第二类加载器，并...

【专利技术属性】
技术研发人员：陈秋林，吴江铮，沈慧海，王新建，
申请(专利权)人：华为技术有限公司，
类型：发明
国别省市：