CN108897562A - 安装包更新方法、装置、介质以及设备 - Google Patents

Abstract

本申请公开了一种安装包更新方法，包括：获取源安装包，以及获取替换文件；反编译所述源安装包得到包内文件，从所述包内文件中搜索与所述替换文件匹配的源文件；利用所述替换文件替换所述包内文件中的源文件，得到替换后的包内文件；对所述替换后的包内文件进行签名，并打包生成新版本的安装包。开发人员在进行应用开发时，无需通过专业引擎工具重新编译生成新的安装包，而利用本申请实施例提供的方法，由开发人员指定源安装包以及替换文件即可自动实现安装包的更新，提高了研发测试效率，满足了开发人员快速验证缺陷、高效优化性能等需求。本申请还公开了一种安装包更新装置、终端设备以及存储介质。

Description

安装包更新方法、装置、介质以及设备

技术领域

本申请涉及应用开发技术领域，尤其涉及一种安装包更新方法、装置、计算机存储介质以及终端设备。

背景技术

在应用的研发测试阶段，研发人员常常会遇到需要构建出安装包才能够进行研发测试的多种工作场景，例如：验证程序漏洞的场景、实现日常需求与优化任务的场景、底层优化需求的场景，等等；在这些工作场景下，研发人员需要对程序作修改，进而利用专业引擎工具重新构建安装包，然后将安装包安装至终端设备上以进行研发测试。

但专业引擎工具，通常构建一个安装包所需时间约在几十分钟至数小时，而在一个应用的研发测试阶段可能需要多大几十至上百次的调试，利用专业引擎工具重新构建安装包，其时间成本非常大，这就极大地限制了应用的研发测试效率。

发明内容

本申请实施例提供了一种安装包更新方法、装置、计算机存储介质以及终端设备，使得能够快速实现安装包更新，大幅降低时间成本，提高了应用的研发测试效率。

有鉴于此，本申请一方面提供了一种安装包更新方法，所述方法包括：

获取源安装包，以及获取替换文件；

反编译所述源安装包得到包内文件，从所述包内文件中搜索与所述替换文件匹配的源文件；

利用所述替换文件替换所述包内文件中的源文件，得到替换后的包内文件；

对所述替换后的包内文件进行签名，并打包生成新版本的安装包。

本申请一方面提供一种安装包更新装置，所述装置包括：

获取单元，用于获取源安装包，以及获取替换文件；

搜索单元，用于反编译所述源安装包得到包内文件，从所述包内文件中搜索与所述替换文件匹配的源文件；

替换单元，用于利用所述替换文件替换所述包内文件中的源文件，得到替换后的包内文件；

打包单元，用于对所述替换后的包内文件进行签名，并打包生成新版本的安装包。

本申请一方面提供一种终端设备，所述设备包括处理器以及存储器：

所述存储器用于存储程序代码，并将所述程序代码传输给所述处理器；

所述处理器用于根据所述程序代码中的指令，执行如上述安装包更新方法的步骤。

本申请一方面提供一种计算机可读存储介质，所述计算机可读存储介质用于存储程序代码，所述程序代码用于执行上述安装包更新方法的步骤。

从以上技术方案可以看出，本申请实施例具有以下优点：

本申请实施例中提供了一种安装包更新方法，该方法包括获取源安装包以及替换文件，通过对源安装包反编译得到包内文件，从包内文件中搜索与替换文件匹配的源文件，利用替换文件替换包内文件中的源文件，得到替换后的包内文件，对替换后的包内文件签名，并打包生成新版本的安装包。开发人员在进行应用开发时，无需通过专业引擎工具重新编译生成新的安装包，而利用本申请实施例提供的方法，由开发人员指定源安装包以及替换文件即可自动实现安装包的更新。由于不需要重新构建安装包，仅仅进行文件替换、签名以及打包等操作大幅降低了时间开销，提高了研发测试效率，满足了开发人员快速验证缺陷、高效优化性能等需求。

附图说明

图1为本申请实施例中一种安装包更新方法的场景架构图；

图2为本申请实施例中一种安装包更新方法的流程图；

图3为本申请实施例中一种安装包更新方法的流程图；

图4为本申请实施例中一种生成程序集方法的流程图；

图5为本申请实施例中安装包更新界面的界面示意图；

图6为本申请实施例中一种安装包更新方法的场景示意图；

图7为本申请实施例中一种安装包更新装置的一个结构示意图；

图8为本申请实施例中一种安装包更新装置的一个结构示意图；

图9为本申请实施例中一种安装包更新装置的一个结构示意图；

图10为本申请实施例中一种安装包更新装置的一个结构示意图；

图11为本申请实施例中一种终端设备的一个结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

针对现有技术中利用专业引擎工具重新构建安装包导致的时间成本非常大，研发测试效率低这一技术问题，本申请提供了一种安装包更新方法，包括获取源安装包以及替换文件，通过对源安装包反编译得到包内文件，从包内文件中搜索与替换文件匹配的源文件，利用替换文件替换包内文件中的源文件，得到替换后的包内文件，对替换后的包内文件签名，并打包生成新版本的安装包。

可以理解，开发人员在进行应用开发时，无需通过专业引擎工具重新编译生成新的安装包，而利用本申请实施例提供的方法，由开发人员指定源安装包以及替换文件即可自动实现安装包的更新。由于不需要重新构建安装包，仅仅进行文件替换、签名以及打包等操作大幅降低了时间开销，提高了研发测试效率，满足了开发人员快速验证缺陷、高效优化性能等需求。

本申请实施例提供的上述方法可以应用于终端设备。上述安装包更新方法以客户端的形式存储于终端设备中，当客户端运行时，执行本申请实施例提供的安装包更新方法。其中，客户端是提供安装包更新服务的应用程序或应用程序功能模块，例如，客户端可以是独立的应用程序，也可以是集成于应用开发平台的控件或组件等等。客户端所依托的的终端设备是具有数据处理能力的计算设备，包括台式机、笔记本电脑等个人计算机(PersonalComputer，PC)设备或工作站等设备。

为了便于理解本申请的技术方案，下面将结合具体场景对本申请实施例提供的安装包更新方法进行介绍。

图1为本申请实施例中安装包更新方法的场景架构图。在该场景中，开发人员通过终端设备对版本号为1.0的应用程序进行优化，得到版本号为1.1的应用程序的安装包。其具体实现过程参见下文相关描述。

首先，开发人员通过终端设备获取版本号为1.0的应用程序的安装包，也即源安装包，开发人员对原应用程序文件进行修改，获得替换文件，在开发人员指定源安装包以及替换文件后，终端设备上的客户端可以获取源安装包以及替换文件，并对源安装包进行反编译获得包内文件，为了方便表述，将包内文件记分别记作包内文件1至包内文件N，N为正整数。

接着，终端设备从包内文件中搜索与替换文件匹配的的源文件i，其中，i为介于1至N之间的正整数，源文件i可以为包内文件1至包内文件N中的至少一个文件。

然后，终端设备利用替换文件替换包内文件中的源文件i，得到替换后的包内文件。以源文件为包内文件i作为示例，源安装包的包内文件为包内文件1、包内文件2…包内文件i…包内文件N，以替换文件替换源文件i得到替换后的包内文件为包内文件1、包内文件2…替换文件…包内文件N。

最后，终端设备对替换后的包内文件进行签名，并打包生成新版本的安装包，该安装包即为版本号为1.1的应用程序。

在该应用场景中，开发人员无需通过专业引擎工具重新编译生成新的安装包，仅需指定源安装包以及替换文件，如此，终端设备可以自动对包体内的源文件进行替换，然后对替换后的包内文件进行签名和打包，生成新版本的安装包，如此，可以大幅度降低程序优化的时间开销，提高研发测试效率，满足了开发人员对应用程序产品优化的需求。

为了便于理解，下面将从客户端的角度对本申请实施例提供的安装包更新方法进行介绍。

图2为本申请实施例提供的一种安装包更新方法的流程图，参见图2，该方法包括：

S201：获取源安装包，以及获取替换文件。

源安装包是指需要进行更新的安装包。安装包是可自行解压缩文件的集合，包括软件安装的所有文件。安装包内包括多种类型的文件，例如图片、库文件等等。以基于安卓(Android)***的安装包为例，源安装包为安卓安装包(Android Package，APK)格式，APK实际属于一种压缩格式，在该压缩文件中包括了xml格式文件、dex格式文件、arsc格式文件等等。

在一些可能的实现方式中，研发人员或测试人员可以从开发工具或开发平台中获取打包历史记录，根据打包历史记录查询历史安装包的存储位置，从历史安装包的存储位置获取安装包作为源安装包，上传至客户端，以便客户端获取该源安装包。在另一些可能的实现方式中，还可以从网络中获取已发布的安装包，作为源安装包，然后上传至客户端，以便客户端获取该源安装包。获取源安装包可以有多种实现方式，本申请实施例对此不作限定。

在软件开发过程中，尤其是在研发测试阶段，常常需要对一些隐藏的缺陷进行快速地验证也即对bug进行快速验证，对软件底层性能进行优化，或者根据提出的新需求对程序进行优化，基于此，需要对源安装包进行更新。

在本实施例中，采用了包体内进行文件替换的方式，实现对源安装包的更新。为此，需要获取替换文件对源安装包内的文件进行替换。需要说明的是，根据替换方式不同，可以将替换文件分为直接替换文件和间接替换文件。直接替换文件是指可以直接替换，而不用作转换的替换文件，间接替换文件是指需要对替换文件进行转换，然后再进行替换的替换文件。作为本申请的一些具体示例，直接替换文件包括程序集等纯文件，间接替换文件包括jar(Java Archive)包文件。

其中，替换文件可以是研发人员或测试人员对工程文件进行编辑得到，也可以是从网络中获取得到，接着客户端可以接收研发人员或测试人员的上传指令，获取上传的替换文件。例如，当需要对软件的用户界面中的图标等元素进行更新时，可以从网络中获取对应图标元素的图片作为替换文件。又例如，测试人员在对软件进行测试时发现了bug，可以对工程文件中的程序代码进行更新，从而获得替换文件。

S202：反编译所述源安装包得到包内文件，从所述包内文件中搜索与所述替换文件匹配的源文件。

安装包是包括了多种类型文件的压缩文件。为了实现包体内的文件替换，需要对源安装包反编译得到包内文件。反编译也称反向编译，属于软件还原工程，高级语言源程序经过编译变成可执行文件，而反编译就是该编译过程的逆过程。

在一些可能的实现方式中，可以通过解包工具对源安装包进行反编译，实现对源安装包的解包，得到包内文件。以安卓安装包APK为例，客户端可以通过调用apktool工具解开安卓安装包，得到包内文件。

在反编译得到包内文件后，从包内文件中搜索与替换文件匹配的源文件。其中，解包目录中存在文件与替换文件的文件名称以及文件类型相同，则可以将该文件确定与替换文件匹配的源文件，或者，解包目录中存在文件与替换文件转换后的文件的文件名称以及文件类型相同，则可以将该文件确定为与替换文件匹配的源文件。

在一些可能的实现方式中，可以先以文件名称进行检索，若检索到文件与替换文件的文件名称相同，则将该文件的文件类型与替换文件的文件类型进行比较，若相同，则确定该文件与替换文件匹配。作为本实施例的扩展，也可以先按照替换文件的文件类型进行检索，然后在按文件名称进行检索。

在有些情况下，也可以先对替换文件进行转换，然后以转换后的文件的文件名称以及文件类型进行检索。具体的，可以将转换后的文件的文件类型作为关键词检索，然后在检索结果中进一步检索转换后的文件的文件名称，若存在文件的文件名称与转换后的文件的文件名称相同，文件类型与转换后的文件的文件类型相同，则可以确定该文件与替换文件匹配。

S203：利用所述替换文件替换所述包内文件中的源文件，得到替换后的包内文件。

客户端利用替换文件替换包内文件中的源文件，从而得到替换后的包内文件。其中，替换文件可以是一个，也可以是多个，当替换文件为多个时，可以逐个进行替换，也可以多个并行替换，从而提高替换效率，提高用户体验。在本实施例中，替换过程可以由客户端在后台进行，也可以由客户端执行，并在界面上显示。

根据替换文件类型不同，可以有多种替换方式。在一些可能的实现方式中，客户端可以通过直接替换的方式获得替换后的包内文件。具体地，客户端可以将包内文件中的源文件直接替换为替换文件，从而得到替换后的包内文件。在另一些可能的实现方式中，客户端可以通过间接替换的方式获得替换后的包内文件。具体地，客户端可以对替换文件进行转换，采用转换后的文件替换源文件，从而得到替换后的包内文件。

S204：对所述替换后的包内文件进行签名，并打包生成新版本的安装包。

在安装包生成或更新过程中，需要对包内文件进行签名，然后进行打包操作从而生成安装包。因此，在获得替换后的包内文件后，客户端对替换后的包内文件进行签名，并打包生成新版本的安装包，从而实现安装包的更新。

本实施例中的签名是指数字签名。数字签名是附加在数据单元上的一些数据，或是对数据单元所作的密码变换，这种数据或变换允许数据单元的接收者用以确认数据单元的来源和数据单元的完整性并保护数据，防止被伪造或被篡改。客户端在对包内文件进行签名时，可以通过调用签名工具，执行签名算法实现。签名算法包括RSA公钥加密算法、ElGamal算法和/或Schnorr算法等等。客户端可以选择上述签名算法中的至少一种，对替换后的包内文件进行签名。

在对替换后的包内文件签名后，客户端可以将替换后的包内文件连同其签名打包生成新版本的安装包。其中，对文件打包可以通过打包工具或者打包命令实现。在一些可能的实现方式中，客户端可以根据打包命令，自动对替换后的包内文件及其签名进行打包，从而生成新的安装包。

由上可知，本申请实施例提供了一种安装包更新方法，该方法包括获取源安装包以及替换文件，通过对源安装包反编译得到包内文件，从包内文件中搜索与替换文件匹配的源文件，利用替换文件替换包内文件中的源文件，得到替换后的包内文件，对替换后的包内文件签名，并打包生成新版本的安装包。开发人员在进行应用开发时，无需通过专业引擎工具重新编译生成新的安装包，而利用本申请实施例提供的方法，由开发人员指定源安装包以及替换文件即可自动实现安装包的更新。由于不需要重新构建安装包，仅仅进行文件替换、签名以及打包等操作大幅降低了时间开销，提高了研发测试效率，满足了开发人员快速验证缺陷、高效优化性能等需求。

在上述实施例中，替换文件类型不同，替换方式也存在一定的差异。有些类型的替换文件，可以通过纯文件替换方式进行替换。作为本申请的一些具体示例，该类型的替换文件包括图片文件和/或程序集。在有些情况下，针对一些类型的替换文件，可以先对替换文件进行转换，然后以转换后的文件进行替换。作为本申请的一些具体示例，该类型的替换文件包括jar包文件。

为了便于理解上述不同的替换方式，接下来将分别结合jar包替换和程序集替换对本申请实施例提供的安装包更新方法进行介绍。

图3为本申请实施例提供的一种安装包更新方法的流程图，参见图3，该方法包括：

S301：获取源安装包，以及获取用于替换的Jar包文件。

在本实施例中，替换文件为Jar包文件。获取源安装包文件以及获取Jar包文件的过程可以参见图2所示实施例，在此不再赘述。

S302：将Jar包文件转换成dex文件，将dex文件转换成smali文件。

由于对源安装包解包后发现并无Jar文件，无法直接对Jar包文件进行替换。通过对Android安装包打包流程进行分析，可知Android工程源代码(包括库文件jar)都会被编译成相应的.class文件，然后这些class文件会继续生成Android dalvik虚拟机的可执行文件格式dex，也即classes.dex。由于所有代码都变成了二进制，已经无法做单向替换。

其中，Android虚拟机Dalvik并不是执行java虚拟机编译后生成的class文件，而是执行class文件重新整合打包后生成的dex文件，dex文件反编译之后就是smali代码。如果将jar包源代码直接解析成对应的smali文件，把替换classes.dex问题转换为替换smali问题，可以间接实现替换jar包。

在本实施例一些可能的实现方式中，将jar包文件转换为dex文件，可以通过Andriod SDK提供的dx工具实现。具体地，客户端可以通过如下指令将jar包文件转换为dex文件：

dx---dex---output＝DEXNAME.dex JARNAME.jar。

在获得dex文件后，可以通过Andriod SDK提供的baksmali工具将dex文件转换为smali文件。具体地，客户端可以通过如下指令将dex文件转换为smali文件：

Java---jar baksmali.jar DEXNAME.dex。

以上仅为本申请将jar包文件转换成dex文件，将dex文件转换成smali文件的一些具体示例，在本申请实施例其他可能的实现方式中，也可以采用其他方式将jar包文件转换为smali文件，本申请实施例对此不作限定。

S303：反编译所述源安装包得到包内文件，从包内文件中搜索与所述smali文件名称匹配的源文件。

反编译所述源安装包得到包内文件的具体实现可以参见图2所示实施例，在此不再赘述。在反编译得到包内文件后，客户端从包内文件中搜索与所述smali文件名称匹配的源文件。

需要说明的是，S302中将jar包文件转换为dex文件，再将dex文件转换为smali文件，与S303中反编译源安装包得到包内文件的顺序可以是任意的，例如可以同时执行，也可以按照设定的顺序先后执行，本实施例对此不作限定。

S304：利用所述smali文件替换所述包内文件中的源文件，得到替换后的包内文件。

客户端利用smali文件替换所述包内文件中的源文件，得到替换后的报文文件。其中，具体替换过程可以参见图2所示实施例。

S305：对所述替换后的包内文件进行签名，并打包生成新版本的安装包。

本步骤的具体实现可以参见图2所示实施例，在此不再赘述。

由上可知，本申请实施例提供了一种Android安装包更新方法，通过将jar包源代码直接解析成对应的smali文件，将替换classes.dex问题转换为替换smali问题，间接实现替换jar包，然后对替换后的包内文件进行签名并打包，从而实现安装包的更新。该方法只需要在已有的包体内进行文件替换，并对替换后的文件进行签名并打包，无需重新构建安装包，仅仅进行文件替换、签名以及打包等操作大幅降低了时间开销，提高了研发测试效率，满足了开发人员快速验证缺陷、高效优化性能等需求。

在一些可能的实现方式中，替换文件可以是程序集。程序集是.netframework编程的基本组成部分，具体为包含一个或多个类型定义和资源文件的集合。程序集包含公共语言运行库执行的代码。当替换文件为程序集时，可以采用纯文件替换方式将包内文件中与该程序集匹配的源文件直接替换为该程序集。

在有些开发平台或开发工具中，并不包含编译游戏逻辑程序集。当使用该开发平台生成的程序集可能存在对其他平台不适用的情况，基于此，需要生成适用于其他平台的程序集。例如，用户通过Unity 3D引擎开发手游时，由于unity4.x和Unity5.x版本的引擎并不包括单独编译游戏逻辑程序集如Assembly-CSharp.dll的方案。在使用Unity3D Editor开发过程中，若研发人员修改了工程文件代码，如c#代码，则Unity3D引擎会重新编译代码，在library目录生成临时文件夹ScriptAssemblies，其中包含了最新编译完成的代码。但上述代码在Unity3D Editor环境下使用，生成的程序集并不适用于Android移动平台。本申请结合Unity3D官方使用文档，提出了一种独立编译C#程序集，使得适用于其他平台的方案。

接下来，结合附图对本申请实施例中生成程序集的方法进行介绍。

图4为本申请实施例提供的一种生成程序集的方法的流程图，参见图4，该方法包括：

S401：根据新版本的程序代码生成中间文件，所述中间文件包括在特定操作平台上编译程序集所需的资源。

新版本的程序代码是指对源安装包对应的工程文件的程序代码进行更新得到的程序代码。研发或测试人员可以根据验证bug或者优化性能的需求，对程序代码进行更新得到新版本的程序代码。

在获得新版本的程序代码后，根据新版本的程序代码生成中间文件。其中，中间文件包括在特定操作平台上编译程序集所需的资源。以Android平台作为示例，中间文件包括编译各个程序集各自需要的代码文件、编译各个程序集需要的编译宏定义以及编译各个程序集依赖的其他程序库。

在本申请实施例一些可能的实现方式中，Unity 3D Editor响应于针对Unity 3DEditor中菜单控件的触发指令，针对新版本的程序代码进行处理以生成中间文件。具体地，研发人员或测试人员在Unity 3DEditor下触发菜单点击操作，Unity 3D Editor可以响应于该操作，自动生成一个用来编译c#程序集的中间文件，该中间文件收集编译各个程序集需要的程序代码、依赖库、以及编译宏。

S402：根据所述中间文件编译生成所述程序集。

在获取到中间文件后，可以根据中间文件包括的在特定操作平台上编译程序集所需的资源，对程序代码进行编译生成程序集。

在本实施例一些可能的实现方式中，可以通过mono C#编译器调用所述中间文件，编译生成所述程序集。mono是一个自由开放源代码项目，与.NETFramework不同，mono项目不仅可以在windows***上运行，还可以运行于Linux，Free BSD，Unix，OS X和Solaris，甚至还可以运行于游戏平台如Playstation，Wii或Xbox。基于此，通过mono C#编译器编译生成的程序集具有良好的兼容性，可以运行于较多的平台，例如Android平台。

在本实施例一些可能的实现方式中，源安装包是基于Unity3D引擎开发的手游客户端安装包。当替换文件为程序集时，可以根据上述生成程序集的方法生成程序集，对源安装包中的源文件进行替换，以便对替换后的包内文件进行签名打包。

由上可知，本申请实施例提供了一种程序集的生成方法，包括根据新版本的程序代码生成中间文件，然后根据所述中间文件编译生成所述程序集，由于该程序集是根据在特定操作平台上编译程序集所需的资源编译生成的，因此，该程序集能够适用于该特定的操作平台。当需要更新安装包时，可以将该程序集以纯文件替换方式对源安装包的源文件进行替换，然后对替换后的包内文件签名并打包，从而生成新的安装包。如此，可以大幅降低时间开销，提高研发测试效率，满足开发人员快速验证缺陷、高效优化性能等需求。

为了方便操作，本申请提供的上述安装包更新方法，还可以提供图形界面，以便用户输入替换文件和源安装包，提高操作便捷性。具体地，客户端可以显示安装包更新界面，该安装包更新界面上承载有用于输入替换文件的第一输入控件，以及，用于输入源安装包的第二输入控件；如此，客户端可以获取研发或测试人员通过第二输入控件传输的源安装包，以及获取研发或测试人员通过所述第一输入控件传输的替换文件。

其中，当替换文件为多个时，可以通过批处理的方式加快替换效率，加快安装包更新进度，从而提高研发测试效率。具体地，用户可以通过ctrl键同时选中多个文件，一并拖入第一输入控件的输入框，当触发了安装包更新操作时，被选中的多个文件可以同时对包内文件中各个文件对应的源文件进行替换，对替换后的包内文件进行签名并打包即可生成新的安装包。

为了进一步区分不同类型的替换文件，在一些可能的实现方式中，安装包更新界面上承载有两个第一输入控件；其中，一个第一输入控件用于输入支持纯文件替换方式的替换文件，另一个第一输入控件是用于输入Jar包文件类型的替换文件。图5示出了该安装包更新界面的界面示意图，如图5所示，安装包更新界面承载有两个第一输入控件，分别用于输入支持纯文件替换方式的替换文件和jar包文件类型的替换文件。并且，所述安装包更新界面上还承载有用于触发安装包更新指令的更新控件；当用户通过鼠标点击、触控或者声控等方式触发该更新控件时，客户端响应于所述更新控件被触发的指令，再执行反编译所述源安装包得到包内文件的步骤。

为了便于理解本申请的技术方案，本申请实施例将结合具体应用场景对本申请实施例提供的安装包更新方法进行介绍。

图6为本申请实施例提供的一种安装包更新方法的场景示意图，参见图6，该场景是以跨平台游戏开发工具和专业游戏引擎Unity3D上开发的手游客户端安装包更新作为示例的，下面结合附件进行详细说明。

如图6所示，该应用场景中提供了Unity3D Editor、Mono C#编译器以及安装包更新客户端，通过上述工具的交互实现安装包更新。具体地，Unity 3D引擎中的Unity3DEditor可以编辑手游客户端的工程文件，本实施例中的源安装包是通过将Unity3D Editor的工程文件进行编译、打包等操作生成的。

在该实施例中，研发人员基于优化该手游性能的需求对工程文件的程序代码进行了更新，为此，需要对手游客户端的安装包也进行更新。其中，本实施例是通过在包体内替换程序集和jar包，然后对替换后的文件进行签名和打包，从而实现该手游客户端安装包的更新。

具体地，首先研发人员或测试人员触发Unity3D Editor的菜单控件，Unity3DEditor响应于菜单控件被触发的指令，针对新版本的代码进行处理以生成中间文件，该中间文件包括手游客户端在Android平台上编译所需的资源，如程序代码、依赖库以及编译宏等等。然后通过mono C#编译器以中间文件作为输入，编译生成程序集。

在生成程序集，并且获得jar包后，将程序集拖入到安装包更新客户端的安装包更新界面中“纯文件替换”对应的输入控件，将jar包拖入到安装包更新界面中“jar包替换”对应的输入控件，将源安装包拖入到安装包更新界面中“源安装包”对应的输入控件，然后点击“更新”控件，触发更新安装包的操作。

安装包更新客户端响应于更新控件被触发的指令，通过解包工具对源安装包反编译得到包内文件，然后通过Android SDK中的dx工具将替换文件jar包转换为dex文件，再将dex文件通过baksmali工具转换为smali文件，接着在包内文件中检索与smali文件以及程序集相匹配的源文件，然后利用smali文件和程序集替换包内文件中的源文件，再利用签名工具对替换后的包内文件进行签名，以及利用打包工具对签名后的包内文件打包，从而生成新的手游客户端的安装包。

需要说明的是，以上仅为本申请实施例中安装包更新方法的一个具体示例，在本申请实施例其他可能的实现方式中，也可以对其他文件进行替换，或者可以对jar包和程序集中的一种文件进行替换，具体替换过程可以根据实际需求确定，本申请实施例对此不作限定。

可以理解，本申请提供的安装包更新方法，在Unity3d手游研发测试环节中，通过在现有Unity3d手游Android安装包内直接或间接替换包内文件，包括研发测试阶段使用的Java库和承载游戏逻辑的运行时程序库等文件，从而达到无需重新构建安装包，仅对替换后的包内文件签名并打包即可实现安装包的更新，大幅度降低了时间开销，提升了研发测试的效率。

以上为本申请实施例提供的一种安装包更新方法的具体实现方式，基于此，本申请实施例还提供了一种安装包更新装置。接下来将从功能模块化的角度对本申请实施例提供的安装包更新装置进行介绍。

图7为本申请实施例提供的一种安装包更新装置的结构示意图，参见图7，该装置700包括：

获取单元710，用于获取源安装包，以及获取替换文件；

搜索单元720，用于反编译所述源安装包得到包内文件，从所述包内文件中搜索与所述替换文件匹配的源文件；

替换单元730，用于利用所述替换文件替换所述包内文件中的源文件，得到替换后的包内文件；

打包单元740，用于对所述替换后的包内文件进行签名，并打包生成新版本的安装包。

可选的，所述替换文件包括Jar包文件和/或程序集。

可选的，参见图8，图8为本申请实施例提供的一种安装包更新装置的一个结构示意图，所述装置还包括转换单元750；所述转换单元750具体用于：

若所述替换文件包括Jar包文件，将所述Jar包文件转换成dex文件，将所述dex文件转换成smali文件；

则所述搜索单元720具体用于：

从所述包内文件中搜索与所述smali文件名称匹配的源文件。

可选的，参见图9，图9为本申请实施例提供的一种安装包更新装置的一个结构示意图，所述装置还包括生成单元760；所述生成单元760具体用于：

若所述替换文件包括程序集，根据新版本的程序代码生成中间文件，所述中间文件包括在特定操作平台上编译程序集所需的资源；根据所述中间文件编译生成所述程序集。

可选的，所述生成单元760具体用于：

响应于针对Unity3D Editor中菜单控件的触发指令，针对新版本的程序代码进行处理以生成中间文件。

可选的，所述生成单元760具体用于：

通过mono C#编译器调用所述中间文件，编译生成所述程序集。

可选的，参见图10，图10为本申请实施例提供的一种安装包更新装置的一个结构示意图，所述装置还包括显示单元770；所述显示单元770具体用于：

显示安装包更新界面，所述安装包更新界面上承载有用于输入替换文件的第一输入控件，以及，用于输入源安装包的第二输入控件；

则获取单元710具体用于：

获取通过所述第二输入控件传输的源安装包，以及获取通过所述第一输入控件传输的替换文件。

可选的，所述安装包更新界面上承载有两个第一输入控件；其中，一个第一输入控件用于输入支持纯文件替换方式的替换文件，另一个第一输入控件是用于输入Jar包文件类型的替换文件；

并且，所述安装包更新界面上还承载有用于触发安装包更新指令的更新控件；当用户触发更新控件，则客户端响应于所述更新控件被触发的指令，再执行所述反编译所述源安装包得到包内文件的步骤。

可选的，所述源安装包是基于unity3D引擎开发的手游客户端安装包。

由上可知，本申请实施例提供了一种安装包更新装置，该装置通过获取源安装包以及替换文件，对源安装包反编译得到包内文件，从包内文件中搜索与替换文件匹配的源文件，利用替换文件替换包内文件中的源文件，得到替换后的包内文件，对替换后的包内文件签名，并打包生成新版本的安装包。开发人员在进行应用开发时，无需通过专业引擎工具重新编译生成新的安装包，而利用本申请实施例提供的方法，由开发人员指定源安装包以及替换文件即可自动实现安装包的更新。由于不需要重新构建安装包，仅仅进行文件替换、签名以及打包等操作大幅降低了时间开销，提高了研发测试效率，满足了开发人员快速验证缺陷、高效优化性能等需求。

以上实施例为从功能模块化的角度对本申请实施例提供的安装包更新装置进行介绍，接下来将从硬件实体化的角度对本申请实施例提供的安装包更新装置进行介绍。

本申请实施例还提供了一种终端设备，如图11所示，为了便于说明，仅示出了与本申请实施例相关的部分，具体技术细节未揭示的，请参照本申请实施例方法部分。该终端设备可以为笔记本电脑、台式电脑或者工作站等等，以终端设备为笔记本电脑为例：

图11示出的是与本申请实施例提供的终端设备相关的笔记本电脑的部分结构的框图。参考图11，笔记本电脑包括：射频(英文全称：Radio Frequency，英文缩写：RF)电路1110、存储器1120、输入单元1130、显示单元1140、传感器1150、音频电路1160、无线保真(英文全称：wireless fidelity，英文缩写：WiFi)模块1170、处理器1180、以及电源1190等部件。本领域技术人员可以理解，图11中示出的笔记本电脑结构并不构成对笔记本电脑的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面结合图11对笔记本电脑的各个构成部件进行具体的介绍：

RF电路1110可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，给处理器1180处理；另外，将设计上行的数据发送给基站。通常，RF电路1110包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(英文全称：LowNoise Amplifier，英文缩写：LNA)、双工器等。此外，RF电路1110还可以通过无线通信与网络和其他设备通信。上述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯***(英文全称：Global System of Mobile communication，英文缩写：GSM)、通用分组无线服务(英文全称：General Packet Radio Service，GPRS)、码分多址(英文全称：CodeDivision Multiple Access，英文缩写：CDMA)、宽带码分多址(英文全称：Wideband CodeDivision Multiple Access,英文缩写：WCDMA)、长期演进(英文全称：Long TermEvolution，英文缩写：LTE)、电子邮件、短消息服务(英文全称：Short Messaging Service，SMS)等。

存储器1120可用于存储软件程序以及模块，处理器1180通过运行存储在存储器1120的软件程序以及模块，从而执行笔记本电脑的各种功能应用以及数据处理。存储器1120可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作***、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据笔记本电脑的使用所创建的数据(比如音频数据、通讯录等)等。此外，存储器1120可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

输入单元1130可用于接收输入的数字或字符信息，以及产生与笔记本电脑的用户设置以及功能控制有关的键信号输入。具体地，输入单元1130可包括触控面板1131以及其他输入设备1132。触控面板1131，也称为触摸板，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板1131上或在触控面板1131附近的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触控面板1131可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器1180，并能接收处理器1180发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板1131。除了触控面板1131，输入单元1130还可以包括其他输入设备1132。具体地，其他输入设备1132可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元1140可用于显示由用户输入的信息或提供给用户的信息以及笔记本电脑的各种菜单。显示单元1140可包括显示面板1141，可选的，可以采用液晶显示器(英文全称：Liquid Crystal Display，英文缩写：LCD)、有机发光二极管(英文全称：OrganicLight-Emitting Diode，英文缩写：OLED)等形式来配置显示面板1141。进一步的，触控面板1131可覆盖显示面板1141，当触控面板1131检测到在其上或附近的触摸操作后，传送给处理器1180以确定触摸事件的类型，随后处理器1180根据触摸事件的类型在显示面板1141上提供相应的视觉输出。虽然在图11中，触控面板1131与显示面板1141是作为两个独立的部件来实现笔记本电脑的输入和输入功能，但是在某些实施例中，可以将触控面板1131与显示面板1141集成而实现笔记本电脑的输入和输出功能。

笔记本电脑还可包括至少一种传感器1150，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及距离传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板1141的亮度，距离传感器可在用户离开笔记本电脑时，关闭显示面板1141和/或背光。作为运动传感器的一种，加速计传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别笔记本电脑姿态的应用，比如识别屏幕位置，从而调整该笔记本电脑的电源状态，当屏幕合上，可以关闭显示器，控制电源处于节能模式；至于笔记本电脑还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

音频电路1160、扬声器1161，传声器1162可提供用户与笔记本电脑之间的音频接口。音频电路1160可将接收到的音频数据转换后的电信号，传输到扬声器1161，由扬声器1161转换为声音信号输出；另一方面，传声器1162将收集的声音信号转换为电信号，由音频电路1160接收后转换为音频数据，再将音频数据输出处理器1180处理后，经RF电路1110以发送给比如另一笔记本电脑，或者将音频数据输出至存储器1120以便进一步处理。

WiFi属于短距离无线传输技术，笔记本电脑通过WiFi模块1170可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图11示出了WiFi模块1170，但是可以理解的是，其并不属于笔记本电脑的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略。

处理器1180是笔记本电脑的控制中心，利用各种接口和线路连接整个笔记本电脑的各个部分，通过运行或执行存储在存储器1120内的软件程序和/或模块，以及调用存储在存储器1120内的数据，执行笔记本电脑的各种功能和处理数据，从而对笔记本电脑进行整体监控。可选的，处理器1180可包括一个或多个处理单元；优选的，处理器1180可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作***、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器1180中。

笔记本电脑还包括给各个部件供电的电源1190(比如电池)，优选的，电源可以通过电源管理***与处理器1180逻辑相连，从而通过电源管理***实现管理充电、放电、以及功耗管理等功能。

尽管未示出，笔记本电脑还可以包括摄像头、蓝牙模块等，在此不再赘述。

在本申请实施例中，该终端设备所包括的处理器1180还具有以下功能：

获取源安装包，以及获取替换文件；

反编译所述源安装包得到包内文件，从所述包内文件中搜索与所述替换文件匹配的源文件；

利用所述替换文件替换所述包内文件中的源文件，得到替换后的包内文件；

对所述替换后的包内文件进行签名，并打包生成新版本的安装包。

可选的，处理器1180还用于执行本申请实施例提供的安装包更新方法的任意一种实现方式的方法步骤。

本申请实施例还提供一种计算机可读存储介质，用于存储程序代码，该程序代码用于执行前述各个实施例所述的一种安装包更新方法中的任意一种实施方式。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的***，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的***，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

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

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

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (12)

1.一种安装包更新方法，其特征在于，包括：

获取源安装包，以及获取替换文件；

反编译所述源安装包得到包内文件，从所述包内文件中搜索与所述替换文件匹配的源文件；

利用所述替换文件替换所述包内文件中的源文件，得到替换后的包内文件；

对所述替换后的包内文件进行签名，并打包生成新版本的安装包。

2.根据权利要求1所述的方法，其特征在于，所述替换文件包括Jar包文件和/或程序集。

3.根据权利要求2所述的方法，其特征在于，若所述替换文件包括Jar包文件，则所述方法还包括：

将所述Jar包文件转换成dex文件，将所述dex文件转换成smali文件；

则从所述包内文件中搜索与所述替换文件匹配的源文件，包括：

从所述包内文件中搜索与所述smali文件名称匹配的源文件。

4.根据权利要求2所述的方法，其特征在于，若所述替换文件包括程序集，则所述方法还包括：

根据新版本的程序代码生成中间文件，所述中间文件包括在特定操作平台上编译程序集所需的资源；

根据所述中间文件编译生成所述程序集。

5.根据权利要求4所述的方法，其特征在于，所述根据新版本的程序代码生成中间文件，包括：

响应于针对Unity3D Editor中菜单控件的触发指令，针对新版本的程序代码进行处理以生成中间文件。

6.根据权利要求4所述的方法，其特征在于，所述根据所述中间文件，编译生成所述程序集，包括：

通过mono C#编译器调用所述中间文件，编译生成所述程序集。

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

显示安装包更新界面，所述安装包更新界面上承载有用于输入替换文件的第一输入控件，以及，用于输入源安装包的第二输入控件；

则获取源安装包，以及获取替换文件，包括：

获取通过所述第二输入控件传输的源安装包，以及获取通过所述第一输入控件传输的替换文件。

8.根据权利要求7所述的方法，其特征在于，所述安装包更新界面上承载有两个第一输入控件；其中，一个第一输入控件用于输入支持纯文件替换方式的替换文件，另一个第一输入控件是用于输入Jar包文件类型的替换文件；

并且，所述安装包更新界面上还承载有用于触发安装包更新指令的更新控件；

则响应于所述更新控件被触发的指令，再执行所述反编译所述源安装包得到包内文件的步骤。

9.根据权利要求1至6中任一项所述的方法，其特征在于，所述源安装包是基于unity3D引擎开发的手游客户端安装包。

10.一种安装包更新装置，其特征在于，包括：

获取单元，用于获取源安装包，以及获取替换文件；

搜索单元，用于反编译所述源安装包得到包内文件，从所述包内文件中搜索与所述替换文件匹配的源文件；

替换单元，用于利用所述替换文件替换所述包内文件中的源文件，得到替换后的包内文件；

打包单元，用于对所述替换后的包内文件进行签名，并打包生成新版本的安装包。

11.一种终端设备，其特征在于，所述设备包括处理器以及存储器：

所述存储器用于存储程序代码，并将所述程序代码传输给所述处理器；

所述处理器用于根据所述程序代码中的指令执行权利要求1至9任一项所述的安装包更新方法。

12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质用于存储程序代码，所述程序代码用于执行权利要求1至9任一项所述的安装包更新方法。