一种脚本打包方法、装置、电子设备及存储介质与流程

本申请涉及应用程序开发领域，尤其涉及一种脚本打包方法、装置、电子设备及存储介质。

背景技术：

为了可以实现应用程序的跨平台运行和可动态更新的需求，开发人员通常可以以跨平台移动应用开发框架(reactnative，rn)来开发应用程序，采用此方式开发出的应用程序即为rn应用程序。通常一个rn应用程序具有多个代码仓库，每个代码仓库对应不同的脚本，这些脚本包括用于实现rn应用基础功能的基础脚本和实现用户不同需求的按需加载脚本。

随着用户需求的不断变化，以及出于对应用程序各项性能的优化，开发人员需要不断地对应用程序进行更新。而在更新应用程序的过程中，通常需要对应用程序内的各个脚本进行更新。为实现脚本更新，需要开发人员在开发平台上依次找到每一个脚本对应的代码仓库，再对每一个代码仓库中更新后的代码进行打包，最后得到每一个脚本对应的更新后脚本，将这些更新后脚本放入内容分发网络(contentdeliverynetwork，cdn)中，供用户使用。

如果应用程序中包含大量脚本，采用这种手动打包更新的方式，无论在确定各个脚本对应的代码仓库的阶段，还是对更新后代码的打包操作的阶段，都容易出现错漏。

技术实现要素：

本申请提供了一种脚本打包方法、装置、电子设备及存储介质，以提高应用程序的更新质量。

第一方面，本申请提供了一种脚本打包方法，所述方法包括：

接收打包指令，所述打包指令包括待更新应用程序中基础脚本的入口文件，所述基础脚本为用于实现所述待更新应用程序基础功能的脚本，所述入口文件为所述基础脚本的全部文件中第一个被访问的文件，所述入口文件包括进入所述基础脚本中各文件的入口信息；

遍历所述入口文件中的各所述入口信息，检测是否存在下层按需加载脚本，所述下层按需加载脚本为与所述基础脚本具有依赖关系的按需加载脚本，所述按需加载脚本为用于实现用户需求对应的功能的脚本；

如果存在所述下层按需加载脚本，则打包每一所述下层按需加载脚本，得到每一所述下层按需加载脚本对应的更新后唯一标识；

更新所述基础脚本中每一个所述下层按需加载脚本对应的唯一标识，生成已更新基础脚本；

打包所述已更新基础脚本，得到所述已更新基础脚本的唯一标识。

在本发明实施例第一方面一种可能的实现方式中，所述打包每一所述下层按需加载脚本包括：

检测所述下层按需加载脚本是否存在次下层按需加载脚本，所述次下层按需加载脚本为与所述下层按需加载脚本具有依赖关系的按需加载脚本；

如果存在所述次下层按需加载脚本，则打包每一所述次下层按需加载脚本，得到每一所述次下层按需加载脚本对应的唯一标识；

更新所述下层按需加载脚本中每一所述次下层按需加载脚本对应的唯一标识，得到已更新下层按需加载脚本；

打包所述已更新下层按需加载脚本，得到所述已更新下层按需加载脚本的唯一标识。

在本发明实施例第一方面一种可能的实现方式中，所述检测所述下层按需加载脚本是否存在次下层按需加载脚本还包括：

如果不存在所述次下层按需加载脚本，则直接打包所述下层按需加载脚本，得到所述下层按需加载脚本对应的更新后唯一标识。

在本发明实施例第一方面一种可能的实现方式中，所述打包指令还包括所述基础脚本的所述下层按需加载脚本对应的仓库地址和代码分支，所述打包每一所述下层按需加载脚本包括：

从所述打包指令中获取每一所述下层按需加载脚本对应的仓库地址和代码分支，所述仓库地址为所述下层按需加载脚本的对应代码仓库在所述待更新应用程序对应数据库中的存放位置，所述代码分支用于代表所述下层按需加载脚本的代码版本；

按照所述仓库地址从所述待更新应用程序对应数据库中获取所述下层按需加载脚本的代码仓库；按照所述代码分支从所述代码仓库中获取所述下层按需加载脚本的更新后代码；

打包每一所述下层按需加载脚本的更新后代码，得到每一所述下层按需加载脚本对应的更新后唯一标识。

在本发明实施例第一方面一种可能的实现方式中，所述打包指令还包括所述基础脚本对应的仓库地址和代码分支，所述打包所述已更新基础脚本，得到所述已更新基础脚本的唯一标识包括：

从所述打包指令中获取所述基础脚本对应的仓库地址和代码分支，所述基础脚本对应的仓库地址为所述基础脚本的对应代码仓库在所述待更新应用程序对应数据库中的存放位置，所述基础脚本的代码分支用于代表所述基础脚本的代码版本；

按照所述基础脚本的仓库地址从所述待更新应用程序对应数据库中获取所述基础脚本的代码仓库；

按照所述基础脚本的代码分支从所述基础脚本的代码仓库中获取所述基础脚本更新后代码；

打包所述基础脚本更新后代码和各所述下层按需加载脚本对应的唯一标识，得到所述已更新基础脚本的唯一标识。

第二方面，本申请提供了一种脚本打包装置，所述装置包括：

打包指令接收模块，用于接收打包指令，所述打包指令包括待更新应用程序中基础脚本的入口文件，所述基础脚本为用于实现所述待更新应用程序基础功能的脚本，所述入口文件为所述基础脚本的全部文件中第一个被访问的文件，所述入口文件包括进入所述基础脚本中各文件的入口信息；

信息遍历模块，用于遍历所述入口文件中的各所述入口信息，检测是否存在下层按需加载脚本，所述下层按需加载脚本为与所述基础脚本具有依赖关系的按需加载脚本，所述按需加载脚本为用于实现用户需求对应的功能的脚本；

下层按需加载脚本打包模块，用于如果存在所述下层按需加载脚本，则打包每一所述下层按需加载脚本，得到每一所述下层按需加载脚本对应的更新后唯一标识；

基础脚本更新模块，用于更新所述基础脚本中每一个所述下层按需加载脚本对应的唯一标识，生成已更新基础脚本；

脚本打包模块，用于打包所述已更新基础脚本，得到所述已更新基础脚本的唯一标识。

在本发明实施例第二方面一种可能的实现方式中，所述下层按需加载脚本打包模块包括：

检测模块，用于检测所述下层按需加载脚本是否存在次下层按需加载脚本，所述次下层按需加载脚本为与所述下层按需加载脚本具有依赖关系的按需加载脚本；

第一打包模块，用于如果存在所述次下层按需加载脚本，则打包每一所述次下层按需加载脚本，得到每一所述次下层按需加载脚本对应的唯一标识；

更新模块，用于更新所述下层按需加载脚本中每一所述次下层按需加载脚本对应的唯一标识，得到已更新下层按需加载脚本；

第二打包模块，用于打包所述已更新下层按需加载脚本，得到所述已更新下层按需加载脚本的唯一标识。

在本发明实施例第二方面一种可能的实现方式中，所述下层按需加载脚本打包模块还包括：

第三打包模块，用于如果不存在所述次下层按需加载脚本，则直接打包所述下层按需加载脚本，得到所述下层按需加载脚本对应的更新后唯一标识。

在本发明实施例第二方面一种可能的实现方式中，所述下层按需加载脚本打包模块包括：

第一信息获取模块，用于从所述打包指令中获取每一所述下层按需加载脚本对应的仓库地址和代码分支，所述仓库地址为所述下层按需加载脚本的对应代码仓库在所述待更新应用程序对应数据库中的存放位置，所述代码分支用于代表所述下层按需加载脚本的代码版本；

第一代码仓库获取模块，用于按照所述仓库地址从所述待更新应用程序对应数据库中获取所述下层按需加载脚本的代码仓库；

第一更新后代码获取模块，用于按照所述代码分支从所述代码仓库中获取所述下层按需加载脚本的更新后代码；

第一子打包模块，用于打包每一所述下层按需加载脚本的更新后代码，得到每一所述下层按需加载脚本对应的更新后唯一标识。

在本发明实施例第二方面一种可能的实现方式中，所述下层按需加载脚本打包模块包括：

第二信息获取模块，用于从所述打包指令中获取所述基础脚本对应的仓库地址和代码分支，所述基础脚本对应的仓库地址为所述基础脚本的对应代码仓库在所述待更新应用程序对应数据库中的存放位置，所述基础脚本的代码分支用于代表所述基础脚本的代码版本；

第二代码仓库获取模块，用于按照所述基础脚本的仓库地址从所述待更新应用程序对应数据库中获取所述基础脚本的代码仓库；

第二更新后代码获取模块，用于按照所述基础脚本的代码分支从所述基础脚本的代码仓库中获取所述基础脚本更新后代码；

第二子打包模块，用于打包所述基础脚本更新后代码和各所述下层按需加载脚本对应的唯一标识，得到所述已更新基础脚本的唯一标识。

第三方面，本发明实施例提供了一种电子设备，包括：

处理器，以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行所述的脚本打包方法。

第四方面，本发明实施例提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现所述的脚本打包方法。

本申请提供了一种脚本打包方法、装置、电子设备及存储介质，其中，首先接收开发人员发送的打包指令，所述打包指令包括待更新应用程序中基础脚本的入口文件。通过遍历所述入口文件中的各所述入口信息，检测所述基础脚本是否存在下层按需加载脚本，如果存在，则依次打包每一所述下层按需加载脚本，得到每一所述下层按需加载脚本对应的更新后唯一标识。然后，更新基础脚本中每一个下层按需加载脚本对应的唯一标识，得到已更新基础脚本。最后，打包所述已更新基础脚本，得到已更新基础脚本的唯一标识，以完成对待更新应用程序的更新。可见，本申请所提供的技术方案可以通过入口文件自动判断待更新应用程序中各脚本之间的依赖关系，从而通过逐级打包各个脚本，进而得到已更新基础脚本的唯一标识，完成对待更新应用程序的更新，更新后的应用程序中包含各层级脚本的唯一标识，方便用户使用。

附图说明

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

图1为本申请实施例提供的一种脚本打包方法的流程图；

图2为本申请实施例提供的一种脚本打包流程示意图；

图3为本申请实施例提供的一种打包下层按需加载脚本的方法的流程图；

图4为本申请实施例提供的一种打包下层按需加载脚本的方法的流程图；

图5为本申请实施例提供的一种打包已更新基础脚本的方法的流程图；

图6为本发明实施例提供的脚本打包装置实施例一的结构示意图；

图7为本发明实施例提供的脚本打包装置实施例二的结构示意图；

图8为本发明实施例提供的脚本打包装置实施例三的结构示意图；

图9为本发明实施例提供的脚本打包装置实施例四的结构示意图；

图10为本发明实施例提供的脚本打包装置实施例五的结构示意图；

图11为本发明实施例提供的电子设备的硬件结构示意图。

具体实施方式

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

图1为本申请实施例提供的一种脚本打包方法的流程图，如图1所示，所述方法包括：

s1、接收打包指令，所述打包指令包括待更新应用程序中基础脚本的入口文件，所述基础脚本为用于实现所述待更新应用程序基础功能的脚本，所述入口文件为所述基础脚本的全部文件中第一个被访问的文件，所述入口文件包括进入所述基础脚本中各文件的入口信息。

待更新应用程序为rn应用程序，此时的待更新应用程序为经过开发人员对相应代码进行更新之后，等待上传至cdn并公开的阶段。开发人员将待更新应用程序放置于打包平台上，所述打包平台为具有代码打包功能的设备、管理器、服务器等。开发人员对打包平台发送打包指令，该打包指令中至少包含基础脚本的入口文件，通过这个入口文件，可以进入基础脚本对应的全部子文件，这些子文件中会包含与基础脚本存在依赖关系的按需加载脚本，因此，通过这个入口文件，可以准确找到基础脚本的下层按需加载脚本。

s2、遍历所述入口文件中的各所述入口信息，检测是否存在下层按需加载脚本，所述下层按需加载脚本为与所述基础脚本具有依赖关系的按需加载脚本，所述按需加载脚本为用于实现用户需求对应的功能的脚本。

通过浏览入口文件中全部入口信息，可以确定基础脚本是否存在下层按需加载脚本。

具体地，本申请实施例提供了一种判断是否存在下层按需加载脚本的方法，具体如下：

s201、从所述入口文件中获取各入口信息；

s202、判断各所述入口信息中是否存在下层入口信息，所述下层入口信息为对应所述下层按需加载脚本的打包文件的所述入口信息，所述打包文件为存储有所述下层按需加载脚本的代码的文件；

如果存在，则所述基础脚本存在下层按需加载脚本；如果不存在，则所述基础脚本不存在下层按需加载脚本。

入口文件相当于全部文件的展示首页，如果想要进入其它子文件，则需要首先进入入口文件，然后再通过入口文件中包含的入口信息，进入各个对应的子文件。在本申请实施例中主要提供影响基础脚本打包结果的入口信息，即这些入口信息对应于进入下层按需加载脚本的打包文件，这样的入口信息在本实施例中定义为下层入口信息。

如果入口文件中存在下层入口信息，则说明由基础脚本可以进入下层按需加载脚本，即基础脚本存在下层按需加载脚本；反之，如果入口文件中不存在下层入口信息，则说明基础脚本没有可以进入的下层按需加载脚本，即基础脚本不存在下层按需加载脚本。

s3、如果存在所述下层按需加载脚本，则打包每一所述下层按需加载脚本，得到每一所述下层按需加载脚本对应的更新后唯一标识；

进一步地，用户在更新所使用的应用程序时，是按照自己的需求对各个脚本逐步进行更新的，如图2所示，为本申请实施例提供的一种脚本打包流程示意图，当用户打开应用程序时，应用程序首先需要展示首页，此时所对应的脚本即为基础脚本，而随着用户的真实需求，如果用户最终需要展示第一页面，则需要从首页进入第一页面，该第一页面对应于按需加载脚本1，为了顺利展示第一页面，则需要下载与第一页面相匹配的按需加载脚本1。由以上过程可知，如果用户需要浏览第一页面，则需要相应的下载按需加载脚本1，那么用户需要清楚地知道第一页面与哪一个脚本对应，而这个脚本的当前版本又是哪一个，而这些信息都是从基础脚本中获得的。可见，基础脚本中需要包含代表下层按需加载脚本的标识，以供用户通过该标识下载相应的脚本数据。

由上述过程可知，基础脚本的打包过程与下层按需加载脚本的更新后唯一标识相关联，因此，在打包基础脚本之前，需要对基础脚本所对应的下层按需加载脚本进行打包，以获得这些下层按需加载脚本各自对应的更新后唯一标识。

需要注意的是，在打包更新脚本时，每一次的打包过程仅针对同一层级中的一个脚本进行，如图2所示，当通过入口文件判断存在按需加载脚本1时，则在此打包过程中不再继续找寻按需加载脚本2，而是从按需加载脚本1中找寻次下层按需加载脚本。当次打包过程完毕之后，再从基础脚本开始重新找寻是否存在下层按需加载脚本，再次开启新的打包过程。

具体地，如图3所示，为本申请实施例提供的一种打包下层按需加载脚本的方法的流程图，所述方法包括：

s301、检测所述下层按需加载脚本是否存在次下层按需加载脚本，所述次下层按需加载脚本为与所述下层按需加载脚本具有依赖关系的按需加载脚本；

s302、如果存在所述次下层按需加载脚本，则打包每一所述次下层按需加载脚本，得到每一所述次下层按需加载脚本对应的唯一标识；

s303、更新所述下层按需加载脚本中每一所述次下层按需加载脚本对应的唯一标识，得到已更新下层按需加载脚本；

s304、打包所述已更新下层按需加载脚本，得到所述已更新下层按需加载脚本的唯一标识。

此时，按照上文的思路，下层按需加载脚本的打包过程必然也会与位于其下层，即与下层按需加载脚本存在依赖关系的次下层按需加载脚本的唯一标识相关联。因此，如果下层按需加载脚本具有次下层按需加载脚本，则需要获得与该下层按需加载脚本相关联的全部次下层按需加载脚本的更新后唯一标识，再进行打包。如图2所示，其中按需加载脚本1即为基础脚本的下层按需加载脚本，而且按需加载脚本1具有次下层按需加载脚本3、4、5，因此，需要获取次下层按需加载脚本3、4、5各自的更新后唯一标识，作为按需加载脚本1的打包基础。

进一步地，图2仅示例性的给出了具有三层脚本结构的待更新应用程序，在应用程序的实际开发中，应用程序可以具有不同数量的脚本层级结构，其中，在对每一层级上的某一脚本进行打包时，该脚本的打包基础均与其下层脚本的更新后唯一标识相关联，因此，通常可以先逐层查找下一层级的脚本，直至找到最底层的脚本，该最底层的脚本不再具有下层按需加载脚本，因此，该最底层的脚本在打包时仅与本身的更新后代码相关联，而不受其它脚本的影响。此时，从最底层的脚本开始逐层向上层打包，这样就可以为上层等待打包的脚本提供更新后唯一标识。

其中，以图2所示的脚本层级结构为例，如果下层按需加载脚本存在次下层按需加载脚本，则在打包的过程中，除了需要各次下层按需加载脚本的更新后唯一标识，还需要该按需加载脚本的更新后代码，这样打包所得的脚本才具有更新后代码，才是最新版本的脚本。

具体地，如图4所示，为本申请实施例提供的一种打包下层按需加载脚本的方法的流程图，所述方法包括：

s3021、从所述打包指令中获取每一所述下层按需加载脚本对应的仓库地址和代码分支，所述仓库地址为所述下层按需加载脚本的对应代码仓库在所述待更新应用程序对应数据库中的存放位置，所述代码分支用于代表所述下层按需加载脚本的代码版本；

s3022、按照所述仓库地址从所述待更新应用程序对应数据库中获取所述下层按需加载脚本的代码仓库；

s3023按照所述代码分支从所述代码仓库中获取所述下层按需加载脚本的更新后代码；

s3024、打包每一所述下层按需加载脚本的更新后代码，得到每一所述下层按需加载脚本对应的更新后唯一标识。

开发人员下发的打包指令中通常带有每一个脚本在待更新应用程序中的仓库地址和更新后代码对应的代码分支，显然，下层按需加载脚本对应的仓库地址和代码分支也包含在打包指令中，这样打包平台根据仓库地址，可以获取下层按需加载脚本对应的代码仓库，此时的代码仓库中包含该下层按需加载脚本全部使用过的代码版本和更新后的代码版本。然后，打包平台根据代码分支可以从代码仓库中确定更新后的代码版本，从而获取到更新后代码。此时，通过打包该下层按需加载脚本的各次下层按需加载脚本的更新后唯一标识和该下层按需加载脚本的更新后代码，即可获得更新后下层按需加载脚本，为了方便用户获取，可以为该更新后下层按需加载脚本赋予一个唯一标识，通过这唯一标识用户可以获得对应的脚本数据。其中，唯一标识可以采用数字、代码、特殊符号等。

需要注意的是，对于次下层按需加载脚本以及所有的按需加载脚本，如果存在与其具有依赖关系的按需加载脚本，均可采用上述步骤进行打包。

在另一种实施方式中，如果不存在所述次下层按需加载脚本，则直接打包所述下层按需加载脚本，得到所述下层按需加载脚本对应的更新后唯一标识。

如图2所述，其中按需加载脚本2即为基础脚本的下层按需加载脚本，而其不存在次下层按需加载脚本，那么它的打包过程将不受其它按需加载脚本的影响，仅与其更新后代码相关联，因此，只要打包它的更新后代码，即可获得更新后下层按需加载脚本，为了方便用户获取，可以为该更新后下层按需加载脚本赋予一个唯一标识，通过这唯一标识用户可以获得对应的脚本数据。其中，唯一标识可以采用数字、代码、特殊符号等。

需要注意的是，对于次下层按需加载脚本以及所有的按需加载脚本，如果不存在与其具有依赖关系的按需加载脚本，均可采用上述步骤进行打包。

s4、更新所述基础脚本中每一个所述下层按需加载脚本对应的唯一标识，生成已更新基础脚本。

依据上述过程，得到每一个下层按需加载脚本对应的唯一标识之后，该唯一标识为下层按需加载脚本对应的最新的唯一标识，由于基础脚本与各下层按需加载脚本之间存在依赖关系，因此，通过更新基础脚本中的每一个下层按需加载脚本对应的唯一标识，可以更新基础脚本，进而得到已更新基础脚本，作为更新待更新应用程序的基础。

s5、打包所述已更新基础脚本，得到所述已更新基础脚本的唯一标识。

在获得已更新基础脚本之后，就可以对已更新基础脚本进行打包。

具体地，如图5所示，为本申请实施例提供的一种打包已更新基础脚本的方法的流程图，所述方法包括：

s501、从所述打包指令中获取所述基础脚本对应的仓库地址和代码分支，所述基础脚本对应的仓库地址为所述基础脚本的对应代码仓库在所述待更新应用程序对应数据库中的存放位置，所述基础脚本的代码分支用于代表所述基础脚本的代码版本；

s502、按照所述基础脚本的仓库地址从所述待更新应用程序对应数据库中获取所述基础脚本的代码仓库；

s503、按照所述基础脚本的代码分支从所述基础脚本的代码仓库中获取所述基础脚本更新后代码；

s504、打包所述基础脚本更新后代码和各所述下层按需加载脚本对应的唯一标识，得到所述已更新基础脚本的唯一标识。

开发人员下发的打包指令中通常带有基础脚本在待更新应用程序中的仓库地址和更新后代码对应的代码分支，这样打包平台根据仓库地址，可以获取基础脚本对应的代码仓库，此时的代码仓库中包含基础脚本全部使用过的代码版本和更新后的代码版本。然后，打包平台根据代码分支可以从代码仓库中确定更新后的代码版本，从而获取到更新后代码。此时，通过打包基础脚本的各下层按需加载脚本的更新后唯一标识和基础脚本的更新后代码，即可获得更新后基础脚本，为了方便用户获取，可以为该更新后基础脚本赋予一个唯一标识，通过这个唯一标识用户可以获得对应的脚本数据。其中，唯一标识可以采用数字、代码、特殊符号等。

由以上技术方案可知，本申请所提供的技术方案可以通过入口文件自动判断待更新应用程序中各脚本之间的依赖关系，从而可以自动逐层打包各个脚本对应的更新后代码，并且在打包的过程中添加下层脚本的唯一标识，可以令打包得到的更新后脚本中带有下层脚本的唯一标识，以供用户在产生具体需求时，可以该唯一标识获取到下层脚本的更新后脚本。

图6为本发明实施例提供的脚本打包装置实施例一的结构示意图，所述装置包括：打包指令接收模块1，用于接收打包指令，所述打包指令包括待更新应用程序中基础脚本的入口文件，所述基础脚本为用于实现所述待更新应用程序基础功能的脚本，所述入口文件为所述基础脚本的全部文件中第一个被访问的文件，所述入口文件包括进入所述基础脚本中各文件的入口信息；信息遍历模块2，用于遍历所述入口文件中的各所述入口信息，检测是否存在下层按需加载脚本，所述下层按需加载脚本为与所述基础脚本具有依赖关系的按需加载脚本，所述按需加载脚本为用于实现用户需求对应的功能的脚本；下层按需加载脚本打包模块3，用于如果存在所述下层按需加载脚本，则打包每一所述下层按需加载脚本，得到每一所述下层按需加载脚本对应的更新后唯一标识；基础脚本更新模块4，用于更新所述基础脚本中每一个所述下层按需加载脚本对应的唯一标识，生成已更新基础脚本；脚本打包模块5，用于打包所述已更新基础脚本，得到所述已更新基础脚本的唯一标识。

图7为本发明实施例提供的脚本打包装置实施例二的结构示意图，所述下层按需加载脚本打包模块3包括：检测模块31，用于检测所述下层按需加载脚本是否存在次下层按需加载脚本，所述次下层按需加载脚本为与所述下层按需加载脚本具有依赖关系的按需加载脚本；第一打包模块32，用于如果存在所述次下层按需加载脚本，则打包每一所述次下层按需加载脚本，得到每一所述次下层按需加载脚本对应的唯一标识；更新模块33，用于更新所述下层按需加载脚本中每一所述次下层按需加载脚本对应的唯一标识，得到已更新下层按需加载脚本；第二打包模块34，用于打包所述已更新下层按需加载脚本，得到所述已更新下层按需加载脚本的唯一标识。

图8为本发明实施例提供的脚本打包装置实施例三的结构示意图，所述下层按需加载脚本打包模块3还包括：第三打包模块35，用于如果不存在所述次下层按需加载脚本，则直接打包所述下层按需加载脚本，得到所述下层按需加载脚本对应的更新后唯一标识。

图9为本发明实施例提供的脚本打包装置实施例四的结构示意图，所述下层按需加载脚本打包模块3还包括：第一信息获取模块301，用于从所述打包指令中获取每一所述下层按需加载脚本对应的仓库地址和代码分支，所述仓库地址为所述下层按需加载脚本的对应代码仓库在所述待更新应用程序对应数据库中的存放位置，所述代码分支用于代表所述下层按需加载脚本的代码版本；第一代码仓库获取模块302，用于按照所述仓库地址从所述待更新应用程序对应数据库中获取所述下层按需加载脚本的代码仓库；第一更新后代码获取模块303，用于按照所述代码分支从所述代码仓库中获取所述下层按需加载脚本的更新后代码；第一子打包模块304，用于打包每一所述下层按需加载脚本的更新后代码，得到每一所述下层按需加载脚本对应的更新后唯一标识。

图10为本发明实施例提供的脚本打包装置实施例五的结构示意图，所述脚本打包模块4包括：第二信息获取模块41，用于从所述打包指令中获取所述基础脚本对应的仓库地址和代码分支，所述基础脚本对应的仓库地址为所述基础脚本的对应代码仓库在所述待更新应用程序对应数据库中的存放位置，所述基础脚本的代码分支用于代表所述基础脚本的代码版本；第二代码仓库获取模块42，用于按照所述基础脚本的仓库地址从所述待更新应用程序对应数据库中获取所述基础脚本的代码仓库；第二更新后代码获取模块43，用于按照所述基础脚本的代码分支从所述基础脚本的代码仓库中获取所述基础脚本更新后代码；第二子打包模块44，用于打包所述基础脚本更新后代码和各所述下层按需加载脚本对应的唯一标识，得到所述已更新基础脚本的唯一标识。

图11为本发明实施例提供的电子设备的硬件结构示意图。该电子设备包括：存储器101和处理器102；

存储器101，用于存储计算机程序；

处理器102，用于执行存储器存储的计算机程序，以实现上述实施例中的脚本打包方法。具体可以参见前述方法实施例中的相关描述。

可选地，存储器101既可以是独立的，也可以跟处理器102集成在一起。

当所述存储器101是独立于处理器102之外的器件时，所述电子设备还可以包括：

总线103，用于连接所述存储器101和处理器102。

本发明实施例提供的电子设备可用于执行上述实施例中任一所示的脚本打包方法，其实现方式和技术效果类似，本发明实施例此处不再赘述。

本发明实施例还提供一种可读存储介质，可读存储介质中存储有计算机程序，当消息发送的装置的至少一个处理器执行该计算机程序时，消息发送的装置执行上述实施例任一所述的脚本打包方法。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于以计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。

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