发明内容
本申请旨在至少解决现有技术中存在的技术问题之一。为此,本申请提出一种应用程序打包方法、电子设备及存储介质,根据预设应用类型提供不同的打包功能,并且无需用户安装配置环境。
根据本申请的第一方面实施例的应用程序打包方法,包括:
配置生成应用工程;
对所述应用工程进行编译处理,生成资源包信息;
根据所述应用工程和预设的应用类型获取打包配置;
根据所述打包配置将所述资源包信息上传至对应的服务器进行打包,生成对应的应用程序。
根据本申请实施例的应用程序打包方法,至少具有如下有益效果:
配置生成应用工程,对应用工程进行编译处理,生成资源包信息;根据应用工程和预设的应用类型获取打包配置;根据打包配置将资源包信息上传至对应的服务器进行打包,生成对应的应用程序。本申请实施例通过对应用工程进行编译,生成资源包信息,无需用户安装配置环境,通过应用工程和预设的应用类型获取打包配置,提供不同的打包功能。
根据本申请的一些实施例,所述根据所述打包配置将所述资源包信息上传至对应的服务器进行打包,生成对应的应用程序,包括:
根据所述应用类型,生成与所述应用类型的对应的打包配置,并且得到与所述打包配置对应的所述服务器;
将所述打包配置和所述资源包信息发送至对应的所述服务器,由所述服务器根据所述打包配置获取打包脚本;
获取所述服务器生成的应用程序,所述应用程序由所述服务器根据所述打包脚本对所述资源包信息打包生成。
根据本申请的一些实施例,所述方法还包括:
获取所述服务器生成的打包日志;
基于所述打包日志查询所述应用程序的打包进度。
根据本申请的一些实施例,所述资源包信息包括:插件信息;
对应的,所述方法还包括:
将预添加的第一插件配置到所述插件信息中,并更新所述打包配置,其中所述第一插件从预设插件库中获取。
根据本申请的一些实施例,所述方法还包括:
获取预删除的第二插件的标识信息;
根据所述标识信息判断所述插件信息是否存在所述第二插件;
若存在,则从所述插件信息中删除所述第二插件,并更新所述打包配置。
根据本申请的一些实施例,所述方法还包括:
获取所述应用程序的配置地址;
根据所述配置地址,生成配置文件;
对所述配置文件的正确性进行校验得到校验结果;
若所述校验结果为正确,根据所述配置文件对所述资源包信息进行更新,得到更新后的所述资源包信息;
根据所述打包配置将更新后的所述资源包信息上传至对应的服务器进行打包,生成更新的应用程序。
根据本申请的一些实施例,所述资源包信息包括页面信息;
对应的,所述方法还包括:
根据所述打包配置将所述页面信息上传至对应的服务器进行打包,生成对应的应用程序。
根据本申请的一些实施例,所述方法还包括:
通过重新编译处理所述应用工程,对所述资源包信息进行更新,得到更新后的资源包信息;
根据所述更新后的资源包信息对所述应用程序进行热更新。
根据本申请的第二方面实施例的电子设备,包括:
至少一个处理器,以及,
与所述至少一个处理器通信连接的存储器;其中,
所述存储器存储有指令,所述指令被所述至少一个处理器执行,以使所述至少一个处理器执行所述指令时实现如本申请第一方面实施例任一项所述的应用程序打包方法。
根据本申请实施例的电子设备,至少具有如下有益效果:通过执行如第一方面实施例所述的应用程序打包方法,配置生成应用工程,对应用工程进行编译处理,生成资源包信息;根据应用工程和预设的应用类型获取打包配置;根据打包配置将资源包信息上传至对应的服务器进行打包,生成对应的应用程序。本申请实施例通过对应用工程进行编译,生成资源包信息,无需用户安装配置环境,通过应用工程和预设的应用类型获取打包配置,提供不同的打包功能。
根据本申请的第三方面实施例的计算机可读存储介质,包括:
所述计算机可读存储介质存储有计算机可执行指令,所述计算机可执行指令用于执行如本申请第一方面实施例所述的应用程序打包方法。
根据本申请实施例的计算机可读存储指令,至少具有如下有益效果:通过执行如第一方面实施例所述的应用程序打包方法,配置生成应用工程,对应用工程进行编译处理,生成资源包信息;根据应用工程和预设的应用类型获取打包配置;根据打包配置将资源包信息上传至对应的服务器进行打包,生成对应的应用程序。本申请实施例通过对应用工程进行编译,生成资源包信息,无需用户安装配置环境,通过应用工程和预设的应用类型获取打包配置,提供不同的打包功能。
本申请的附加方面和优点将在下面的描述中部分给出,部分将从下面的描述中变得明显,或通过本申请的实践了解到。
具体实施方式
下面详细描述本申请的实施例,实施例的示例在附图中示出,其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的,仅用于解释本申请,而不能理解为对本申请的限制。
在本申请的描述中,若干的含义是一个或者多个,多个的含义是两个以上,大于、小于、超过等理解为不包括本数,以上、以下、以内等理解为包括本数。如果有描述到第一、第二只是用于区分技术特征为目的,而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量或者隐含指明所指示的技术特征的先后关系。
本申请的描述中,参考术语“一个实施例”、“一些实施例”、“示意性实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中,对上述术语的示意性表述不一定指的是相同的实施例或示例。而且,描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。
目前,对于前后端分离的项目来说,前端项目工程化搭建、应用程序打包环境搭建是项目开发过程中必不可少的环节。前端工程化对于大部分开发者来说并不友好,需要用户自己安装配置环境。
为此,本申请提出一种应用程序打包方法、电子设备及存储介质,能够配置生成应用工程,对应用工程进行编译处理,生成资源包信息;根据应用工程和预设的应用类型获取打包配置;根据打包配置将资源包信息上传至对应的服务器进行打包,生成对应的应用程序。本申请实施例通过对应用工程进行编译,生成资源包信息,无需用户安装配置环境,通过应用工程和预设的应用类型获取打包配置,提供不同的打包功能。
第一方面,本申请实施例提供了一种应用程序打包方法。
首先,本申请实施例提供了一种打包工具,该工具完成从项目搭建到项目完成并且将应用程序进行打包的过程。首先本申请实施例的打包工具可以采取命令行的方式,通过对用户在控制台输入的参数,执行不同的命令。比如,用户可以向控制台输入创建工程命令、打包命令和调试命令,打包工具通过从控制台接收到用户输入的参数来执行对应命令的操作。
参照图1,图1为本申请一些实施例提供的应用程序打包方法的流程图,具体包括步骤:
S100,配置生成应用工程;
S200,对应用工程进行编译处理,生成资源包信息;
S300,根据应用工程和预设的应用类型获取打包配置;
S400,根据打包配置将资源包信息上传至对应的服务器进行打包,生成对应的应用程序。
在步骤S100中,用户向控制台输入创建工程命令,这里的创建工程命令指的是在本地需要创建相应的项目工程,打包工具基于标准的工程模板,对用户的输入参数进行收集处理,通过文件读写的方式完成对项目工程的配置。其中采用文件读写的方式表示根据不同的项目需求对项目工程的配置,并且生成应用工程。
在步骤S200中,对上述创建的项目工程进行编译处理,生成资源包信息,这里的资源包信息指的是应用程序所需要的页面信息以及插件信息。页面信息指的是应用程序中显示页面的所有资源,而插件信息用于根据实际需求调用应用程序的一些原生能力,从而实现应用程序的某些功能。本申请实施例可借助前端工程化工具webpack,对应用工程进行编译。
在步骤S300中,根据应用工程和预设的应用类型获取打包配置,这里具体的操作平台包括Android和ios。用户选择对应操作平台后,打包工具会在工程目录生成对应平台的打包配置。通过应用工程和预设的应用类型获取打包配置,提供不同的打包功能,满足不同操作平台用户的打包需求。
在步骤S400中,需要说明的是,这里的资源包信息指的是应用程序所需要的页面信息以及插件信息。将页面信息和插件信息上传至对应的服务器进行应用程序打包,打包完成后生成对应的下载链接,用户点击下载链接就可以下载相应的应用程序。需要说明的是,这里的页面信息可以通过模拟的应用程序的页面上获取。
在一些实施例中,如图7所示,项目工程创建的应用流程为:首先用户可以输出初始化工程命令,这里利用到了poros-devtools工具,也就是一款开发工具,其中poros-devtools工具用于对项目工程进行调试,然后gitlab验证用户信息,其中gitlab是一种项目管理和代码托管工具,用于提高代码撰写的效率,poros-devtools工具从gitlab获取项目工程下载的具体地址,并且下载到打包工具的临时目录中,用户根据具体的问题输入工程配置,然后创建工程项目。
在一些实施例中,如图8所示,应用程序打包方法的应用实例为:首先通过打包工具创建h5工程,也就是创建网页工程,然后通过h5工程生成h5应用发布包,也就是打包配置,构建原生应用至h5容器(包括ios和Android平台),将h5应用发布包上传至Jenkins并结合h5容器生成APP,也就是应用程序,接着将APP上传至升级服务模块,用于后续对APP进行更新,用户可以根据下载链接下载对应的APP,其中下载链接可以是二维码的形式,用户通过扫描二维码就可以下载APP并且可以对APP进行更新。其中,Jenkins是一个开源软件项目,是基于Java开发的一种持续集成工具,用于监控持续重复的工作,旨在提供一个开放易用的软件平台,使软件的持续集成变成可能。
在一些实施例中,如图2所示,步骤S400具体包括步骤:
S410,根据应用类型,生成与应用类型的对应的打包配置,并且得到与打包配置对应的服务器;
S420,将打包配置和资源包信息发送至对应的服务器,由服务器根据打包配置获取打包脚本;
S430,获取服务器生成的应用程序,应用程序由服务器根据打包脚本对资源包信息打包生成。
在步骤S410中,用户选择不同的操作平台,比如ios或Android,打包后也会生成不同的应用类型,根据不同的应用类型生成与应用类型对应的打包配置,并且得到对应的服务器。
在步骤S420中,将之前得到的打包配置和资源包信息发送至对应的服务器上,由服务器根据打包配置获取打包脚本。
在步骤S430中,服务器根据打包脚本对资源包信息打包生成对应的应用程序。
在一些实施例中,如图3所示,步骤S400具体还包括步骤:
S440,获取服务器生成的打包日志;
S450,基于打包日志查询应用程序的打包进度。
在步骤S440中,服务器在打包过程中会生成一个打包日志,用于记录打包过程中的打包数据。
在步骤S450中,打包工具可以根据打包日志查询应用程序的打包进度,还可以根据打包日志对代码进行调试。
在一些实施例中,如图9所示,跨平台打包的应用流程为:
首先由开发者也就是用户输入打包命令,由终端构建APP资源,并上传至Jenkins,由打包服务器根据打包配置执行打包脚本,并且输出打包日志,终端可以实时查询打包的进度,比如可以通过打包进度条的方式获取打包的进度,在打包过程中,可以不断向终端反馈打包的数据,并且收到打包完成的通知,打包完成后会生成一个下载链接,用户可以点击下载链接对应用程序进行下载安装。
在一些实施例中,资源包信息包括插件信息,本申请实施例中提到的应用程序打包方法具体还包括:将预添加的第一插件配置到插件信息中,并更新打包配置,其中第一插件从预设插件库中获取。其中预设插件库可以从插件服务器上下载,第一插件就是从预设插件库中获取的。具体为:打包工具会根据用户添加插件的名字,自动下载插件服务器上的插件,并且删除本地插件目录,同时修改对应的打包插件配置。
在一些实施例中,如图4所示,本申请实施例中提到的应用程序打包方法具体还包括步骤:
S500,获取预删除的第二插件的标识信息;
S600,根据标识信息判断插件信息是否存在第二插件;
S700,若存在,则从插件信息中删除第二插件,并更新打包配置。
在步骤S500中,获取需要删除的第二插件的标识信息,比如可以是第二插件的类型或者第二插件的名称,其中第二插件表示用户需要删除的插件。
在步骤S600中,根据标识信息判断插件信息中是否存在需要删除的第二插件;
在步骤S700中,如果存在,就从插件信息中删除第二插件,然后更新打包配置。
在一些实施例中,若插件信息中不存在第二插件,那么就不能从插件信息中删除第二插件,这时可以提示用户不存在该插件,删除插件失败。
在一些实施例中,如图10所示,选择需要添加或者删除的插件,如果选择添加插件,那么就将需要添加的插件写在到项目工程中,并且写入工程配置;如果选择删除插件,那么就需要判断是否存在需要删除的插件,如果存在,就删除插件以及配置,如果不存在,就发送提示信息,用于提示用户删除插件失败。
在一些实施例中,如图5所示,本申请实施例中提到的应用程序打包方法具体还包括步骤:
S800,获取应用程序的配置地址;
S900,根据配置地址,生成配置文件;
S1000,对配置文件的正确性进行校验得到校验结果;
S1100,若校验结果为正确,根据配置文件对资源包信息进行更新,得到更新后的资源包信息;
S1200,根据打包配置将更新后的资源包信息上传至对应的服务器进行打包,生成更新的应用程序。
在步骤S800中,获取应用程序的配置地址,这里的配置地址指的是h5地址,也就是应用程序的首页地址。
在步骤S900中,根据应用程序的首页地址,获取应用程序页面中的配置文件,也就包括应用程序的页面资源以及插件资源等。
在步骤S1000中,对配置文件进行校验,判断配置文件是否正常;
在步骤S1100中,如果校验到的结果为正常,那么就根据配置文件对资源包信息进行更新,得到更新后的资源包信息;如果校验到的结果不正常,那么就不能对资源包进行更新,此时可以提示用户更新失败。
在步骤S1200中,根据打包配置将更新后的资源包信息上传至对应的服务器进行打包,生成更新的应用程序,这里可以利用前端工程化工具webpack,实现对代码动态编译以及对页面的同步更新。
在一些实施例中,如图11所示,Debug动态调试,也就是计算机排除故障过程为:
输入在线的h5地址,也就是应用程序的首页地址,校验应用程序的配置文件,如果校验成功,则说明配置文件正常,这时就上传到Jenkins并根据配置构建插件资源,构建插件资源过程中可以实时查询构建进度,如果打包完成就生成下载地址,并且根据下载地址下载应用程序。如果配置文件校验错误,则说明配置文件异常,这时就不能对应用程序进行打包。如果在查询进度的时候得到的反馈是打包未完成,则可以等待一定的时间,比如2秒,然后再次查询打包进度。
在一些实施例中,资源包信息包括页面信息,本申请实施例中提到的应用程序打包方法具体还包括:根据打包配置将页面信息上传至对应的服务器进行打包,生成对应的应用程序。本申请实施例包括在线模式和离线模式,如果选择在线模式,打包的资源中不会包含页面信息,将这些页面信息上传到另一台服务器上,比如在线的业务服务器,并不是直接嵌入在打包的应用程序中。应用程序中包括有h5容器,在打开应用程序时,h5容器会跳转到在线的h5应用地址,这样就能节省打包的资源。如果选择离线模式,打包的资源中同时包含页面信息和插件信息,在打开应用程序时,可以通过打包的资源直接获取到页面信息,不需要访问网络。本申请实施例的在线模式和离线模式可以根据实际的需求进行选择,提高用户的体验。
在一些实施例中,如图6所示,本申请实施例中提到的应用程序打包方法具体还包括步骤:
S1300,通过重新编译处理应用工程,对资源包信息进行更新,得到更新后的资源包信息;
S1400,根据更新后的资源包信息对应用程序进行热更新。
在步骤S1300中,在下载完应用程序后,如果想对应用程序进行更新,可以开启Debug模式,这时客户端的应用程序会和本地电脑建立socket连接,本地工程的改动会实时通知到应用程序中,从而达到动态调试的效果。具体为,本地工程对代码重新编译,重新编译后资源包就会更新,得到更新后的资源包信息。
在步骤S1400中,根据更新后的资源包信息对页面进行热更新,也就是局部更新,本申请实施例在工程代码进行改动时,只在客户端应用程序只更新工程代码修改的部分信息,不用一次性更新,减少更新时间,从而提高应用程序更新的效率。
在一些实施例中,如图12所示,Debug动态调试,也就是计算机排除故障过程还可以为:
用户在本地工程修改代码,由webpack工具编译更新h5应用,由webpack工具通过socket通知webview组件,其中webview是安卓和ios内置的浏览器组件,可以解析DOM元素并且展示html页面的控件。然后由webpack热更新h5应用,也就是针对用户修改部分的代码对h5应用进行局部更新。
在本申请实施例中,配置生成应用工程,对应用工程进行编译处理,生成资源包信息;根据应用工程和预设的应用类型获取打包配置;根据打包配置将资源包信息上传至对应的服务器进行打包,生成对应的应用程序。本申请实施例通过对应用工程进行编译,生成资源包信息,无需用户安装配置环境,通过应用工程和预设的应用类型获取打包配置,提供不同的打包功能。
第二方面,本申请实施例还提供了一种电子设备。
在一些实施例中,电子设备包括:至少一个处理器,以及与至少一个处理器通信连接的存储器;其中,存储器存储有指令,指令被至少一个处理器执行,以使至少一个处理器执行指令时实现本申请实施例中任一项应用程序打包方法。
处理器和存储器可以通过总线或者其他方式连接。
存储器作为一种非暂态计算机可读存储介质,可用于存储非暂态软件程序以及非暂态性计算机可执行程序,如本申请实施例描述的应用程序打包方法。处理器通过运行存储在存储器中的非暂态软件程序以及指令,从而实现上述的应用程序打包方法。
存储器可以包括存储程序区和存储数据区,其中,存储程序区可存储操作***、至少一个功能所需要的应用程序;存储数据区可存储执行上述应用程序打包方法。此外,存储器可以包括高速随机存取存储器,还可以包括非暂态存储器,比如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施方式中,存储器可选包括相对于处理器远程设置的存储器,这些远程存储器可以通过网络连接至该处理器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
实现上述的应用程序打包方法所需的非暂态软件程序以及指令存储在存储器中,当被一个或者多个处理器执行时,执行上述第一方面实施例中提到的应用程序打包方法。
第三方面,本申请实施例还提供了计算机可读存储介质。
在一些实施例中,计算机可读存储介质存储有计算机可执行指令,计算机可执行指令用于执行第一方面实施例中提到的应用程序打包方法。
在一些实施例中,该存储介质存储有计算机可执行指令,该计算机可执行指令被一个或多个控制处理器执行,比如,被上述电子设备中的一个处理器执行,可使得上述一个或多个处理器执行上述应用程序打包方法。
以上所描述的装置实施例仅仅是示意性的,其中作为分离部件说明的单元可以是或者也可以不是物理上分开的,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。
本领域普通技术人员可以理解,上文中所公开方法中的全部或某些步骤、***可以被实施为软件、固件、硬件及其适当的组合。某些物理组件或所有物理组件可以被实施为由处理器,如中央处理器、数字信号处理器或微处理器执行的软件,或者被实施为硬件,或者被实施为集成电路,如专用集成电路。这样的软件可以分布在计算机可读介质上,计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的,术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外,本领域普通技术人员公知的是,通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据,并且可包括任何信息递送介质。
上面结合附图对本申请实施例作了详细说明,但是本申请不限于上述实施例,在所属技术领域普通技术人员所具备的知识范围内,还可以在不脱离本申请宗旨的前提下作出各种变化。此外,在不冲突的情况下,本申请的实施例及实施例中的特征可以相互组合。