pod库之间依赖关系的确定方法及其装置、电子设备

摘要

本申请实施例提供了一种pod库之间依赖关系的确定方法及其装置、计算机存储介质、电子设备，该pod库之间依赖关系的确定方法包括：获取壳工程下所有已发布pod库的依赖关系；确定所述已发布pod库中进入开发状态的pod库，并获取所述进入开发状态的pod库的描述文件；根据所述进入开发状态的pod库的描述文件，在所述依赖关系中查找出所述进入开发状态的pod库的依赖关系。本申请实施例提供的pod库之间依赖关系的确定方法及其装置、计算机存储介质、电子设备，不需要进行人工确定或者运行pod库，提高了依赖关系的确定速度以及效率。

说明书

技术领域

本申请涉及数据处理技术领域，具体涉及一种pod库之间依赖关系的确定方法及其装置、计算机存储介质、电子设备。

背景技术

在应用程序开发时，由于会涉及到应用程序要实现的多种功能，为此，针对各个功能的开发，按照组件进行划分存在多个功能组件，即一个功能组件开发的目标是要实现至少一个功能，这种开发模式业界又称之为组件化开发。为此，在应用程序的开发过程中，引入了组件化管理工具，比如针对基于IOS系统的应用程序开发，一般采用CocoaPods工具进行管理。基于CocoaPods工具进行组件化开发时，针对每个功能组件的开发，都会分配一个Pod库进行相关代码的独立编写管理，所有组件对应的Pod库在一个壳工程下进行管理。

随着组件数量的日益增长，对应的pod库的数量也随之增长，当要发布pod库时，需要按照pod库的依赖关系确定发布的先后顺序，避免出现由于先后顺序发生错误导致pod库的发布失败。而现有技术中，确定依赖关系时，一种方式是通过人工来确定，另一种方式是通过运行pod库来确定，但是，这两种方式，随着产品功能的不断丰富，导致功能组件数量增多，进而使得pod库的数量也随之增多，导致依赖关系的确定速度较慢，效率较低。

发明内容

本申请实施例提供一种pod库之间依赖关系的确定方法及其装置、计算机存储介质、电子设备，用以克服或者缓解现有技术中存在的上述技术问题。

本申请采用的技术方案为：

一种pod库之间依赖关系的确定方法，其包括：

获取壳工程下所有已发布pod库的依赖关系；

确定所述已发布pod库中进入开发状态的pod库，并获取所述进入开发状态的pod库的描述文件；

根据所述进入开发状态的pod库的描述文件，在所述依赖关系中查找出所述进入开发状态的pod库的依赖关系。

可选地，本申请一实施例中，所述获取壳工程下所有已发布pod库的依赖关系，包括：

获取所述壳工程下已发布pod库的描述文件；

通过对所述已发布pod库的描述文件进行解析，以建立所有已发布pod库的依赖关系。

可选地，本申请一实施例中，所述通过对所述已发布pod库的描述文件进行解析，以建立所有已发布pod库的依赖关系，包括：

针对每一已发布pod库，从所述每一已发布pod库的描述文件中提取对应pod库的名称以及其直接依赖的已发布pod库的名称；

以键值对的方式存储所有所述已发布pod库的名称以及其直接依赖的已发布pod库的名称，以建立所有所述已发布pod库的依赖关系。

可选地，本申请一实施例中，所述以键值对的方式存储所有所述已发布pod库的名称以及其直接依赖的已发布pod库的名称，以建立所有所述已发布pod库的依赖关系，包括：

针对每一已发布pod库，其名称作为键值对的key，其直接依赖的已发布pod库的名称作为value；

根据所有所述已发布pod库对应的所述key和所述value，建立所有所述已发布pod库的依赖关系。

可选地，本申请一实施例中，所述以键值对的方式存储所有所述已发布pod库的名称以及其直接依赖的已发布pod库的名称，以建立所有所述已发布pod库的依赖关系，还包括：

针对每一已发布pod库，确定其间接依赖的已发布pod库的名称，并将其间接依赖的已发布pod库的名称添加到所述value中。

可选地，本申请一实施例中，所述确定所述已发布pod库中进入开发状态的pod库，包括：

对所述已发布pod库的描述文件进行解析，从中获取所述已发布pod库的依赖模式描述，根据所述依赖模式描述，确定所述已发布pod库中进入开发状态的pod库。

可选地，本申请一实施例中，若所述依赖模式描述为路径依赖模式，则对应的已发布pod库为进入开发状态的pod库；若所述依赖模式描述为版本依赖模式或者远端依赖模式，则对应的已发布pod库为未进入开发状态的pod库。

可选地，本申请一实施例中，所述确定所述已发布pod库中进入开发状态的pod库，并获取所述进入开发状态的pod库的描述文件之后，包括：从所述进入开发状态的pod库的描述文件中获取进入开发状态的pod库的名称，并将其增加到建立的进入开发状态的pod库列表中；

所述根据所述进入开发状态的pod库的描述文件，在所述依赖关系中查找出所述进入开发状态的pod库的依赖关系，包括：根据所述开发状态的pod库列表记录的进入开发状态的pod库的名称，在所述依赖关系中查找出所述进入开发状态的pod库的依赖关系。

一种pod库之间依赖关系的建立方法，其包括：

获取壳工程下已发布pod库的描述文件；

通过对所述已发布pod库的描述文件进行解析，以建立所有已发布pod库的依赖关系。

可选地，本申请一实施例中，所述通过对所述已发布pod库的描述文件进行解析，以建立所有已发布pod库的依赖关系，包括：

针对每一已发布pod库，从所述每一已发布pod库的描述文件中提取对应pod库的名称以及其直接依赖的已发布pod库的名称；

以键值对的方式存储所有所述已发布pod库的名称以及其直接依赖的已发布pod库的名称，以建立所有所述已发布pod库的依赖关系。

可选地，本申请一实施例中，所述以键值对的方式存储所有所述已发布pod库的名称以及其直接依赖的已发布pod库的名称，以建立所有所述已发布pod库的依赖关系，包括：

针对每一已发布pod库，其名称作为键值对的key，其直接依赖的已发布pod库的名称作为value；

根据所有所述已发布pod库对应的所述key和所述value，建立所有已发布pod库的依赖关系。

可选地，本申请一实施例中，所述以键值对的方式存储所有所述已发布pod库的名称以及其直接依赖的已发布pod库的名称，以建立所有所述已发布pod库的依赖关系，还包括：

针对每一已发布pod库，确定其间接依赖的已发布pod库的名称，并将其间接依赖的已发布pod库的名称添加到所述value中。

一种pod库之间依赖关系的确定装置，其包括：

依赖关系获取单元，用于获取壳工程下所有已发布pod库的依赖关系；

pod库确定单元，用于确定所述已发布pod库中进入开发状态的pod库，并获取所述进入开发状态的pod库的描述文件；

依赖关系筛选单元，用于根据所述进入开发状态的pod库的描述文件，在所述依赖关系中查找出所述进入开发状态的pod库的依赖关系。

一种pod库之间依赖关系的建立装置，其包括：

描述文件获取单元，用于获取壳工程下已发布pod库的描述文件；

依赖关系建立单元，用于通过对所述已发布pod库的描述文件进行解析，以建立所有已发布pod库的依赖关系。

一种计算机存储介质，所述计算机存储介质上存储有计算机可执行程序，所述计算机可执行程序被运行以实施本申请任一实施例所述的方法。

一种电子设备，所述电子设备包括存储器以及处理器，所述存储器上用于存储计算机可执行程序，所述处理器用于运行所述计算机可执行程序以实施实施本申请任一实施例所述的方法。

本申请实施例，获取壳工程下所有已发布pod库的依赖关系；确定所述已发布pod库中进入开发状态的pod库，并获取所述进入开发状态的pod库的描述文件；根据所述进入开发状态的pod库的描述文件，在所述依赖关系中查找出所述进入开发状态的pod库的依赖关系，其不需要进行人工确定或者运行pod库，提高了依赖关系的确定速度以及效率。

附图说明

图1为本申请实施例一种pod库之间依赖关系的确定方法的流程示意图；

图2为本申请实施例一种pod库之间依赖关系的建立方法的流程示意图；

图3为本申请实施例一种pod库之间依赖关系的确定装置的结构示意图；

图4为本申请实施例一种pod库之间依赖关系的建立装置的结构示意图；

图5为本申请实施例中依赖关系的处理系统结构示意图；

图6为本申请实施例一种电子设备的结构示意图。

具体实施方式

为使本申请要解决的技术问题、技术方案和优点更加清楚，下面将结合附图及具体实施例进行详细描述。

本申请实施例，获取壳工程下所有已发布pod库的依赖关系，确定所述已发布pod库中进入开发状态的pod库，并获取所述进入开发状态的pod库的描述文件；根据所述进入开发状态的pod库的描述文件，在所述依赖关系中查找出所述进入开发状态的pod库的依赖关系，其不需要进行人工确定或者运行pod库，提高了依赖关系的确定速度以及效率。

图1为本申请实施例一种pod库之间依赖关系的确定方法的流程示意图；如图1所示，本实施例主要用于确定进入开发状态的pod库的依赖关系，具体地，pod库之间依赖关系的确定方法包括：

S101、获取壳工程下所有已发布pod库的依赖关系；

本实施例中，所述壳工程又称之为project，该project用于管理涉及到应用程序代码开发的所有pod库，每一个pod库对应应用程序一个组件的开发，而组件是基于应用程序的功能来进行区分的。

本实施例中，之所以要基于已发布pod库的依赖关系，是由于在pod库发布之后，各个pod库的依赖关系才是准确的。

本实施例中，所述依赖关系包括所述已发布pod库之间的直接依赖关系，以及间接依赖关系。比如，已发布pod库1依赖于已发布pod库2，已发布pod库2又依赖于已发布pod库3，则已发布pod库1与已发布pod库2的依赖关系为直接依赖关系，而由于已发布pod库2又依赖于已发布pod库3，已发布pod库2与已发布pod库3的依赖关系为直接依赖关系，已发布pod库1与已发布pod库3的依赖关系为间接依赖关系。此处，在确定上述依赖关系，按照单向确定即可，比如确定出已发布pod库1依赖于已发布pod库2，因此，无须确定已发布pod库2是否依赖于已发布pod库1，因此，进一步提高了依赖关系的确定速度和效率。

本实施例中，可以通过对任何能反映出pod库之间依赖关系的文件进行解析，从而获取到壳工程下所有已发布pod库的依赖关系。

本实施例中，所述依赖关系可以以图（map）的形式体现，当然，在其他一些实施例中，也可以以列表或者索引或者树的形式体现。

具体地，在获取壳工程下所有已发布pod库之间的依赖关时，可以并行获取，也可以串行获取，并行获取即同时获取多个已发布pod库的依赖关系，串行获取即每次只获取一个已发布pod库的依赖关系。具体是并行获取还是串行获取根据资源条件或者应用场景的需求灵活设置。

本实施例中，步骤S101中要获取的所有已发布pod库的依赖关系可以预先建立好，也可以在本实施例中实时建立，具体根据应用场景灵活设定。

本实施例中，步骤S101中要获取的所有已发布pod库的依赖关系可以存储在指定目录中。

S102、确定所述已发布pod库中进入开发状态的pod库，并获取所述进入开发状态的pod库的描述文件；

具体地，本实施例中，所述确定所述已发布pod库中进入开发状态的pod库，包括：对所述已发布pod库的描述文件进行解析，从中获取所述已发布pod库的依赖模式描述，根据所述依赖模式描述，确定所述已发布pod库中进入开发状态的pod库。

具体地，所述已发布pod库的描述文件可以为任意记录了pod的依赖模式的文件，比如在一具体应用场景中，所述pod库的描述文件可以为所述pod库的声明文件，在该所述已发布pod库的声明文件中包括有pod库的依赖模式描述，在根据所述依赖模式描述，确定所述已发布pod库中进入开发状态的pod库时，通过对依赖模式描述进行解析，从而获得描述依赖关系的数据，进而确定所述已发布pod库中进入开发状态的pod库。

具体地，所述已发布pod库的声明文件在为实现组件化管理的CocoaPods工具中的podfile文件，在该文件中记录有描述已发布pod库的依赖关系的数据。

更为具体地，所述已发布pod库的声明文件在为实现组件化管理的CocoaPods工具中的podfile文件，在该文件的specification中的dependency列表中记录有描述已发布pod库的依赖关系的数据。

进一步地，若所述依赖模式描述为路径依赖模式（业界又称之为path依赖），则对应的已发布pod库为进入开发状态的pod库；若所述依赖模式描述为版本依赖模式或者远端依赖模式，则对应的已发布pod库为未进入开发状态的pod库。

由此，基于所有已发布pod库的描述文件，从而快速地确定出了所有已发布pod库的依赖关系，无须每次执行pod库（如无须每次执行pod库中的pod install）去获取已发布pod库的依赖关系。

进一步地，在所述确定所述已发布pod库中进入开发状态的pod库，并获取所述进入开发状态的pod库的描述文件之后，步骤S103之前，还可以包括：从所述进入开发状态的pod库的描述文件中获取进入开发状态的pod库的名称，并将其增加到建立的进入开发状态的pod库列表中，从而通过列表的方式，有效地实现了对进入开发状态的pod库的维护。

本实施例中，所述添加可以为实时添加，即每确定出一个进入开发状态的pod库，就将对应的pod库的名称添加到进入开发状态的pod库列表中；所述添加也可以为在确定出所有进入开发状态的pod库之后再批量将对应的所有pod库的名称添加到进入开发状态的pod库列表。

具体地，可以从所述进入开发状态的pod库的描述文件中获取进入开发状态的pod库的名称。

S103、根据所述进入开发状态的pod库的描述文件，在所述依赖关系中查找出所述进入开发状态的pod库的依赖关系。

本实施例中，所述根据所述进入开发状态的pod库的描述文件，在所述依赖关系中查找出所述进入开发状态的pod库的依赖关系，包括：根据所述开发状态的pod库列表记录的进入开发状态的pod库的名称，在所述依赖关系中查找出所述进入开发状态的pod库的依赖关系，从而提高了依赖关系确定的速度和效率。

上述实施例中，考虑到后续pod库的发布，也可以在进入开发状态的pod库的描述文件中增加所述pod库的当前版本号，要发布的版本号以及源代码的存储地址，以便于完成pod库的开发后进行发布。

图2为本申请实施例一种pod库之间依赖关系的建立方法的流程示意图；如图2所示，本实施例提供的pod库之间依赖关系的建立方法包括：

S201、获取壳工程下已发布pod库的描述文件；

S202、通过对所述已发布pod库的描述文件进行解析，以建立所有已发布pod库的依赖关系。

上述图1实施例中的步骤S101可以包括步骤S201和S202。

具体地，所述通过对所述已发布pod库的描述文件进行解析，以建立所有已发布pod库的依赖关系，包括：针对每一已发布pod库，从所述每一已发布pod库的描述文件中提取对应pod库的名称以及其直接依赖的已发布pod库的名称；

以键值对的方式存储所有所述已发布pod库的名称以及其直接依赖的已发布pod库的名称，以建立所有所述已发布pod库的依赖关系。

进一步地，所述以键值对的方式存储所有所述已发布pod库的名称以及其直接依赖的已发布pod库的名称，以建立所有已发布pod库的依赖关系，包括：

针对每一已发布pod库，其名称作为键值对的key，其直接依赖的已发布pod库的名称作为value；

根据所有所述已发布pod库对应的所述key和所述value，建立所有已发布pod库的依赖关系。

进一步地，所述以键值对的方式存储所有所述已发布pod库的名称以及其直接依赖的已发布pod库的名称，以建立所有已发布pod库的依赖关系，还包括：

针对每一已发布pod库，确定其间接依赖的已发布pod库的名称，并将其间接依赖的已发布pod库的名称添加到所述value中，从而实现了基于同一对key-value即可记录直接依赖关系，又可以记录间接依赖关系。

本实施例中，针对每一已发布pod库，确定其间接依赖的已发布pod库的名称具体可以以递归遍历的方式来确定，比如，pod库1依赖pod库2，再去确定pod库2依赖的pod库（比如为pod库3），从而确定出pod库1间接依赖pod库3，以此类推，从而快速地确定出了已发布pod库的间接依赖关系。

此处，需要说明的是，上述图2所示实施例的方法，也可以作为上述图1所示实施例中的步骤。

图3为本申请实施例一种pod库之间依赖关系的确定装置的结构示意图；如图3所示，其包括：

依赖关系获取单元301，用于获取壳工程下所有已发布pod库的依赖关系，

pod库确定单元302，用于确定所述已发布pod库中进入开发状态的pod库，并获取所述进入开发状态的pod库的描述文件；

依赖关系筛选单元303，用于根据所述进入开发状态的pod库的描述文件，在所述依赖关系中查找出所述进入开发状态的pod库的依赖关系。

具体地，在一实施例中，所述pod库之间依赖关系的建立装置还包括：包括：

描述文件获取单元，用于获取所述壳工程下已发布pod库的描述文件；

依赖关系建立单元，用于通过对所述已发布pod库的描述文件进行解析，以建立所有已发布pod库的依赖关系。

可选地，在一实施例中，所述依赖关系建立单元具体用于针对每一已发布pod库，从所述每一已发布pod库的描述文件中提取对应pod库的名称以及其直接依赖的已发布pod库的名称；以及以键值对的方式存储所有所述已发布pod库的名称以及其直接依赖的已发布pod库的名称，以建立所有所述已发布pod库的依赖关系。

可选地，在一实施例中，所述依赖关系建立单元具体用于：针对每一已发布pod库，其名称作为键值对的key，其直接依赖的已发布pod库的名称作为value；以及根据所有所述已发布pod库对应的所述key和所述value，建立所有已发布pod库的依赖关系。

可选地，在一实施例中，所述依赖关系建立单元还用于针对每一已发布pod库，确定其间接依赖的已发布pod库的名称，并将其间接依赖的已发布pod库的名称添加到所述value中。

可选地，在一实施例中，所述pod库确定单元具体用于对所述已发布pod库的描述文件进行解析，从中获取所述已发布pod库的依赖模式描述，根据所述依赖模式描述，确定所述已发布pod库中进入开发状态的pod库。

可选地，在一实施例中，若所述依赖模式描述为路径依赖模式，则对应的已发布pod库为进入开发状态的pod库；若所述依赖模式描述为版本依赖模式或者远端依赖模式，则对应的已发布pod库为未进入开发状态的pod库。

具体地，在一实施例中，所述pod库之间依赖关系的建立装置还包括：添加单元，用于从所述进入开发状态的pod库的描述文件中获取进入开发状态的pod库的名称，并将其增加到建立的进入开发状态的pod库列表中；

对应地，所述依赖关系筛选单元具体用于根据所述开发状态的pod库列表记录的进入开发状态的pod库的名称，在所述依赖关系中查找出所述进入开发状态的pod库的依赖关系。

图4为本申请实施例一种pod库之间依赖关系的建立装置的结构示意图；如图4所示，其包括：

描述文件获取单元401，用于获取壳工程下已发布pod库的描述文件；

依赖关系建立单元402，用于通过对所述已发布pod库的描述文件进行解析，以建立所有已发布pod库的依赖关系。

本实施例中，有关描述文件获取单元401，依赖关系建立单元402的具体示例性描述可参见上述图3的记载。

图5为本申请实施例中依赖关系的处理系统结构示意图；如图5所示，其包括图3所述的确定装置，以及图4所述的建立装置。

本申请实施例提供一种计算机存储介质，所述计算机存储介质上存储有计算机可执行程序，所述计算机可执行程序被运行以实施本申请任一实施例所述的方法。

图6为本申请实施例一种电子设备的结构示意图；如图6所示，所述电子设备包括存储器601以及处理器602，所述存储器上用于存储计算机可执行程序，所述处理器用于运行所述计算机可执行程序以实施本申请任一实施例所述的方法。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分从网络上被下载和安装，和/或从可拆卸介质被安装。在该计算机程序被中央处理单元（CPU）执行时，执行本申请的方法中限定的上述功能。需要说明的是，本申请所述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器（RAM）、只读存储器（ROM）、可擦式可编程只读存储器（EPROM或闪存）、光纤、便携式紧凑磁盘只读存储器（CD-ROM）、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言或其组合来编写用于执行本申请的操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如”C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机（例如利用因特网服务提供商来通过因特网连接）。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定，例如，接收单元还可以被描述为“接收用户的网页浏览请求的单元”。

以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本申请中所涉及的发明范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离上述发明构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本申请中公开的（但不限于）具有类似功能的技术特征进行互相替换而形成的技术方案。