组件兼容性管理方法、装置、电子设备和存储介质与流程

1.本技术实施例涉及应用程序开发技术领域，尤其涉及一种组件兼容性管理方法、装置、电子设备和计算机存储介质。


背景技术：

2.在移动互联网技术的发展过程中，应用程序(application program，app)的功能日趋复杂，开发项目日趋庞大。面对用户业务、开发团队规模增加，在多个业务团队共同参与app开发时，为了提高基础功能模块的复用率，减少业务团队间的互相干扰，进行相对独立的功能开发和测试，组件化开发成为大型app开发的标准开发方式。随着功能组件和业务组件不断增多，组件化开发管理方法对应用程序项目的开发效率、进度、质量的影响越来越大，组件管理平台成为组件化开发不可缺少的部分。
3.在相关技术中，在组件化开发过程中，主要针对组件本身进行管理，缺少针对不同版本组件间的兼容性管理、组件依赖关系数据的管理；在对多个组件集成时，主要通过jenkins自动化集成进行编译层面的可靠性验证，缺少对所集成组件和引入的间接依赖组件的兼容性检查，在同一类型组件的多个不同版本的组件采用不同应用程序接口时，容易出现组件间的兼容性冲突问题。因此，如何提高组件化开发过程中组件兼容性管理的可靠性成为亟待解决的重要问题。


技术实现要素：

4.本技术实施例提供了一种组件兼容性管理方法、装置、电子设备和计算机存储介质，可以提高组件化开发过程中组件兼容性管理的可靠性。
5.本技术实施例提供的一种组件兼容性管理方法，包括：
6.根据应用程序中的多个组件间的依赖关系数据，获取所述多个组件中每个组件对应的数据节点的信息；
7.根据所述多个组件中每个组件的组件类型信息，确定每一组件类型对应的数据节点的信息的集合；
8.根据所述每一组件类型对应的数据节点的信息的集合和所述每一组件类型的每个组件采用的应用程序接口的等级信息，确定所述每一组件类型对应的多个组件在所述应用程序中是否兼容。
9.在一种实现方式中，所述根据所述每一组件类型对应的数据节点的信息的集合和所述每一组件类型的每个组件采用的应用程序接口的等级信息，确定所述每一组件类型对应的多个组件在所述应用程序中是否兼容，包括：
10.在所述集合中存在两个数据节点对应的组件采用的应用程序接口的等级信息不同时，确定所述两个数据节点对应的组件在所述应用程序中不兼容；
11.在所述集合中存在两个数据节点对应的组件采用的应用程序接口的等级信息相同时，确定所述两个数据节点对应的组件在所述应用程序中兼容。
12.在一种实现方式中，在确定所述每一组件类型对应的多个组件在所述应用程序中是否兼容后，所述方法还包括：
13.确定所述多个组件中的目标组件；所述目标组件为在所述应用程序中相同组件类型的至少两个互相不兼容的组件；
14.根据所述依赖关系数据获取所述目标组件对应的依赖关系信息，对所述依赖关系信息进行展示；
15.其中，所述依赖关系信息包括所述应用程序中相同组件类型的至少两个互相不兼容的组件对应的数据节点的信息。
16.在一种实现方式中，所述依赖关系信息还包括：所述目标组件对应的数据节点的父节点的信息和/或所述目标组件对应的数据节点的子节点的信息。
17.在一种实现方式中，所述方法还包括：
18.根据所述多个组件中每一个组件的标识信息，获取所述多个组件间的依赖关系数据。
19.在一种实现方式中，在确定所述每一组件类型对应的多个组件在所述应用程序中是否兼容后，所述方法还包括：
20.获取所述应用程序的配置信息；
21.在所述每一组件类型对应的多个组件在所述应用程序中相互兼容时，采用所述配置信息对所述应用程序进行配置。
22.在一种实现方式中，所述采用所述配置信息对所述应用程序进行配置，包括：
23.在第一次采用所述配置信息对所述应用程序进行配置时，根据所述配置信息生成所述应用程序的工程模板，根据所述工程模板对所述应用程序进行配置；
24.在第i次采用所述配置信息对所述应用程序进行配置时，采用所述配置信息对所述应用程序的工程模板进行更新；根据更新后的所述工程模板对所述应用程序进行配置，i大于1。
25.本技术实施例提供的一种组件兼容性管理装置，包括：
26.获取模块，用于根据应用程序中的多个组件间的依赖关系数据，获取所述多个组件中每个组件对应的数据节点的信息；
27.确定模块，用于根据所述多个组件中每个组件的组件类型信息，确定每一组件类型对应的数据节点的信息的集合；
28.处理模块，用于根据所述每一组件类型对应的数据节点的信息的集合和所述每一组件类型的每个组件采用的应用程序接口的等级信息，确定所述每一组件类型对应的多个组件在所述应用程序中是否兼容。
29.在一种实现方式中，所述处理模块，用于根据所述每一组件类型对应的数据节点的信息的集合和所述每一组件类型的每个组件采用的应用程序接口的等级信息，确定所述每一组件类型对应的多个组件在所述应用程序中是否兼容，包括：
30.在所述集合中存在两个数据节点对应的组件采用的应用程序接口的等级信息不同时，确定所述两个数据节点对应的组件在所述应用程序中不兼容；
31.在所述集合中存在两个数据节点对应的组件采用的应用程序接口的等级信息相同时，确定所述两个数据节点对应的组件在所述应用程序中兼容。
32.在一种实现方式中，所述处理模块，在确定所述每一组件类型对应的多个组件在所述应用程序中是否兼容后，还用于：
33.确定所述多个组件中的目标组件；所述目标组件为在所述应用程序中相同组件类型的至少两个互相不兼容的组件；
34.根据所述依赖关系数据获取所述目标组件对应的依赖关系信息，对所述依赖关系信息进行展示；
35.其中，所述依赖关系信息包括所述应用程序中相同组件类型的至少两个互相不兼容的组件对应的数据节点的信息。
36.在一种实现方式中，所述依赖关系信息还包括：所述目标组件对应的数据节点的父节点的信息和/或所述目标组件对应的数据节点的子节点的信息。
37.在一种实现方式中，所述获取模块，用于根据应用程序中的多个组件间的依赖关系数据，获取所述多个组件中每个组件对应的数据节点的信息，包括：
38.根据所述多个组件中每一个组件的标识信息和所述依赖关系数据，获取所述多个组件中每个组件对应的数据节点的信息。
39.在一种实现方式中，所述处理模块，在确定所述每一组件类型对应的多个组件在所述应用程序中是否兼容后，还用于：
40.获取所述应用程序的配置信息；
41.在所述每一组件类型对应的多个组件在所述应用程序中相互兼容时，采用所述配置信息对所述应用程序进行配置。
42.在一种实现方式中，所述处理模块，用于采用所述配置信息对所述应用程序进行配置，包括：
43.在第一次采用所述配置信息对所述应用程序进行配置时，根据所述配置信息生成所述应用程序的工程模板，根据所述工程模板对所述应用程序进行配置；
44.在第i次采用所述配置信息对所述应用程序进行配置时，采用所述配置信息对所述应用程序的工程模板进行更新；根据更新后的所述工程模板对所述应用程序进行配置，i大于1。
45.本技术实施例提供一种电子设备，所述电子设备包括存储器、处理器及存储在存储器上可在处理器上运行的计算机程序，所述处理器执行所述程序时实现前述一个或多个技术方案提供的组件兼容性管理方法。
46.本技术实施例提供一种计算机存储介质，所述计算机存储介质存储有计算机程序；所述计算机程序被执行后能够实现前述一个或多个技术方案提供的组件兼容性管理方法。
47.基于本技术提供的组件兼容性管理方法，根据应用程序中的多个组件间的依赖关系数据，获取多个组件中每个组件对应的数据节点的信息；根据多个组件中每个组件的组件类型信息，确定每一组件类型对应的数据节点的信息的集合；根据每一组件类型对应的数据节点的信息的集合和每个组件采用的应用程序接口的等级信息，确定每一组件类型对应的多个组件在所述应用程序中是否兼容。因此，可以检查出同一组件类型的多个组件采用不同应用程序接口出现的兼容性冲突问题，提高组件化开发过程中组件兼容性管理的可靠性。
48.应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，而非限制本技术。
附图说明
49.图1为本技术实施例提供的一种组件兼容性管理方法的应用场景图；
50.图2为本技术实施例提供的另一种组件兼容性管理方法的应用场景图；
51.图3为本技术实施例提供的一种组件兼容性管理方法的流程示意图；
52.图4为本技术实施例提供的一种组件依赖关系的结构示意图；
53.图5为本技术实施例提供的一种关于组件聚类结果的示意图；
54.图6为本技术实施例提供的一种组件间的依赖关系链的示意图；
55.图7为本技术实施例提供的另一种组件兼容性管理方法的流程示意图；
56.图8为本技术实施例提供的又一种组件兼容性管理方法的流程示意图；
57.图9为本技术实施例提供的一种组件兼容性管理装置的示意图；
58.图10为本技术实施例提供的一种电子设备的结构示意图。
具体实施方式
59.以下结合附图及实施例，对本技术进行进一步详细说明。应当理解，此处所提供的实施例仅仅用以解释本技术，不用于限定本技术。另外，以下所提供的实施例是用于实施本技术的部分实施例，而非提供实施本技术的全部实施例，在不冲突的情况下，本技术实施例记载的技术方案可以任意组合的方式实施。
60.参见图1，本技术实施例提供的一种组件兼容性管理方法的应用场景图。在组件化开发过程中，业务组件可以根据公司具体业务而独立形成一个的工程；在业务组件中，main组件用于指定应用程序的启动页面、主界面。功能组件提供开发应用程序的某些基础功能；在功能组件中，common组件用于提供支撑业务组件的基础功能，例如，网络请求功能。
61.在实际应用中，可以根据业务组件面向的业务类型的不同，对业务组件的组件类型作进一步区分，根据功能组件实现的功能类型的不同，对功能组件的组件类型作进一步区分。
62.在示例中，功能组件的组件类型可以包括以下类型中的任一项：网络请求组件、视频推送组件、图片加载组件、自动更新组件、二维码组件、社交分享组件。
63.参见图2，本技术实施例提供的组件兼容性管理方法，可以应用于app组件管理平台，在app组件管理平台中，可以包括以下模块：组件管理模块、组件发布模块、组件依赖关系管理模块、组件依赖关系验证模块、组件集成模块、gradle插件。
64.其中，组件管理模块用于实现组件的信息展示、分类管理、版本管理、组件说明展示等方面；组件发布模块用于实现组件的编译、打包、上传，将组件待发布版本信息、功能信息等有效数据进行收集，传递到组件管理模块进行展示；app组件集成模块用于管理不同app版本下所集成的组件和组件版本，将管理员维护的组件及版本集成到app的工程中，供开发团队使用或者进行自动化集成打包。
65.在本技术实施例中，基于gradle插件实现依赖关系数据的采集功能，配合依赖关系管理模块完成组件依赖关系的数据收集、存储、查询、展示、验证和管理。
66.在示例中，组件依赖关系验证模块，可以将app集成的所有组件的依赖关系进行验证，基于应用程序接口(application programming interface，api)的等级信息和组件依赖关系数据对组件依赖关系进行兼容性检查。针对组件间存在不兼容的问题，将问题反馈到组件集成模块，同时向用户发送提示信息。
67.在示例中，在组件发布时，可以由用户录入某一组件的待发布版本的apilevel。apilevel的定义规则可以采用以下方式：在待发布版本和上一版本兼容时，待发布版本的apilevel值保持和上一版本一致；在待发布版本和上一版本不兼容时，待发布版本的apilevel值为上一版本apilevel值 1。
68.在示例中，在待发布版本和上一版本符合预设条件时，则认定待发布版本是否和上一版本不兼容；在待发布版本和上一版本不符合预设条件时，则认定待发布版本和上一版本兼容。
69.这里，预设条件包括以下情况中的任一项：应用程序接口存在删减的情况、api存在废弃的情况、api的功能发生变化、api的使用方法发生变化。api的使用方法可以包括以下任一种情况：api的传参方式、api的调用方式、api的调用顺序。
70.图3示出了本技术实施例提供的组件兼容性管理方法的示意性流程图。参见图3，本技术实施例提供的组件兼容性管理方法，应用于app组件管理平台，可以包括以下步骤：
71.步骤a301：根据应用程序中的多个组件间的依赖关系数据，获取多个组件中每个组件对应的数据节点的信息。
72.这里，多个组件间的依赖关系数据可以包括：多个组件中每个组件的标识信息、每个组件所依赖的组件的信息。其中，组件的标识信息可以包括组件的组件类型信息、组件的版本信息。
73.在示例中，依赖关系数据为树形结构的数据，在树形结构的数据中存在多个数据节点，每一个数据节点存在父节点和/或子节点。数据节点间存在数据调用关系，例如，数据节点a存在对数据节点a的子节点的数据调用，数据节点a的父节点存在对数据节点a的数据调用。
74.对于依赖关系数据中的任一数据节点，每一个数据节点对应应用程序中的一个组件。相应地，对于应用程序的多个组件，每一个组件对应依赖关系数据中的一个数据节点。
75.应理解，在应用程序中，多个组件中的部分组件间存在相互依赖关系，即某一组件的功能实现需要另外一个或多个组件的支持。依赖关系数据反映了应用程序中的多个组件间的依赖关系信息，在依赖关系数据中，多个数据节点中的每一个数据节点对应一个组件。
76.在示例中，基于依赖关系数据得到多个组件中每个组件对应的数据节点的依赖关系树，根据每个组件的标识信息确定组件在依赖关系树中的数据节点的信息。这里，数据节点的信息可以包括数据节点对应的组件的组件类型信息、数据节点对应的组件的组件版本信息。
77.在示例中，参见图4，应用程序包括多个组件，多个组件在应用程序中对应不同的数据节点，多个数据节点中的部分数据节点存在依赖关系。这里，依赖关系可以包括数据节点和数据节点对应的父节点的关联关系、数据节点和数据节点对应的子节点的关联关系。
78.例如，参见图4，应用程序包括组件a、组件b、组件c、组件d、组件e、组件f，其中，组件d对应的数据节点作为组件e对应的数据节点的父节点，组件d的功能实现依赖组件e；组
件a对应的数据节点作为组件d对应的数据节点的父节点，组件a的功能实现依赖组件d。
79.在实际应用中，组件a、组件b可以分别属于两个不同类型的业务组件，业务组件间相互独立；组件c、组件d、组件e、组件f可以分别属于不同类型的功能组件。在组件化开发过程中，为了减少重复开发和维护工作量，可以对部分功能组件进行组件复用。
80.在示例中，组件e存在组件复用的情况，例如，组件d依赖组件e、组件b依赖组件e。其中，组件d依赖版本3，apilevel2的组件e，组件b依赖版本1，apilevel1的组件e。
81.在实际应用中，针对组件e存在组件复用的情况，为了降低不同apilevel的组件e的耦合性，在应用程序编译时可以将组件b、组件d复用的组件e统一为版本3，apilevel2的组件e。
82.在示例中，调用gradle api获取应用程序的依赖关系信息，在依赖关系信息中可以保留依赖方式为应用程序在编译时依赖的数据，提取得到组件标识信息对应的数据节点的信息。这里，依赖方式可以按照应用程序不同开发阶段进行划分。
83.在示例中，采用gradle依赖管理插件收集组件的依赖关系数据，通过组件依赖关系管理模块提供的接口发送到服务器。在服务器中基于组件的依赖关系，采用组件依赖关系管理模块对组件的依赖关系数据进行存储和管理。
84.步骤a302：根据多个组件中每个组件的组件类型信息，确定每一组件类型对应的数据节点的信息的集合。
85.在示例中，对于依赖关系数据中的任一数据节点，可以根据组件类型信息，将任一组件类型对应的所有数据节点，归类到同一个集合中。
86.在示例中，参见图5，在应用程序中，a、b、c、d、e、f用于区分不同的组件，组件a、组件b、组件c、组件d、组件e、组件f可以分别对应不同的组件类型。
87.在示例中，在根据多个组件中每个组件的组件类型信息，对组件a、组件b、组件c、组件d、组件e、组件f对应的数据节点进行聚类；根据对多个组件中每个组件对应的数据节点进行聚类的聚类结果，确定每一组件类型对应的数据节点的信息的集合。
88.在示例中，参见图5，c1、c2、c3、c4、c5、c6分别用于表征对组件a、组件b、组件c、组件d、组件e、组件f的聚类结果。其中，聚类c3可以是对版本2-apilevel1的组件c、版本1-apilevel1的组件c对应的数据节点的聚类结果。即，组件类型e对应的数据节点的信息的集合。
89.步骤a303：根据每一组件类型对应的数据节点的信息的集合和每一组件类型的每个组件采用的应用程序接口的等级信息，确定每一组件类型对应的多个组件在所述应用程序中是否兼容。
90.这里，应用程序接口的等级信息采用api level值进行定义，api level值的范围为自然数，是用于描述软件开发工具包(software development kit，sdk)开放给移动插件的api等级，每个api level包含有一组sdk，每个sdk包含着一组api的集合。
91.应理解，移动插件能够与移动应用兼容，需要满足以下条件：移动应用配置的api level》＝移动插件的api level。
92.在示例中，参见图5，聚类c3对应的集合可以是版本2-apilevel1的组件c、版本1-apilevel1的组件c对应的数据节点的信息的集合。聚类c5对应的集合可以是版本1-apilevel1的组件e、版本3-apilevel2的组件e对应的数据节点的信息的集合。
93.在示例中，遍历数据集合信息对应的多个数据节点，检查同一类型组件对应的多个数据节点的信息的集合中是否存在不同apilevel值的数据节点的情况。在同一类型组件对应的多个数据节点的信息的集合中存在两个数据节点对应的apilevel值不同时，确定两个数据节点对应的组件的兼容性信息为依赖冲突。
94.这里，依赖冲突可以定义为应用程序直接依赖、间接依赖的所有组件中不兼容的组件。依赖冲突的判断标准是组件版本间的apilevel值不同。即，对于同一组件类型的多个不同版本的组件，不同版本的组件对应的apilevel值不同，则不同版本的组件存在依赖冲突。
95.在实际应用中，针对应用程序中存在组件复用的情况，为了降低不同apilevel值的组件的耦合性，在应用程序编译时可以将不同apilevel值的组件标准化为相同apilevel值的组件。例如，将apilevel1的组件e、apilevel2的组件e标准化为apilevel2的组件。
96.基于本技术提供的组件兼容性管理方法，根据应用程序中的多个组件间的依赖关系数据，获取多个组件中每个组件对应的数据节点的信息；根据多个组件中每个组件的组件类型信息，确定每一组件类型对应的数据节点的信息的集合；根据每一组件类型对应的数据节点的信息的集合和每一组件类型的每个组件采用的应用程序接口的等级信息，确定多个组件在所述应用程序中的兼容性。因此，可以检查出同一组件类型的多个组件采用不同应用程序接口出现的兼容性冲突问题，提高组件化开发过程中组件兼容性管理的可靠性。
97.在实际应用中，上述步骤a301至步骤a303可以采用处理器实现，上述处理器可以为专用集成电路(application specific integrated circuit，asic)、数字信号处理器(digital signal processor，dsp)、数字信号处理装置(digital signal processing device，dspd)、可编程逻辑装置(programmable logic device，pld)、现场可编程逻辑门阵列(field programmable gate array，fpga)、中央处理器(central processing unit，cpu)、控制器、微控制器、微处理器中的至少一种。
98.在一种实现方式中，在上述步骤a303中，所述根据所述每一组件类型对应的数据节点的信息的集合和所述每一组件类型的每个组件采用的应用程序接口的等级信息，确定所述每一组件类型对应的多个组件在所述应用程序中是否兼容，包括：
99.在所述集合中存在两个数据节点对应的组件采用的应用程序接口的等级信息不同时，确定所述两个数据节点对应的组件在所述应用程序中不兼容；
100.在所述集合中存在两个数据节点对应的组件采用的应用程序接口的等级信息相同时，确定所述两个数据节点对应的组件在所述应用程序中兼容。
101.在示例中，在对api level等级信息进行管理时，可以根据api level等级信息，对相同组件类型的、不同版本的组件进行兼容性区分。在不同版本的组件的apilevel值相同时，则确定不同版本的组件兼容；在不同版本的组件的apilevel值不同时，则确定不同版本的组件不兼容。
102.在示例中，在聚类c3中，版本2-apilevel1的组件c、版本1-apilevel1的组件c采用的应用程序接口的等级信息相同，在此情况下，确定版本2-apilevel1的组件c、版本1-apilevel1的组件c在应用程序中兼容。
103.在示例中，在聚类c5中，版本1-apilevel1的组件e、版本1-apilevel1的组件e采用
的应用程序接口的等级信息相同，在此情况下，确定版本1-apilevel1的组件e、版本3-apilevel2的组件e在应用程序中不兼容。
104.在一种实现方式中，上述组件兼容性管理方法，在确定所述每一组件类型对应的多个组件在所述应用程序中是否兼容后，还可以包括以下步骤：
105.步骤a1：确定所述多个组件中的目标组件；所述目标组件为在所述应用程序中相同组件类型的至少两个互相不兼容的组件。
106.在示例中，根据多个组件在应用程序中的兼容性信息，确定多个组件中的目标组件包括：版本1-apilevel1的组件e、版本3-apilevel2的组件e。
107.在示例中，检查出存在兼容性问题的两个数据节点，根据目标数据节点对应的父节点和/或子节点，推导出目标数据节点的依赖链信息。
108.在本技术实施例中，基于组件的apilevel来实现组件不同版本间的兼容性区分和管理，根据多个组件间的依赖关系数据，对应用程序的多个组件进行兼容性检查，确定存在潜在依赖冲突的目标组件，可以在无人工参与的情况下，检查出app集成组件时的潜在依赖冲突问题，从而，提高对应用程序中的组件进行组件兼容性分析的可靠性。
109.步骤a2：根据所述依赖关系数据获取所述目标组件对应的依赖关系信息，对所述依赖关系信息进行展示；其中，所述依赖关系信息包括所述应用程序中相同组件类型的至少两个互相不兼容的组件对应的数据节点的信息。
110.在示例中，参见图6，根据依赖关系数据获取版本1-apilevel1的组件e、版本3-apilevel2的组件e对应的依赖关系信息，对版本1-apilevel1的组件e、版本3-apilevel2的组件e对应的依赖关系信息进行展示。
111.在示例中，在相同组件集合中存在不同apilevel值的数据节点时，向用户展示目标数据节点的依赖链信息。这里，目标数据节点的依赖链信息可以是检查出的存在兼容性问题的依赖链的信息。
112.应理解，基于确定多个组件在所述应用程序中的兼容性，可以从任意一个数据节点推导出完整的依赖链信息，对存在兼容性冲突的目标组件进行展示，提示开发人员对目标组件对应的依赖关系链进行检查确认。
113.在实际应用中，基于开发gradle插件，可以在工程构建过程中加入组件依赖关系数据的收集功能。基于组件依赖关系管理模块提供的数据检索功能，在平台页面上进行组件依赖关系的展示和管理。
114.在一种实现方式中，在上述组件兼容性管理方法中，所述依赖关系信息还包括：所述目标组件对应的数据节点的父节点的信息和/或所述目标组件对应的数据节点的子节点的信息。
115.在示例中，参见图6，版本1-apilevel1的组件e对应的依赖关系信息还包括：版本1-apilevel1的组件e对应的数据节点的父节点的信息和/或版本1-apilevel1的组件e对应的数据节点的子节点的信息。
116.在示例中，参见图6，版本3-apilevel2的组件e对应的依赖关系信息还包括：版本3-apilevel2的组件e对应的数据节点的父节点的信息和/或版本3-apilevel2的组件e对应的数据节点的子节点的信息。
117.在一种实现方式中，在上述步骤a301中，所述根据应用程序中的多个组件间的依
赖关系数据，获取所述多个组件中每个组件对应的数据节点的信息，可以包括以下步骤：
118.根据所述多个组件中每一个组件的标识信息和所述依赖关系数据，获取所述多个组件中每个组件对应的数据节点的信息。
119.在示例中，根据应用程序在编译时依赖的数据，获取应用程序中的多个组件间的依赖关系数据。这里，应用程序在编译时依赖的数据可以是应用程序在编译时依赖的多个组件对应的数据节点的数据。
120.在实际应用中，针对应用程序中的多个组件，可以采用组件标识信息对多个组件中的每一个组件进行区分。这里，组件的标识信息可以包括：group属性标识、name属性标识、version属性标识。
121.进一步地，基于依赖关系数据得到多个组件中每个组件对应的数据节点的依赖关系树，根据每个组件的标识信息确定组件在依赖关系树中的数据节点的信息。
122.应理解，为了声明组件所属项目的依存关系，最常见的依赖项称为外部依赖项，可从外部存储库找到外部依赖项。
123.在示例中，采用以下属性来标识外部依赖项：group属性标识，用于标识依赖项的组、name属性标识，用于标识依赖项的名称、version属性标识，用于标识外部依赖项的版本。
124.在示例中，外部存储库可以采用项目管理和构建工具maven仓库，在此情况下，group属性标识可以是maven仓库中定义的groupid。name属性标识可以是maven仓库中定义的artifactid。version属性可以是maven仓库中定义的version。
125.在maven仓库中，groupid和artifactid构成了一个组件所属项目的jar包的坐标，坐标是组件所属项目的jar包的唯一标识，maven根据坐标在仓库中找到应用程序的多个组件所属项目的jar包。
126.其中，artifactid对应组件所属项目的名称，即组件所属项目根目录的名称，是组件所属项目的标识符。groupid对应main目录里java的目录结构，是组件所属项目的项目组织的标识符。version对应版本信息。
127.在示例中，groupid可以包括域信息、公司名称。域信息中的域可以包括org、com、cn，org为非营利组织所属域，com为商业组织所属域。
128.在示例中，采用组织标识(groupid)、项目标识(artifactid)、版本号(version)的组合，对于每个组件对应的数据节点进行标识。根据多个组件中每一个组件的标识信息，获取多个组件间的依赖关系数据。
129.在示例中，在依赖关系数据中，可以包括组件对应的数据节点的信息、组件对应的数据节点的父节点的信息、组件对应的数据节点的子节点的信息。
130.在实际应用中，项目对象模型(program object model，pom)文件中存储有组件所属项目的依赖关系信息，对maven工程中的pom文件进行解析，得到多个组件间的依赖关系数据。
131.这里，pom文件文件用于定义中间件与第三方组件、中间件与中间件的依赖关系。pom文件是maven工程的核心文件，pom文件中通过dependencymanagement来声明依赖，通过dependencies元素来管理依赖。
132.在一种实现方式中，在上述组件兼容性管理方法，在确定所述每一组件类型对应
的多个组件在所述应用程序中是否兼容后，还可以包括以下步骤：获取所述应用程序的配置信息；在所述每一组件类型对应的多个组件在所述应用程序中相互兼容时，采用所述配置信息对所述应用程序进行配置。
133.在示例中，在app组件集成管理模块中应用组件配置信息，在组件配置信息生效前，调用依赖关系验证检查模块，基于组件采用的应用程序接口的apilevel值和依赖关系数据，在多个组件间的依赖关系树中，对同一组件类型的多个组件对应的apilevel值进行对比检查，确定多个组件在应用程序中互相兼容，排除多个组件间存在的潜在依赖冲突。
134.在示例中，在多个组件在应用程序中互相不兼容时，不采用配置信息对应用程序进行配置，向用户报告依赖冲突相关的问题细节。在多个组件在应用程序中互相兼容时，则采用所述配置信息对应用程序进行配置。
135.在一种实现方式中，在上述组件兼容性管理方法中，所述采用所述配置信息对所述应用程序进行配置，包括：
136.在第一次采用所述配置信息对所述应用程序进行配置时，根据所述配置信息生成所述应用程序的工程模板，根据所述工程模板对所述应用程序进行配置。
137.在示例中，在第一次采用配置信息对应用程序进行配置时，创建应用程序的代码仓库；根据配置信息生成应用程序的代码工程模版，上传组件相应的程序代码到代码仓库，根据代码工程模板对应用程序进行配置。
138.这里，代码仓库可以采用以下仓库中的任一种：github仓库、gitlab仓库、码云仓库、coding.net仓库。
139.在一种实现方式中，在上述组件兼容性管理方法中，所述采用所述配置信息对所述应用程序进行配置，包括：
140.在第i次采用所述配置信息对所述应用程序进行配置时，采用所述配置信息对所述应用程序的工程模板进行更新；根据更新后的所述工程模板对所述应用程序进行配置，i大于1。
141.基于前述实施例相同的技术构思，参见图7，本技术实施例提供的组件兼容性管理方法，应用于app组件管理平台，可以包括以下步骤：
142.步骤a701：根据组件的基本信息创建代码仓库。
143.在示例中，基于组件管理模块创建组件，获取组件的基本信息，根据组件的基本信息创建代码仓库。这里，组件的基本信息可以包含以下信息中的任一项：组件的名称、组件的说明、代码仓库的名称、代码使用主包名、组件的标识信息。
144.步骤a702：获取应用程序的组件相应的程序代码。
145.在示例中，在开发者完成组件开发时，可以由开发者提交组件相应的程序代码至代码仓库。相应地，代码仓库对开发者提交的组件相应的程序代码进行存储。
146.步骤a703：根据应用程序接口的等级信息区分不同版本的组件间是否兼容。
147.在示例中，根据组件发布时使用的代码分支，采用api level等级信息区分不同版本的组件间是否兼容。
148.应理解，代码分支可以在特定版本的提交点上从主干创建出来，用来进行上线部署和hotfix。这里，hotfix是微软公司研发的一个程序，针对某一个具体的系统漏洞或安全问题而发布的专门解决该漏洞或安全问题，通常称为修补程序。
149.步骤a704：完成组件发布任务。
150.在实际应用中，可以由用户录入不同版本的组件的api level等级信息，在api level等级信息录入完毕后，由用户提交组件发布任务。
151.在示例中，采用组件发布模块获取组件的版本信息，组件的版本信息可以包括组件的版本号、组件的版本说明。
152.进一步地，采用jenkins集成环境的自动化job完成组件发布任务。这里，jenkins是一个开源软件项目，是基于java开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件项目可以进行持续集成。
153.在示例中，组件发布任务可以包括以下任务内容中的任一项：
154.从代码仓库中拉取代码、编译代码、打包代码、上传代码至maven、调用gradle插件收集组件的依赖关系数据。
155.步骤a705：获取组件的依赖关系数据。
156.步骤a706：根据app项目的版本信息，确定app项目对应的组件信息。
157.在示例中，采用app组件集成管理模块创建app项目，在app项目中管理app版本，对于每一个版本的app项目，可以根据app项目的版本信息，确定app项目对应的组件信息。
158.这里，组件信息可以包括以下信息：组件名称信息、组件版本信息。其中，组件信息可以由组件管理模块提供。
159.步骤a707：根据组件的依赖关系数据，对app项目对应的组件信息进行兼容性检查。
160.步骤a708：判断是否属于第一次采用配置信息对应用程序进行配置。
161.在示例中，确定属于第一次采用配置信息对应用程序进行配置时，执行以下步骤a709，否则，执行以下步骤a710。
162.步骤a709：根据配置信息生成应用程序的代码工程模版，根据代码工程模板对应用程序进行配置。
163.步骤a710：采用配置信息对代码工程模板进行更新，根据更新后的代码工程模板对应用程序进行配置。
164.这里，关于步骤a701至步骤a710的实现过程，详见以上步骤a301至上述步骤a303，此处不作赘述。
165.基于前述实施例相同的技术构思，参见图8，本技术提供的一种组件兼容性管理方法，可以包括以下步骤：
166.步骤a801：开发app组件管理平台中的gradle插件。
167.在示例中，基于groovy语言开发符合标准的gradle插件，这里，对于安卓操作系统中，gradle插件可以为android plugin for gradle。gradle插件可以包括以下功能单元：获取单元、处理单元、验证单元、上传单元。
168.其中，获取单元，用于调用gradle插件的应用程序接口获取组件的依赖关系信息，处理单元，用于保留依赖方式为编译时依赖的数据，提取依赖关系信息中的groupid、artifactid、version信息，生成json格式数据。这里，json是一种与语言无关的数据交换的格式。
169.验证单元，用于按照预设规则进行验证。上传单元，用于将json格式数据通过组件
依赖关系管理模块发送到服务器。这里，依赖关系信息中的每一条数据包含groupid、artifactid、version的元数据信息。
170.在示例中，gradle插件采用以下程序代码获取组件的依赖关系信息：
[0171][0172][0173]
步骤a802：将gradle插件集成到组件发布模块。
[0174]
在示例中，组件依赖关系管理模块提供接口，用于将json格式数据发送到服务器，由服务器对组件依赖关系数据进行存储。gradle插件可以集成于组件发布的构建过程中，实现对组件依赖关系数据的收集，将数据上传到组件依赖关系管理模块进行数据存储。
[0175]
在示例中，将gradle插件集成到组件发布模块，在jenkins执行发布构建时调用gradle插件，收集组件依赖关系数据，上传组件依赖关系数据到组件依赖关系管理模块。
[0176]
步骤a803：存储组件依赖关系数据。
[0177]
在示例中，组件依赖关系管理模块存储组件依赖关系数据，同时，提供组件依赖关系数据相关的数据检索功能。
[0178]
步骤a804：根据组件依赖关系数据，在平台页面上对组件依赖关系进行展示、管理。
[0179]
这里，关于步骤a801至步骤a804的实现过程，详见以上步骤a301至上述步骤a303，
此处不作赘述。
[0180]
基于前述实施例相同的技术构思，参见图9，本技术实施例提供的组件兼容性管理装置，可以包括：
[0181]
获取模块901，用于根据应用程序中的多个组件间的依赖关系数据，获取所述多个组件中每个组件对应的数据节点的信息；
[0182]
确定模块902，用于根据所述多个组件中每个组件的组件类型信息，确定每一组件类型对应的数据节点的信息的集合；
[0183]
处理模块903，用于根据所述每一组件类型对应的数据节点的信息的集合和所述每一组件类型的每个组件采用的应用程序接口的等级信息，确定所述每一组件类型对应的多个组件在所述应用程序中是否兼容。
[0184]
在一种实现方式中，所述处理模块903，用于根据所述每一组件类型对应的数据节点的信息的集合和所述每一组件类型的每个组件采用的应用程序接口的等级信息，确定所述每一组件类型对应的多个组件在所述应用程序中是否兼容，包括：
[0185]
在所述集合中存在两个数据节点对应的组件采用的应用程序接口的等级信息不同时，确定所述两个数据节点对应的组件在所述应用程序中不兼容；
[0186]
在所述集合中存在两个数据节点对应的组件采用的应用程序接口的等级信息相同时，确定所述两个数据节点对应的组件在所述应用程序中兼容。
[0187]
在一种实现方式中，所述处理模块903，在确定所述每一组件类型对应的多个组件在所述应用程序中是否兼容后，还用于：
[0188]
确定所述多个组件中的目标组件；所述目标组件为在所述应用程序中相同组件类型的至少两个互相不兼容的组件；
[0189]
根据所述依赖关系数据获取所述目标组件对应的依赖关系信息，对所述依赖关系信息进行展示；
[0190]
其中，所述依赖关系信息包括所述应用程序中相同组件类型的至少两个互相不兼容的组件对应的数据节点的信息。
[0191]
在一种实现方式中，所述依赖关系信息还包括：所述目标组件对应的数据节点的父节点的信息和/或所述目标组件对应的数据节点的子节点的信息。
[0192]
在一种实现方式中，所述获取模块901，用于根据应用程序中的多个组件间的依赖关系数据，获取所述多个组件中每个组件对应的数据节点的信息，包括：根据所述多个组件中每一个组件的标识信息和所述依赖关系数据，获取所述多个组件中每个组件对应的数据节点的信息。
[0193]
在一种实现方式中，所述处理模块903，在确定所述每一组件类型对应的多个组件在所述应用程序中是否兼容后，还用于：获取所述应用程序的配置信息；
[0194]
在所述每一组件类型对应的多个组件在所述应用程序中相互兼容时，采用所述配置信息对所述应用程序进行配置。
[0195]
在一种实现方式中，所述处理模块903，用于采用所述配置信息对所述应用程序进行配置，包括：
[0196]
在第一次采用所述配置信息对所述应用程序进行配置时，根据所述配置信息生成所述应用程序的工程模板，根据所述工程模板对所述应用程序进行配置；
[0197]
在第i次采用所述配置信息对所述应用程序进行配置时，采用所述配置信息对所述应用程序的工程模板进行更新；根据更新后的所述工程模板对所述应用程序进行配置，i大于1。
[0198]
在一些实施例中，本技术实施例提供的装置具有的功能或包含的模块可以用于执行上文方法实施例描述的方法，其具体实现可以参照上文方法实施例的描述，为了简洁，这里不再赘述。
[0199]
基于前述实施例相同的技术构思，参见图10，本技术实施例提供的电子设备1000，可以包括：存储器1010和处理器1020；其中，
[0200]
存储器1010，用于存储计算机程序和数据；
[0201]
处理器1020，用于执行存储器中存储的计算机程序，以实现前述实施例中的任意一种组件兼容性管理方法。
[0202]
在实际应用中，上述存储器1010可以是易失性存储器(volatile memory)，示例性地ram；或者非易失性存储器(non-volatile memory)，示例性地rom，快闪存储器(flash memory)，硬盘(hard disk drive，hdd)或固态硬盘(solid-state drive，ssd)；或者上述种类的存储器的组合。上述存储器1010可以向处理器1020提供指令和数据。
[0203]
上文对各个实施例的描述倾向于强调各个实施例间的不同处，其相同或相似处可以互相参考，为了简洁，本文不再赘述
[0204]
本技术所提供的各方法实施例中所揭露的方法，在不冲突的情况下可以任意组合，得到新的方法实施例。
[0205]
本技术所提供的各产品实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的产品实施例。
[0206]
本技术所提供的各方法或设备实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的方法实施例或设备实施例。
[0207]
在本技术所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，示例性地，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。
[0208]
上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元，即可以位于一个地方，也可以分布到多个网格单元上；可以根据实际的可以选择其中的部分或全部单元来实现本实施例方案的目的。
[0209]
另外，在本技术各实施例中的各功能单元可以全部集成在一个处理模块中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
[0210]
本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤。
[0211]
以上，仅为本技术的具体实施方式，但本技术的保护范围不局限于此，任何熟悉本
技术领域的技术人员在本技术揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本技术的保护范围内。因此，本技术的保护范围应以权利要求的保护范围为准。