CN113031957A - 应用程序的安装方法、客户端、终端、服务器及存储介质 - Google Patents

Abstract

本申请实施例公开了一种应用程序的安装方法、客户端、终端、服务器及存储介质，所述方法包括：客户端向服务器发送待安装应用的下载请求；其中，下载请求携带移动设备的标识信息；获取服务器生成的待安装应用对应的安装文件；其中，安装文件包括与待安装应用对应的APK文件，以及与待安装应用和标识信息对应的第一AOT编译文件；对APK文件和第一AOT编译文件进行文件校验处理，获得校验结果；若校验结果为通过，则根据第一AOT编译文件和APK文件完成待安装应用的安装。服务器接收客户端发送的待安装应用的下载请求；生成待安装应用对应的安装文件；将安装文件发送至客户端，以使客户端根据第一AOT编译文件和APK文件完成待安装应用的安装。

Description

应用程序的安装方法、客户端、终端、服务器及存储介质

技术领域

本发明涉及通信技术领域，尤其涉及一种应用程序的安装方法、客户端、终端、服务器及存储介质。

背景技术

与原有的Dalvik虚拟机相比，安卓运行库(Android Runtime，ART)虚拟机的推出，能够通过提前(Ahead-of-time，AOT)编译的方式进行二进制机器码的提前编译，从而在一定程度上提升了应用程序的运行效率。

然而，如果要以AOT的方式运行安卓(Android)应用程序，就需要在应用程序的安装过程中调用可执行程序dexopt或dex2opt对dex文件进行编译，这样的编译过程不但增大了安装时间，还产生了较大的资源开销，可见，如何在提高运行效率的同时，提升应用程序的安装效率并降低资源开销，成为亟待解决的问题。

发明内容

本申请实施例提供了一种应用程序的安装方法、客户端、终端、服务器及存储介质，能够有效提升应用程序的安装效率，并减少资源开销。

本申请实施例的技术方案是这样实现的：

第一方面，本申请实施例提供了一种应用程序的安装方法，所述方法应用于客户端，所述方法包括：

向服务器发送待安装应用的下载请求；其中，所述下载请求携带移动设备的标识信息；

获取所述服务器生成的所述待安装应用对应的安装文件；其中，所述安装文件包括与所述待安装应用对应的APK文件，以及与所述待安装应用和所述标识信息对应的第一AOT编译文件；

对所述APK文件和所述第一AOT编译文件进行文件校验处理，获得校验结果；

若所述校验结果为通过，则根据所述第一AOT编译文件和所述APK文件完成所述待安装应用的安装。

第二方面，本申请实施例提供了一种应用程序的安装方法，所述方法应用于服务器，所述方法包括：

接收客户端发送的待安装应用的下载请求；其中，所述下载请求携带移动设备的标识信息；

生成所述待安装应用对应的安装文件；其中，所述安装文件包括与所述待安装应用对应的APK文件，以及与所述待安装应用和所述标识信息对应的第一AOT编译文件；

将所述安装文件发送至所述客户端，以使客户端根据所述第一AOT编译文件和所述APK文件完成所述待安装应用的安装。

第三方面，本申请实施例提供了一种客户端，所述客户端包括：第一发送单元、获取单元、校验单元以及安装单元，

所述确定单元，用于向服务器发送待安装应用的下载请求；其中，所述下载请求携带移动设备的标识信息；

所述获取单元，用于获取所述服务器生成的所述待安装应用对应的安装文件；其中，所述安装文件包括与所述待安装应用对应的APK文件，以及与所述待安装应用和所述标识信息对应的第一AOT编译文件；

所述校验单元，用于对所述APK文件和所述第一AOT编译文件进行文件校验处理，获得校验结果；

所述安装单元，用于若所述校验结果为通过，则根据所述第一AOT编译文件和所述APK文件完成所述待安装应用的安装。

第四方面，本申请实施例提供了一种终端，所述终端中运行如权利要求16所述的客户端，所述终端包括第一处理器、存储有所述第一处理器可执行指令的第一存储器，当所述指令被所述第一处理器执行时，实现如上所述的应用程序的安装方法。

第五方面，本申请实施例提供了一种服务器，所述服务器包括：接收单元、生成单元以及第二发送单元，

所述接收单元，用于接收客户端发送的待安装应用的下载请求；其中，所述下载请求携带移动设备的标识信息；

所述生成单元，用于生成所述待安装应用对应的安装文件；其中，所述安装文件包括与所述待安装应用对应的APK文件，以及与所述待安装应用和所述标识信息对应的第一AOT编译文件；

所述第二发送单元，用于将所述安装文件发送至所述客户端，以使客户端根据所述第一AOT编译文件和所述APK文件完成所述待安装应用的安装。

第六方面，本申请实施例提供了一种服务器，所述服务器包括第二处理器、存储有所述第二处理器可执行指令的第二存储器，当所述指令被所述第二处理器执行时，实现如上所述的应用程序的安装方法。

第七方面，本申请实施例提供了一种计算机可读存储介质，其上存储有程序，应用于客户端和服务器中，所述程序被第一处理器执行时，实现如第一方面所述的应用程序的安装方法；所述程序被第二处理器执行时，实现如第二方面所述的应用程序的安装方法。

本申请实施例提供了一种应用程序的安装方法、客户端、终端、服务器及存储介质，客户端向服务器发送待安装应用的下载请求；其中，下载请求携带移动设备的标识信息；获取服务器生成的待安装应用对应的安装文件；其中，安装文件包括与待安装应用对应的APK文件，以及与待安装应用和标识信息对应的第一AOT编译文件；对APK文件和第一AOT编译文件进行文件校验处理，获得校验结果；若校验结果为通过，则根据第一AOT编译文件和APK文件完成待安装应用的安装。服务器接收客户端发送的待安装应用的下载请求；其中，下载请求携带移动设备的标识信息；生成待安装应用对应的安装文件；其中，安装文件包括与待安装应用对应的APK文件，以及与待安装应用和标识信息对应的第一AOT编译文件；将安装文件发送至客户端，以使客户端根据第一AOT编译文件和APK文件完成待安装应用的安装。也就是说，在本申请的实施例中，在进行应用程序的安装时，客户端不再执行odex文件或vdex文件的生成流程，而是直接获取服务器生成的odex文件或vdex文件，即客户端不再对APK进行预编译处理，而是由服务器提前完成可执行程序dex2oat或dexopt的调用，从而能够有效提升应用程序的安装效率，并减少资源开销。

附图说明

图1为APK的编译和安装示意图；

图2为应用程序的安装方法的实现流程示意图一；

图3为应用程序的安装方法的实现流程示意图二；

图4为应用程序的安装方法的实现流程示意图三；

图5为应用程序的安装方法的实现流程示意图四；

图6为应用程序的安装方法的实现流程示意图五；

图7为应用程序的安装方法的实现流程示意图六；

图8为应用程序的安装方法的实现流程示意图七；

图9为客户端的组成结构示意图；

图10为终端的组成结构示意图；

图11为服务器的组成结构示意图一；

图12为服务器的组成结构示意图二。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。可以理解的是，此处所描述的具体实施例仅用于解释相关申请，而非对该申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与有关申请相关的部分。

Android是一种基于Linux的自由及开放源代码的操作***，主要使用于移动设备，如智能手机和平板电脑，由Google公司和开放手机联盟领导及开发。Android操作***最初由Andy Rubin开发，主要支持手机，随后，Android逐渐扩展到平板电脑及其他领域上，如电视、数码相机、游戏机等。

从Android5.0开始，安卓运行库ART就彻底代替了原先的虚拟机(Dalvik)，成为Android***上新的虚拟机。

AOT是相对于即时编译技术(Just-in-time，JIT)而言的。JIT是在运行时进行字节码到本地机器码的编译，这也是为什么Java普遍被认为效率比C++差的原因。无论是解释器的解释还是运行过程中即时编译，都比C++编译出的本地机器码执行多了一个耗费时间的过程。而AOT就是向C++编译过程靠拢的一项技术：当应用程序包(Android applicationpackage，Android，APK)在安装的时候，***会通过一个名称为dex2oat的工具将APK中的dex文件编译成包含本地机器码的oat文件存放下来。这样做之后，在程序执行的时候，就可以直接使用已经编译好的机器码以加快效率。

图1为APK的编译和安装示意图，如图1所示，编译阶段，通过编译命令javac将Java文件编译成Class文件(步骤S1)，例如，将Hello.java文件编译成Hello.class文件；然后再将Class文件经过dx过程编译成dex文件(步骤S2)，例如，将Hello.class文件编译成Hello.dex文件；最终通过Android资源打包工具(Android Asset Packaging Tool，aapt)将dex文件打包到应用程序包APK里，同时，将资源文件Resources和本地代码Native Code也打包到APK里(步骤S3)。而对于安装阶段，在安卓5.0以前，APK中的dex文件在安装时会被优化成odex文件，即采用dexopt工具将dex文件编译成odex文件(步骤S4)，在运行时，对于Dalvik虚拟机，odex文件会被JIT编译器编译成Native代码(步骤S5)。而在安卓5.0以后，使用dex2oat工具进行AOT预编译，AOT是静态编译，应用在安装的时候会启动dex2oat过程把dex文件预编译成ELF文件(步骤S6)，其中既包含了dex文件中原先的内容，也包含了已经编译好的Native代码，因此，对于ART虚拟机，ELF文件可以直接被本地处理器执行，每次运行程序的时候不用重新编译。

也就是说，ART虚拟机采用了AOT的方式提前编译成二进制机器码，因此大大提升了应用程序的运行效率。

然而，由于在安装环节的dex2oat发生的时候，需要将原文件中的dex文件抽出来，然后进行逐个指令的判断，再进行翻译，并生成大量的中间内容，而这这一过程的开销会占据安装的大部分时间。

并且，dex2oat过程是一个CPU密集型的运算过程，会占用大量的CPU时间，为了提升安装速度甚至使用所有核心完成安装，便造成其他应用很难分到CPU时间片，从而造成卡顿。

如果dex文件比较大，会产生大量的中间内容，这些在存储器memory当中是保存不下的，所以采用了虚拟内存swap机制，会将一些内容交换到嵌入式存储(Embedded MultiMedia Card，EMMC)当中，而且有大量的读操作，同时会将结果保存至EMMC当中，因此dex2oat过程对整个***的输入输出IO资源消耗也很大，与其他应用竞争可能引起ANR问题。

综上所述，虽然ART虚拟机能够通过AOT的方式进行二进制机器码的提前编译，大大提升了应用程序的运行效率，但是，Google原生APK格式安装包仍然是一个包含Dex字节码的APK文件，因此，为了将Dex字节码转换为机器码存储在移动设备中，供运行应用所使用，在安装应用时仍然需要再次进行编译，而在整个应用安装过程中，消耗资源和时间最多的部分正是安卓***应用安装流程，即将APK文件中的classes.dex字节码翻译为最终执行所需优化字节码或机器码的过程，它占据应用安装过程的大部分性能开销，导致应用安装耗时很长、***响应变慢。

为了解决相关技术存在的问题，在本申请的实施例中，在本申请的实施例中，在进行应用程序的安装时，客户端不再执行odex文件或vdex文件的生成流程，而是直接获取服务器生成的odex文件或vdex文件，即客户端不再对APK进行预编译处理，而是由服务器提前完成可执行程序dex2oat或dexopt的调用，从而能够有效提升应用程序的安装效率，并减少资源开销。

需要说明的是，本申请提出的应用程序的安装方法，可以应用于客户端和服务器中。具体地，服务器-客户端，即Client-Server(C/S)结构。C/S结构通常采取两层结构。服务器负责数据的管理，客户端负责完成与用户的交互任务。

客户端通过局域网与服务器相连，接受用户的请求，并通过网络向服务器提出请求，对数据库进行操作。服务器接受客户端的请求，将数据提交给客户端，客户端将数据进行计算并将结果呈现给用户。服务器还要提供完善安全保护及对数据完整性的处理等操作，并允许多个客户端同时访问服务器，这就对服务器的硬件处理数据能力提出了很高的要求。

在C/S结构中，应用程序分为两部分：服务器部分和客户端部分。服务器部分是多个用户共享的信息与功能，执行后台服务，如控制共享数据库的操作等；客户端部分为用户所专有，负责执行前台功能，在出错提示、在线帮助等方面都有强大的功能，并且可以在子程序间自由切换。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

本申请一实施例提供了一种应用程序的安装方法，应用于客户端中，其中，客户端，即为客户提供本地服务的程序。除了一些只在本地运行的应用程序之外，一般安装在普通的客户机上，需要与服务端互相配合运行。因特网发展以后，较常用的用户端包括了如万维网使用的网页浏览器、收寄电子邮件时的电子邮件客户端、以及即时通讯的客户端软件等。对于这一类应用程序，需要网络中有相应的服务器和服务程序来提供相应的服务，如数据库服务、电子邮件服务等。

图2为应用程序的安装方法的实现流程示意图一，如图2所示，在本申请的实施例中，客户端安装应用程序的方法可以包括以下步骤：

步骤101、向服务器发送待安装应用的下载请求；其中，下载请求携带移动设备的标识信息。

在本申请的实施例中，客户端可以先向服务器发送待安装应用的下载请求，其中，该下载请求用于进行待安装应用对应的安装文件的获取。

需要说明的是，在本申请中，客户端向服务器发送的下载请求中，可以携带有移动设备的标识信息，其中，该移动设备为运行客户端的智能设备。示例性的，移动设备可以为Android***的各种电子设备，包括但不限于诸如移动电话、笔记本电脑、数字广播接收器、个人数字助理(Personal Digital Assistant，PDA)、平板电脑(PAD)、便携式多媒体播放器(Portable Media Player，PMP)、车载电子设备(例如车载导航电子设备)等等的移动电子设备以及诸如数字电视(TV)、台式计算机等等的固定电子设备。

进一步地，在本申请的实施例中，移动设备的标识信息可以为移动设备配置的只读存储器(Read-Only Memory，ROM)的标识。

其中，ROM以非破坏性读出方式工作，只能读出无法写入信息。信息一旦写入后就固定下来，即使切断电源，信息也不会丢失，所以又称为固定存储器。ROM所存数据通常是装入整机前写入的，整机工作过程中只能读出，不像随机存储器能快速方便地改写存储内容。ROM所存数据稳定，断电后所存数据也不会改变，并且结构较简单，使用方便，因而常用于存储各种固定程序和数据。

除少数种类的只读存储器(如字符发生器)可通用之外，不同种类的只读存储器功能不同。为便于用户使用和大批量生产，进一步发展出多种类型的ROM，且每种只读存储器都有各自的特性和适用范围。从其制造工艺和功能上分，ROM有五种类型，即掩膜编程的只读存储器MROM(Mask-programmedROM)、可编程的只读存储器PROM(Programmable ROM)、可擦除可编程的只读存储器EPROM(Erasable Programmable ROM)、可电擦除可编程的只读存储器EEPROM(Elecrically Erasable Programmable ROM)和快擦除读写存储器(FlashMemory)。

可以理解的是，在本申请中，移动设备的标识信息是移动设备所属类型的唯一标识，由于同一类型移动设备间硬件版本、***软件版本完全相同，因此同一类型移动设备多对应的标识信息可以相同。

步骤102、获取服务器生成的待安装应用对应的安装文件；其中，安装文件包括与待安装应用对应的APK文件，以及与待安装应用和标识信息对应的第一AOT编译文件。

在本申请的实施例中，客户端在向服务器发送待安装应用的下载请求之后，可以获取服务器生成的、待安装应用的安装文件。

可以理解的是，在本申请中，客户端可以将待安装应用的下载请求发送至服务器，服务器在接收到客户端发送的、携带有移动设备的标识信息的下载请求之后，便可以根据标识信息生成与运行客户端的移动终端所对应的、待安装应用的安装文件。

需要说明的是，在本申请的实施例中，安装文件可以包括与所述待安装应用对应的APK文件，还可以包括与所述待安装应用和所述标识信息对应的第一AOT编译文件。

其中，APK是Android操作***使用的一种应用程序包文件格式，用于分发和安装移动应用及中间件。一个Android应用程序的代码想要在Android设备上运行，必须先进行编译，然后被打包成为一个被Android***所能识别的文件才可以被运行，而这种能被Android***识别并运行的文件格式便是“APK”。一个APK文件内可以包含被编译的代码文件(.dex文件)，文件资源(resources)，原生资源文件(assets)，证书(certificates)，以及清单文件(manifest file)等。

进一步地，在本申请的实施例中，第一AOT编译文件是与待安装应用和标识信息相对应的，由于同一类型的移动设备所对应的标识信息可以相同，因此，对于同一类型的移动设备，安装待安装应用时所使用的第一AOT编译文件可以是相同的。

需要说明的是，在本申请的实施例中，第一AOT编译文件可以为服务器调用可执行程序dex2oat或dexopt执行APK的编译，生成的用于运行待安装应用的文件。

可以理解的是，在本申请中，第一AOT编译文件可以包括odex文件或vdex文件。具体地，服务器调用可执行程序dexopt可以生成odex文件，服务器调用可执行程序dex2oat可以生成vdex文件。

其中，vdex是package直接转化的可执行二进制码文件，第一次开机就会生成在/system/app/<packagename>/oat/下；在***运行过程中，虚拟机将其从“/system/app”下copy到“/data/davilk-cache/”下；odex是从vdex这个文件中提取了部分模块生成的一个新的可执行二进制码文件，第一次开机就会生成在/system/app/<packagename>/oat/下，在***运行过程中，虚拟机将其从“/system/app”下copy到“/data/davilk-cache/”下。

进一步地，在本申请的实施例中，服务器根据接收到的下载请求中携带的标识信息，选择调用可执行程序dexopt，还是调用可执行程序dex2oat。

需要说明的是，在本申请的实施例中，服务器可以包括下载服务器和编译服务器，其中，下载服务器可以用于接收客户端发送的下载请求，还可以用于进行安装文件的存储，编译服务器可以用于进行第一AOT编译文件的生成。

步骤103、对APK文件和第一AOT编译文件进行文件校验处理，获得校验结果。

在本申请的实施例中，客户端在获取服务器生成的待安装应用对应的安装文件之后，可以进一步对APK文件和第一AOT编译文件进行文件校验处理，从而可以获得校验结果。

需要说明的是，在本申请的实施例中，校验结果可以包括通过或不通过，其中，只有在APK文件和第一AOT编译文件均校验成功的情况下，校验结果才能为通过。

图3为应用程序的安装方法的实现流程示意图二，如图3所示，在对所述APK文件和所述第一AOT编译文件进行文件校验处理，获得校验结果之前，即步骤103之前，客户端安装应用程序的方法还可以包括以下步骤：

步骤105、获取服务器生成的文件校验码；其中，文件校验码包括APK文件对应的第一校验码，和第一AOT编译文件对应的第二校验码。

在本申请的实施例中，客户端还可以获取服务器生成的与安装文件对应的文件校验码。

可以理解的是，在本申请的实施例中，服务器在进行待安装应用的安装包的生成之后，还可以进一步进行文件校验值的计算，从而获得文件检验码。其中，文件校验码可以包括APK文件对应的第一校验码，还可以包括第一AOT编译文件对应的第二校验码。

需要说明的是，在本申请中，第一校验码用于对APK文件进行校验处理，第二校验码用于对第一AOT编译文件进行校验处理，即对odex文件或vdex文件进行校验处理。

进一步地，在本申请的实施例中，客户端在对APK文件和第一AOT编译文件进行文件校验处理，获得校验结果时，可以先确定所述APK文件的第一校验和；如果第一校验和等于第一校验码，那么客户端可以继续确定所述第一AOT编译文件对应的第二校验和；如果第二校验和等于所述第二校验码，那么客户端可以确定所述校验结果为通过；如果第二校验和不等于第二校验码，那么客户端可以确定所述校验结果为不通过。

需要说明的是，在本申请的实施例中，文件校验是指文件的MD5、SHA1、CRC32的值的检验。其中，每个文件都可以用MD5验证程序算出一个固定的MD5码来。进一步地，由于MD5存在被修改的风险，因此客户端还可以采用消息认证码(Message Authentication Code，MAC)的方式进行文件校验，其中，MAC是发送方和接收放约定的一个特定的数值串，当发送方发送文件时，将文件内容加上MAC一起进行HASH计算(MAC不随文件一同发送)，即使第三方截获到此文件，由于没有MAC，因此无法再计算出正确的HASH值。

进一步地，在本申请的实施例中，客户端在确定所述APK文件的第一校验和之后，如果第一校验和不等于第一校验码，那么客户端可以重新获取所述服务器生成的所述安装文件。也就是说，如果APK文件校验失败，那么客户端需要重新进行安装文件的下载。

步骤104、若校验结果为通过，则根据第一AOT编译文件和APK文件完成待安装应用的安装。

在本申请的实施例中，客户端在对所述APK文件和第一AOT编译文件进行文件校验处理，获得校验结果之后，如果校验结果为通过，则根据所述第一AOT编译文件和APK文件完成待安装应用的安装。

需要说明的是，在本申请的实施例中，客户端在分别对APK文件和第一AOT编译文件进行文件校验处理之后，如果获得的验证结果为通过，即APK文件和第一AOT编译文件均验证成功，那么客户端便可以直接使用APK文件和第一AOT编译文件完成待安装文件的安装处理。

也就是说，在本申请中，在进行待安装应用的安装时，客户端不再调用可执行程序dex2oat或dexopt执行APK的编译，而是直接从服务器获取已经生成的odex文件或vdex文件。

进一步地，在本申请的实施例中，图4为应用程序的安装方法的实现流程示意图三，如图4所示，在对所述APK文件和所述第一AOT编译文件进行文件校验处理，获得校验结果之后，即步骤103之后，客户端安装应用程序的方法还可以包括以下步骤：

步骤106、若校验结果为不通过，则通过编译处理生成第二AOT编译文件。

步骤107、根据第二AOT编译文件和APK文件完成待安装应用的安装。

在本申请的实施例中，客户端在对所述APK文件和第一AOT编译文件进行文件校验处理，获得校验结果之后，如果校验结果为不通过，那么客户端需要进行编译处理，从而获得第二AOT编译文件。

可以理解的是，在本申请的实施例中，客户端在进行文件校验处理之后，如果APK文件检验成功，而第一AOT编译文件校验失败，那么客户端可以选择按照现有的安装方法，通过调用可执行程序dex2oat或dexopt执行APK的编译，生成的用于运行待安装应用的第二AOT编译文件。

需要说明的是，在本申请的实施例中，第二AOT编译文件是与待安装应用和标识信息相对应的，由于同一类型的移动设备所对应的标识信息可以相同，因此，对于同一类型的移动设备，安装待安装应用时所使用的第二AOT编译文件可以是相同的。

可以理解的是，在本申请中，第二AOT编译文件可以包括odex文件或vdex文件。具体地，客户端调用可执行程序dexopt可以生成odex文件，服务器调用可执行程序dex2oat可以生成vdex文件。

进一步地，在本申请的实施例中，客户端根据标识信息，选择调用可执行程序dexopt，还是调用可执行程序dex2oat。

需要说明的是，在本申请的实施例中，客户端在生成第二AOT编译文件之后，便可以根据第二AOT编译文件和APK文件进行安装处理，即可以按照现有的AOT方式完成所述待安装应用的安装。

进一步地，在本申请的实施例中，客户端执行文件校验处理，并确定验结果为通过之后，客户端在根据所述第一AOT编译文件和所述APK进行安装处理的过程中，如果出现安装异常的情况，那么客户端可以选择使用现有的AOT方式进行应用程序的安装，即客户端基于所述标识信息进行编译处理，生成所述第二AOT编译文件；然后根据所述第二AOT编译文件和所述APK文件完成所述待安装应用的安装。

需要说明的是，在本申请的实施例中，客户端可以通过应用程序接口(Application Programming Interface，API)获取所述安装文件和所述文件校验码；其中，所述API支持所述第一AOT编译文件和所述文件校验码的传输。

具体地，应用程序接口API是一些预先定义的函数，或指软件***不同组成部分衔接的约定。可以用来提供应用程序与开发人员基于某软件或硬件得以访问的一组例程，而又无需访问源码，或理解内部工作机制的细节。

也就是说，在本申请的实施例中，可以在原生接口基础上，调整API，使API支持传入odex文件或vdex文件以及相关的文件校验码，从而可以使客户端与服务器通过API进行AOT编译文件和所述文件校验码的传输。

综上所述，在本申请的实施例中，通过上述步骤101至步骤107所提出的应用程序的安装方法，针对采用AOT方式安装应用存在的安装流程的慢、***资源占用大等问题，选择在客户端去除dexopt或dex2oat的处理流程，而在服务器中进行odex文件或vdex文件的生成，同时，通过向服务器同步移动设备的标识信息，以使服务器针对特定的***Rom进行AOT预编译工作，从而保证服务器编译的二进制文件与本地编译的二进制文件完全一致。可见，本申请提出的应用程序的安装方法，能够在原有安装流程的基础上，提升安装速度，减少资源开销，同时保证了整个安装流程的可靠性。

也就是说，在本申请中，由于客户端不再调用可执行程序dex2oat或dexopt执行APK的预编译，而是直接从服务器获取与终端设备对应的odex文件或vdex文件，进而能够大幅提升应用安装速度，与现有的应用安装方案相比，缩短了安装时间，同时大幅减少***CPU资源、IO资源开销，避免了应用安装时造成的使用卡顿、发热ANR。

本申请实施例提供了一种应用程序的安装方法，客户端向服务器发送待安装应用的下载请求；其中，下载请求携带移动设备的标识信息；获取服务器生成的待安装应用对应的安装文件；其中，安装文件包括与待安装应用对应的APK文件，以及与待安装应用和标识信息对应的第一AOT编译文件；对APK文件和第一AOT编译文件进行文件校验处理，获得校验结果；若校验结果为通过，则根据第一AOT编译文件和APK文件完成待安装应用的安装。也就是说，在本申请的实施例中，在进行应用程序的安装时，客户端不再执行odex文件或vdex文件的生成流程，而是直接获取服务器生成的odex文件或vdex文件，即客户端不再对APK进行预编译处理，而是由服务器提前完成可执行程序dex2oat或dexopt的调用，从而能够有效提升应用程序的安装效率，并减少资源开销。

本申请的再一实施例提供了一种应用程序的安装方法，应用于服务器中，其中，服务器在网络中为其它客户机(如PC机、智能手机、ATM等终端甚至是火车***等大型设备)提供计算或者应用服务。服务器具有高速的CPU运算能力、长时间的可靠运行、强大的I/O外部数据吞吐能力以及更好的扩展性。根据服务器所提供的服务，一般来说服务器都具备承担响应服务请求、承担服务、保障服务的能力。服务器作为电子设备，其内部的结构十分的复杂，但与普通的计算机内部结构相差不大，如：CPU、硬盘、内存，***、***总线等。

图5为应用程序的安装方法的实现流程示意图四，如图5所示，在本申请的实施例中，服务器安装应用程序的方法可以包括以下步骤：

步骤201、接收客户端发送的待安装应用的下载请求；其中，下载请求携带移动设备的标识信息。

在本申请的实施例中，服务器可以先接收客户端发送的待安装应用的下载请求，其中，该下载请求用于进行待安装应用对应的安装文件的获取。

需要说明的是，在本申请中，服务器接收客户端发送的下载请求中，可以携带有移动设备的标识信息，其中，该移动设备为运行客户端的智能设备。

进一步地，在本申请的实施例中，移动设备的标识信息可以为移动设备配置的只读存储器ROM的标识。

可以理解的是，在本申请中，移动设备的标识信息是移动设备所属类型的唯一标识，由于同一类型移动设备间硬件版本、***软件版本完全相同，因此同一类型移动设备多对应的标识信息可以相同。

步骤202、生成待安装应用对应的安装文件；其中，安装文件包括与待安装应用对应的APK文件，以及与待安装应用和标识信息对应的第一AOT编译文件。

在本申请的实施例中，服务器在接收客户端发送的待安装应用的下载请求之后，可以生成与待安装应用对应的安装文件。

可以理解的是，在本申请中，服务器在接收到客户端发送的、携带有移动设备的标识信息的下载请求之后，便可以根据标识信息生成与运行客户端的移动终端所对应的、待安装应用的安装的安装文件。

需要说明的是，在本申请的实施例中，安装文件可以包括与所述待安装应用对应的APK文件，还可以包括与所述待安装应用和所述标识信息对应的第一AOT编译文件。

其中，APK是Android操作***使用的一种应用程序包文件格式，用于分发和安装移动应用及中间件。一个Android应用程序的代码想要在Android设备上运行，必须先进行编译，然后被打包成为一个被Android***所能识别的文件才可以被运行，而这种能被Android***识别并运行的文件格式便是“APK”。一个APK文件内可以包含被编译的代码文件(.dex文件)，文件资源(resources)，原生资源文件(assets)，证书(certificates)，以及清单文件(manifest file)等。

进一步地，在本申请的实施例中，第一AOT编译文件是与待安装应用和标识信息相对应的，由于同一类型的移动设备所对应的标识信息可以相同，因此，对于同一类型的移动设备，安装待安装应用时所使用的第一AOT编译文件可以是相同的。

需要说明的是，在本申请的实施例中，第一AOT编译文件可以为服务器调用可执行程序dex2oat或dexopt执行APK的编译，生成的用于运行待安装应用的文件。

可以理解的是，在本申请中，第一AOT编译文件可以包括odex文件或vdex文件。具体地，服务器调用可执行程序dexopt可以生成odex文件，服务器调用可执行程序dex2oat可以生成vdex文件。

其中，vdex是package直接转化的可执行二进制码文件，第一次开机就会生成在/system/app/<packagename>/oat/下；在***运行过程中，虚拟机将其从“/system/app”下copy到“/data/davilk-cache/”下；odex是从vdex这个文件中提取了部分模块生成的一个新的可执行二进制码文件，第一次开机就会生成在/system/app/<packagename>/oat/下，在***运行过程中，虚拟机将其从“/system/app”下copy到“/data/davilk-cache/”下。

进一步地，在本申请的实施例中，服务器根据接收到的下载请求中携带的标识信息，选择调用可执行程序dexopt，还是调用可执行程序dex2oat。

需要说明的是，在本申请的实施例中，服务器可以包括下载服务器和编译服务器，其中，下载服务器可以用于接收客户端发送的下载请求，还可以用于进行安装文件的存储，编译服务器可以用于进行第一AOT编译文件的生成。

进一步地，在本申请的实施例中，服务器在生成所述待安装应用对应的安装文件时，可以先根据所述标识信息进行查询处理，获得查询结果；然后可以进一步根据查询结果获取所述第一AOT编译文件。

可以理解的是，在本申请中，服务器进行查询处理的查询结果可以为存在第一AOT编译文件或不存在第一AOT编译文件。

示例性的，在本申请的实施例中，下载服务器在接收到携带有标识信息的下载请求之后，可以根据标识信息进行对应的第一AOT编译文件的查询处理，如果下载服务器中保存有与标识信息对应的第一AOT编译文件，那么可以确定查询结果为存在第一AOT编译文件；如果下载服务器中没有保存与标识信息对应的第一AOT编译文件，那么可以确定查询结果为不存在第一AOT编译文件。

进一步地，在本申请的实施例中，服务器在基于所述查询结果获取所述第一AOT时，如果查询处理后获得的查询结果为存在所述第一AOT编译文件，那么服务器可以直接读取该第一AOT编译文件。

也就是说，在本申请中，下载服务器在确定查询结果为存在第一AOT编译文件之后，可以直接从存储空间中读取预先存储的、与标识信息对应的第一AOT编译文件。

进一步地，在本申请的实施例中，服务器在基于所述查询结果获取所述第一AOT时，如果查询处理后获得的查询结果为不存在所述第一AOT编译文件，那么服务器可以进一步基于所述标识信息进行编译处理，生成所述第一AOT编译文件。

需要说明的是，在本申请的实施例中，下载服务器在确定查询结果为不存在第一AOT编译文件之后，可以调用编译服务器进行第一AOT编译文件的生成。具体地，编译服务器可以根据标识信息选择调用可执行程序dexopt或者调用可执行程序dex2oat，从而生成与标识信息对应的第一AOT编译文件。

可以理解的是，在本申请的实施例中，编译服务器在根据标识信息生成第一AOT编译文件时，可以先解析获得与标识信息对应的Android framework，然后进行APK的编译处理，从而生成第一AOT编译文件。具体地，在本申请中，基于标识信息，编译解码器可以调用可执行程序dexopt，生成odex文件，也可以调用可执行程序dex2oat，生成vdex文件。

其中，Android架构主要分为分为四部分，从下往上以此为内核层(LINUXKERNEL)、共享库，以及android运行时库(LIBRARIES)、应用框架层(APPLICATIONFRAMEWORK)、应用程序(APPLICATION)。

Android的应用程序框架为应用程序层的开发者提供APIs，它实际上是一个应用程序的框架。由于上层的应用程序是以JAVA构建的，因此本层次提供了以下服务：丰富而又可扩展的视图(Views)，可以用来构建应用程序，它包括列表(lists)，网格(grids)，文本框(text boxes)，按钮(buttons)，甚至可嵌入的web浏览器；内容提供器(ContentProviders)使得应用程序可以访问另一个应用程序的数据(如联系人数据库)，或者共享它们自己的数据；资源管理器(Resource Manager)提供非代码资源的访问，如本地字符串，图形，和布局文件(layout files)；通知管理器(Notification Manager)使得应用程序可以在状态栏中显示自定义的提示信息；活动管理器(Activity Manager)用来管理应用程序生命周期并提供常用的导航回退功能。

需要说明的是，在本申请的实施例中，编译服务器在完成第一AOT编译文件的生成之后，可以将第一AOT编译文件传输至下载服务器进行存储。

步骤203、将安装文件发送至客户端，以使客户端根据第一AOT编译文件和APK文件完成待安装应用的安装。

在本申请的实施例中，服务器在获取所述服务器生成的所述待安装应用对应的安装文件之后，还可以将安装文件发送至客户端，从而可以使客户端根据第一AOT编译文件和APK文件完成待安装应用的安装。

可以理解的是，在本申请的实施例中，下载服务器在从存储空间中读取第一AOT编译文件之后，或者，下载服务器在获取编译服务器传输的第一AOT编译文件之后，便可以响应下载请求，将包括待下载应用对应的APK文件和第一AOT编译文件的安装文件发送至客户端。

图6为应用程序的安装方法的实现流程示意图五，如图6所示，在本申请的实施例中，服务器在生成所述待安装应用对应的安装文件之后，即步骤202之后，服务器安装应用程序的方法还可以包括以下步骤：

步骤204、生成文件校验码；其中，文件校验码包括APK文件对应的第一校验码，和第一AOT编译文件对应的第二校验码。

步骤205、将文件校验码发送至客户端。

在本申请的实施例中，服务器在完成安装文件的生成之后，还可以生成与安装文件对应的文件校验码，然后可以将文件校验码发送至客户端，以使客户端基于文件校验码进行校验处理。

可以理解的是，在本申请的实施例中，服务器在进行待安装应用的安装的安装文件的生成之后，还可以进一步进行文件校验值的计算，从而获得文件检验码。其中，文件校验码可以包括APK文件对应的第一校验码，还可以包括第一AOT编译文件对应的第二校验码。

需要说明的是，在本申请中，第一校验码用于对APK文件进行校验处理，第二校验码用于对第一AOT编译文件进行校验处理，即对odex文件或vdex文件进行校验处理。

需要说明的是，在本申请的实施例中，文件校验是指文件的MD5、SHA1、CRC32的值的检验。其中，每个文件都可以用MD5验证程序算出一个固定的MD5码来。进一步地，由于MD5存在被修改的风险，因此还可以采用消息认证码MAC的方式进行文件校验，其中，MAC是发送方和接收放约定的一个特定的数值串，当发送方发送文件时，将文件内容加上MAC一起进行HASH计算(MAC不随文件一同发送)，即使第三方截获到此文件，由于没有MAC，因此无法再计算出正确的HASH值。

需要说明的是，在本申请的实施例中，客户端可以通过应用程序接口通过API发送所述安装文件和所述文件校验码；其中，所述API支持所述第一AOT编译文件和所述文件校验码的传输。

具体地，应用程序接口API是一些预先定义的函数，或指软件***不同组成部分衔接的约定。可以用来提供应用程序与开发人员基于某软件或硬件得以访问的一组例程，而又无需访问源码，或理解内部工作机制的细节。

也就是说，在本申请的实施例中，可以在原生接口基础上，调整API，使API支持传入odex文件或vdex文件以及相关的文件校验码，从而可以使客户端与服务器通过API进行AOT编译文件和所述文件校验码的传输。

综上所述，在本申请的实施例中，通过上述步骤201至步骤205所提出的应用程序的安装方法，针对采用AOT方式安装应用存在的安装流程的慢、***资源占用大等问题，选择在服务器中进行odex文件或vdex文件的生成，而避免在客户端进行dexopt或dex2oat的处理流程，同时，服务器通过客户端同步的移动设备的标识信息，可以针对特定的***Rom进行AOT预编译工作，从而保证服务器编译的二进制文件与本地编译的二进制文件完全一致。可见，本申请提出的应用程序的安装方法，能够在原有安装流程的基础上，提升安装速度，减少资源开销，同时保证了整个安装流程的可靠性。

也就是说，在本申请中，由于服务器可以获取与终端设备对应的odex文件或vdex文件，并将odex文件或vdex文件传输至客户端，因此客户端不再需要调用可执行程序dex2oat或dexopt执行APK的预编译，进而能够大幅提升应用安装速度，与现有的应用安装方案相比，缩短了安装时间，同时大幅减少***CPU资源、IO资源开销，避免了应用安装时造成的使用卡顿、发热ANR。

本申请实施例提供了一种应用程序的安装方法，服务器接收客户端发送的待安装应用的下载请求；其中，下载请求携带移动设备的标识信息；生成待安装应用对应的安装文件；其中，安装文件包括与待安装应用对应的APK文件，以及与待安装应用和标识信息对应的第一AOT编译文件；将安装文件发送至客户端，以使客户端根据第一AOT编译文件和APK文件完成待安装应用的安装。也就是说，在本申请的实施例中，在进行应用程序的安装时，客户端不再执行odex文件或vdex文件的生成流程，而是直接获取服务器生成的odex文件或vdex文件，即客户端不再对APK进行预编译处理，而是由服务器提前完成可执行程序dex2oat或dexopt的调用，从而能够有效提升应用程序的安装效率，并减少资源开销。

基于上述实施例，本申请的再一实施例提出了一种应用程序的安装方法，应用于客户端和服务器中，图7为应用程序的安装方法的实现流程示意图六，如图7所示，客户端和服务器安装应用程序的方法可以包括以下步骤：

步骤301、客户端向服务器发送待安装应用的下载请求；其中，下载请求携带移动设备的标识信息。

在本申请的实施例中，客户端可以先向服务器发送待安装应用的下载请求，其中，该下载请求用于进行待安装应用对应的安装文件的获取。

需要说明的是，在本申请中，客户端向服务器发送的下载请求中，可以携带有移动设备的标识信息，其中，该移动设备为运行客户端的智能设备。

进一步地，在本申请的实施例中，移动设备的标识信息可以为移动设备配置的只读存储器ROM的标识。

步骤302、服务器生成待安装应用对应的安装文件，并生成安装文件对应的文件校验码；其中，安装文件包括与待安装应用对应的APK文件，以及与待安装应用和标识信息对应的第一AOT编译文件；文件校验码包括APK文件对应的第一校验码，和第一AOT编译文件对应的第二校验码。

在本申请的实施例中，服务器在接收客户端发送的待安装应用的下载请求之后，可以生成与待安装应用对应的安装文件。

需要说明的是，在本申请的实施例中，安装文件可以包括与所述待安装应用对应的APK文件，还可以包括与所述待安装应用和所述标识信息对应的第一AOT编译文件。

需要说明的是，在本申请的实施例中，第一AOT编译文件可以为服务器调用可执行程序dex2oat或dexopt执行APK的编译，生成的用于运行待安装应用的文件。

可以理解的是，在本申请中，第一AOT编译文件可以包括odex文件或vdex文件。具体地，服务器调用可执行程序dexopt可以生成odex文件，服务器调用可执行程序dex2oat可以生成vdex文件。

需要说明的是，在本申请中，第一校验码用于对APK文件进行校验处理，第二校验码用于对第一AOT编译文件进行校验处理，即对odex文件或vdex文件进行校验处理。

步骤303、客户端获取服务器生成的待安装应用对应的安装文件，以及安装文件对应的文件校验码。

在本申请的实施例中，客户端可以将待安装应用的下载请求发送至服务器，服务器在接收到客户端发送的、携带有移动设备的标识信息的下载请求之后，便可以根据标识信息生成与运行客户端的移动终端所对应的、待安装应用的安装的安装文件。

需要说明的是，在本申请的实施例中，客户端可以通过应用程序接口API获取所述安装文件和所述文件校验码；其中，所述API支持所述第一AOT编译文件和所述文件校验码的传输。

步骤304、客户端对APK文件和第一AOT编译文件进行文件校验处理，获得校验结果。

在本申请的实施例中，客户端在获取所述服务器生成的所述待安装应用对应的安装文件之后，可以进一步对APK文件和第一AOT编译文件进行文件校验处理，从而可以获得校验结果。

需要说明的是，在本申请的实施例中，校验结果可以包括通过或不通过，其中，只有在APK文件和第一AOT编译文件均校验成功的情况下，校验结果才能为通过。

步骤305、客户端判断校验结果是否为通过？是则执行步骤306，否则执行步骤308。

步骤306、客户端根据第一AOT编译文件和APK文件进行安装处理。

在本申请的实施例中，客户端在对APK文件和第一AOT编译文件进行文件校验处理，获得校验结果之后，如果校验结果为通过，则根据第一AOT编译文件和APK文件进行安装处理。

步骤307、安装是否异常？是则执行步骤308，否则执行步骤310。

步骤308、客户端通过编译处理生成第二AOT编译文件。

在本申请的实施例中，客户端在对所述APK文件和第一AOT编译文件进行文件校验处理，获得校验结果之后，如果校验结果为不通过，那么客户端需要进行编译处理，从而获得第二AOT编译文件。

进一步地，在本申请的实施例中，客户端执行文件校验处理，并确定验结果为通过之后，客户端在根据所述第一AOT编译文件和所述APK进行安装处理的过程中，如果出现安装异常的情况，那么客户端可以选择使用现有的AOT方式进行应用程序的安装，即客户端基于所述标识信息进行编译处理，生成所述第二AOT编译文件。

可以理解的是，在本申请中，第二AOT编译文件可以包括odex文件或vdex文件。具体地，客户端调用可执行程序dexopt可以生成odex文件，服务器调用可执行程序dex2oat可以生成vdex文件。

步骤309、客户端根据第二AOT编译文件和APK文件进行安装处理。

在本申请的实施例中，客户端在生成第二AOT编译文件之后，便可以根据第二AOT编译文件和APK文件进行安装处理，即可以按照现有的AOT方式完成所述待安装应用的安装。

步骤310、客户端完成待安装应用的安装。

综上所述，在本申请的实施例中，通过上述步骤301至步骤310所提出的应用程序的安装方法，针对采用AOT方式安装应用存在的安装流程的慢、***资源占用大等问题，选择在客户端去除dexopt或dex2oat的处理流程，而在服务器中进行odex文件或vdex文件的生成，同时，通过向服务器同步移动设备的标识信息，以使服务器针对特定的***Rom进行AOT预编译工作，从而保证服务器编译的二进制文件与本地编译的二进制文件完全一致。可见，本申请提出的应用程序的安装方法，能够在原有安装流程的基础上，提升安装速度，减少资源开销，同时保证了整个安装流程的可靠性。

进一步地，在本申请的实施例中，服务器可以包括下载服务器和编译服务器，其中，下载服务器可以用于接收客户端发送的下载请求，还可以用于进行安装文件的存储，编译服务器可以用于进行第一AOT编译文件的生成。

图8为应用程序的安装方法的实现流程示意图七，如图8所示，客户端和服务器安装应用程序的方法可以包括以下步骤：

步骤401、客户端向下载服务器发送待安装应用的下载请求；其中，下载请求携带移动设备的标识信息。

在本申请的实施例中，客户端可以先向下载服务器发送待安装应用的下载请求，其中，该下载请求用于进行待安装应用对应的安装文件的获取。

需要说明的是，在本申请中，客户端向下载服务器发送的下载请求中，可以携带有移动设备的标识信息，其中，该移动设备为运行客户端的智能设备。

步骤402、下载服务器是否查询到标识信息对应的第一AOT编译文件？若是，则执行步骤405，否则执行步骤403。

在本申请的实施例中，第一AOT编译文件可以为服务器调用可执行程序dex2oat或dexopt执行APK的编译，生成的用于运行待安装应用的文件。

可以理解的是，在本申请中，第一AOT编译文件可以包括odex文件或vdex文件。具体地，服务器调用可执行程序dexopt可以生成odex文件，服务器调用可执行程序dex2oat可以生成vdex文件。

步骤403、编译服务器进行第一AOT编译文件的生成。

在本申请的实施例中，下载服务器在接收到携带有标识信息的下载请求之后，可以根据标识信息进行对应的第一AOT编译文件的查询处理，如果确定不存在第一AOT编译文件，那么编译服务器可以根据标识信息选择调用可执行程序dexopt或者调用可执行程序dex2oat，从而生成与标识信息对应的第一AOT编译文件。

步骤404、编译服务器向下载服务器传输第一AOT编译文件。

在本申请的实施例中，编译服务器在完成第一AOT编译文件的生成之后，可以将第一AOT编译文件传输至下载服务器进行存储。

步骤405、下载服务器生成待安装应用对应的安装文件，并生成安装文件对应的文件校验码。

在本申请的实施例中，安装文件可以包括与所述待安装应用对应的APK文件，还可以包括与所述待安装应用和所述标识信息对应的第一AOT编译文件。

需要说明的是，在本申请中，第一校验码用于对APK文件进行校验处理，第二校验码用于对第一AOT编译文件进行校验处理，即对odex文件或vdex文件进行校验处理。

步骤406、客户端获取待安装应用对应的安装文件，以及安装文件对应的文件校验码。

在本申请的实施例中，客户端可以将待安装应用的下载请求发送至下载服务器之后，可以接收下载服务器返回的、响应下载请求的安装文件。

需要说明的是，在本申请的实施例中，客户端可以通过应用程序接口API获取所述安装文件和所述文件校验码；其中，所述API支持所述第一AOT编译文件和所述文件校验码的传输。

步骤407、客户端对APK文件进行文件校验处理。

步骤408、APK文件校验是否通过？若是，则执行步骤410，否则执行步骤409。

在本申请的实施例中，客户端可以确定所述APK文件的第一校验和；如果第一校验和等于第一校验码，则认为校验通过，否则校验不通过。

步骤409、客户端重新获取安装文件，再次执行步骤407。

步骤410、客户端对第一AOT编译文件进行文件校验处理。

步骤411、第一AOT编译文件校验是否通过？若是，则执行步骤412，否则执行步骤414。

在本申请的实施例中，客户端可以确定第一AOT编译文件对应的第二校验和；如果第二校验和等于第二校验码，则认为校验通过，否则校验不通过。

步骤412、客户端根据第一AOT编译文件和APK文件进行安装处理。

在本申请的实施例中，客户端在对所述APK文件和第一AOT编译文件进行文件校验处理，获得校验结果之后，如果校验结果为通过，则根据第一AOT编译文件和APK文件进行安装处理。

步骤413、安装是否异常？是则执行步骤414，否则执行步骤416。

步骤414、客户端通过编译处理生成第二AOT编译文件。

在本申请的实施例中，如果第一AOT编译文件的校验结果为不通过，那么客户端需要进行编译处理，从而获得第二AOT编译文件。

进一步地，在本申请的实施例中，客户端在根据所述第一AOT编译文件和所述APK进行安装处理的过程中，如果出现安装异常的情况，那么客户端可以选择使用现有的AOT方式进行应用程序的安装，即客户端基于所述标识信息进行编译处理，生成所述第二AOT编译文件。

可以理解的是，在本申请中，第二AOT编译文件可以包括odex文件或vdex文件。具体地，客户端调用可执行程序dexopt可以生成odex文件，服务器调用可执行程序dex2oat可以生成vdex文件。

步骤415、客户端根据第二AOT编译文件和APK文件进行安装处理。

在本申请的实施例中，客户端在生成第二AOT编译文件之后，便可以根据第二AOT编译文件和APK文件进行安装处理，即可以按照现有的AOT方式完成所述待安装应用的安装。

步骤416、客户端完成待安装应用的安装。

由此可见，通过上述步骤401至步骤416所提出的应用程序的安装方法可知，客户端发起下载请求，请求下载服务器并指明当前设备的Rom版本的标识信息，下载服务器查询是否有标识信息对应的AOT编译文件(odex/vdex)，如果没有AOT编译文件，则调用编译服务器，编译服务器下载与标识信息对应的Android framework，并启动dex2oat任务，生成AOT编译文件(odex/vdex)，然后将生成的odex/vdex回传至下载服务器进行保存，并计算文件校验值；接着，客户端在下载APK文件、AOT编译文件之后可以进行文件校验处理，如果APK校验失败则启动重新下载流程；如果AOT编译文件校验失败，则客户端直接使用现有的原生安装方式进行安装处理，即使用AOT方式进行编译处理，生成AOT编译文件；如果AOT编译文件校验成功，客户端在使用服务器生成的AOT进行安装处理，如果在安装流程中出现安装异常，客户端可以选择使用现有的原生安装方式进行安装处理。

可以理解的是，本申请提出的应用程序的安装方法，在服务器端完成安装最耗时的dex2oat操作，在应用分发环节将对应设备应用程序二进制接口(Application BinaryInterface，ABI)的odex/vdex文件随APK下发，最后通过改造后的***接口完成应用安装。由于已经提前做完了dex2oat，在安装环节可以省略掉这一步，能够极大地减少***资源开销以及提升应用安装速度。其中，在原生接口基础上，调整API支持传入odex/vdex及相关的文件校验码；如果传入了vdex/odex，并且文件校验通过，则跳过Dex2oat流程。

也就是说，在本申请中，由于客户端不再调用可执行程序dex2oat或dexopt执行APK的预编译，而是直接从服务器获取与终端设备对应的odex文件或vdex文件，进而能够大幅提升应用安装速度，与现有的应用安装方案相比，缩短了安装时间，同时大幅减少***CPU资源、IO资源开销，避免了应用安装时造成的使用卡顿、发热ANR。

本申请实施例提供了一种应用程序的安装方法，客户端向服务器发送待安装应用的下载请求；其中，下载请求携带移动设备的标识信息；获取服务器生成的待安装应用对应的安装文件；其中，安装文件包括与待安装应用对应的APK文件，以及与待安装应用和标识信息对应的第一AOT编译文件；对APK文件和第一AOT编译文件进行文件校验处理，获得校验结果；若校验结果为通过，则根据第一AOT编译文件和APK文件完成待安装应用的安装。服务器接收客户端发送的待安装应用的下载请求；其中，下载请求携带移动设备的标识信息；生成待安装应用对应的安装文件；其中，安装文件包括与待安装应用对应的APK文件，以及与待安装应用和标识信息对应的第一AOT编译文件；将安装文件发送至客户端，以使客户端根据第一AOT编译文件和APK文件完成待安装应用的安装。也就是说，在本申请的实施例中，在进行应用程序的安装时，客户端不再执行odex文件或vdex文件的生成流程，而是直接获取服务器生成的odex文件或vdex文件，即客户端不再对APK进行预编译处理，而是由服务器提前完成可执行程序dex2oat或dexopt的调用，从而能够有效提升应用程序的安装效率，并减少资源开销。

基于上述实施例，在本申请的另一实施例中，图9为客户端的组成结构示意图，如图9示，本申请实施例提出的客户端10可以包括第一发送单元11、获取单元12、校验单元13以及安装单元14，

所述第一发送单元11，用于向服务器发送待安装应用的下载请求；其中，所述下载请求携带移动设备的标识信息；

所述获取单元12，用于获取所述服务器生成的所述待安装应用对应的安装文件；其中，所述安装文件包括与所述待安装应用对应的APK文件，以及与所述待安装应用和所述标识信息对应的第一AOT编译文件；

所述校验单元13，用于对所述APK文件和所述第一AOT编译文件进行文件校验处理，获得校验结果；

所述安装单元14，用于若所述校验结果为通过，则根据所述第一AOT编译文件和所述APK文件完成所述待安装应用的安装。

进一步地，本申请的实施例提出一种终端，该终端运行如上述实施例所述的客户端，图10为终端的组成结构示意图，如图10示，本申请实施例提出的终端20可以包括第一处理器201、存储有第一处理器201可执行指令的第一存储器202，进一步地，终端20还可以包括第一通信接口203，和用于连接第一处理器201、第一存储器202以及第一通信接口203的第一总线204。

在本申请的实施例中，上述第一处理器201可以为特定用途集成电路(Application Specific Integrated Circuit，ASIC)、数字信号处理器(Digital SignalProcessor，DSP)、数字信号处理装置(Digital Signal Processing Device，DSPD)、可编程逻辑装置(ProgRAMmable Logic Device，PLD)、现场可编程门阵列(Field ProgRAMmableGate Array，FPGA)、中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器中的至少一种。可以理解地，对于不同的设备，用于实现上述处理器功能的电子器件还可以为其它，本申请实施例不作具体限定。终端20还可以包括第一存储器202，该第一存储器202可以与第一处理器201连接，其中，第一存储器202用于存储可执行程序代码，该程序代码包括计算机操作指令，第一存储器202可能包含高速RAM存储器，也可能还包括非易失性存储器，例如，至少两个磁盘存储器。

在本申请的实施例中，第一总线204用于连接第一通信接口203、第一处理器201以及第一存储器202以及这些器件之间的相互通信。

在本申请的实施例中，第一存储器202，用于存储指令和数据。

进一步地，在本申请的实施例中，上述第一处理器201，用于向服务器发送待安装应用的下载请求；其中，所述下载请求携带移动设备的标识信息；获取所述服务器生成的所述待安装应用对应的安装文件；其中，所述安装文件包括与所述待安装应用对应的APK文件，以及与所述待安装应用和所述标识信息对应的第一AOT编译文件；对所述APK文件和所述第一AOT编译文件进行文件校验处理，获得校验结果；若所述校验结果为通过，则根据所述第一AOT编译文件和所述APK文件完成所述待安装应用的安装。

进一步地，本申请的实施例提出一种服务器，图11为服务器的组成结构示意图一，如图11示，本申请实施例提出的服务器30可以包括接收单元31、生成单元32以及第二发送单元33，

所述接收单元31，用于接收客户端发送的待安装应用的下载请求；其中，所述下载请求携带移动设备的标识信息；

所述生成单元32，用于生成所述待安装应用对应的安装文件；其中，所述安装文件包括与所述待安装应用对应的APK文件，以及与所述待安装应用和所述标识信息对应的第一AOT编译文件；

所述第二发送单元33，用于将所述安装文件发送至所述客户端，以使客户端根据所述第一AOT编译文件和所述APK文件完成所述待安装应用的安装。

在本申请的实施例中，进一步地，图12为服务器的组成结构示意图二，如图12示，本申请实施例提出的服务器30还可以包括第二处理器304、存储有第二处理器304可执行指令的第二存储器305，进一步地，服务器30还可以包括第二通信接口306，和用于连接第二处理器304、第二存储器305以及第二通信接口306的第二总线307。

在本申请的实施例中，上述第二处理器304可以为特定用途集成电路(Application Specific Integrated Circuit，ASIC)、数字信号处理器(Digital SignalProcessor，DSP)、数字信号处理装置(Digital Signal Processing Device，DSPD)、可编程逻辑装置(ProgRAMmable Logic Device，PLD)、现场可编程门阵列(Field ProgRAMmableGate Array，FPGA)、中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器中的至少一种。可以理解地，对于不同的设备，用于实现上述处理器功能的电子器件还可以为其它，本申请实施例不作具体限定。服务器30还可以包括第二存储器305，该第二存储器305可以与第二处理器304连接，其中，第二存储器305用于存储可执行程序代码，该程序代码包括计算机操作指令，第二存储器305可能包含高速RAM存储器，也可能还包括非易失性存储器，例如，至少两个磁盘存储器。

在本申请的实施例中，第二总线307用于连接第二通信接口306、第二处理器304以及第二存储器305以及这些器件之间的相互通信。

在本申请的实施例中，第二存储器305，用于存储指令和数据。

进一步地，在本申请的实施例中，上述第二处理器304，用于接收客户端发送的待安装应用的下载请求；其中，所述下载请求携带移动设备的标识信息；生成所述待安装应用对应的安装文件；其中，所述安装文件包括与所述待安装应用对应的APK文件，以及与所述待安装应用和所述标识信息对应的第一AOT编译文件；将所述安装文件发送至所述客户端，以使客户端根据所述第一AOT编译文件和所述APK文件完成所述待安装应用的安装。

另外，在本实施例中的各功能模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

集成的单元如果以软件功能模块的形式实现并非作为独立的产品进行销售或使用时，可以存储在一个计算机可读取存储介质中，基于这样的理解，本实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或processor(处理器)执行本实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

本申请实施例提供了一种客户端、服务器以及运行客户端的终端，客户端向服务器发送待安装应用的下载请求；其中，下载请求携带移动设备的标识信息；获取服务器生成的待安装应用对应的安装文件；其中，安装文件包括与待安装应用对应的APK文件，以及与待安装应用和标识信息对应的第一AOT编译文件；对APK文件和第一AOT编译文件进行文件校验处理，获得校验结果；若校验结果为通过，则根据第一AOT编译文件和APK文件完成待安装应用的安装。服务器接收客户端发送的待安装应用的下载请求；其中，下载请求携带移动设备的标识信息；生成待安装应用对应的安装文件；其中，安装文件包括与待安装应用对应的APK文件，以及与待安装应用和标识信息对应的第一AOT编译文件；将安装文件发送至客户端，以使客户端根据第一AOT编译文件和APK文件完成待安装应用的安装。也就是说，在本申请的实施例中，在进行应用程序的安装时，客户端不再执行odex文件或vdex文件的生成流程，而是直接获取服务器生成的odex文件或vdex文件，即客户端不再对APK进行预编译处理，而是由服务器提前完成可执行程序dex2oat或dexopt的调用，从而能够有效提升应用程序的安装效率，并减少资源开销。

本申请实施例提供一种计算机可读存储介质，其上存储有程序，该程序被处理器执行时实现如上所述的应用程序的安装方法。

具体来讲，本实施例中的一种应用程序的安装方法对应的程序指令可以被存储在光盘，硬盘，U盘等存储介质上，当存储介质中的与一种应用程序的安装方法对应的程序指令被一电子设备读取或被执行时，包括如下步骤：

向服务器发送待安装应用的下载请求；其中，所述下载请求携带移动设备的标识信息；

获取所述服务器生成的所述待安装应用对应的安装文件；其中，所述安装文件包括与所述待安装应用对应的APK文件，以及与所述待安装应用和所述标识信息对应的第一AOT编译文件；

对所述APK文件和所述第一AOT编译文件进行文件校验处理，获得校验结果；

若所述校验结果为通过，则根据所述第一AOT编译文件和所述APK文件完成所述待安装应用的安装。

具体来讲，本实施例中的一种应用程序的安装方法对应的程序指令可以被存储在光盘，硬盘，U盘等存储介质上，当存储介质中的与一种应用程序的安装方法对应的程序指令被一电子设备读取或被执行时，包括如下步骤：

接收客户端发送的待安装应用的下载请求；其中，所述下载请求携带移动设备的标识信息；

生成所述待安装应用对应的安装文件；其中，所述安装文件包括与所述待安装应用对应的APK文件，以及与所述待安装应用和所述标识信息对应的第一AOT编译文件；

将所述安装文件发送至所述客户端，以使客户端根据所述第一AOT编译文件和所述APK文件完成所述待安装应用的安装。

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

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

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

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

以上所述，仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围。

Claims (14)

1.一种应用程序的安装方法，其特征在于，所述方法应用于客户端，所述方法包括：

向服务器发送待安装应用的下载请求；其中，所述下载请求携带移动设备的标识信息；

获取所述服务器生成的所述待安装应用对应的安装文件；其中，所述安装文件包括与所述待安装应用对应的应用程序包APK文件，以及与所述待安装应用和所述标识信息对应的第一AOT编译文件；

对所述APK文件和所述第一AOT编译文件进行文件校验处理，获得校验结果；

若所述校验结果为通过，则根据所述第一AOT编译文件和所述APK文件完成所述待安装应用的安装。

2.根据权利要求1所述的方法，其特征在于，所述第一AOT编译文件包括odex文件或vdex文件。

3.根据权利要求2所述的方法，其特征在于，所述对所述APK文件和所述第一AOT编译文件进行文件校验处理，获得校验结果之前，所述方法还包括：

获取所述服务器生成的文件校验码；其中，所述文件校验码包括所述APK文件对应的第一校验码，和所述第一AOT编译文件对应的第二校验码。

4.根据权利要求3所述的方法，其特征在于，所述对所述APK文件和所述第一AOT编译文件进行文件校验处理，获得校验结果，包括：

确定所述APK文件的第一校验和；

若所述第一校验和等于所述第一校验码，则确定所述第一AOT编译文件对应的第二校验和；

若所述第二校验和等于所述第二校验码，则确定所述校验结果为通过；

若所述第二校验和不等于所述第二校验码，则确定所述校验结果为不通过。

5.根据权利要求4所述的方法，其特征在于，确定所述APK文件的第一校验和之后，所述方法还包括：

若所述第一校验和不等于所述第一校验码，则重新获取所述服务器生成的所述安装文件。

6.根据权利要求4所述的方法，其特征在于，所述对所述APK文件和所述第一AOT编译文件进行文件校验处理，获得校验结果之后，所述方法还包括：

若所述校验结果为不通过，则通过编译处理生成第二AOT编译文件；

根据所述第二AOT编译文件和所述APK文件完成所述待安装应用的安装。

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

在根据所述第一AOT编译文件和所述APK进行安装处理时，若出现安装异常，则基于所述标识信息进行编译处理，生成所述第二AOT编译文件；

根据所述第二AOT编译文件和所述APK文件完成所述待安装应用的安装。

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

通过应用程序编程接口API获取所述安装文件和所述文件校验码；其中，所述API支持所述第一AOT编译文件和所述文件校验码的传输。

9.一种应用程序的安装方法，其特征在于，所述方法应用于服务器，所述方法包括：

接收客户端发送的待安装应用的下载请求；其中，所述下载请求携带移动设备的标识信息；

生成所述待安装应用对应的安装文件；其中，所述安装文件包括与所述待安装应用对应的APK文件，以及与所述待安装应用和所述标识信息对应的第一AOT编译文件；

将所述安装文件发送至所述客户端，以使客户端根据所述第一AOT编译文件和所述APK文件完成所述待安装应用的安装。

10.一种客户端，其特征在于，所述客户端包括：第一发送单元、获取单元、校验单元以及安装单元，

所述第一发送单元，用于向服务器发送待安装应用的下载请求；其中，所述下载请求携带移动设备的标识信息；

所述获取单元，用于获取所述服务器生成的所述待安装应用对应的安装文件；其中，所述安装文件包括与所述待安装应用对应的APK文件，以及与所述待安装应用和所述标识信息对应的第一AOT编译文件；

所述校验单元，用于对所述APK文件和所述第一AOT编译文件进行文件校验处理，获得校验结果；

所述安装单元，用于若所述校验结果为通过，则根据所述第一AOT编译文件和所述APK文件完成所述待安装应用的安装。

11.一种终端，其特征在于，所述终端运行如权利要求10所述的客户端，所述终端包括第一处理器、存储有所述第一处理器可执行指令的第一存储器，当所述指令被所述第一处理器执行时，实现如权利要求1-8任一项所述的方法。

12.一种服务器，其特征在于，所述服务器包括：接收单元、生成单元以及第二发送单元，

所述接收单元，用于接收客户端发送的待安装应用的下载请求；其中，所述下载请求携带移动设备的标识信息；

所述生成单元，用于生成所述待安装应用对应的安装文件；其中，所述安装文件包括与所述待安装应用对应的APK文件，以及与所述待安装应用和所述标识信息对应的第一AOT编译文件；

所述第二发送单元，用于将所述安装文件发送至所述客户端，以使客户端根据所述第一AOT编译文件和所述APK文件完成所述待安装应用的安装。

13.一种服务器，其特征在于，所述服务器包括第二处理器、存储有所述第二处理器可执行指令的第二存储器，当所述指令被所述第二处理器执行时，实现如权利要求9所述的方法。

14.一种计算机可读存储介质，其上存储有程序，应用于客户端和服务器中，其特征在于，所述程序被第一处理器执行时，实现如权利要求1-8任一项所述的方法；所述程序被第二处理器执行时，实现如权利要求9所述的方法。

Images