CN107247584A - 应用安装包打包方法及装置 - Google Patents

Abstract

本发明实施例提供一种应用安装包打包方法及装置。其中，方法包括如下的步骤：根据待打包文件的发布渠道，获取所述发布渠道对应的资源文件和功能类；根据所述资源文件及所述功能类，对所述待打包文件进行处理以生成满足所述发布渠道所需执行逻辑的可执行文件；对所述可执行文件进行打包，得到所述发布渠道对应的应用安装包。本发明实施例提供的技术方案实现了针对不同发布渠道的自动打包过程，避免了现有技术中人工手动修改所带来的诸多问题。

Description

应用安装包打包方法及装置

技术领域

本发明涉及计算机领域，尤其涉及一种应用安装包打包方法及装置。

背景技术

Android(安卓)项目开发完成以后要将Android App(安卓应用)打包成应用安装包(APK)，并通过发布渠道(亦称发布平台)发布以便于用户下载使用。在开发Android App时，由于Android市场的发布渠道很多，各个发布渠道都有自己的App市场。每个APP市场对应用安装包的展示方式以及平台具体业务功能的要求是不同的。因此，需要针对不同的发布渠道，修改Android App安装包，以使其满足不同渠道的要求。

现有技术是通过人工手动的方式对不同发布渠道的APK文件进行修改并完成打包的。有时一个工程应用非常大，每次打包都要浪费几分钟，再加上手工修改APP文件会增加很多额外的耗费，并且如果每个渠道都单独发布，那样效率会及其低下；此外，由于渠道数目多，人工修改极易出错。

发明内容

本发明实施例提供一种应用安装包打包方法及装置，用以解决现有技术中需人工手动修改APK文件以满足不同发布渠道的要求存在的诸多问题。

于是，在本发明的一个实施例中，提供了一种应用安装包打包方法。该方法包括：根据待打包文件的发布渠道，获取所述发布渠道对应的资源文件和功能类；根据所述资源文件及所述功能类，对所述待打包文件进行处理以生成满足所述发布渠道所需执行逻辑的可执行文件；对所述可执行文件进行打包，得到所述发布渠道对应的应用安装包。

可选地，上述根据待打包文件的发布渠道，获取所述发布渠道对应的资源文件和功能类，包括：根据预置的发布渠道与资源文件的对应关系，获取所述发布渠道对应的资源文件；获取gradle构建工具目录下的多个功能类；根据发布渠道的功能需求信息，从所述多个功能类中获取与所述功能需求信息匹配的所述功能类。

可选地，根据所述资源文件及所述功能类，对所述待打包文件进行处理以生成满足所述发布渠道所需执行逻辑的可执行文件，包括：将所述资源文件与所述待打包文件进行合并得到中间文件；将所述功能类添加到所述中间文件中得到所述可执行文件。

可选地，将所述资源文件与所述待打包文件进行合并得到中间文件，包括：若所述待打包文件中包含有与所述资源文件重名的子文件，则将所述子文件替换为所述资源文件得到所述中间文件；若所述待打包文件不包含与所述资源文件重名的子文件，则将所述资源文件添加到所述待打包文件中得到所述中间文件。

可选地，将所述功能类添加到所述中间文件中得到所述可执行文件，包括：获取所述中间文件中预留的添加位置；在所述添加位置处添加所述功能类得到所述可执行文件。

在本发明的另一实施例中，提供了一种应用安装包打包装置。该装置包括：获取模块，用于根据待打包文件的发布渠道，获取所述发布渠道对应的资源文件和功能类；处理模块，用于根据所述资源文件及所述功能类，对所述待打包文件进行处理以生成满足所述发布渠道所需执行逻辑的可执行文件；打包模块，用于对所述可执行文件进行打包，得到所述发布渠道对应的应用安装包。

本发明实施例提供的技术方案，根据待打包文件的发布渠道对应的资源文件及功能类，对待打包文件进行打包生成发布渠道对应的应用安装包，使得应用安装包按照发布渠道所需执行逻辑进行运行，例如按照资源文件确定应用安装包的展示形式以满足发布渠道形式要求，通过调用功能类使应用安装包具有发布渠道所要求的具体业务功能；由此可知，本发明实施例提供的技术方案实现了针对不同发布渠道的自动打包过程，避免了现有技术中人工手动修改所带来的诸多问题。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明一实施例提供的应用安装包打包方法的流程示意图；

图2为本发明另一实施例提供的应用安装包打包方法的流程示意图；

图3为本发明一实施例提供的应用安装包打包装置的结构框图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。

在本发明的说明书、权利要求书及上述附图中描述的一些流程中，包含了按照特定顺序出现的多个操作，这些操作可以不按照其在本文中出现的顺序来执行或并行执行。操作的序号如101、102等，仅仅是用于区分各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。

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

图1示出了本发明一实施例提供的应用安装包打包方法的流程示意图。如图1所示，本实施例提供的所述方法，包括：

101、根据待打包文件的发布渠道，获取所述发布渠道对应的资源文件和功能类。

102、根据所述资源文件及所述功能类，对所述待打包文件进行处理以生成满足所述发布渠道所需执行逻辑的可执行文件。

103、对所述可执行文件进行打包，得到所述发布渠道对应的应用安装包。

上述101中，所述发布渠道所需的资源文件中包含有：有关应用安装包展示形式的配置信息，例如，应用安装包在发布渠道的APP市场中的展示图标大小信息、展示图标的样式信息等等。每个发布渠道对应有一个资源文件，即在具体实施时，可预置发布渠道与资源文件的对应关系。相应的，上述的根据待打包文件的发布渠道，确定所述发布渠道所需的资源文件，可具体为：发布渠道与资源文件的对应关系，获取与所述发布渠道对应的资源文件，并将获取到的资源文件作为所述发布渠道所需的资源文件。或者，根据发布渠道的展示要求生成对应的资源文件，即上述的根据待打包文件的发布渠道，确定所述发布渠道所需的资源文件，可具体为：获取待打包文件的发布渠道的形式要求信息(例如图片大小信息、展示样式信息等等)；根据所述形式要求信息，生成相应的资源文件。功能类可以是实现具体功能的class()文件。一种可实现的技术方案是，本发明实施例提供的技术方案可采用gradle构建工具来实现。gradle构建工具会在其目录下预先生成对应不同功能的类。一个或多个功能类可对应一种发布渠道。因此，上述获取发布渠道对应的功能类的过程可包括：获取gradle构建工具目录下的多个功能类；根据发布渠道与功能类的对应关系，从所述多个功能类中获取所述发布渠道对应的所述功能类。其中，获取到的所述功能类可以是一个，也可以是多个。功能类可包含但不限于：实现检查更新功能的类、实现发布渠道对应登录方式的功能类等等。

上述102中对待打包文件进行的处理包括：资源文件的合并处理以及功能类的添加处理。一种可实现的方案中，将所述资源文件与所述待打包文件进行合并得到中间文件；将所述功能类添加到所述中间文件中得到所述可执行文件。其中，合并处理及功能类的添加处理均可采用现有技术中的gradle构建工具来实现，例如，通过调用gradle构建工具中对应的执行指令来实现。

上述103中对可执行文件打包的过程可参见现有技术中的Android App的打包流程，此处不再赘述。

本实施例提供的技术方案，根据待打包文件的发布渠道对应的资源文件及功能类，对待打包文件进行打包生成发布渠道对应的应用安装包，使得应用安装包按照发布渠道所需执行逻辑进行运行，例如按照资源文件确定应用安装包的展示形式以满足发布渠道形式要求，通过调用功能类使应用安装包具有发布渠道所要求的具体业务功能；由此可知，本发明实施例提供的技术方案实现了针对不同发布渠道的自动打包过程，避免了现有技术中人工手动修改所带来的诸多问题。

图2示出了本发明另一实施例提供的应用安装包打包方法的流程示意图。如图2所示，所述方法包括：

201、根据待打包文件的发布渠道，获取所述发布渠道对应的资源文件和功能类。

202、若所述待打包文件中包含有与所述资源文件重名的子文件，则将所述子文件替换为所述资源文件得到所述中间文件。

203、若所述待打包文件不包含与所述资源文件重名的子文件，则将所述资源文件添加到所述待打包文件中得到所述中间文件。

204、获取所述中间文件中预留的添加位置。

205、在所述添加位置处添加所述功能类得到所述可执行文件。

206、对所述可执行文件进行打包，得到所述发布渠道对应的应用安装包。

上述201可参见上述实施例中的相应内容，此处不再赘述。

上述202和203中，待打包文件通过情况下是包含有资源文件的，当然也有例外(即不包含资源文件的情况)。不同的待打包文件中的资源文件的文件名是相同的。因此，在待打包文件中包含有资源文件时，需将该资源文件替换为所述发布渠道对应的资源文件。若待打包文件中不包含资源文件，则直接将所述发布渠道对应的资源文件添加到待打包文件中即可。

上述204中，Android应用程序编写过程中都会预留一些可进行功能扩展的扩展位。通过在扩展位中添加相应的功能语句，即实现功能的扩展。由此可知，本实施例即是通过将功能类添加到预留的扩展位(即上述提到的添加位置)来实现功能扩展以实现发布渠道所需的业务功能。

上述206中对可执行文件打包的过程可参见现有技术中的Android App的打包流程，此处不再赘述。

本实施例提供的技术方案，根据待打包文件的发布渠道对应的资源文件及功能类，对待打包文件进行打包生成发布渠道对应的应用安装包，使得应用安装包按照发布渠道所需执行逻辑进行运行，例如按照资源文件确定应用安装包的展示形式以满足发布渠道形式要求，通过调用功能类使应用安装包具有发布渠道所要求的具体业务功能；由此可知，本发明实施例提供的技术方案实现了针对不同发布渠道的自动打包过程，避免了现有技术中人工手动修改所带来的诸多问题。

下面以小米发布渠道为例对本发明实施例提供的技术方案进行说明。

Gradle构建工具在构建待打包文件(构建的过程就是针对小米渠道对待打包文件进行打包的过程)时会去判断其工程里是不是有小米的工程包。若有，则执行小米的功能包以将小米渠道对应的资源文件与待打包文件的main()文件进行合并。合并过程可参见上述各实施例中的相应内容，此处不再赘述。在预先留好添加位置的Main()文件里面添加小米渠道对应的class()类文件得到可执行文件，对可执行文件进行打包得到小米渠道对应的应用安装包。应用安装包下发到小米渠道的平台后，基于应用安装包中的资源文件指向的展示形式在小米平台上展示应用安装包。用户若通过小米渠道的平台下载该应用安装包并进行本地安装时，会对main()文件中的功能类进行类名的判断；若mian()文件中存在有指定类名的功能类，则调用该功能类，以执行该功能类对应的逻辑行为；否则，不执行该功能对应的逻辑行为。

需要说明的是：上述实施例所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。比如，步骤101至步骤103的执行主体可以为设备A；又比如，步骤101和102的执行主体可以为设备A，步骤103的执行主体可以为设备B；等等。

图3示出了本发明一实施例提供的应用安装包打包装置的结构示意图。如图3所示，所述装置包括：获取模块301用于根据待打包文件的发布渠道，获取所述发布渠道对应的资源文件和功能类；处理模块302用于根据所述资源文件及所述功能类，对所述待打包文件进行处理以生成满足所述发布渠道所需执行逻辑的可执行文件；打包模块303用于对所述可执行文件进行打包，得到所述发布渠道对应的应用安装包。

本实施例提供的技术方案，根据待打包文件的发布渠道对应的资源文件及功能类，对待打包文件进行打包生成发布渠道对应的应用安装包，使得应用安装包按照发布渠道所需执行逻辑进行运行，例如按照资源文件确定应用安装包的展示形式以满足发布渠道形式要求，通过调用功能类使应用安装包具有发布渠道所要求的具体业务功能；由此可知，本发明实施例提供的技术方案实现了针对不同发布渠道的自动打包过程，避免了现有技术中人工手动修改所带来的诸多问题。

进一步的，所述获取模块，还用于：根据预置的发布渠道与资源文件的对应关系，获取所述发布渠道对应的资源文件；获取gradle构建工具目录下的多个功能类；根据发布渠道的功能需求信息，从所述多个功能类中获取与所述功能需求信息匹配的所述功能类。

进一步的，所述处理模块，包括：合并单元，用于将所述资源文件与所述待打包文件进行合并得到中间文件；添加单元，用于将所述功能类添加到所述中间文件中得到所述可执行文件。

进一步的，所述合并单元，还用于：若所述待打包文件中包含有与所述资源文件重名的子文件，则将所述子文件替换为所述资源文件得到所述中间文件；若所述待打包文件不包含与所述资源文件重名的子文件，则将所述资源文件添加到所述待打包文件中得到所述中间文件。

进一步的，所述添加单元，还用于：获取所述中间文件中预留的添加位置；在所述添加位置处添加所述功能类得到所述可执行文件。

这里需要说明的是：上述实施例提供的应用安装包打包装置可实现上述各方法实施例中描述的技术方案，上述各模块或单元具体实现的原理可参见上述各方法实施例中的相应内容，此处不再赘述。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

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

Claims (10)

1.一种应用安装包打包方法，其特征在于，包括：

根据待打包文件的发布渠道，获取所述发布渠道对应的资源文件和功能类；

根据所述资源文件及所述功能类，对所述待打包文件进行处理以生成满足所述发布渠道所需执行逻辑的可执行文件；

对所述可执行文件进行打包，得到所述发布渠道对应的应用安装包。

2.根据权利要求1所述的方法，其特征在于，根据待打包文件的发布渠道，获取所述发布渠道对应的资源文件和功能类，包括：

根据预置的发布渠道与资源文件的对应关系，获取所述发布渠道对应的资源文件；

获取gradle构建工具目录下的多个功能类；

根据发布渠道的功能需求信息，从所述多个功能类中获取与所述功能需求信息匹配的所述功能类。

3.根据权利要求1或2所述的方法，其特征在于，根据所述资源文件及所述功能类，对所述待打包文件进行处理以生成满足所述发布渠道所需执行逻辑的可执行文件，包括：

将所述资源文件与所述待打包文件进行合并得到中间文件；

将所述功能类添加到所述中间文件中得到所述可执行文件。

4.根据权利要求3所述的方法，其特征在于，将所述资源文件与所述待打包文件进行合并得到中间文件，包括：

若所述待打包文件中包含有与所述资源文件重名的子文件，则将所述子文件替换为所述资源文件得到所述中间文件；

若所述待打包文件不包含与所述资源文件重名的子文件，则将所述资源文件添加到所述待打包文件中得到所述中间文件。

5.根据权利要求3所述的方法，其特征在于，将所述功能类添加到所述中间文件中得到所述可执行文件，包括：

获取所述中间文件中预留的添加位置；

在所述添加位置处添加所述功能类得到所述可执行文件。

6.一种应用安装包打包装置，其特征在于，包括：

获取模块，用于根据待打包文件的发布渠道，获取所述发布渠道对应的资源文件和功能类；

处理模块，用于根据所述资源文件及所述功能类，对所述待打包文件进行处理以生成满足所述发布渠道所需执行逻辑的可执行文件；

打包模块，用于对所述可执行文件进行打包，得到所述发布渠道对应的应用安装包。

7.根据权利要求6所述的装置，其特征在于，所述获取模块，还用于：

根据预置的发布渠道与资源文件的对应关系，获取所述发布渠道对应的资源文件；

获取gradle构建工具目录下的多个功能类；

根据发布渠道的功能需求信息，从所述多个功能类中获取与所述功能需求信息匹配的所述功能类。

8.根据权利要求6或7所述的装置，其特征在于，所述处理模块，包括：

合并单元，用于将所述资源文件与所述待打包文件进行合并得到中间文件；

添加单元，用于将所述功能类添加到所述中间文件中得到所述可执行文件。

9.根据权利要求8所述的装置，其特征在于，所述合并单元，还用于：

若所述待打包文件中包含有与所述资源文件重名的子文件，则将所述子文件替换为所述资源文件得到所述中间文件；

若所述待打包文件不包含与所述资源文件重名的子文件，则将所述资源文件添加到所述待打包文件中得到所述中间文件。

10.根据权利要求8所述的装置，其特征在于，所述添加单元，还用于：

获取所述中间文件中预留的添加位置；

在所述添加位置处添加所述功能类得到所述可执行文件。