发明内容
有鉴于此,本公开至少提供一种文件构建方法及装置。
第一方面,本公开提供了一种文件构建方法,包括:
获取实现目标功能的多个依赖文件;其中,每个所述依赖文件中包括至少一个类;
从所述多个依赖文件中,筛选包括相同名称的类的N个目标依赖文件;其中,N为大于或等于2的正整数;
将所述具有相同名称的所述类的名称修改为互不相同的名称;
针对包括修改后的名称的类的每个所述目标依赖文件,分别基于修改名称后的类,生成新的依赖文件。
在一种可能的实施方式中,所述将所述具有相同名称的所述类的名称修改为互不相同的名称,包括:
确定所述N个目标依赖文件中具有的相同名称的类的数量;
若所述数量等于1,则从所述N个目标依赖文件中选取N-1个待处理依赖文件,并修改每个所述待处理依赖文件中的所述相同名称的类的名称,以使所述N个目标依赖文件中所述具有相同名称的类的名称互不相同;
若所述数量大于1,则针对每个所述相同名称的类,将该类所在的各个目标依赖文件中的该类的名称修改为互不相同的名称。
在一种可能的实施方式中,所述将所述具有相同名称的所述类的名称修改为互不相同的名称,包括:
基于预定保持规则,对所述待处理依赖文件进行混淆处理,以使所述N个目标依赖文件中的所述具有相同名称的类的名称互不相同。
在一种可能的实施方式中,所述预定保持规则为:
保持所述待处理依赖文件中,除具有相同名称的类以外的所有类不发生更改;
保持所述待处理依赖文件中,具有相同名称的类的方法和字段不发生更改。
在一种可能的实施方式中,所述针对包括修改后的名称的类的每个所述目标依赖文件,分别基于修改名称后的类,生成新的依赖文件,包括:
针对包括修改后的名称的类的每个所述目标依赖文件,获取该目标依赖文件的配置文件;
基于该目标依赖文件中的修改名称后的类,生成基础依赖文件;
基于该目标依赖文件的配置文件和基础依赖文件,生成该目标依赖文件对应的新的依赖文件。
在一种可能的实施方式中,所述基于该目标依赖文件中的修改名称后的类,生成基础依赖文件,包括:
判断该目标依赖文件中是否包括预设文件;
若该目标依赖文件中包括预设文件,则基于该目标依赖文件中的修改名称后的类生成新的类文件;包括所述预设文件的所述目标依赖文件包括原类文件;
利用所述新的类文件替换该目标依赖文件中的所述原类文件,得到所述基础依赖文件。
在一种可能的实施方式中,上述文件构建方法还包括:
将生成的新的依赖文件存入三方库中,并将该新的依赖文件对应的原来的依赖文件删除。
在一种可能的实施方式中,上述文件构建方法还包括:
将每个所述依赖文件中的类进行合并处理;
基于合并后的类生成预设的可执行代码格式的文件。
第二方面,本公开还公开了一种文件构建装置,包括:
文件获取模块,用于获取实现目标功能的多个依赖文件;其中,每个所述依赖文件中包括至少一个类;
文件筛选模块,用于从所述多个依赖文件中,筛选包括相同名称的类的N个目标依赖文件;其中,N为大于或等于2的正整数;
名称修改模块,用于将所述具有相同名称的所述类的名称修改为互不相同的名称;
文件生成模块,用于针对包括修改后的名称的类的每个所述目标依赖文件,分别基于修改名称后的类,生成新的依赖文件。
在一种可能的实施方式中,所述名称修改模块在将所述具有相同名称的所述类的名称修改为互不相同的名称时,用于:
确定所述N个目标依赖文件中具有的相同名称的类的数量;
若所述数量等于1,则从所述N个目标依赖文件中选取N-1个待处理依赖文件,并修改每个所述待处理依赖文件中的所述相同名称的类的名称,以使所述N个目标依赖文件中所述具有相同名称的类的名称互不相同;
若所述数量大于1,则针对每个所述相同名称的类,将该类所在的各个目标依赖文件中的该类的名称修改为互不相同的名称。
第三方面,本公开提供了一种电子设备,包括:处理器、存储器和总线,所述存储器存储有所述处理器可执行的机器可读指令,当电子设备运行时,所述处理器与所述存储器之间通过总线通信,所述机器可读指令被所述处理器执行时执行如上述文件构建方法的步骤。
第四方面,本公开还提供一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行如上述文件构建方法的步骤。
本公开上述装置、电子设备、和计算机可读存储介质,至少包含与本公开上述方法的任一方面或任一方面的任一实施方式的技术特征实质相同或相似的技术特征。
本公开提供了一种文件构建方法及装置,其中,本公开首先获取实现目标功能的多个依赖文件;之后,从所述多个依赖文件中,筛选包括相同名称的类的N个目标依赖文件;将所述具有相同名称的所述类的名称修改为互不相同的名称;最后,针对包括修改后的名称的类的每个目标依赖文件,分别基于修改名称后的类,生成新的依赖文件。本公开并未直接删除三方文件或依赖文件中相同名称的类,而是将相同名称的类进行名称修改,得到的各个依赖文件中不包括相同名称的类,从而能够正常形成可执行代码格式的文件,并且能够保证目标功能的正常实现。
具体实施方式
为使本公开实施例的目的、技术方案和优点更加清楚,下面将结合本公开实施例中的附图,对本公开实施例中的技术方案进行清楚、完整地描述,应当理解,本公开中附图仅起到说明和描述的目的,并不用于限定本公开的保护范围。另外,应当理解,示意性的附图并未按实物比例绘制。本公开中使用的流程图示出了根据本公开的一些实施例实现的操作。应该理解,流程图的操作可以不按顺序实现,没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外,本领域技术人员在本公开内容的指引下,可以向流程图添加一个或多个其他操作,也可以从流程图中移除一个或多个操作。
另外,所描述的实施例仅仅是本公开一部分实施例,而不是全部的实施例。通常在此处附图中描述和示出的本公开实施例的组件可以以各种不同的配置来布置和设计。因此,以下对在附图中提供的本公开的实施例的详细描述并非旨在限制要求保护的本公开的范围,而是仅仅表示本公开的选定实施例。基于本公开的实施例,本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本公开保护的范围。
需要说明的是,本公开实施例中将会用到术语“包括”,用于指出其后所声明的特征的存在,但并不排除增加其它的特征。
以开发安卓系统上的某一功能为例,如图1所示,该功能的实现可能依赖程序开发者编写的Java代码、aar依赖文件以及jar依赖文件,程序开发者编写的Java代码经过编译,生成Java class文件;aar依赖文件经过解压,取出其中的类文件classes.jar文件;jar依赖文件与上述生成Java class文件以及classes.jar文件进行类class合并,之后生成可执行代码格式的文件dex。
上述流程中,一旦出现重复的类,即具有相同名称的类,最后生成dex的步骤就会失败,为了克服该问题,本公开提供了一种文件构建方法及装置。其中,本公开首先获取实现目标功能的多个依赖文件;之后,从所述多个依赖文件中,筛选包括相同名称的类的N个目标依赖文件;将所述具有相同名称的所述类的名称修改为互不相同的名称;最后,针对包括修改后的名称的类的每个依赖文件,分别基于修改名称后的类,生成新的依赖文件。本公开并未直接删除三方文件或依赖文件中相同名称的类,而是将相同名称的类进行名称修改,得到的各个依赖文件中不包括相同名称的类,从而能够正常形成可执行代码格式的文件,并且能够保证目标功能的正常实现。
下面通过具体的实施例对本申请的文件构建方法及装置进行详细的说明。
本公开实施例提供了一种文件构建方法,该方法应用于对依赖文件的类进行处理的终端设备,具体地,如图2所示,可以包括如下步骤:
S210、获取实现目标功能的多个依赖文件;其中,每个所述依赖文件中包括至少一个类。
这里,目标功能是当前终端设备或终端设备上的一个应用需要实现的一个功能,例如支付功能、积分兑换功能、认证识别功能等。该功能的实现需要依赖多个依赖文件,因此,在实现目标功能之前,首先需要获取实现目标功能所依赖的多个依赖文件。该依赖文件具体可以是三方文件,当然也可以是程序开发者自己编写的文件,但是包括重复名称的类的文件一般是不同的三方文件,程序开发者在具体编写代码的时候会避免重复类名的出现。例如,如图1中,一般是jar依赖文件和aar依赖文件之间存在相同名称的类。
上述,不同依赖文件中相同名称的类的功能和具体的代码可能不同,因此不能简单的将相同名称的类从其中一个或多个依赖文件中删除。
S220、从所述多个依赖文件中,筛选包括相同名称的类的N个目标依赖文件;其中,N为大于或等于2的正整数。
这里,包含相同类名的类的依赖文件可能是两个,也可能多于两个,本步骤将包含相同类型的类的依赖文件筛选出来,作为目标依赖文件。例如,筛选得到两个目标依赖文件,这两目标依赖文件中相同名称的类class CLS。
S230、将所述具有相同名称的所述类的名称修改为互不相同的名称。
在筛选得到目标依赖文件之后,将N个目标依赖文件中具有相同名称的类的名称修改为互不相同的名称时,对于N个目标依赖文件中只包括一个具有相同名称的类时,可以只修改其中N-1个依赖文件中具有相同名称的类的名称,剩下一个依赖文件中的类的名称不进行修改。当然,也可以修改所有的依赖文件中具有相同名称的类的名称,本公开对此并不进行限定。
另外,N个目标依赖文件中,也可能同时存在多个具有相同名称的类,此时,对于每个具有相同名称的类,可以分别利用上面的方法修改每个具有相同名称的类的名称。
在修改具有相同的名称的类时,可以基于预定保持规则,对所述待处理依赖文件进行混淆处理,以使所述N个目标依赖文件中的所述具有相同名称的类的名称互不相同。该预定保持规则可以为:保持所述待处理依赖文件中,除具有相同名称的类以外的所有类不发生更改;保持所述待处理依赖文件中,具有相同名称的类的方法和字段不发生更改。上述对所述待处理依赖文件进行混淆处理,具体是修改或混淆所述待处理依赖文件中的所述相同名称的类的名称,不修改或混淆待处理依赖文件中的所述相同名称的类的字段和方法,目标是使所述N个目标依赖文件中的所述具有相同名称的类的名称互不相同。
具体地,可以利用proguard对目标依赖文件进行混淆处理,以修改其中相同名称的类的名称。例如,步骤S220中筛选得到的目标依赖文件有两个,分别是依赖文件A和依赖文件B,相同名称的类是class CLS,此时利用proguard对依赖文件A或者依赖文件B进一次混淆处理以修改上述class CLS的名称。假定对依赖文件A进行混淆处理,通过proguard-rule.pro控制混淆粒度,即利用proguard-rule.pro配置要进行混淆处理的类仅仅为classCLS,依赖文件中的其他类和类名均不进行修改,且只修改类class CLS的名称,不对类的方法和字段等进行修改。
在具体实施时,可以利用如下代码实现:
keep class!CLS{*;}/保持依赖文件A中除CLS以外所有的类不发生更改
keep classmembers class CLS{*;}/保持依赖文件A中CLS的方法和字段不发生更改。
S240、针对包括修改后的名称的类的每个目标依赖文件,分别基于修改名称后的类,生成新的依赖文件。
由于在修改目标依赖文件中的类的名称时,并不一定是修改了所有目标依赖文件,因此,本步骤只修改名称的目标依赖文件进行了处理,得到新的依赖文件。
在将实现目标功能所依赖的所有依赖文件中相同名称的类的名称修改完毕,并且生成新的依赖文件之后,可以将目标功能所依赖的依赖文件中的类进行合并,生成可执行代码格式的文件,例如生成dex文件。
上述实施例并未直接删除三方文件或依赖文件中相同名称的类,而是将相同名称的类进行名称修改,得到的各个依赖文件中不包括相同名称的类,从而能够正常形成可执行代码格式的文件,并且能够保证目标功能的正常实现。
根据上面的描述可知,对于N个目标依赖文件中只有一个具有相同名称的类时,在对N个目标依赖文件的类的名称进行修改的时候,可以只修改N-1个目标依赖文件中的类的名称,在具体实施时,可以例如用如下子步骤实现:
从所述N个目标依赖文件中选取N-1个待处理依赖文件;修改每个所述待处理依赖文件中的所述相同名称的类的名称,以使所述N个目标依赖文件中所述具有相同名称的类的名称互不相同。
上述筛选待处理依赖文件具体可以时随机进行筛选。
在一些实施例中,如图3所示,上述针对包括修改后的名称的类的每个目标依赖文件,分别基于修改名称后的类,生成新的依赖文件,具体可以利用如下步骤实现:
S310、针对包括修改后的名称的类的每个目标依赖文件,获取该目标依赖文件的配置文件。
这里,每个目标依赖文件均对应配置文件,例如,在安卓系统中进行功能开发时,每个jar依赖文件均会有一个pom文件作为其配置文件,aar依赖文件中的classes.jar也会有一个pom文件作为配置文件,因此在生成新的依赖文件之前,需要获取依赖文件对应的配置文件。
S320、基于该目标依赖文件中的修改名称后的类,生成基础依赖文件。
这里,如果目标依赖文件是一个jar依赖文件,那么经过proguard对这个jar依赖文件进行处理之后,直接生成的jar文件可以作为上述基础依赖文件。如果目标依赖文件时一个aar文件,那么经过proguard处理之后得到的jar文件需要替换原aar文件中的classes.jar文件,替换后的aar文件作为上述基础依赖文件。
对于目标依赖文件为aar文件的情况,具体可以利用如下子步骤生成基础依赖文件:
子步骤一、判断该目标依赖文件中是否包括预设文件。
aar依赖文件中不仅包括类class文件,还包括res资源文件,这里判断目标依赖文件是否包括预设文件,实质上判断目标依赖文件是否为aar依赖文件。具体地,上述预设文件可以是res资源文件,如果目标依赖文件中包括res资源文件,则表示目标依赖文件为aar依赖文件,否则不是aar依赖文件。
子步骤二、若该目标依赖文件中包括预设文件,则基于该目标依赖文件中的修改名称后的类生成新的类文件;包括所述预设文件的目标依赖文件包括原类文件。
在依赖文件为aar文件时,经过proguard对类的名称进行修改之后,生成的jar文件即为上述新的类文件。
子步骤三、利用所述新的类文件替换该目标依赖文件中的所述原类文件,得到所述基础依赖文件。
在依赖文件为aar依赖文件时,利用新的类文件,即jar文件替换原aar文件中的classes.jar文件,得到基础依赖文件。
S330、基于该目标依赖文件的配置文件和基础依赖文件,生成该目标依赖文件对应的新的依赖文件。
在得到基础依赖文件之后,结合配置文件pom即可生成新的依赖文件。并将生成的新的依赖文件发布到maven module或三方库中。之后,在依赖文件配置处,需要将新的依赖文件对应的原来的依赖文件删除。
在一些实施例中,在需改了目标功能对应的所有相同名称的类的名称后,具体可以利用如下步骤生成可执行代码格式的文件:
将每个所述依赖文件中的类进行合并处理;基于合并后的类生成预设的可执行代码格式的文件。例如,可以生成dex文件。
对应于上述文件构建方法,本公开实施例还提供了一种文件构建装置,该装置及其各个模块能够执行与上述文件构建方法相同的方法步骤,并且能够达到相同或相似的有益效果,因此对于重复的部分不再赘述。
具体地,如图4所示,本公开的一种文件构建装置包括:
文件获取模块410,用于获取实现目标功能的多个依赖文件;其中,每个所述依赖文件中包括至少一个类。
文件筛选模块420,用于从所述多个依赖文件中,筛选包括相同名称的类的N个目标依赖文件;其中,N为大于或等于2的正整数。
名称修改模块430,用于将所述具有相同名称的所述类的名称修改为互不相同的名称。
文件生成模块440,用于针对包括修改后的名称的类的每个目标依赖文件,分别基于修改名称后的类,生成新的依赖文件。
在一些实施例中,所述名称修改模块430在将所述具有相同名称的所述类的名称修改为互不相同的名称时,用于:
确定所述N个目标依赖文件中具有的相同名称的类的数量;
若所述数量等于1,则从所述N个目标依赖文件中选取N-1个待处理依赖文件,并修改每个所述待处理依赖文件中的所述相同名称的类的名称,以使所述N个目标依赖文件中所述具有相同名称的类的名称互不相同;
若所述数量大于1,则针对每个所述相同名称的类,将该类所在的各个目标依赖文件中的该类的名称修改为互不相同的名称。
本公开实施例公开了一种电子设备,如图5所示,包括:处理器501、存储器502和总线503,所述存储器502存储有所述处理器501可执行的机器可读指令,当电子设备运行时,所述处理器501与所述存储器502之间通过总线503通信。
所述机器可读指令被所述处理器501执行时执行以下文件构建方法的步骤:
获取实现目标功能的多个依赖文件;其中,每个所述依赖文件中包括至少一个类;
从所述多个依赖文件中,筛选包括相同名称的类的N个目标依赖文件;其中,N为大于或等于2的正整数;
将所述具有相同名称的所述类的名称修改为互不相同的名称;
针对包括修改后的名称的类的每个目标依赖文件,分别基于修改名称后的类,生成新的依赖文件。
除此之外,机器可读指令被处理器501执行时,还可以执行上述方法部分描述的任一实施方式中的方法内容,这里不再赘述。
本公开实施例还提供的一种对应于上述方法及装置的计算机程序产品,包括存储了程序代码的计算机可读存储介质,程序代码包括的指令可用于执行前面方法实施例中的方法,具体实现可参见方法实施例,在此不再赘述。
上文对各个实施例的描述倾向于强调各个实施例之间的不同之处,其相同或相似之处可以相互参考,为了简洁,本文不再赘述。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统和装置的具体工作过程,可以参考方法实施例中的对应过程,本公开中不再赘述。在本公开所提供的几个实施例中,应该理解到,所揭露的系统、装置和方法,可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的,例如,所述模块的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,又例如,多个模块或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口,装置或模块的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的模块可以是或者也可以不是物理上分开的,作为模块显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本公开各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解,本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
以上仅为本公开的具体实施方式,但本公开的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本公开揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本公开的保护范围之内。因此,本公开的保护范围应以权利要求的保护范围为准。