CN113391812A - 应用程序模块的分析方法、装置以及分析工具 - Google Patents

Abstract

本公开涉及一种应用程序模块分析方法、装置以及分析工具。其中应用程序模块分析方法包括：对应用程序所包含的至少一个文件的源码进行分析，得到应用程序至少一个文件的分析结果，得出模块所包含的所有文件的分析结果；在模块级别上进行模块依赖分析，得到模块正向依赖分析结果，再结合模块文件分析结果，得到模块的分析结果；最后进行跨模块分析，得到在模块级别和文件级别上模块和文件之间的逆向依赖分析结果。本公开提供了文件级别和模块级别的逆向依赖分析结果，可供研发人员清楚地了解应用程序中模块和文件中的逆向依赖关系，减少程序的冗余，降低了程序的维护和迭代成本。

Description

应用程序模块的分析方法、装置以及分析工具

技术领域

本公开涉及计算机程序领域，特别涉及一种应用程序模块的分析方法、装置以及分析工具。

背景技术

一款复杂的应用程序为了并行开发、降低开发复杂度、提升开发效率，通常应用程序中包含多个模块，一个模块包含一个或多个文件，一个文件包含一个或多个API。模块之间通过某种约定方式进行相互依赖协作。

采用这种方法带来了一个新的问题：模块间的依赖难以追踪，在应用程序迭代的过程中，易出现改动一个模块，影响多个模块的问题。由于应用程序内的模块数量众多，人工检索成本较高，导致开发人员难以知道模块之间逆向依赖(被其他模块依赖)情况，也就是难以知晓一个模块的迭代，具体会影响哪些其它模块，例如当多个模块均依赖同一个模块时，一旦该模块发生迭代或修改，则难免都会对被依赖的模块产生影响，但由于研发人员难以知悉模块和文件之间的逆向依赖关系，会导致在迭代和维护过程中源码大量冗余，程序变得越来越臃肿，迭代成本越来越高。

发明内容

鉴于上述问题，提出了本公开以便提供一种克服上述问题或者至少部分地解决上述问题的一种分析应用程序模块的分析方法、装置以及分析报告。

第一方面，本公开实施例提供一种应用程序模块的分析方法，包括：

对应用程序所包含的至少一个文件的源码进行分析，得到所述至少一个文件的分析结果；

根据所述模块包含的文件，确定模块所包含的文件的分析结果；并对所述应用程序的模块，在模块级别上进行模块依赖分析，得到所述模块的正向依赖分析结果；

根据所述模块的正向依赖分析结果和模块所包含的文件的分析结果，得到所述模块的分析结果；

汇总所述应用程序中模块的分析结果，进行跨模块分析，得到在模块级别和文件级别上模块之间的逆向依赖分析结果。

在一个实施例中，对应用程序所包含的至少一个文件的源码进行分析，得到所述至少一个文件的分析结果，具体包括：

从应用程序的至少一个入口文件开始，依次对所述入口文件的源码进行文件依赖分析，得到文件依赖分析结果，以递归的方式的对入口文件依赖文件继续进行文件依赖分析，直到遍历完所述应用程序包含的文件，得到应用程序所有文件的分析结果。

在一个实施例中，一种应用程序模块的分析方法，还包括：

创建栈数据结构，在所述栈数据结构中记录应用程序所包含的文件递归的路径；

根据所述文件递归的路径，判断当前所需分析的文件的源码是否已被遍历；

当判断为否时，执行对所述文件的源码进行分析的步骤；

当判断为是时，跳转至下一个所依赖的文件的源码进行分析。

在一个实施例中，对应用程序所包含的至少一个文件的源码进行分析，得到所述至少一个文件的分析结果，包括：

分别收集文件的属性数据；

对所述文件的源码进行语法分析，构建对应的语法树；

基于所述文件的语法树，分别对所述文件的源码进行切面API分析和文件依赖分析，分别得到所述文件的切面API分析结果和文件正向依赖分析结果；所述切面API分析为应用层文件的API和容器层API之间依赖关系的分析；

根据所述文件的正向依赖分析结果，确定文件级别上的文件逆向依赖分析结果和无用资源分析结果；所述无用资源分析结果包含未被其他任何文件所依赖的文件；

汇总所述文件的属性数据、切片API分析结果、文件正向依赖分析结果、文件逆向依赖分析结果和无用资源分析结果，得到所述文件的分析结果。

在一个实施例中，对文件的源码进行文件依赖分析，得到文件正向依赖分析结果，包括：

根据所述文件的语法树，在应用层内，对所述文件所包含的API进行API依赖分析，得到所述文件所包含的API的正向依赖分析结果；

根据所述语法树，对所述文件进行文件路径依赖分析，得到所述文件所依赖的文件的相对路径；并根据文件地图和所述文件的相对路径进行依赖寻路，确定所依赖的文件的绝对路径；所述文件地图记录有文件和文件绝对路径的映射关系；

汇总文件所包含的API的正向依赖分析结果和所述文件所依赖的文件绝对路径，得到文件正向依赖分析结果。

在一个实施例中，汇总所述应用程序中模块的分析结果，进行跨模块分析，得到在模块级别和文件级别上模块之间的逆向依赖分析结果，包括：

根据所述模块的分析结果中模块的正向依赖分析结果，以及所述模块所包含的文件分析结果中的文件逆向依赖分析结果，推导出模块级别和文件级别上所述模块的逆向分析结果。

在一个实施例中，在模块级别上进行模块依赖分析，得到模块正向依赖分析结果，包括：

根据所述模块依赖声明文件，对模块进行依赖分析，所述依赖分析包括模块间依赖关系分析和依赖合法性分析，得到模块正向依赖分析结果。

第二方面，本公开实施例提供一种应用程序模块的分析装置，包括：

文件分析单元，用于对应用程序所包含的至少一个文件的源码进行分析，得到应用程序中至少一个文件的分析结果；包括文件正向依赖分析结果和文件逆向依赖分析结果；

模块分析单元，用于根据所述模块包含的文件，确定模块所包含的所有文件的分析结果；并对所述应用程序的模块，在模块级别上进行模块依赖分析，得到所述模块的正向依赖分析结果；根据所述模块的正向依赖分析结果和模块所包含的文件的分析结果，分别得到所述模块的分析结果；汇总所述应用程序中模块的分析结果，进行跨模块分析，得到在模块级别和文件级别上模块之间的逆向依赖分析结果。

第三方面，本公开提供一种应用程序模块依赖关系的分析工具，所述分析工具用于分析应用程序的源码，生成对应的模块分析报告，所述报告包括下述任一项或多项的组合：

所述应用程序所包含的模块之间的依赖关系；

所述各模块所包含的文件之间的依赖关系；

所述各文件所包含的API之间的依赖关系；

所述依赖关系包括：正向依赖关系和逆向依赖关系。

第四方面，本公开提供一种应用程序源码分析工具，包括：存储器和处理器；其中，所述存储器存储有计算机程序，所述程序被处理器执行时能够实现所述的应用程序模块的分析方法。

第五方面，本公开提供一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现所述的应用程序模块的分析方法。

本公开实施例提供的上述技术方案的有益效果至少包括：

本公开实施例提供的上述应用程序模块的分析方法、装置以及分析工具，通过对应用程序源码进行分析，先得到文件级别的分析结果，然后再根据模块之间的依赖关系和模块所包含的文件，再构建出模块级别的依赖分析结果，从而最终得到模块之间，模块中文件级别多个粒度的依赖分析结果，实现对应用程序更精确的分析。研发人员根据本公开分析得出模块级别和文件级别逆向依赖分析结果，可以在进行应用程序的模块迭代的时候，清楚明了地知道对源码的改动会对被依赖的模块、文件产生哪些影响，从而可以针对性地避免的错误的产生，减少了程序的冗余，降低了应用程序的迭代和维护成本。

本公开的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本公开而了解。本公开的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

下面通过附图和实施例，对本公开的技术方案做进一步的详细描述。

附图说明

附图用来提供对本公开的进一步理解，并且构成说明书的一部分，与本公开的实施例一起用于解释本公开，并不构成对本公开的限制。在附图中：

图1为本公开实施例中应用程序模块的分析方法的流程图；

图2为本公开实施例中递归遍历应用程序中包含的文件的流程图；

图3为本公开实施例中文件依赖关系示意图；

图4为本公开实施例中递归遍历所用堆栈示意图；

图5为本公开实施例中文件分析的流程图；

图6为本公开实施例中语法树的示意图；

图7为本公开实施例中应用层，容器层，操作系统，以及应用程序中模块、文件、API关系示意图；

图8为本公开实施例中文件正向依赖分析的流程图。

图9为本公开实施例中模块文件树的示意图。

图10为本公开实施例中模块正向依赖分析的流程图。

图11为本公开实施例中应用程序模块的分析方法的又一流程图；

图12为本公开实施例中用程序模块分析装置的结构框图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

为了清晰的说明本公开实施例的技术方案，本公开实施例中，正向依赖关系指的是模块、文件、API依赖其他模块、文件或者API的情形，而逆向依赖关系，是指模块、文件、API被其他模块、文件或者API所依赖的情形。

本实施例提供一种应用程序模块分析的方法，参考图1，包括如下步骤：

S11、对应用程序所包含的至少一个各文件的源码进行分析，得到至少一个文件的分析结果；

S12、根据模块包含的文件，确定模块所包含的所有文件的分析结果；并对应用程序的模块，在模块级别上进行模块依赖分析，得到模块的正向依赖分析结果；

S13、根据模块的正向依赖分析结果和模块所包含的所有文件的分析结果，得到模块的分析结果；

S14、汇总应用程序中模块的分析结果，进行跨模块分析，得到在模块级别和文件级别上模块之间的逆向依赖分析结果。

本公开实施例提供的上述应用程序模块分析的方法，通过对应用程序源码进行分析，实现对应用程序更精确的分析，提供精确到文件级别的元数据及依赖分析数据、模块间的逆向依赖分析数据，并同时带有依赖合法性数据。开发人员根据本公开分析得出模块级别和文件级别逆向依赖结依赖分析结果，可以在进行应用程序的模块迭代的时候，清楚明了地知道新的改动将会对被依赖的模块、文件产生哪些影响，从而避免的错误的产生，降低了日后程序的维护成本。

在一个实施例中，上述步骤S11可以用递归的方式，对应用程序包含所有文件进行遍历的同时进行源码分析，例如采用如下方式：

从应用程序的至少一个入口文件开始，依次对入口文件的源码进行文件依赖分析，得到文件依赖分析结果，以递归的方式的对入口文件依赖文件继续进行文件依赖分析，直到遍历完应用程序包含的所有文件，得到应用程序所有文件的分析结果。

一个应用程序可以有一个或多个入口文件，入口文件是指模块开始进行编译的文件，是应用程序页面或对外的接口文件。

入口文件可以依赖其他入口文件或者其他非入口文件，而非入口文件可以依赖入口文件或者其他非入口文件。

当存在多个入口文件时，可以采用并行处理的流程，从多个入口文件同时开始分析及遍历，当然，也可以按照先后顺序来分别对多个入口文件开始进行分析和遍历。

因为文件的依赖关系是图状的，文件之间的依赖关系可能存在一个闭环，例如A依赖B，B又反过来依赖A，这样可能导致文件分析过程中重复分析，浪费处理资源，为了解决上述重复分析的问题，本公开实施例上述S11步骤为了避免重复分析，可参照图2所示的流程，首先从入口文件开始，对此文件进行源码分析，分析完成后跳转至下一个所依赖的文件，判断此文件是否被遍历，如果此文件没有被遍历过，则对此文件进行源码分析，如果该文件被遍历过，判断此模块所有文件是否都遍历过，如果没有完全遍历，则跳转至下一个所依赖的文件进行分析，如果此模块所有文件都被遍历过，则本次递归结束。

上述流程中，避免重复分析的手段可以通过堆栈数据结构的方式，具体而言，在遍历文件进行分析的过程中，创建栈数据结构，在栈数据结构中记录文件递归的路径；

根据文件递归的路径，判断当前所需分析的文件的源码是否已被遍历；

当判断为否时，执行对文件的源码进行分析的步骤；

当判断为是时，跳转至下一个所依赖的文件的源码进行分析。

简单举例说明：假设应用程序中包含五个文件ABCDE，它们之间的依赖关系如图3所示，以图4所示的堆栈的数据结构记录递归的路径，分析过程中，文件A为入口文件，分析过程开始时把文件A加入堆栈，分析文件A的源码得到其与其他文件的依赖关系，即文件A依赖文件B，然后将文件B加入堆栈，进一步分析文件B的源码，得到文件B依赖文件C和文件E，把文件C和文件E加入堆栈，分析文件E的源码得到文件E没有依赖的文件，继续分析文件C的源码，得到文件C依赖文件D，把文件D加入堆栈，分析文件D的源码得到文件D依赖文件A，此时发现文件A已经在堆栈中，说明文件A已经被分析过，则不需要重复分析。此时判断发现应用程序中所有文件ABCDE都已在堆栈中，说明它们都已经被遍历过，这样应用程序的文件的递归遍历结束。

以此类推，将应用程序所有入口文件用递归的方式的遍历之后，得到所有文件正向依赖关系。使用堆栈的数据结构的方式可以解决循环依赖的问题，记录递归的路径，当检测到之前已经遍历过当前节点的时候，可以跳过此节点，不需要重复处理。本公开不限于用堆栈的形式实现对文件的递归遍历，本公开实施例在此不做限定。

在一个实施例中，上述步骤S11中对应用程序所包含的各文件的源码进行分析，得到应用程序各文件的分析结果，可以通过如图5所示的下述步骤实现：

S51、分别收集文件的属性数据，例如文件名、存放路径、底层系统API调用关系、文件体积、代码行数等；

S52、对文件的源码进行语法分析，构建对应的语法树；

例如可利用现有语法分析工具typescript，esprima，less把应用程序源码解析成语法树；

语法树以树状的形式表现应用程序编程语言的语法结构，如图6所示的一个语法树的例子，把一段源码解析成一个树状结构，每个叶子节点都是不能再解析的变量，非叶子节点表示了一种语法结构，比如一个循环结构，或判断结构。

S53、基于文件的语法树，分别对文件的源码进行切面API分析和文件依赖分析，分别得到文件的切面API分析结果和文件正向依赖分析结果；

切面API分析是指对应用层的API和容器层API之间依赖关系的分析；

S54、根据文件的正向依赖分析结果，确定文件级别上的文件逆向依赖分析结果和无用资源分析结果；其中，无用资源分析结果包含未被其他任何文件所依赖的文件；

S55、汇总文件的属性数据、切片API分析结果、文件正向依赖分析结果、文件逆向依赖分析结果和无用资源分析结果，得到文件的分析结果。

举例说明上述步骤S53中的切面API的分析过程，参照图7所示，文件1和文件2为入口文件，其中文件2包括API2和API3，容器层模块C中的文件5包括API5，经过切面API分析可得到结果：文件2的API3依赖文件5的API5，这样就构成切面API依赖；

切面API依赖分析结果：API3依赖API5。

切面API依赖分析结果最终会作为分析结果输出，由此可以分析得出应用层和容器层之间API的依赖和被依赖的关系，这样，研发人员可以清楚的得出应用层API和容器层API的依赖和被依赖关系，当多个应用层API均依赖同一个容器层API时，当研发人员对容器层API源码进行迭代或修改，可以及时调整代码以避免对上层API造成错误的影响。

在一个实施例中，上述步骤S53中的文件依赖分析得到文件正向依赖分析结果，在具体实施时，可通过参照图8所示流程实现，该流程包括下述步骤：

S81、根据文件的语法树，在应用层内，对文件所包含的API进行API依赖分析，得到文件所包含的API的正向依赖分析结果；

还是参照图7所示，以文件1作为入口文件开始分析，文件1包括API1，文件2包括API4，其中API1正向依赖API4，因为文件1和文件2同在应用层中，这样就构成API正向依赖；

S82、根据语法树，对文件进行文件路径依赖分析，得到文件所依赖的文件的相对路径；并根据文件地图和文件的相对路径进行依赖寻路，确定所依赖的文件的绝对路径；文件地图记录文件和文件绝对路径的映射关系；

上述文件路径依赖是指一个文件根据约定规则编写的该文件依赖其他文件的依赖路径。约定规则说明了源码中各种依赖路径写法所代表的含义，可以根据这些规则来找到具体的文件。

上述S82中，以一个例子来说，比如约定规则规定以@开头的路径，表明跨模块依赖，参照图7所示，文件a1.json的依赖路径是@B/B2/b2.json，表明文件a1.json跨模块依赖模块B中文件B1/b2.json。从已知的图9所示的模块文件树，可以构建出的如下表1所示的文件地图的例子，该文件地图中包含了文件名和文件的绝对路径的映射关系。

表1

文件名	绝对路径
		a1.json	D:/A/A1/a1.json
a2.json	D:/A/A2/a2.json
		b1.json	D:/B/B1/b1.json
b2.json	D:/B/B2/b2.json
		c1.json	D:/C/C1/c1.json
c2.json	D:/C/C2/c2.json

文件a1.json的依赖路径@B/B2/b2.json，结合表1所示的文件地图中找到b2.json的绝对路径，可以得知a1.json依赖文件b2.json的绝对路径为D:/B/B2/b2.json。

S83、汇总文件所包含的API的正向依赖分析结果和文件所依赖的文件绝对路径，得到文件正向依赖分析结果。

还是以图7所示的例子为例，文件正向依赖分析结果可以包括下面的内容：

API依赖分析结果：API1正向依赖API4；

文件正向依赖关系：文件a1.json正向依赖文件b2.json；

文件依赖路径：b2.json的绝对路径D:/B/B2/b2.json。

在一个实施例中，上述步骤S54中的无用资源是指不被任何其他资源所依赖的资源，对于文件分析结果来说，无用资源分析结果中包含了所有未被其他任何文件所依赖的文件。

逆向依赖分析可以根据文件正向依赖分析的结果进行逆向推导，可以得出文件逆向依赖关系，如图7所示例子，可以推导出文件4逆向依赖文件1，文件5逆向依赖文件2，以及文件3没有被任何文件依赖，为无用文件。

步骤S55中，参照图7所示的例子，汇总后得到的文件分析结果如下：

文件属性数据，即文件元数据：文件1的源代码行数，文件的大小等；

切面API分析结果:API3正向依赖API5；

API依赖分析结果：API1正向依赖API4；

文件正向依赖分析结果：文件a1.json正向依赖文件b2.json；

文件依赖路径：b2.json的绝对路径D:/B/B2/b2.json；

文件逆向依赖分析结果：文件b2.json逆向依赖文件a1.json；

无用资源分析结果：文件b1.json。

经过对应用程序各个文件采用同样的方式进行文件分析，可分别得到各个文件对应的文件分析结果。

在一个实施例中，上述步骤S12对每个模块，在模块级别上进行模块依赖分析，得到各模块正向依赖分析结果，参考图10所示，可以通过下述流程实现，该流程包括下述步骤：

S101、根据模块依赖声明文件，进行模块依赖分析，得到模块的依赖关系；

声明的模块间的依赖关系，并不一定都是合法的，所以，本公开实施例还会结合模块声明文件，对模块依赖关系进行合法性分析，例如：判断容器层模块是否依赖应用层模块，如果判断出存在容器层模块依赖应用层模块，则为非法依赖。以及其他类似的非法依赖关系等。

参照图7所示，假如根据模块声明文件分析得出模块C依赖模块A，经过合法性分析可得出这是个非法依赖关系。容器层模块的存在目的是作为公共模块而被应用层模块所调用的，当发现一个容器层模块依赖应用层模块，就构成了一个非法依赖关系。

S102、根据模块文件树和每个模块所包含的所有文件的分析结果，得到各个模块正向依赖分析结果：

如图7所示，从步骤S55得到文件正向依赖分析结果中得知：文件a1.json正向依赖文件b2.json得出包含文件a1.json的模块A正向依赖包含文件b2.json的模块B，即模块A正向依赖模块B。

在一个实施例中，上述步骤S13中，可以根据汇总模块正向依赖结果，以及每个模块包含所有文件的分析结果，得到每个模块的分析结果。

如图7所示的例子，汇总模块A正向依赖结果和文件分析结果，得出模块A正向依赖模块B，模块A正向依赖模块C，以及模块A中文件1正向依赖模块B中文件4。

在一个实施例中，上述步骤S14中，可根据应用程序各模块的分析结果中模块的正向依赖分析结果，以及模块所包含的文件分析结果中的文件逆向依赖分析结果，推导出模块级别和文件级别上模块的逆向分析结果。

参照图7所示，可以从模块正向依赖关系，推导出模块逆向依赖关系，即可得出模块B逆向依赖模块A，模块C逆向依赖模块A，以及文件4逆向依赖文件1。

下面结合一个具体的实例，说明本公开实施例提供的上述应用程序模块分析的方法，参照图11所示的流程图，包括下述步骤：

从入口文件开始分析源码文件内容，收集文件元数据，同时构建语法树；

根据语法树进行切面API分析、API依赖分析以及文件路径依赖分析；

根据依赖路径，结合文件模块树得到的文件地图，得到依赖路径；

根据API依赖分析结果，依赖路径，得到文件正向依赖分析结果；

对文件正向依赖分析结果进行文件逆向分析，得到文件逆向分析结果和无用资源分析结果；

汇总收集到的文件元数据、切面API分析结果、文件正向依赖分析结果，文件逆向依赖分析结果以及无用资源分析结果，得到文件分析结果；

通过模块依赖声明文件，进行模块依赖分析和合法性分析，得到模块依赖分析结果；

结合模块文件树，模块依赖分析结果和文件分析结果，得到单个模块的分析结果；

汇总单个模块分析结果，得到所有模块分析结果，进行跨模块分析，得到模块逆向依赖分析结果。

在此结合具体的程序，举例说明使用上述应用程序模块的分析方法得到的应用程序模块的分析结果：

假设有一模块的目录结构及文件内容如下：

模块目录结构：.

其余文件内容为空。

经过上述应用程序模块分析方法处理后，将可以获得以下分析结果：

上述分析结果中，举例说明其中一个文件的分析结果，其他类似，在此不再重复说明。

id是指该文件的编号；

name是指该文件名字为getHead.js；

path是指该文件的相对路径；

bundle是指该文件所在的模块；

refError是指该文件存在非法依赖；

"reference":[6]是指该文件依赖其他模块(bundle)中的ID为6的文件；

"refBy":[6]是指该文件被其他模块(bundle)中的ID为6的文件所依赖。

基于同一发明构思，本公开实施例还提供了一种应用程序模块的分析装置、应用程序模块依赖关系的分析工具和计算机可读存储介质，由于这些装置和分析工具等所解决问题的原理与前述方法相似，因此该装置和分析工具等的实施可以参见前述方法的实施，重复之处不再赘述。

本公开实施例还提供了一种应用程序模块的分析装置，参照图12所示，包括：

文件分析单元121，用于对应用程序所包含的至少一个文件的源码进行分析，得到应用程序中至少一个文件的分析结果，包括文件正向依赖分析结果和文件逆向依赖分析结果；

模块分析单元122，用于根据模块包含的文件，确定模块所包含的所有文件的分析结果；并对应用程序的每个模块，在模块级别上进行模块依赖分析，得到模块的正向依赖分析结果；根据模块的正向依赖分析结果和模块所包含的所有文件的分析结果，分别得到模块的分析结果；汇总应用程序中模块的分析结果，进行跨模块分析，得到在模块级别和文件级别上模块之间的逆向依赖分析结果。

本公开实施例还提供了一种应用程序模块依赖关系的分析工具，该分析工具用于分析应用程序的源码，生成对应的模块分析报告，模块分析报告包括下述任一项或多项的组合：

应用程序所包含的模块之间的依赖关系；

各模块所包含的文件之间的依赖关系；

各文件所包含的API之间的依赖关系；

依赖关系包括：正向依赖关系和逆向依赖关系。

根据依赖关系的分析报告，可以帮助程序员准确定位错误依赖关系的模块，及时纠正错误，并且可以明确模块、文件、API被依赖的模块、文件、API，在修改被依赖模块的时候可以预知修改导致的影响，避免错误的产生，减少程序源码的冗余，降低模块维护的成本。

本公开实施例还提供了一种应用程序源码分析工具，包括存储器和处理器；存储器存储有计算机程序，程序被处理器执行时能够实现应用程序模块的分析方法。

本公开实施例还提供了一种计算机可读存储介质，其上存储有计算机指令，改指令被处理器执行时实现应用程序模块的分析方法。

本公开是参照根据本公开实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本公开进行各种改动和变型而不脱离本公开的精神和范围。这样，倘若本公开的这些修改和变型属于本公开权利要求及其等同技术的范围之内，则本公开也意图包含这些改动和变型在内。

Claims (11)

1.一种应用程序模块的分析方法，包括：

对应用程序所包含的至少一个文件的源码进行分析，得到所述至少一个文件的分析结果；

根据所述模块包含的文件，确定模块所包含的文件的分析结果；并对所述应用程序的模块，在模块级别上进行模块依赖分析，得到所述模块的正向依赖分析结果；

根据所述模块的正向依赖分析结果和模块所包含的文件的分析结果，得到所述模块的分析结果；

汇总所述应用程序中模块的分析结果，进行跨模块分析，得到在模块级别和文件级别上模块之间的逆向依赖分析结果。

2.如权利要求1所述的方法，对应用程序所包含的至少一个文件的源码进行分析，得到所述至少一个文件的分析结果，具体包括：

从应用程序的至少一个入口文件开始，依次对所述入口文件的源码进行文件依赖分析，得到文件依赖分析结果，以递归的方式的对入口文件依赖文件继续进行文件依赖分析，直到遍历完所述应用程序包含的文件，得到应用程序所有文件的分析结果。

3.如权利要求2所述的方法，还包括：

创建栈数据结构，在所述栈数据结构中记录应用程序所包含的文件递归的路径；

根据所述文件递归的路径，判断当前所需分析的文件的源码是否已被遍历；

当判断为否时，执行对所述文件的源码进行分析的步骤；

当判断为是时，跳转至下一个所依赖的文件的源码进行分析。

4.如权利要求1-3任一项所述的方法，对应用程序所包含的至少一个文件的源码进行分析，得到所述至少一个文件的分析结果，包括：

分别收集文件的属性数据；

对所述文件的源码进行语法分析，构建对应的语法树；

基于所述文件的语法树，分别对所述文件的源码进行切面API分析和文件依赖分析，分别得到所述文件的切面API分析结果和文件正向依赖分析结果；所述切面API分析为应用层文件的API和容器层API之间依赖关系的分析；

根据所述文件的正向依赖分析结果，确定文件级别上的文件逆向依赖分析结果和无用资源分析结果；所述无用资源分析结果包含未被其他任何文件所依赖的文件；

汇总所述文件的属性数据、切片API分析结果、文件正向依赖分析结果、文件逆向依赖分析结果和无用资源分析结果，得到所述文件的分析结果。

5.如权利要求4所述的方法，对文件的源码进行文件依赖分析，得到文件正向依赖分析结果，包括：

根据所述文件的语法树，在应用层内，对所述文件所包含的各API进行API依赖分析，得到所述文件所包含的API的正向依赖分析结果；

根据所述语法树，对所述文件进行文件路径依赖分析，得到所述文件所依赖的文件的相对路径；并根据文件地图和所述文件的相对路径进行依赖寻路，确定所依赖的文件的绝对路径；所述文件地图记录有文件和文件绝对路径的映射关系；

汇总文件所包含的API的正向依赖分析结果和所述文件所依赖的文件绝对路径，得到文件正向依赖分析结果。

6.如权利要求4的方法，汇总所述应用程序中模块的分析结果，进行跨模块分析，得到在模块级别和文件级别上模块之间的逆向依赖分析结果，包括：

根据所述模块的分析结果中模块的正向依赖分析结果，以及所述模块所包含的文件分析结果中的文件逆向依赖分析结果，推导出模块级别和文件级别上所述模块的逆向分析结果。

7.如权利要求1-3任一项所述的方法，在模块级别上进行模块依赖分析，得到模块正向依赖分析结果，包括：

根据所述模块依赖声明文件，对模块进行依赖分析，所述依赖分析包括模块间依赖关系分析和依赖合法性分析，得到模块正向依赖分析结果。

8.一种应用程序模块的分析装置，包括：

文件分析单元，用于对应用程序所包含的至少一个文件的源码进行分析，得到应用程序中至少一个文件的分析结果；包括文件正向依赖分析结果和文件逆向依赖分析结果；

模块分析单元，用于根据所述模块包含的文件，确定模块所包含的所有文件的分析结果；并对所述应用程序的模块，在模块级别上进行模块依赖分析，得到所述模块的正向依赖分析结果；根据所述模块的正向依赖分析结果和模块所包含的文件的分析结果，得到所述模块的分析结果；汇总所述应用程序中模块的分析结果，进行跨模块分析，得到在模块级别和文件级别上模块之间的逆向依赖分析结果。

9.一种应用程序模块依赖关系的分析工具，所述分析工具用于分析应用程序的源码，生成对应的模块分析报告，所述报告包括下述任一项或多项的组合：

所述应用程序所包含的模块之间的依赖关系；

所述各模块所包含的文件之间的依赖关系；

所述各文件所包含的API之间的依赖关系；

所述依赖关系包括：正向依赖关系和逆向依赖关系。

10.一种应用程序源码分析工具，包括：存储器和处理器；其中，所述存储器存储有计算机程序，所述程序被处理器执行时能够实现如权利要求1-7任一项所述的应用程序模块的分析方法。

11.一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现如权利要求1-7任一项所述的应用程序模块的分析方法。

Images