本发明涉及互联网数据处理领域，具体涉及到一种移动端app自动打包方法、系统、电子设备及存储介质。
背景技术：
各大应用市场和代理商针对上架到自己平台的应用有不同的要求，需要在每个应用市场和代理商发布不同的应用安装包。应用安装包中可能存在很多差异性，以此用来区分和统计各个应用市场和代理商的下载量、用户量等。目前市面上比较成熟的方式是通过第三方，比如友盟，但是第三方的方案只能针对一些应用的基本信息，比如渠道号，应用包名，版本号等，在实际需求中，除了这些基本信息以外，还需要对应用的一些高级设置做定制，这些工作细节给开发人员带来了很大的工作量，而且很容易出现失误，不利于工作的顺利开展。
技术实现要素：
有鉴于此，本发明实施例提供了一种移动端app自动打包方法、系统、电子设备及存储介质，以实现不同渠道移动端app的自动打包。
为此，本发明实施例提供了如下技术方案：
根据第一方面，本发明实施例提供了一种移动端app自动打包方法，包括：获取不同渠道移动端app的参数配置，所述参数配置包括app的基本信息和高级设置信息；根据参数配置在多渠道配置管理后台中进行移动端app参数的配置，得到每一个渠道的配置信息；将所有渠道的配置信息通过接口发送至打包服务器；启动打包脚本，解析接口中的配置信息，将检测出的对应ios通用代码和android通用代码发送至打包服务器；将配置信息同步到对应的ios通用代码和android通用代码中，得到ios项目代码和android项目代码；对ios项目代码进行打包操作，生成ios打包文件；对android项目代码进行打包操作，生成android打包文件。
可选地，将所有渠道的配置信息通过接口发送至打包服务器的步骤中，包括：启动多渠道配置管理后台中的启动打包操作，并向打包服务器请求打包接口；通过打包接口将各个渠道的配置信息以json格式发送至打包服务器。
可选地，启动打包脚本，解析接口中的配置信息，将检测出的对应ios通用代码和android通用代码发送至打包服务器的步骤中，包括：启动打包脚本，解析接口中的配置信息，根据预先约定的数据解析协议获取打包代码的地址；根据打包代码的地址对应的从gitlab或者svn中检出需要打包的ios通用代码和android通用代码；将ios通用代码和android通用代码发送至打包服务器。
可选地，对android项目代码进行打包操作，生成android打包文件的步骤中，包括：对android项目代码进行打包操作，编译android代码生成apk初始安装包文件；将apk初始安装包文件进行加固，得到加固安装包文件；对加固安装包文件进行重新签名，生成apk最终安装包文件，所述apk最终安装包文件即为android打包文件。
可选地，对android项目代码进行打包操作，生成android打包文件的步骤之后，还包括：根据ios打包文件和android打包文件生成二维码；根据软件测试需求将二维码发送至软件测试方，以使软件测试方根据二维码下载对应的app软件并对app软件进行功能测试。
可选地，根据软件测试需求将二维码发送至软件测试方的步骤之后，还包括：接收软件测试方反馈的功能测试结果；若所述功能测试结果为功能测试通过，则将ios打包文件和android打包文件进行存储；若所述功能测试结果为功能测试不通过，则对ios项目代码和android项目代码进行修复，并将修复后的ios项目代码和android项目代码重新打包。
根据第二方面，本发明实施例提供了一种移动端app自动打包系统，包括：获取模块，用于获取不同渠道移动端app的参数配置，所述参数配置包括app的基本信息和高级设置信息；第一处理模块，用于根据参数配置在多渠道配置管理后台中进行移动端app参数的配置，得到每一个渠道的配置信息；第二处理模块，用于将所有渠道的配置信息通过接口发送至打包服务器；第三处理模块，用于启动打包脚本，解析接口中的配置信息，将检测出的对应ios通用代码和android通用代码发送至打包服务器；第四处理模块，用于将配置信息同步到对应的ios通用代码和android通用代码中，得到ios项目代码和android项目代码；第五处理模块，用于对ios项目代码进行打包操作，生成ios打包文件；第六处理模块，用于对android项目代码进行打包操作，生成android打包文件。
可选地，所述第二处理模块包括：第一处理单元，用于启动多渠道配置管理后台中的启动打包操作，并向打包服务器请求打包接口；第二处理单元，用于通过打包接口将各个渠道的配置信息以json格式发送至打包服务器。
可选地，所述第三处理模块包括：第三处理单元，用于启动打包脚本，解析接口中的配置信息，根据预先约定的数据解析协议获取打包代码的地址；第四处理单元，用于根据打包代码的地址对应的从gitlab或者svn中检出需要打包的ios通用代码和android通用代码；第五处理单元，用于将ios通用代码和android通用代码发送至打包服务器。
可选地，所述第六处理模块包括：第六处理单元，用于对android项目代码进行打包操作，编译android代码生成apk初始安装包文件；第七处理单元，用于将apk初始安装包文件进行加固，得到加固安装包文件；第八处理单元，用于对加固安装包文件进行重新签名，生成apk最终安装包文件，所述apk最终安装包文件即为android打包文件。
可选地，还包括：第七处理模块，用于根据ios打包文件和android打包文件生成二维码；第八处理模块，用于根据软件测试需求将二维码发送至软件测试方，以使软件测试方根据二维码下载对应的app软件并对app软件进行功能测试。
可选地，还包括：第九处理模块，用于接收软件测试方反馈的功能测试结果；第十处理模块，用于若所述功能测试结果为功能测试通过，则将ios打包文件和android打包文件进行存储；第十一处理模块，用于若所述功能测试结果为功能测试不通过，则对ios项目代码和android项目代码进行修复，并将修复后的ios项目代码和android项目代码重新打包。
根据第三方面，本发明实施例提供了一种电子设备，包括：至少一个处理器；以及与至少一个处理器通信连接的存储器；其中，存储器存储有可被至少一个处理器执行的计算机程序，计算机程序被至少一个处理器执行，以使至少一个处理器执行上述第一方面任意一项描述的移动端app自动打包方法。
根据第四方面，本发明实施例提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机指令，计算机指令用于使计算机执行上述第一方面任意一项描述的移动端app自动打包方法。
本发明实施例技术方案，具有如下优点：
本发明实施例提供了一种移动端app自动打包方法、系统、电子设备及存储介质，其中，该方法包括：获取不同渠道移动端app的参数配置，所述参数配置包括app的基本信息和高级设置信息；根据参数配置在多渠道配置管理后台中进行移动端app参数的配置，得到每一个渠道的配置信息；将所有渠道的配置信息通过接口发送至打包服务器；启动打包脚本，解析接口中的配置信息，将检测出的对应ios通用代码和android通用代码发送至打包服务器；将配置信息同步到对应的ios通用代码和android通用代码中，得到ios项目代码和android项目代码；对ios项目代码进行打包操作，生成ios打包文件；对android项目代码进行打包操作，生成android打包文件。上述步骤将不同渠道移动端app的参数配置通过多渠道管理后台进行配置后得到每一个渠道的配置信息，根据配置信息确定每一个渠道所对应的通用代码，将配置信息更新至对应的通用代码中得到对应的项目代码，将项目代码进行打包，实现了自动化打包，很大程度的节省人员成本，减少开发人员重复工作，提高app多渠道打包发布的效率，并且不易出错。
附图说明
为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本发明实施例的移动端app自动打包方法的一个具体示例的流程图；
图2为本发明实施例的移动端app自动打包方法的另一个具体示例的流程图；
图3为本发明实施例的移动端app自动打包系统的一个具体示例的框图；
图4为本发明实施例的电子设备的示意图。
具体实施方式
下面将结合附图对本发明的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
本发明实施例提供了一种移动端app自动打包方法，如图1所示，该方法包括步骤s1-s7。
步骤s1：获取不同渠道移动端app的参数配置，所述参数配置包括app的基本信息和高级设置信息。
本实施例中，不同渠道指的是不同的应用市场或者不同代理商。本实施例中，不同渠道可以是360应用市场、华为应用市场、小米应用市场、苹果商店等；本实施例对不同渠道仅作示意性说明，不以此为限，在实际应用中，还可以为其它渠道。移动端app包括ios系统app和安卓系统app。
步骤s2：根据参数配置在多渠道配置管理后台中进行移动端app参数的配置，得到每一个渠道的配置信息。
步骤s3：将所有渠道的配置信息通过接口发送至打包服务器。
本实施例中，将配置信息中的非文本信息在配置的时候同步至打包服务器本地，并存储至打包服务器本地，以便使得打包服务器的打包操作更加便捷，无需对非文本数据进行处理。非文本信息可以是图片资源文件和图片格式的数据(如应用图标)。配置信息中的其它文本类信息则以二进制的形式存储至多渠道配置管理后台的数据库中。当然，在其它实施例中，也可将所有的配置信息均存储在数据库中，由于数据库需要以二进制的形式进行存储，故需要对配置信息中的非文本数据进行转换，将转换后得到的二进制数据存储至数据库。
在多渠道配置管理后台中启动打包操作，向打包服务器请求打包接口(app_server/build)，将各个渠道的配置信息以json格式发送到打包服务器，接口中包含渠道的基本信息和高级设置的配置信息。
步骤s4：启动打包脚本，解析接口中的配置信息，将检测出的对应ios通用代码和android通用代码发送至打包服务器。
本实施例中，启动打包脚本，打包脚本具体可以是phthon脚本，也可以是其它脚本，本实施例对此仅作示意性描述，不以此为限。具体地，打包脚本中包含多个不同系统不同版本的脚本，例如，ios系统1.0版本打包脚本、ios系统2.0版本打包脚本、android系统1.0版本打包脚本、android系统2.0版本打包脚本等。
配置信息中包括app所属系统和应用版本号信息，解析出接口中的配置信息，便可得到渠道所对应的通用代码。例如，某一个渠道的移动端app是应用于ios系统的app，应用版本号是2.0，那么，检测出的该渠道所对应的打包脚本是ios系统2.0版本打包脚本，从而得到该渠道所对应的ios通用代码。又例如，另一个渠道的移动端app是应用于android系统的app，根据该渠道的配置信息得到该渠道所对应的android通用代码。通过该步骤，便可得到所有渠道中每一个渠道所对应的通用代码。之后，将检测出的对应ios通用代码和android通用代码发送至打包服务器。
步骤s5：将配置信息同步到对应的ios通用代码和android通用代码中，得到ios项目代码和android项目代码。
本实施例中，将配置信息同步到对应的ios通用代码和android通用代码中，也就是将配置信息中的具体信息替换到通用代码中，更新替换对应的配置信息和图片资源文件后，得到每一个配置信息所对应的项目代码。例如，某一个渠道移动端app是ios系统的app，将该渠道移动端所对应的配置信息同步修改ios通用代码后得到对应的ios项目代码。又例如，另一个渠道移动端app是android系统的app，将该渠道移动端所对应的配置信息同步修改android通用代码后得到对应的android项目代码。
步骤s6：对ios项目代码进行打包操作，生成ios打包文件。
本实施例中，ios资源替换后，执行打包操作，编译ios代码生成ipa安装包文件，ipa安装包文件即为生成的ios打包文件。
步骤s7：对android项目代码进行打包操作，生成android打包文件。
本实施例中，android资源替换后，执行打包操作，编译android代码生成apk安装包文件，因为android是开源的，为防止反编译安装包，使用比较权威的第三方加固工具360加固，加固后重新签名生成最终的apk安装包文件，最终的apk安装包文件即为生成的android打包文件。
上述步骤将不同渠道移动端app的参数配置通过多渠道管理后台进行配置后得到每一个渠道的配置信息，根据配置信息确定每一个渠道所对应的通用代码，将配置信息更新至对应的通用代码中得到对应的项目代码，将项目代码进行打包，实现了自动化打包，很大程度的节省人员成本，减少开发人员重复工作，提高了app多渠道打包发布的效率，并且不易出错。
作为示例性的实施例，步骤s3将所有渠道的配置信息通过接口发送至打包服务器的步骤中，包括步骤s31-s34。
步骤s31：启动多渠道配置管理后台中的启动打包操作，并向打包服务器请求打包接口。
本实施例中，阶段性的开发完成后，官网版本正式发布，会自动触发多渠道配置管理后台中打包操作，多渠道配置管理后台请求打包接口(app_server/build)。
步骤s32：通过打包接口将各个渠道的配置信息以json格式发送至打包服务器。
本实施例中，先将所有渠道中各个渠道的配置信息处理为json格式的数据，然后，通过打包接口将json格式的数据发送至打包服务器。配置信息的json格式如下所示。
{"ios_code_path":"ios代码路径","android_code_path":"android代码路径","app_version":{"environment":"m3","android":"3.7.4.1","ios":"3.7.4.1"},"job_id":1614665369,"package_list":{"9978":{"platform":"113","app_share_info":{"app_key_qq_android":"9bwbgil4mhuwi0j7","app_id_weixin":"wx74e0828ca71e995d","app_key_qq":"9bwbgil4mhuwi0j7","app_secret_weixin":"c524fbea84a2d0db021eec4f5f1363bd","app_id_qq":"1108047225","app_id_qq_android":"1108047225"},"app_name":"应用名称"}}}
上述步骤通过打包接口将各个渠道的配置信息以json格式发送至打包服务器，以便打包服务器根据各个渠道的配置信息得到相应的项目代码并进行打包操作。
作为示例性的实施例，步骤s4启动打包脚本，解析接口中的配置信息，将检测出的对应ios通用代码和android通用代码发送至打包服务器的步骤中，包括步骤s41-s43。
步骤s41：启动打包脚本，解析接口中的配置信息，根据预先约定的数据解析协议获取打包代码的地址，协议的具体内容：返回值为json格式，直接通过键值对去解析，获取对应的key中的value。
打包服务器接收到打包请求后自动执行打包脚本，解析接口请求中的配置信息，根据约定好的数据解析协议(json解析)获取打包代码的地址。
步骤s42：根据打包代码的地址对应的从gitlab或者svn中下载需要打包的ios通用代码和android通用代码。
具体的，git和svn都是一种版本控制系统，gitlab是一种分布式版本控制，svn是一种集中式版本控制。
gitlab是一个用于仓库管理系统的开源项目，使用git作为代码管理工具，并在此基础上搭建起来的web服务。
本实施例中的各种通用代码根据实际应用的需要可以存储至gitlab中，也可以存储至svn中。根据打包代码的地址可以确定通用代码，进而从从gitlab或者svn中下载对应的通用代码。
步骤s43：将ios通用代码和android通用代码发送至打包服务器。
具体的，将检出需要打包的ios和android通用代码发送到打包服务器，并存储至打包服务器的本地。
上述步骤，根据打包代码的地址确定需要打包的ios通用代码和android通用代码，并将ios通用代码和android通用代码发送至打包服务器，以便打包服务器将配置信息更新至相应的通用代码中得到不同渠道app的项目代码，实现了项目代码的自动生成。
作为示例性的实施例，步骤s7对android项目代码进行打包操作，生成android打包文件的步骤中，包括步骤s71-s73。
步骤s71：对android项目代码进行打包操作，使用命令(gradlewassemblerelease)编译android代码生成apk初始安装包文件。
步骤s72：将apk初始安装包文件进行加固，得到加固安装包文件。目前公司使用的是比较权威的第三方加固工具360加固对apk初始安装包文件进行加固，得到加固安装包文件。第三方加固工具可以是360加固，也可以使用爱加密等其它加固工具，在实际应用中根据需要合理确定加固工具。加固的具体命令：
1、java-jarjiagu.jar-login帐号密码(配置加固的帐号信息)
2、java-jarjiagu.jar-importsign签名路径签名密码别名别名密码(配置加固的签名信息)
3、java-jarjiagu.jar-config-x86(配置支持x86)
4、java-jarjiagu.jar初始安装文件路径-autosign(配置自动签名)
步骤s73：加固后对生成的安装包文件进行重新签名，生成apk最终安装包文件，所述apk最终安装包文件即为android打包文件。
本实施例中，对加固安装包文件进行重新签名，重新签名的具体过程是利用360加固自带的签名工具进行签名。签名后生成apk最终安装包文件，这个apk最终安装包文件即为android打包文件。
上述步骤，使用比较权威的第三方加固工具360加固，加固后重新签名生成最终的apk安装包文件，防止反编译安装包，提高了安装包的安全性。
作为示例性的实施例，步骤s7对android项目代码进行打包操作，生成android打包文件的步骤之后，还包括步骤s8-s9。
步骤s8：根据ios打包文件和android打包文件生成二维码。
本实施例中，将ios打包文件和android打包文件上传至移动应用内测分发服务平台生成供测试下载扫描的二维码，以使软件测试方根据二维码下载软件安装包，进行软件测试。
具体的，移动应用内测分发服务平台可以是蒲公英、乐分发等平台，本实施例对此仅作示意性描述，不以此为限。
步骤s9：根据软件测试需求将二维码发送至软件测试方，以使软件测试方根据二维码下载对应的app软件并对app软件进行功能测试。
本实施例中，软件测试需求包括软件测试方的名称。将二维码发送至软件测试方，软件测试方接收到二维码之后，扫描二维码便可下载软软件安装包，将软件安装包进行安装，软件安装好后，根据产品需求进行功能测试。
上述步骤通过二维码的方式将打包文件发送至软件测试方，使得软件下载更加简单便捷。
作为示例性的实施例，步骤s9根据软件测试需求将二维码发送至软件测试方的步骤之后，还包括步骤s10-s12。
步骤s10：接收软件测试方反馈的功能测试结果。
本实施例中，软件测试方根据产品需求进行功能测试，得到功能测试结果。若功能测试合格，则功能测试结果为通过，执行步骤s11；若功能测试不合格，则功能测试结果为不通过，执行步骤s12。软件测试方反馈功能测试结果，打包服务器接收软件测试方反馈的功能测试结果。
步骤s11：若所述功能测试结果为功能测试通过，则将ios打包文件和android打包文件进行存储。
本实施例中，功能测试结果为功能测试通过，则无需对代码进行修改，ios打包文件和android打包文件即可作为最终的打包文件。
步骤s12：若所述功能测试结果为功能测试不通过，则对ios项目代码和android项目代码进行修复，并将修复后的ios项目代码和android项目代码重新打包。
本实施例中，功能测试结果为不通过，则需要对代码进行修改，将修复后的ios项目代码和android项目代码进行重新打包，打包完成后再次发送至软件测试方进行功能测试，直至功能测试通过。功能测试通过后还需要进行系统测试；系统测试通过后，多渠道配置管理后台中一键发布，将文件同步到对应的代理商的下载服务器,另外备份一份到服务器，以备不时之需。
通过上述步骤对打包文件中的项目代码进行功能测试，保证项目代码的正确性。
下面以一个具体示例进行详细说明，如图2所示。
app自动化打包主要分为两个部分，包括：
a、基本信息：应用名称、应用图标、应用包名、应用版本号，启动页、引导页和其他图片资源文件；
c、图片资源文件在编辑配置的时候同步到打包服务器本地，供自动打包时使用，其他配置信息保存到数据库中。
自动化打包流程分为以下几部分，包括：
b、阶段性的开发完成后，官网版本正式发布，会自动触发多渠道配置管理后台中打包操作，多渠道配置管理后台请求打包接口(app_server/build)，将各个渠道的配置信息以json格式(下图所示)发送到打包服务器，接口中的包含渠道的基本信息和高级设置的配置信息；
c、打包服务器接收到打包请求后自动执行打包脚本，解析接口请求中的配置信息，根据约定好的数据解析协议(json解析)获取打包代码的地址，对应的从gitlab或者svn中检出需要打包的ios和android两端的打包代码到打包服务器的本地存储；
d、根据解析到的基本信息和高级设置等配置信息，自动同步修改ios和android各自的打包代码，更新替换对应的配置信息和图片资源文件，完成各自待打包的项目代码；
e、脚本自动执行打包操作，使用ios待打包的项目代码编译生成ipa安装包文件；
f、脚本自动执行打包操作，使用android待打包的项目代码编译android代码生成apk安装包文件，因为android是开源的，为防止反编译安装包，使用比较权威的第三方加固工具360加固，加固后重新签名生成最终的apk安装包文件；
h、系统测试通过后，多渠道配置管理后台中一键发布，将文件同步到对应的代理商的下载服务器,另外备份一份到服务器，以备不时之需。
在本实施例中还提供了一种移动端app自动打包系统，该系统用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的系统较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。
本实施例还提供一种移动端app自动打包系统，如图3所示，包括：
获取模块1，用于获取不同渠道移动端app的参数配置，所述参数配置包括app的基本信息和高级设置信息；
第一处理模块2，用于根据参数配置在多渠道配置管理后台中进行移动端app参数的配置，得到每一个渠道的配置信息；
第二处理模块3，用于将所有渠道的配置信息通过接口发送至打包服务器；
第三处理模块4，用于启动打包脚本，解析接口中的配置信息，将检测出的对应ios通用代码和android通用代码发送至打包服务器；
第四处理模块5，用于将配置信息同步到对应的ios通用代码和android通用代码中，得到ios项目代码和android项目代码；
第五处理模块6，用于对ios项目代码进行打包操作，生成ios打包文件；
第六处理模块7，用于对android项目代码进行打包操作，生成android打包文件。
本实施例中的移动端app自动打包系统是以功能单元的形式来呈现，这里的单元是指asic电路，执行一个或多个软件或固定程序的处理器和存储器，和/或其他可以提供上述功能的器件。
上述各个模块的更进一步的功能描述与上述对应实施例相同，在此不再赘述。
本发明实施例还提供了一种电子设备，如图4所示，该电子设备包括一个或多个处理器71以及存储器72，图4中以一个处理器71为例。
该控制器还可以包括：输入装置73和输出装置74。
处理器71、存储器72、输入装置73和输出装置74可以通过总线或者其他方式连接，图4中以通过总线连接为例。
处理器71可以为中央处理器(centralprocessingunit，cpu)。处理器71还可以为其他通用处理器、数字信号处理器(digitalsignalprocessor，dsp)、专用集成电路(applicationspecificintegratedcircuit，asic)、现场可编程门阵列(field-programmablegatearray，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等芯片，或者上述各类芯片的组合。通用处理器可以是微处理器或者是任何常规的处理器等。
存储器72作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序、非暂态计算机可执行程序以及模块，如本申请实施例中的移动端app自动打包方法对应的程序指令/模块。处理器71通过运行存储在存储器72中的非暂态软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例的移动端app自动打包方法。
存储器72可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据服务器操作的处理装置的使用所创建的数据等。此外，存储器72可以包括高速随机存取存储器，还可以包括非暂态存储器，例如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施例中，存储器72可选包括相对于处理器71远程设置的存储器，这些远程存储器可以通过网络连接至网络连接装置。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
输入装置73可接收输入的数字或字符信息，以及产生与服务器的处理装置的用户设置以及功能控制有关的键信号输入。输出装置74可包括显示屏等显示设备。
一个或者多个模块存储在存储器72中，当被一个或者多个处理器71执行时，执行如图1-2所示的方法。
虽然结合附图描述了本发明的实施方式，但是本领域技术人员可以在不脱离本发明的精神和范围的情况下作出各种修改和变型，这样的修改和变型均落入由所附权利要求所限定的范围之内。