CN114443087A - 程序生成方法、装置、终端设备及计算机可读存储介质 - Google Patents

Abstract

本申请适用于计算机技术领域，提供了一种程序生成方法、装置、终端设备及计算机可读存储介质，包括：监测打包命令；根据所述打包命令的类型从配置文件中获取目标对象；根据获取到的目标对象生成所述打包命令的类型对应版本的打包文件。通过上述方法，可以有效降低程序维护成本，提高小程序的更新效率。

Description

程序生成方法、装置、终端设备及计算机可读存储介质

技术领域

本申请属于计算机技术领域，尤其涉及一种程序生成方法、装置、终端设备及计算机可读存储介质。

背景技术

在A应用当中，存在不需要下载安装即可使用的B应用，那么将A应用中的B应用称为小程序。随着电商模式的发展，小程序的类型越来越丰富，且需要对小程序进行不断地升级和更新。小程序的版本发布涉及不同类别的用户。例如，根据是否开通直播功能将用户分为两类，一类用户开通了直播功能，另一类用户未开通直播功能。

现有技术中，需要为不同类别的用户分别开发不同版本的小程序，这就需要维护多套程序代码。随着小程序的不断升级和更新，现有的这种方式，程序维护成本较高，降低了小程序的更新效率。

发明内容

本申请实施例提供了一种程序生成方法、装置、终端设备及计算机可读存储介质，可以有效降低程序维护成本，提高小程序的更新效率。

第一方面，本申请实施例提供了一种程序生成方法，包括：

监测打包命令；

根据所述打包命令的类型从配置文件中获取目标对象；

根据获取到的目标对象生成所述打包命令的类型对应版本的打包文件。

在本申请实施例中，根据打包命令的类型从配置文件中获取目标对象，再根据获取到的目标对象生成打包命令的类型对应版本的打包文件，相当于通过命令行识别待打包程序的版本类型。可以在配置文件中定义不同的对象，将不同版本所需的对象隔离开来，通过打包命令识别版本类型，进而获取所需的对象。通过上述方法，无需开发不同版本的程序，只需维护一套代码，即可根据打包命令的类型打包成不同版本的程序。有效降低了程序的维护成本，提高了小程序的更新效率。

在第一方面的一种可能的实现方式中，所述打包命令中包括环境变量；

所述监测打包命令包括：

当监测到所述打包命令，判断所述打包命令中的所述环境变量是否为预设变量；

若所述打包命令中的所述环境变量不是预设变量，则所述打包命令的类型为第一类型；

若所述打包命令中的所述环境变量为预设变量，则所述打包命令的类型为第二类型。

在第一方面的一种可能的实现方式中，所述配置文件中包括第一对象和第二对象，其中，所述第一对象不包括预设信息，所述第二对象包括预设信息；

所述根据所述打包命令的类型从配置文件中获取目标对象，包括：

若所述打包命令的类型为所述第一类型，则将所述配置文件中的第一对象确定为所述目标对象；

若所述打包命令的类型为所述第二类型，则将所述配置文件中的所述第一对象和所述第二对象确定为所述目标对象。

在第一方面的一种可能的实现方式中，所述根据获取到的目标对象生成所述打包命令的类型对应版本的打包文件，包括：

若获取到的所述目标对象为所述第一对象，则将所述第一对象生成第一版本文件，所述第一版本文件对应所述第一类型；

若获取到的所述目标对象为所述第一对象和所述第二对象，则将所述第一对象和所述第二对象生成第二版本文件，所述第二版本文件对应所述第二类型。

在第一方面的一种可能的实现方式中，所述若获取到的所述目标对象为所述第一对象和所述第二对象，则将所述第一对象和所述第二对象生成第二版本文件，包括：

若获取到的所述目标对象为所述第一对象和所述第二对象，则将所述第一对象和所述第二对象合并为第三对象；

将所述第三对象生成所述第二版本文件。

在第一方面的一种可能的实现方式中，所述方法还包括：

当接收到版本升级指令，获取所述版本升级指令对应的历史打包文件；

根据所述历史打包文件的版本信息，将所述历史打包文件升级为符合所述版本信息的升级打包文件。

第二方面，本申请实施例提供了一种程序生成装置，包括：

命令监测单元，用于监测打包命令；

对象获取单元，用于根据所述打包命令的类型从配置文件中获取目标对象；

程序打包单元，用于根据获取到的目标对象生成所述打包命令的类型对应版本的打包文件。

第三方面，本申请实施例提供了一种终端设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如上述第一方面中任一项所述的程序生成方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如上述第一方面中任一项所述的程序生成方法。

第五方面，本申请实施例提供了一种计算机程序产品，当计算机程序产品在终端设备上运行时，使得终端设备执行上述第一方面中任一项所述的程序生成方法。

可以理解的是，上述第二方面至第五方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

附图说明

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

图1是本申请实施例提供的小程序提审流程的示意图；

图2是本申请实施例提供的程序生成方法的流程示意图；

图3是本申请实施例提供的程序打包流程示意图；

图4是本申请另一实施例提供的小程序提审流程的示意图；

图5是本申请实施例提供的程序生成装置的结构框图；

图6是本申请实施例提供的终端设备的结构示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

如在本申请说明书和所附权利要求书中所使用的那样，术语“若”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。

另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。

本申请实施例提供的程序生成方法可以应用于小程序提审的应用场景中。参见图1，是本申请实施例提供的小程序提审流程的示意图。图1中的开发者工具，是针对小程序的开发工具，集中了开发、测试、预览和上传等功能。开放平台，面向第三方移动程序，是为第三方移动程序提供接口的平台。第三方平台，在面向垂直行业需求时，可以一键授权给第三方平台(并且可以同时授权给多家第三方)，通过第三方平台来完成业务，开放给所有通过开发者资质认证后的开发者使用。

如图1所示，第三方平台基于一套分布式的授权平台来实现小程序代码的发布流程，通过前端开发人员在本地主干上分别提交两份小程序代码，然后分别上传至开发平台对应的第三方平台中，并添加到第三方模板库。然后通过后台一套小程序的版本管理系统(运营平台)进行版本发布，分别新建两个版本，直播版和非直播版。在后台根据查询的开通微信直播的商户进行自动匹配对应发布版本。当需要切换版本(如非直播版切换至直播版本)时，需要重新提交版本审核，系统无法自动切换。

上述流程中，开发者需要为具有直播资质和不具有直播资质的用户分别开发不同版本的小程序，这就需要维护多套程序代码。随着小程序的不断升级和更新，现有的这种方式，程序维护成本较高，降低了小程序的更新效率。为了解决上述问题，本申请实施例提供了一种程序生成方法。

参见图2，是本申请实施例提供的程序生成方法的流程示意图，作为示例而非限定，所述方法可以包括以下步骤：

S201，监测打包命令。

在该步骤之前，开发人员可以手动配置uni-app，自定义打包目录的脚本命令。其中，uni-app是一个使用Vue.js开发前端应用的框架，开发者编写一套代码，可发布到iOS、Android、Web(响应式)、以及各种小程序和快应用等平台。

在打包目录的脚本中自定义命令时，可以对不同版本设置不同的属性名，并为不同版本对应的命令设置不同的环境变量。在客户端侧的代码中使用环境变量会被静态嵌入到客户端侧的程序包中，这样可以在应用的代码中访问该环境变量。

示例性的，打包目录的脚本中自定义2个命令，普通版本属性名为`buid:mp-weixin`，直播版本属性名为`bulid:mp-weixin-live`，并在直播版命令中加入自定义的环境变量`live`。

在一个实施例中，所述打包命令中包括环境变量。相应的，所述监测打包命令包括：

当监测到所述打包命令，判断所述打包命令中的所述环境变量是否为预设变量；若所述打包命令中的所述环境变量不是预设变量，则所述打包命令的类型为第一类型；若所述打包命令中的所述环境变量为预设变量，则所述打包命令的类型为第二类型。

继续上述示例，当环境变量不为“live”时，打包命令的类型为第一类型，说明版本为非直播版本；当环境变量为“live”时，打包命令的类型为第二类型，说明版本为直播版本。

S202，根据所述打包命令的类型从配置文件中获取目标对象。

在一个实施例中，所述配置文件中包括第一对象和第二对象，其中，所述第一对象不包括预设信息，所述第二对象包括预设信息。

继续以直播版本和非直播版本的小程序为示例，可以将非直播所需的常规目录放到第一对象中，直播所需的目录和相关文件放到第二对象中。通过这种方法，相当于将打包程序所需的信息隔离。在该示例中，预设信息为直播所需的目标和相关文件，即第一对象中不包含直播所需的目录和相关文件，第二对象中包含直播所需的目录和相关文件。通过上述方法，相当于将直播所需的目录和相关文件、与非直播所需的常规目录和相关文件隔离开来。

实际应用中的实现方式可以为，新增配置文件`pages.js`,在`pages.js`文件中创建2个对象`pages`(第一对象)和`lives`(第二对象)，通过`Node.js`的模块导出对象，将`pages`和`lives`作为模块的访问接口。配置脚本(用于编译`pages.json`)，利用`Node.js`中的方法得到操作文件路径的模块对象`pages`和`lives`。

可选的，根据所述打包命令的类型从配置文件中获取目标对象，包括：

若所述打包命令的类型为所述第一类型，则将所述配置文件中的第一对象确定为所述目标对象；若所述打包命令的类型为所述第二类型，则将所述配置文件中的所述第一对象和所述第二对象确定为所述目标对象。

继续S201中的示例，若打包命令的类型为第一类型，说明版本为非直播版本，此时，只需获取非直播所需的常规目录即可。若打包命令的类型为第二类型，说明版本为直播版本，此时，既需要非直播所需的常规目录，又需要直播所需的目标和相关文件。

S203，根据获取到的目标对象生成所述打包命令的类型对应版本的打包文件。

如S202中所述，若获取到的所述目标对象为所述第一对象，则将所述第一对象生成第一版本文件，所述第一版本文件对应所述第一类型；

若获取到的所述目标对象为所述第一对象和所述第二对象，则将所述第一对象和所述第二对象生成第二版本文件，所述第二版本文件对应所述第二类型。

可选的，生成第二版本文件的方式包括：

若获取到的所述目标对象为所述第一对象和所述第二对象，则将所述第一对象和所述第二对象合并为第三对象；将所述第三对象生成所述第二版本文件。

继续以S202中的示例为例，实际应用中将第一对象和第二对象和版为第三对象的实现方式可以为，将对象`lives`(第二对象)利用`JavaScript`的`push方法`(`push`方法可以向数组的末尾添加一个或多个元素)向对象`pages`(第一对象)中数组`pages`末尾添加新的元素。

之后重写`page.json`文件，利用Node.js(基于Chrome V8引擎的JavaScript运行环境；JavaScript是一种脚本语言，存在于全世界所有Web浏览器中，能够增强用户与Web站点和Web应用程序之间的交互)的`writeFile`方法(`Node.js`中实现将数据写入文件的方法)将更新后的对象`pages`(即第三对象)的数据写入`pages.json`文件。执行`npm runxxx`命令(npm run xxx用于指示执行配置在打包目录中的脚本)，普通版运行`build:mp-weixin`，直播版运行`build:mp-weixin-live`。其中，npm是JavaScript运行时Node.js的默认程序包管理器。

在本申请实施例中，根据打包命令的类型从配置文件中获取目标对象，再根据获取到的目标对象生成打包命令的类型对应版本的打包文件，相当于通过命令行识别待打包程序的版本类型。可以在配置文件中定义不同的对象，将不同版本所需的对象隔离开来，通过打包命令识别版本类型，进而获取所需的对象。通过上述方法，无需开发不同版本的程序，只需维护一套代码，即可根据打包命令的类型打包成不同版本的程序。有效降低了程序的维护成本，提高了小程序的更新效率。

参见图3，是本申请实施例提供的程序打包流程示意图。如图3所示，在打包之前的准备工作包括：配置package.json，之后自定义打包脚本命令script，并定义环境变量(准备工作的过程可以参见S201实施例中的描述)。在打包过程中，首先访问环境变量，若环境变量等于live，则执行npm run build:mp-weixin-live，生成直播版代码；若环境变量不等于live，则执行npm run build:mp-weixin，生成非直播版代码(打包过程可参见S201-S203步骤)。

在一个实施例中，所述方法还包括：

当接收到版本升级指令，获取所述版本升级指令对应的历史打包文件；根据所述历史打包文件的版本信息，将所述历史打包文件升级为符合所述版本信息的升级打包文件。

例如，当接收到本版升级指令，该指令用于指示将小程序升级到2.0版本。获取历史打包文件，即获取小程序1.0版本的打包文件，根据该打包文件的版本号可以确定该打包文件的版本类型。如1.0版本的打包文件的版本号为1.0-live，说明该打包文件的版本类型为直播版本。那么将该1.0版本的打包文件升级为2.0直播版本的打包文件。

通过上述方法，在用户指示升级小程序时，可以自动识别升级版本，省却了人工审核的过程，节约了人工成本，提高了小程序升级的效率。

参见图4，是本申请另一实施例提供的小程序提审流程的示意图。如图4所示，通过前端开发人员在本地提交一份小程序代码，通过简单的命令行打包(打包过程对应上述的S201-S203步骤)分别上传至开放平台对应的第三方平台中，并添加到第三方模板库。然后通过后台一套小程序的版本管理系统(运营平台)进行版本发布，分别新建两个版本，直播版和非直播版。在后台，可以根据商户的设置信息判断商户是否开通直播功能；若开通直播，则将直播版本代码对应的小程序界面展示给用户；若未开通直播，则将非直播版本代码对应的小程序界面展示给用户。当用户点击升级，即需要升级小程序时，可以根据历史版本号升级相应的版本。例如，历史版本号带live字样，则升级为直播版本；历史版本号不带live字样，则仍升级为非直播版本。将升级后的版本送到运营平台审核。通过上述方法，根据查询的开通直播的商户进行自动匹配对应发布版本，按需提审，并可实现版本切换。

通过上述方法，实现直播版和非直播版系统层面无缝切换提审，废弃了以往需要研发手动对具有直播资质的商户发布，大大提升了小程序发版效率。前端通过命令行打包相当于隔离了两套代码。一套作为直播版(带直播API)，仅作为具有直播资质并开通直播的商户提审；一套作为非直播版(不带直播API)，仅作为无直播资质商户进行普通版提审，这种隔离性能保证小程序能顺利通过微信官方审核。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

对应于上文实施例所述的方法，图5是本申请实施例提供的程序生成装置的结构框图，为了便于说明，仅示出了与本申请实施例相关的部分。

参照图5，该装置包括：

命令监测单元51，用于监测打包命令。

对象获取单元52，用于根据所述打包命令的类型从配置文件中获取目标对象。

程序打包单元53，用于根据获取到的目标对象生成所述打包命令的类型对应版本的打包文件。

可选的，所述打包命令中包括环境变量。

相应的，所述命令监测单元51还用于：

当监测到所述打包命令，判断所述打包命令中的所述环境变量是否为预设变量；

若所述打包命令中的所述环境变量不是预设变量，则所述打包命令的类型为第一类型；

若所述打包命令中的所述环境变量为预设变量，则所述打包命令的类型为第二类型。

可选的，所述配置文件中包括第一对象和第二对象，其中，所述第一对象不包括预设信息，所述第二对象包括预设信息。

相应的，所述对象获取单元52还用于：

若所述打包命令的类型为所述第一类型，则将所述配置文件中的第一对象确定为所述目标对象；

若所述打包命令的类型为所述第二类型，则将所述配置文件中的所述第一对象和所述第二对象确定为所述目标对象。

可选的，所述程序打包单元53还用于：

若获取到的所述目标对象为所述第一对象，则将所述第一对象生成第一版本文件，所述第一版本文件对应所述第一类型；

若获取到的所述目标对象为所述第一对象和所述第二对象，则将所述第一对象和所述第二对象生成第二版本文件，所述第二版本文件对应所述第二类型。

可选的，所述程序打包单元53还用于：

若获取到的所述目标对象为所述第一对象和所述第二对象，则将所述第一对象和所述第二对象合并为第三对象；将所述第三对象生成所述第二版本文件。

可选的，装置5还包括：

程序升级单元54，用于当接收到版本升级指令，获取所述版本升级指令对应的历史打包文件；根据所述历史打包文件的版本信息，将所述历史打包文件升级为符合所述版本信息的升级打包文件。

需要说明的是，上述装置/单元之间的信息交互、执行过程等内容，由于与本申请方法实施例基于同一构思，其具体功能及带来的技术效果，具体可参见方法实施例部分，此处不再赘述。

另外，图5所示的装置可以是内置于现有的终端设备内的软件单元、硬件单元、或软硬结合的单元，也可以作为独立的挂件集成到所述终端设备中，还可以作为独立的终端设备存在。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

图6是本申请实施例提供的终端设备的结构示意图。如图6所示，该实施例的终端设备6包括：至少一个处理器60(图6中仅示出一个)处理器、存储器61以及存储在所述存储器61中并可在所述至少一个处理器60上运行的计算机程序62，所述处理器60执行所述计算机程序62时实现上述任意各个程序生成方法实施例中的步骤。

所述终端设备可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。该终端设备可包括，但不仅限于，处理器、存储器。本领域技术人员可以理解，图6仅仅是终端设备6的举例，并不构成对终端设备6的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如还可以包括输入输出设备、网络接入设备等。

所称处理器60可以是中央处理单元(Central Processing Unit，CPU)，该处理器60还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

所述存储器61在一些实施例中可以是所述终端设备6的内部存储单元，例如终端设备6的硬盘或内存。所述存储器61在另一些实施例中也可以是所述终端设备6的外部存储设备，例如所述终端设备6上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。进一步地，所述存储器61还可以既包括所述终端设备6的内部存储单元也包括外部存储设备。所述存储器61用于存储操作系统、应用程序、引导装载程序(BootLoader)、数据以及其他程序等，例如所述计算机程序的程序代码等。所述存储器61还可以用于暂时地存储已经输出或者将要输出的数据。

本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现可实现上述各个方法实施例中的步骤。

本申请实施例提供了一种计算机程序产品，当计算机程序产品在终端设备上运行时，使得终端设备执行时实现可实现上述各个方法实施例中的步骤。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质至少可以包括：能够将计算机程序代码携带到装置/终端设备的任何实体或装置、记录介质、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random AccessMemory)、电载波信号、电信信号以及软件分发介质。例如U盘、移动硬盘、磁碟或者光盘等。在某些司法管辖区，根据立法和专利实践，计算机可读介质不可以是电载波信号和电信信号。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

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

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

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

Claims (10)

1.一种程序生成方法，其特征在于，包括：

监测打包命令；

根据所述打包命令的类型从配置文件中获取目标对象；

根据获取到的目标对象生成所述打包命令的类型对应版本的打包文件。

2.如权利要求1所述的程序生成方法，其特征在于，所述打包命令中包括环境变量；

所述监测打包命令包括：

当监测到所述打包命令，判断所述打包命令中的所述环境变量是否为预设变量；

若所述打包命令中的所述环境变量不是预设变量，则所述打包命令的类型为第一类型；

若所述打包命令中的所述环境变量为预设变量，则所述打包命令的类型为第二类型。

3.如权利要求2所述的程序生成方法，其特征在于，所述配置文件中包括第一对象和第二对象，其中，所述第一对象不包括预设信息，所述第二对象包括预设信息；

所述根据所述打包命令的类型从配置文件中获取目标对象，包括：

若所述打包命令的类型为所述第一类型，则将所述配置文件中的第一对象确定为所述目标对象；

若所述打包命令的类型为所述第二类型，则将所述配置文件中的所述第一对象和所述第二对象确定为所述目标对象。

4.如权利要求3所述的程序生成方法，其特征在于，所述根据获取到的目标对象生成所述打包命令的类型对应版本的打包文件，包括：

若获取到的所述目标对象为所述第一对象，则将所述第一对象生成第一版本文件，所述第一版本文件对应所述第一类型；

若获取到的所述目标对象为所述第一对象和所述第二对象，则将所述第一对象和所述第二对象生成第二版本文件，所述第二版本文件对应所述第二类型。

5.如权利要求4所述的程序生成方法，其特征在于，所述若获取到的所述目标对象为所述第一对象和所述第二对象，则将所述第一对象和所述第二对象生成第二版本文件，包括：

若获取到的所述目标对象为所述第一对象和所述第二对象，则将所述第一对象和所述第二对象合并为第三对象；

将所述第三对象生成所述第二版本文件。

6.如权利要求1所述的程序生成方法，其特征在于，所述方法还包括：

当接收到版本升级指令，获取所述版本升级指令对应的历史打包文件；

根据所述历史打包文件的版本信息，将所述历史打包文件升级为符合所述版本信息的升级打包文件。

7.一种程序生成装置，其特征在于，所述装置包括：

命令监测单元，用于监测打包命令；

对象获取单元，用于根据所述打包命令的类型从配置文件中获取目标对象；

程序打包单元，用于根据获取到的目标对象生成所述打包命令的类型对应版本的打包文件。

8.如权利要求7所述的程序生成装置，其特征在于，所述打包命令中包括环境变量；所述命令监测单元还用于：

当监测到所述打包命令，判断所述打包命令中的所述环境变量是否为预设变量；

若所述打包命令中的所述环境变量不是预设变量，则所述打包命令的类型为第一类型；

若所述打包命令中的所述环境变量为预设变量，则所述打包命令的类型为第二类型。

9.一种终端设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至6任一项所述的方法。

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至6任一项所述的方法。

Images