具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
需要说明的是,DVM对Dex文件执行DexOpt操作的过程中,如果Dex 文件中的类引用了重复定义的类(其中,重复定义的类是指:存在于不同Dex 文件中但定义相同的类),则针对该类的校验失败,在此情况下,DVM并不会为该类赋予Verified标识(在实际应用中,未被赋予Verified标识的类,仍能够正常运行),而对于不具有Verified标识的类而言,也就不会触发Verify error。
另需要说明的是,在以下描述中,可认为“类”和“class”代表相同的含义。“定义”操作,是指现有的编程过程中对类的一种操作。这里并不应构成对本申请的限定。
基于此,本申请实施例提供一种文件处理过程如图2所示,该过程具体包括以下步骤:
S201:针对应用程序的待编译文件,确定所述应用程序所包含的类。
所述的待编译文件,可包括:应用程序源文件(即,Java文件)、class文件等。在本申请实施例中,无论是Java文件还是class文件,都需编译生成Dex 文件,故上述的文件均可认为是待编译文件。在实际应用中,应用程序的待编译文件可以是多个文件也可能是一个文件,具体将根据应用程序的规模所决定,也即,大型应用程序通常会包含多个待编译文件,而小型应用程序可能仅包含一个待编译文件。这里并不构成对本申请的限定。
应用程序所包含的类,可认为是该应用程序自身所具备的Java class。通常,一个应用程序中包含多个类,当然,在一些特殊情况,也可以为一个。这里不作具体限定。
S202:在编译所述待编译文件时,向所述待编译文件中添加虚拟机中包含的类。
所述的虚拟机,可认为是Android系统中的DVM。DVM中包含的类,可认为是该DVM加载了相应的Dex文件后所产生的。这里所述的相应的Dex文件,既可以是DVM自身运行所需的Dex文件,也可以是来自于DVM所加载的其他应用程序的Dex文件,在此暂不作具体限定。那么,基于前述内容可知,如果在待编译文件中添加在DVM中包含的类,则添加的类便成为了重复定义的类。
S203:建立运行所述应用程序所需的类与添加的类之间的引用关系,生成可执行文件。
考虑到DVM在执行DexOpt操作时,某Dex文件中的类引用了重复定义的类,则会出现校验失败的情况,也就不会被赋予Verified标识。所以,在本申请实施例中,针对应用程序所包含的类而言,建立其与添加的类(即,重复定义的类)之间的应用关系。
基于此,可生成编译后的可执行文件。其中,所述的可执行文件可包括: Dex文件。
在生成了可执行文件后,便可以使用虚拟机加载该可执行文件,实现程序的运行。
这里需要说明的是,本申请实施例中的上述方法,对可执行文件的编译过程,可以由相应的编译器实现。
那么,作为本申请实施例中的一种方式,编译器运行在诸如服务器或其他设备上,由此,可执行文件可通过网络传输、设备间有线传输等途径,发送到 Android设备上,使得该Android设备上的DVM运行该可执行文件。
作为本申请实施例中的另一种方式,编译器直接运行在Android设备上,那么,当可执行文件生成后,该Android设备可以直接加载该可执行文件。
通过上述步骤,针对某一应用程序的待编译文件,将确定出该待编译文件中包含的运行该应用程序所需的类。在针对该待编译文件进行编译时,除了将运行该应用程序所需的类进行编译之外,还会在待编译文件中添加已在虚拟机上定义的类。此时,对于已在虚拟机上定义的类而言,便成为了重复定义的类。然后再针对运行该应用程序所需的类,建立与重复定义的类之间的引用关系,这样一来,也就满足DexOpt下校验失败的条件,即,某一类引用了重复定义的类。
基于此,将编译生成的可执行文件通过虚拟机(即,DVM)加载,那么,在DexOpt阶段,该可执行文件中的各类均会校验失败,进而,便不会被虚拟机赋予校验标识。针对不具有校验标识的类而言,也就不会触发校验错误。
需要说明的是,实际应用时,DVM会加载自身的Dex文件,用于保证该 DVM的正常运行。如前所述,DVM加载Dex文件,是对Dex文件中的class 进行定义,换言之,DVM加载自身的Dex文件,也就可认为是对自身的class 进行定义。那么,在本申请实施例中,在Dex文件中添加的类,便可以是DVM 自身已定义的类。也即,向所述待编译文件中添加虚拟机中包含的类,包括:确定已在所述Dalvik虚拟机中已定义的、属于该Dalvik虚拟机自身的类,从确定出的类中选择任一类,添加至所述待编译文件中。
当然,向待编译文件中添加已在DVM中定义的类的过程,实质上就是在待编译文件中,重复定义该类的过程(该过程通常在编译阶段实现,这里不做过多赘述)。
此外,在前述内容中,建立所述应用程序所包含的类与添加的类之间的引用关系的过程,具体可以为:将所述应用程序所包含的类引用于所述添加的类。
以上是针对编译阶段的描述说明,而对于虚拟机的加载阶段,其过程可如图3所示,具体包括以下步骤:
S301:虚拟机获取对应于应用程序的可执行文件。
其中,所述可执行文件中包含已在所述虚拟机中定义的类,且该类与所述可执行文件中包含的运行该应用程序所需的类之间具有引用关系。
S302:加载所述待运行文件,以使得所述虚拟机对所述可执行文件中包含的类进行校验时不生成校验标识。
如前所述,这里所提及的虚拟机为DVM,而可执行文件为Dex文件。DVM 加载Dex文件后,如果其中的class引用了重复定义的class,则在DexOpt阶段将不通过校验,因而,DVM便不会针对这些class生成Verified标识。
为了清楚地阐述本申请的上述文件处理方法,下面以一实际应用场景下的示例进行说明:
在本示例中,所基于的架构如图4a所示,图4a中的架构包含终端与服务器。其中,终端上运行Android系统,该终端包括但不限于:智能手机、平板电脑、智能手表等设备。服务器为运行在终端Android系统上的应用A所对应的应用服务器,用于为应用A提供互联网服务(其中也包括向该应用A下发 Dex补丁文件)。
进一步假设,针对以Java语言开发的应用A而言,该应用A自身具备两种类:classA和class B。同时假设,在终端上的DVM中,已定义了class X (需要说明的是,该class X属于该DVM自身的类)。
那么,对该应用A的Java文件进行编译时,将该Java文件编译为class 文件。此时,除了归属于该应用A自身的class A和class B以外,还会在该class 文件中定义class X。此后,DVM将class文件转换为Dex文件。那么,如图 4b所示,在该Dex文件中,包含有三种class:class A、class B以及class X。
在生成了Dex文件后,DVM将加载该Dex文件,但显然,由于DVM中已存在Class X,而生成的Dex文件中也定义了相同的Class X,那么,DVM 会将该class X确定为重复定义的类,又由于class A和class B分别引用了该 class X,即,满足校验失败条件:引用了重复定义的类。所以,DVM在对该 Dex文件执行DexOpt操作时,该Dex文件中的class A和class B均校验失败。这样一来,class A和class B将不会被DVM赋予Verified标识。但该应用A仍能够正常运行。
基于此,在后续的运行过程中,如果该应用A的class A出错,那么,在图4a所示的架构下,服务器可以向运行在该终端Android系统上的应用A发送修复补丁(即,patch Dex文件)。其中,该Patch Dex文件中包含修复后的 class A’。那么,当终端接收到该PatchDex文件后,会将该Patch Dex文件插入至该应用A所对应的Dex文件序列的最前端,从而该应用A重新运行后,DVM将优先加载该Patch Dex文件,也即,优先加载其中的class A’。这样一来,由于归属于应用A的所有class均不具备Verified标识,所以,无论classA’是否与应用A的其他class之间具有引用关系,均不会出现verify error的现象。进而,DVM在加载了该class A’后,可以成功地代替出错的class A。
以上为本申请实施例提供的文件处理方法,基于同样的思路,本申请实施例还提供一种文件处理装置,如图5所示。以用于安卓Android系统中运行的虚拟机,该装置包括:
确定模块501,针对应用程序的待编译文件,确定所述应用程序包含的类;
编译模块502,在编译所述待编译文件时,向所述待编译文件中添加虚拟机中包含的类;
生成模块503,所述应用程序包含的类与添加的类之间的引用关系,生成可执行文件。
其中,所述虚拟机包括:运行于Android系统下的Dalvik虚拟机;所述可执行文件包括:Dex文件。
所述编译模块502,确定已在所述Dalvik虚拟机中已定义的、属于该Dalvik 虚拟机自身的类,从确定出的类中选择任一类,添加至所述待编译文件中。
所述编译模块502,在所述待编译文件中,针对所选择的任一类进行定义。
所述编译模块502,将所述应用程序所包含的类引用于所述添加的类。
本申请实施例还提供一种文件处理装置,如图6所示。以用于安卓Android 系统中运行的虚拟机,该装置包括:
获取模块601,获取对应于应用程序的可执行文件;其中,所述可执行文件中包含已在所述虚拟机中定义的类,且该类与所述可执行文件中包含的该应用程序的类之间具有引用关系;
加载模块602,加载所述待运行文件,以使得所述虚拟机对所述可执行文件中包含的类进行校验时不生成校验标识。
其中,所述虚拟机包括:Dalvik虚拟机;所述可执行文件包括:Dex文件。
在20世纪90年代,对于一个技术的改进可以很明显地区分是硬件上的改进(例如,对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而,随着技术的发展,当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此,不能说一个方法流程的改进就不能用硬件实体模块来实现。例如,可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray, FPGA))就是这样一种集成电路,其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上,而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且,如今,取代手工地制作集成电路芯片,这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现,它与程序开发撰写时所用的软件编译器相类似,而要编译之前的原始代码也得用特定的编程语言来撰写,此称之为硬件描述语言(Hardware Description Language,HDL),而HDL也并非仅有一种,而是有许多种,如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、 Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL (Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL (RubyHardware Description Language)等,目前最普遍使用的是VHDL (Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚,只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中,就可以很容易得到实现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现,例如,控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit,ASIC)、可编程逻辑控制器和嵌入微控制器的形式,控制器的例子包括但不限于以下微控制器:ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320,存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道,除了以纯计算机可读程序代码方式实现控制器以外,完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件,而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至,可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的,计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
为了描述的方便,描述以上装置时以功能分为各种单元分别描述。当然,在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、 CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和 /或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/ 或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器 (RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定事务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行事务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。