资源库处理方法、装置、电子设备及存储介质与流程

1.本公开涉及计算机技术领域，尤其涉及一种资源库处理方法、装置、电子设备、存储介质及程序产品。


背景技术：

2.近年来，随着互联网技术的发展，在应用程序中增加的服务项目或功能越来越多，应用程序或应用产品模块的规模也随之不断增加，模块内部的很多组件也越来越复杂，很多庞大的组件就会变得越来越不好维护。因此经常需要定期的拆解各种模块，进行优化配置处理。
3.目前对应用程序模块的优化配置工作，往往需要技术人员对模块中的各个组件、组件下的各个文件逐个进行分析，然后再按照分析结果进行优化配置，效率较低。


技术实现要素：

4.本公开提供一种资源库处理方法、装置、电子设备、存储介质及程序产品，以至少解决相关技术中对应用程序模块的优化配置工作效率较低的技术问题。本公开的技术方案如下：
5.根据本公开实施例的第一方面，提供一种资源库处理方法，包括：
6.确定应用程序资源库中各个文件之间的依赖关系；所述依赖关系表示文件在使用过程中的调用关系；
7.根据所述各个文件之间的依赖关系，将所述各个文件划分至多个层级的组件中，并生成所述各个文件的初始配置信息；所述初始配置信息用于记录所述各个文件的移动路径，每个层级对应不同的文件复杂程度；
8.基于预设的配置信息影响因素，对目标组件中文件的初始配置信息进行修正，得到修正后配置信息；所述目标组件表示复杂程度符合预设条件的层级的组件；
9.通过所述各个组件中除所述目标组件之外的其余组件对应的初始配置信息，以及所述目标组件对应的修正后配置信息，对所述应用程序资源库中的各个文件进行重新配置，得到所述应用程序资源库对应的重构资源库。
10.在一示例性实施例中，所述根据所述各个文件之间的依赖关系，将所述各个文件划分至多个层级的组件中，包括：
11.根据所述各个文件之间的依赖关系，确定所述各个文件的依赖关系数目；
12.根据所述依赖关系数目，将所述各个文件划分至多个层级的组件中。
13.在一示例性实施例中，所述基于预设的配置信息影响因素，对目标组件中文件的初始配置信息进行修正，得到修正后配置信息，包括：
14.基于所述配置信息影响因素，从所述目标组件的文件中确定出待修正文件和所述待修正文件对应的修正方式；所述修正方式包括移动路径的修改、文件的拆分和文件的合并中的至少一种；
15.根据所述修正方式，对所述待修正文件的初始配置信息进行修正，得到所述修正后配置信息。
16.在一示例性实施例中，在基于预设的配置信息影响因素，对目标组件中文件的初始配置信息进行修正，得到修正后配置信息之后，还包括：
17.获取更新的应用程序资源库，并将所述更新的应用程序资源库与所述应用程序资源库进行对比；
18.在对比得到新的文件的情况下，确定所述新的文件对应的依赖关系，根据所述新的文件对应的依赖关系对所述目标组件对应的修正后配置信息和/或所述其余组件对应的初始配置信息进行再次修正，得到新的修正后配置信息；
19.通过所述新的修正后配置信息对所述更新的应用程序资源库中的各个文件进行重新配置，得到所述应用程序资源库对应的重构资源库。
20.在一示例性实施例中，在得到所述应用程序资源库对应的重构资源库之后，还包括：
21.将所述应用程序资源库中各个文件对应的引用信息替换为所述重构资源库中对应的引用信息。
22.在一示例性实施例中，在得到所述应用程序资源库对应的重构资源库之后，还包括：
23.获取所述重构资源库中各个组件对应的依赖关系；每个组件中包括多个文件；
24.基于各个文件之间的依赖关系和各个组件对应的所述依赖关系，获取各个组件的直接依赖组件数、递归依赖组件数和各个组件下文件的文件特征；
25.基于所述直接依赖组件数、所述递归依赖组件数和所述文件特征，确定各个组件的运行状态。
26.在一示例性实施例中，在基于所述直接依赖组件数、所述递归依赖组件数和所述文件特征，确定各个组件的运行状态之后，还包括：
27.在确定出运行状态异常的异常组件的情况下，从所述直接依赖组件数、所述递归依赖组件数和所述文件特征中，确定出导致所述异常组件异常的异常因素；
28.根据所述异常因素，生成针对所述异常组件和所述异常因素的提示信息。
29.根据本公开实施例的第二方面，提供一种资源库处理装置，包括：
30.确定单元，被配置为执行确定应用程序资源库中各个文件之间的依赖关系；所述依赖关系表示文件在使用过程中的调用关系；
31.划分单元，被配置为执行根据所述各个文件之间的依赖关系，将所述各个文件划分至多个层级的组件中，并生成所述各个文件的初始配置信息；所述初始配置信息用于记录所述各个文件的移动路径，每个层级对应不同的文件复杂程度；
32.修正单元，被配置为执行基于预设的配置信息影响因素，对目标组件中文件的初始配置信息进行修正，得到修正后配置信息；所述目标组件表示复杂程度符合预设条件的层级的组件；
33.配置单元，被配置为执行通过所述各个组件中除所述目标组件之外的其余组件对应的初始配置信息，以及所述目标组件对应的修正后配置信息，对所述应用程序资源库中的各个文件进行重新配置，得到所述应用程序资源库对应的重构资源库。
34.在一示例性实施例中，所述划分单元，还被配置为执行根据所述各个文件之间的依赖关系，确定所述各个文件的依赖关系数目；根据所述依赖关系数目，将所述各个文件划分至多个层级的组件中。
35.在一示例性实施例中，所述修正单元，还被配置为执行基于所述配置信息影响因素，从所述目标组件的文件中确定出待修正文件和所述待修正文件对应的修正方式；所述修正方式包括移动路径的修改、文件的拆分和文件的合并中的至少一种；根据所述修正方式，对所述待修正文件的初始配置信息进行修正，得到所述修正后配置信息。
36.在一示例性实施例中，所述修正单元，还被配置为执行获取更新的应用程序资源库，并将所述更新的应用程序资源库与所述应用程序资源库进行对比；在对比得到新的文件的情况下，确定所述新的文件对应的依赖关系，根据所述新的文件对应的依赖关系对所述目标组件对应的修正后配置信息和/或所述其余组件对应的初始配置信息进行再次修正，得到新的修正后配置信息；
37.所述配置单元，还被配置为执行通过所述新的修正后配置信息对所述更新的应用程序资源库中的各个文件进行重新配置，得到所述应用程序资源库对应的重构资源库。
38.在一示例性实施例中，所述装置还包括替换单元，被配置为执行将所述应用程序资源库中各个文件对应的引用信息替换为所述重构资源库中对应的引用信息。
39.在一示例性实施例中，所述装置还包括状态确定单元，被配置为执行获取所述重构资源库中各个组件对应的依赖关系；每个组件中包括多个文件；基于各个文件之间的依赖关系和各个组件对应的所述依赖关系，获取各个组件的直接依赖组件数、递归依赖组件数和各个组件下文件的文件特征；基于所述直接依赖组件数、所述递归依赖组件数和所述文件特征，确定各个组件的运行状态。
40.在一示例性实施例中，所述装置还包括异常提示单元，被配置为执行在确定出运行状态异常的异常组件的情况下，从所述直接依赖组件数、所述递归依赖组件数和所述文件特征中，确定出导致所述异常组件异常的异常因素；根据所述异常因素，生成针对所述异常组件和所述异常因素的提示信息。
41.根据本公开实施例的第三方面，提供一种电子设备，包括：
42.处理器；
43.用于存储所述处理器可执行指令的存储器；
44.其中，所述处理器被配置为执行所述指令，以实现如上任一项所述的方法。
45.根据本公开实施例的第四方面，提供一种计算机可读存储介质，当所述计算机可读存储介质中的指令由电子设备的处理器执行时，使得所述电子设备能够执行如上任一项所述的方法。
46.根据本公开实施例的第五方面，提供一种计算机程序产品，所述计算机程序产品中包括指令，所述指令被电子设备的处理器执行时，使得所述电子设备能够执行如上任一项所述的方法。
47.本公开的实施例提供的技术方案至少带来以下有益效果：
48.通过应用程序资源库中各个文件之间的依赖关系，先将各个文件划分至多个层级的组件中，并生成各个文件的初始配置信息，然后基于预设的配置信息影响因素，对目标组件中文件的初始配置信息进行修正，得到修正后配置信息，最后通过各个组件中除目标组
件之外的其余组件对应的初始配置信息，以及目标组件对应的修正后配置信息，对应用程序资源库中的各个文件进行重新配置，得到应用程序资源库对应的重构资源库。该方法基于依赖关系先对各个文件进行层级划分，得到初始配置信息，然后只对其中较为复杂的文件进行修正，得到修正后配置信息，无需人工参与每个分析过程，从而提高对资源库的处理效率。
49.应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
50.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。
51.图1是根据一示例性实施例示出的一种资源库处理方法的应用环境图。
52.图2是根据一示例性实施例示出的一种资源库处理方法的流程示意图。
53.图3是根据一示例性实施例示出的一种资源库处理方法的完整流程示意图。
54.图4是根据一示例性实施例示出的一种资源库处理装置的结构框图。
55.图5是根据一示例性实施例示出的一种电子设备的框图。
具体实施方式
56.为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。
57.需要说明的是，以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。还需要说明的是，本公开所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于展示的数据、分析的数据等)，均为经用户授权或者经过各方充分授权的信息和数据。
58.本公开实施例提供的资源库处理方法，可以应用于如图1所示的应用环境中。其中，终端102通过网络与服务器104进行通信，应用程序资源库部署于服务器104中。在本公开的应用场景下，终端102可从服务器104中获取应用程序资源库中各个文件之间的依赖关系，根据各个文件之间的依赖关系，将各个文件划分至多个层级的组件中，并生成各个文件的初始配置信息；基于预设的配置信息影响因素，对目标组件中文件的初始配置信息进行修正，得到修正后配置信息；通过各个组件中除目标组件之外的其余组件对应的初始配置信息，以及目标组件对应的修正后配置信息，对应用程序资源库中的各个文件进行重新配置，得到应用程序资源库对应的重构资源库。
59.其中，终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑、物联网设备和便携式可穿戴设备，物联网设备可为智能音箱、智能电视、智能空调、智能车载设备等。便携式可穿戴设备可为智能手表、智能手环、头戴设备等。服务器104可以用独立的服务器或者是多个服务器组成的服务器集群来实现。
60.图2是根据一示例性实施例示出的一种资源库处理方法的流程示意图，如图2所示，以该方法应用于图1中的终端102为例进行说明，包括以下步骤：
61.在步骤s210中，确定应用程序资源库中各个文件之间的依赖关系，依赖关系表示文件在使用过程中的调用关系。
62.其中，依赖关系可以理解为文件在使用过程中的调用关系，例如应用程序在执行某个功能时，需要使用文件a，而文件a需要调用文件b，则文件a与文件b之间存在依赖关系。
63.可以理解的是，一个应用程序的资源库中存储有实现不同功能的文件，每个功能的文件可存储在一个资源库中，因此，一个应用程序可包括多个资源库，每个资源库中可包括多个组件，每个组件包括多个文件，实现对应用程序文件的逐级划分。
64.具体实现中，要进行资源库的配置，需要先确定资源库中有哪些文件，以及各个文件之间有什么关系，因此，需要先确定应用程序资源库中文件的依赖关系图，组件的依赖关系图，结合文件的依赖关系图和组件的依赖关系图，确定出各个文件之间的依赖关系。
65.在步骤s220中，根据各个文件之间的依赖关系，将各个文件划分至多个层级的组件中，并生成各个文件的初始配置信息。
66.其中，初始配置信息用于记录各个文件的移动路径，具体包括文件当前所在的组件名称和将要移动到的组件名称。
67.其中，每个层级对应不同的文件复杂程度。例如，一级文件表示文件没有对外依赖关系，职责较为单一；二级文件表示文件具有简单的依赖关系，如只有一个或两个依赖的文件；三级文件表示文件具有较为复杂的依赖关系，如依赖有多个其他文件，或被多个其他文件所依赖等。
68.具体实现中，文件的复杂程度可通过依赖关系信息表征，例如依赖关系越多，表示文件的复杂程度越高；依赖关系越少，表示文件越简单。因此，可根据应用程序资源库中各个文件之间的依赖关系，确定每个文件的依赖关系数目，根据依赖关系数目将各个文件划分至多个层级的组件中。
69.在步骤s230中，基于预设的配置信息影响因素，对目标组件中文件的初始配置信息进行修正，得到修正后配置信息；目标组件表示复杂程度符合预设条件的层级的组件。
70.其中，配置信息影响因素可以为文件的实际应用场景和文件的属性信息(如文件的类型)等。
71.具体实现中，由于资源库中文件的存储位置除了受文件的依赖关系的影响外，还会受到如实际应用场景、文件的属性信息等因素的影响，因此，在根据各个文件之间的依赖关系，对各个文件进行配置，得到初始配置信息后，还需要根据预设的配置信息影响因素对初始配置信息进行修正，确定文件实际应该移动到哪个组件下。
72.更具体地，由于无依赖关系或依赖关系简单的文件较少受到配置信息影响因素的影响，因此，为提高处理效率，可从多个组件中确定出复杂程度符合预设条件的层级的目标组件，基于预设的配置信息影响因素，对目标组件的初始配置信息进行修正，得到目标组件的修正后配置信息。
73.在步骤s240中，通过各个组件中除目标组件之外的其余组件对应的初始配置信息，以及目标组件对应的修正后配置信息，对应用程序资源库中的各个文件进行重新配置，得到应用程序资源库对应的重构资源库。
74.具体实现中，在得到目标组件的修正后配置信息后，可基于各个组件中除目标组件之外的其余组件的初始配置信息，以及目标组件的修正后配置信息，对应用程序资源库
中的各个文件进行重新配置，得到应用程序资源库对应的重构资源库。
75.更具体地，对应用程序资源库中的各个文件进行重新配置，包括将应用程序资源库中的每个文件按照配置信息进行拆分、合并和移动等处理，具体的顺序可以为先对需要拆分的文件进行拆分，然后对需要合并的文件进行合并，最后将拆分或合并后的文件、以及其他文件按照配置信息移动到对应的目标组件下，并生成新的组件来描述文件，添加新增组件的配置信息。
76.上述资源库处理方法中，通过应用程序资源库中各个文件之间的依赖关系，先将各个文件划分至多个层级的组件中，并生成各个文件的初始配置信息，然后基于预设的配置信息影响因素，对目标组件中文件的初始配置信息进行修正，得到修正后配置信息，最后通过各个组件中除目标组件之外的其余组件对应的初始配置信息，以及目标组件对应的修正后配置信息，对应用程序资源库中的各个文件进行重新配置，得到应用程序资源库对应的重构资源库。该方法基于依赖关系先对各个文件进行层级划分，得到初始配置信息，然后只对其中较为复杂的文件进行修正，得到修正后配置信息，无需人工参与每个分析过程，从而提高对资源库的处理效率。
77.在一示例性实施例中，在步骤s220中，根据各个文件之间的依赖关系，将各个文件划分至多个层级的组件中，具体可以通过以下步骤实现：
78.步骤s220a，根据各个文件之间的依赖关系，确定各个文件的依赖关系数目；
79.步骤s220b，根据依赖关系数目，将各个文件划分至多个层级的组件中。
80.其中，依赖关系数目可包括直接依赖文件数和递归依赖文件数。
81.其中，直接依赖文件数表示直接与各文件构成依赖关系的文件的数目。例如，使用文件a需要调用文件b，则文件a与文件b之间构成直接依赖，文件b可作为文件a的直接依赖文件。
82.其中，递归依赖文件数表示间接与各文件构成依赖关系的文件的数目。例如，使用文件c需要调用文件d，而使用文件d需要调用文件e，则文件e与文件c之间构成直接依赖，文件c可作为文件e的间接依赖文件。
83.具体实现中，由于不同层级对应不同的文件复杂程度，而文件的依赖关系数目可以反映文件的复杂程度，因此，可根据各个文件之间的依赖关系，确定各个文件的依赖关系数目，进而根据依赖关系数目，将各个文件划分至多个层级的组件中。
84.更具体地，可预先为每个层级的组件设置对应的依赖关系数目区间，在确定各个文件的依赖关系数目后，针对每个文件，从各个依赖关系数目区间中确定出该文件对应的目标依赖关系数目区间，将目标依赖关系数目区间对应的组件作为该文件需要移动到的目标组件，由此将各个文件划分至多个层级的组件中。
85.本实施例中，通过各个文件之间的依赖关系，确定各个文件的依赖关系数目，基于依赖关系数目将各个文件划分至多个层级的组件中，实现对应用程序资源库中各个文件的自动化初级划分，无需人为参与分析，从而提高处理效率。
86.在一示例性实施例中，上述步骤s230中，基于预设的配置信息影响因素，对目标组件中文件的初始配置信息进行修正，得到修正后配置信息，具体可以通过以下步骤实现：
87.步骤s230a，基于配置信息影响因素，从目标组件的文件中确定出待修正文件和待修正文件对应的修正方式；修正方式包括移动路径的修改、文件的拆分和文件的合并中的
至少一种；
88.步骤s230b，根据修正方式，对待修正文件的初始配置信息进行修正，得到修正后配置信息。
89.其中，待修正文件的数量可以为一个，也可以为多个。
90.具体实现中，由于从应用程序资源库中划分至目标组件中的文件在通过配置信息影响因素分析后，可能部分文件的配置信息不需要进行修正，因此，在进行修正处理前，可先根据配置信息影响因素对目标组件中的文件进行分析，确定出需要进行配置信息修正的待修正文件，并基于配置信息影响因素确定待修正文件需要采用移动路径的修改、文件的拆分和文件的合并等方式中的哪些修正方式，根据该修正方式对待修正文件的初始配置信息进行修正，将待修正后文件在修正后的配置信息与目标组件中的其他文件的初始配置信息，作为修正后配置信息。
91.本实施例中，通过从目标组件的文件中确定出待修正文件和待修正文件对应的修正方式，根据修正方式，对待修正文件的初始配置信息进行修正，得到修正后配置信息，无需对目标组件的其他文件进行处理，从而可提高处理效率。
92.在一示例性实施例中，在步骤s230中，基于预设的配置信息影响因素，对目标组件中文件的初始配置信息进行修正，得到修正后配置信息之后，还包括：
93.步骤s231，获取更新的应用程序资源库，并将更新的应用程序资源库与应用程序资源库进行对比；
94.步骤s232，在对比得到新的文件的情况下，确定新的文件对应的依赖关系，根据新的文件对应的依赖关系对目标组件对应的修正后配置信息和/或其余组件对应的初始配置信息进行再次修正，得到新的修正后配置信息；
95.步骤s233，通过新的修正后配置信息对更新的应用程序资源库中的各个文件进行重新配置，得到应用程序资源库对应的重构资源库。
96.具体实现中，由于在对应用程序资源库中的文件进行配置信息确定的过程中，其他研发人员可能开发出了一些新的文件，若不以更新的应用程序资源库进行配置信息的确定，则后续可能会造成大面积的冲突，导致应用程序的运行故障。因此，在对目标组件的初始配置信息进行修正，得到修正后配置信息之后，还需要检查应用程序资源库中的内容是否有更新，若有更新，则获取更新的应用程序资源库，并将更新的应用程序资源库与原来的应用程序资源库进行对比，在对比得到新的文件的情况下，说明需要对得到的目标组件的修正后配置信息或除目标组件之外的其余组件的初始配置信息进行再次修正，故可确定新的文件对应的依赖关系，即确定新的文件与其他文件的依赖关系，根据该依赖关系，确定需要进行修正的文件，对需要进行修正的文件的配置信息进行再次修正，得到新的修正后配置信息。其中，需要进行修正的文件可能属于目标组件，也可能属于除目标组件之外的其余组件，因此，需要进行修正的文件的配置信息可能为修正后配置信息，也可能为初始配置信息。进一步地，在得到新的修正后配置信息后，可通过新的修正后配置信息对更新的应用程序资源库中的各个文件进行拆分、合并或移动等配置，得到应用程序资源库对应的重构资源库。
97.本实施例中，通过更新的应用程序资源库中的新的文件对应的依赖关系，对目标组件的修正后配置信息或除目标组件之外的其余组件的初始配置信息进行修正，根据新的
修正后配置信息对更新的应用程序资源库中的各个文件进行重新配置，保证所得到的配置信息为根据最新的应用程序资源库所分析得到的配置信息，避免后续运行过程中的冲突。
98.在一示例性实施例中，在得到应用程序资源库对应的重构资源库之后，还包括：将应用程序资源库中各个文件对应的引用信息替换为重构资源库中对应的引用信息。
99.具体实现中，在得到应用程序资源库对应的重构资源库之后，各个文件的原始存储目录将无法引用到相应的文件，因此，还需要同步对各个文件的引用信息进行更新，即将应用程序资源库中各个文件对应的引用信息替换为重构资源库中对应的引用信息。
100.举例说明，文件a原本在a组件，引用文件a需要带上组件a，文件a移动到组件b之后，所有引用了文件a的地方都要把组件a改成组件b。
101.本实施例中，在得到应用程序资源库对应的重构资源库之后，将应用程序资源库中各个文件对应的引用信息替换为重构资源库中对应的引用信息，以使各个文件可以被正确引用，保证应用程序可以正常运行。
102.在一示例性实施例中，在得到应用程序资源库对应的重构资源库之后，还包括：
103.步骤s250，获取重构资源库中各个组件对应的依赖关系；每个组件中包括多个文件；
104.步骤s260，基于各个文件之间的依赖关系和各个组件对应的依赖关系，获取各个组件的直接依赖组件数、递归依赖组件数和各个组件下文件的文件特征；
105.步骤s270，基于直接依赖组件数、递归依赖组件数和文件特征，确定各个组件的运行状态。
106.其中，组件之间的依赖关系可以为组件之间的依赖，也可以为组件中文件之间的依赖。
107.其中，直接依赖组件数表示直接与各组件构成依赖关系的组件的数目。例如，调用组件a中的文件a时，文件a需要调用组件b中的文件b，则组件a与组件b构成直接依赖，组件b可作为组件a的直接依赖组件。
108.其中，递归依赖组件数表示间接与各组件构成依赖关系的组件的数目。例如，调用组件a中的文件a时，文件a需要调用组件b中的文件b，而文件b需要调用组件c中的文件c，则组件a与组件c构成递归依赖，组件c可作为组件a的递归依赖组件。
109.其中，文件特征表示一个组件下各个文件的文件特征，具体可以为平均文件行数，平均文件行数表示一个组件下各个文件的文件行数的平均值。
110.可以理解的是，由于应用程序的功能会逐渐增多，应用程序资源库的组件会越来越多，工程架构问题也会越来越多，因此，还需要对各个组件的运行状态进行监督，以便于及时发现出现异常的异常组件。
111.具体实现中，可通过获取重构资源库中各个组件对应的依赖关系，根据各个文件之间的依赖关系，以及各个组件对应的依赖关系，统计各个组件的直接依赖组件数、递归依赖组件数，以及统计各个组件下文件的文件特征。基于直接依赖组件数、递归依赖组件数和文件特征，确定各个组件的运行状态。
112.更具体地，可先计算各个组件的直接依赖组件数的第一平均值，各个组件的递归依赖组件数的第二平均值，各个组件的文件特征的第三平均值，然后针对每个组件，计算该组件的直接依赖数与第一平均值的第一差值，该组件的递归依赖数与第二平均值的第二差
值，该组件的文件特征与第三平均值的第三差值。进一步计算第一差值、第二差值和第三差值的平方和，得到直接依赖组件数、递归依赖组件数、文件特征各自的方差，作为状态指标值，将该状态指标值与阈值进行比对，若大于阈值，则确定组件异常，若小于阈值，则确定组件正常。
113.本实施例中，通过各个文件之间的依赖关系和各个组件对应的依赖关系，获取各个组件的直接依赖组件数、递归依赖组件数和各个组件下文件的文件特征，基于直接依赖组件数、递归依赖组件数和文件特征，确定各个组件的运行状态，实现对各个组件的运行状态的定量化评估，既可保证所确定的异常组件的准确性，还可及时找出出现异常的组件，降低人工检查的时间。
114.在一示例性实施例中，在步骤s270，基于直接依赖组件数、递归依赖组件数和文件特征，确定各个组件的运行状态之后，还包括：
115.步骤s271，在确定出运行状态异常的异常组件的情况下，从直接依赖组件数、递归依赖组件数和文件特征中，确定出导致异常组件异常的异常因素；
116.步骤s272，根据异常因素，生成针对异常组件和异常因素的提示信息。
117.具体实现中，在确定出运行状态异常的异常组件后，还可以确定具体是哪个因素导致了该组件出现异常，具体方式可以为根据异常组件直接依赖组件数、递归依赖组件数和文件特征各自对应的方差的大小确定导致异常组件异常的异常因素，更具体地，可以为从直接依赖组件数、递归依赖组件数和文件特征中确定出方差最大的因素，作为异常因素，可以理解的是，方差越大，表明偏离平均值的程度越大，则越可能异常。
118.在确定出异常因素后，可生成针对异常组件和异常因素的提示信息，并发送提示信息至用户终端，使用户终端对异常组件进行处理。更具体地，对异常组件的处理方式可以为：
119.对于直接依赖组件数较多的组件，可以基于每个文件依赖关系，结合每个组件的职能，得出这个组件承担了多少职能，是否太过臃肿，从而尝试将其中的部分职能智能拆分出去。
120.对于递归依赖组件数较多的组件，可以先结合直接依赖分析自身是否有问题，再基于递归依赖，找到是否依赖了太臃肿的其他组件导致的组件本身递归依赖太过臃肿。
121.对于平均文件行数太多的组件，可以结合每个文件行数，确定是文件数目太多，还是其中的某几个文件单个文件行数太多，对于庞大的单个文件，也可以进行拆分。
122.进一步地，在筛查出异常的组件和文件之后，还可以结合组件所属部门信息，分析每个部门和其他所有部门的代码耦合关系表，对于耦合十分严重的情况，也可以指出哪些地方可以尝试去解除耦合，是哪个组件里面的哪个文件依赖了另一个组件里面的另一个文件导致的这个耦合。最后结合工程组件层级关系图，分析出目前每个组件都在什么层级，每个层级分部的组件都是什么样的，是否需要修改层级关系，哪些依赖层级出现了不满足需求的情况均可以分析报告出来。
123.本实施例中，通过确定导致异常组件异常的异常因素，生成针对异常组件和异常因素的提示信息，并发送提示信息至用户终端，使用户终端的用户不仅知道哪个组件异常，还可以得知异常组件出现异常的原因，从而使终端用户可以针对性地对异常问题进行处理，极大地提高对异常情况的处理效率。
124.在另一示例性实施例中，为了便于本领域技术人员理解本公开实施例，如图3所示，本公开还示出了资源库处理方法的完整流程图，本实施例中，该方法包括以下步骤：
125.步骤s310，确定待处理的应用程序资源库及应用程序资源库中各个文件之间的依赖关系；
126.步骤s320，根据各个文件之间的依赖关系，确定各个文件的依赖关系数目；
127.步骤s330，根据依赖关系数目，将各个文件划分至多个层级的组件中，并生成各个文件的初始配置信息；初始配置信息用于记录各个文件的移动路径；
128.步骤s340，基于配置信息影响因素，从目标组件的文件中确定出待修正文件和待修正文件对应的修正方式；修正方式包括移动路径的修改、文件的拆分和文件的合并中的至少一种；目标组件表示复杂程度符合预设条件的层级的组件；
129.步骤s350，根据修正方式，对待修正文件的初始配置信息进行修正，得到修正后配置信息；
130.步骤s360，获取更新的应用程序资源库，并将更新的应用程序资源库与应用程序资源库进行对比；
131.步骤s370，在对比得到新的文件的情况下，确定新的文件对应的依赖关系，根据新的文件对应的依赖关系对目标组件对应的修正后配置信息和/或其余组件对应的初始配置信息进行再次修正，得到新的修正后配置信息；
132.步骤s380，通过新的修正后配置信息对更新的应用程序资源库中的各个文件进行重新配置，得到应用程序资源库对应的重构资源库。
133.本实施例提供的资源库处理方法，具有以下有益效果：
134.1、缩减了实际代码改动时候的时间，降低了拆分周期内带来的冲突。
135.2、对于机械化的改动，通过自动化提升了处理效率。比如从文件a原本在a组件，引用文件a需要带上组件a，移动到组件b之后，所有引用了文件a的地方都要把组件a改成组件b。
136.3、定期监控工程运行状况，及时抛出架构问题，降低人工检查的时间，直接给出具体问题所在地方，并且可以针对性的解决一些简单问题。
137.4、相比面对整个工程，直接面对完整的报表可以更方便开发人员修改和解决问题。
138.应该理解的是，虽然如上所述的各实施例所涉及的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，如上所述的各实施例所涉及的流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。
139.可以理解的是，本说明书中上述方法的各个实施例之间相同/相似的部分可互相参见，每个实施例重点说明的是与其他实施例的不同之处，相关之处参见其他方法实施例的说明即可。
140.基于同样的发明构思，本公开实施例还提供了一种用于实现上述所涉及的资源库
处理方法的资源库处理装置。
141.图4是根据一示例性实施例示出的一种资源库处理装置的结构框图。参照图4，该装置包括：确定单元410、划分单元420、修正单元430和配置单元440，其中，
142.确定单元410，被配置为执行确定应用程序资源库中各个文件之间的依赖关系；依赖关系表示文件在使用过程中的调用关系；
143.划分单元420，被配置为执行根据各个文件之间的依赖关系，将各个文件划分至多个层级的组件中，并生成各个文件的初始配置信息；初始配置信息用于记录各个文件的移动路径，每个层级对应不同的文件复杂程度；
144.修正单元430，被配置为执行基于预设的配置信息影响因素，对目标组件中文件的初始配置信息进行修正，得到修正后配置信息；目标组件表示复杂程度符合预设条件的层级的组件；
145.配置单元440，被配置为执行通过各个组件中除目标组件之外的其余组件对应的初始配置信息，以及目标组件对应的修正后配置信息，对应用程序资源库中的各个文件进行重新配置，得到应用程序资源库对应的重构资源库。
146.在一示例性实施例中，划分单元420，还被配置为执行根据各个文件之间的依赖关系，确定各个文件的依赖关系数目；根据依赖关系数目，将各个文件划分至多个层级的组件中。
147.在一示例性实施例中，修正单元430，还被配置为执行基于配置信息影响因素，从目标组件的文件中确定出待修正文件和待修正文件对应的修正方式；修正方式包括移动路径的修改、文件的拆分和文件的合并中的至少一种；根据修正方式，对待修正文件的初始配置信息进行修正，得到修正后配置信息。
148.在一示例性实施例中，修正单元430，还被配置为执行获取更新的应用程序资源库，并将更新的应用程序资源库与应用程序资源库进行对比；在对比得到新的文件的情况下，确定新的文件对应的依赖关系，根据新的文件对应的依赖关系对目标组件对应的修正后配置信息和/或其余组件对应的初始配置信息进行再次修正，得到新的修正后配置信息；
149.配置单元440，还被配置为执行通过新的修正后配置信息对更新的应用程序资源库中的各个文件进行重新配置，得到应用程序资源库对应的重构资源库。
150.在一示例性实施例中，上述装置还包括替换单元，被配置为执行将应用程序资源库中各个文件对应的引用信息替换为重构资源库中对应的引用信息。
151.在一示例性实施例中，上述装置还包括状态确定单元，被配置为执行获取重构资源库中各个组件对应的依赖关系；每个组件中包括多个文件；基于各个文件之间的依赖关系和各个组件对应的依赖关系，获取各个组件的直接依赖组件数、递归依赖组件数和各个组件下文件的文件特征；基于直接依赖组件数、递归依赖组件数和文件特征，确定各个组件的运行状态。
152.在一示例性实施例中，上述装置还包括异常提示单元，被配置为执行在确定出运行状态异常的异常组件的情况下，从直接依赖组件数、递归依赖组件数和文件特征中，确定出导致异常组件异常的异常因素；根据异常因素，生成针对异常组件和异常因素的提示信息；发送提示信息至用户终端，使用户终端对异常组件进行处理。
153.关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法
的实施例中进行了详细描述，此处将不做详细阐述说明。
154.图5是根据一示例性实施例示出的一种用于实现资源库处理方法的电子设备500的框图。例如，电子设备500可以是移动电话、计算机、数字广播终端、消息收发设备、游戏控制台、平板设备、医疗设备、健身设备、个人数字助理等。
155.参照图5，电子设备500可以包括以下一个或多个组件：处理组件502、存储器504、电源组件506、多媒体组件508、音频组件510、输入/输出(i/o)的接口512、传感器组件514以及通信组件516。
156.处理组件502通常控制电子设备500的整体操作，诸如与显示、电话呼叫、数据通信、相机操作和记录操作相关联的操作。处理组件502可以包括一个或多个处理器520来执行指令，以完成上述的方法的全部或部分步骤。此外，处理组件502可以包括一个或多个模块，便于处理组件502和其他组件之间的交互。例如，处理组件502可以包括多媒体模块，以方便多媒体组件508和处理组件502之间的交互。
157.存储器504被配置为存储各种类型的数据以支持在电子设备500的操作。这些数据的示例包括用于在电子设备500上操作的任何应用程序或方法的指令、联系人数据、电话簿数据、消息、图片、视频等。存储器504可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(sram)、电可擦除可编程只读存储器(eeprom)、可擦除可编程只读存储器(eprom)、可编程只读存储器(prom)、只读存储器(rom)、磁存储器、快闪存储器、磁盘、光盘或石墨烯存储器。
158.电源组件506为电子设备500的各种组件提供电力。电源组件506可以包括电源管理系统，一个或多个电源，及其他与为电子设备500生成、管理和分配电力相关联的组件。
159.多媒体组件508包括在所述电子设备500和用户之间的提供输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(lcd)和触摸面板(tp)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件508包括前置摄像头和/或后置摄像头。当电子设备500处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是固定的光学透镜系统或具有焦距和光学变焦能力。
160.音频组件510被配置为输出和/或输入音频信号。例如，音频组件510包括麦克风(mic)，当电子设备500处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器504或经由通信组件516发送。在一些实施例中，音频组件510还包括扬声器，用于输出音频信号。
161.i/o接口512为处理组件502和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。
162.传感器组件514包括一个或多个传感器，用于为电子设备500提供各个方面的状态评估。例如，传感器组件514可以检测到电子设备500的打开/关闭状态，组件的相对定位，例如所述组件为电子设备500的显示器和小键盘，传感器组件514还可以检测电子设备500或电子设备500组件的位置改变，用户与电子设备500接触的存在或不存在，设备500方位或加
速/减速和电子设备500的温度变化。传感器组件514可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件514还可以包括光传感器，如cmos或ccd图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件514还可以包括加速度传感器、陀螺仪传感器、磁传感器、压力传感器或温度传感器。
163.通信组件516被配置为便于电子设备500和其他设备之间有线或无线方式的通信。电子设备500可以接入基于通信标准的无线网络，如wifi，运营商网络(如2g、3g、4g或5g)，或它们的组合。在一个示例性实施例中，通信组件516经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件516还包括近场通信(nfc)模块，以促进短程通信。例如，在nfc模块可基于射频识别(rfid)技术，红外数据协会(irda)技术，超宽带(uwb)技术，蓝牙(bt)技术和其他技术来实现。
164.在示例性实施例中，电子设备500可以被一个或多个应用专用集成电路(asic)、数字信号处理器(dsp)、数字信号处理设备(dspd)、可编程逻辑器件(pld)、现场可编程门阵列(fpga)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。
165.在一示例性实施例中，还提供了一种包括指令的计算机可读存储介质，例如包括指令的存储器504，上述指令可由电子设备500的处理器520执行以完成上述方法。例如，计算机可读存储介质可以是rom、随机存取存储器(ram)、cd-rom、磁带、软盘和光数据存储设备等。
166.在一示例性实施例中，还提供了一种计算机程序产品，所述计算机程序产品中包括指令，上述指令可由电子设备500的处理器520执行以完成上述方法。
167.需要说明的，上述的装置、电子设备、计算机可读存储介质、计算机程序产品等根据方法实施例的描述还可以包括其他的实施方式，具体的实现方式可以参照相关方法实施例的描述，在此不作一一赘述。
168.本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由权利要求指出。
169.应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。