基于多引擎系统的恶意程序检测方法和装置与流程

本申请涉及计算机安全技术领域，特别涉及一种基于多引擎系统的恶意程序检测方法和装置。

背景技术：

随着互联网业务高速发展，越来越多的业务需要接受并处理用户提交的各类信息，如果信息被盗用或者泄露，会带来极大安全风险。例如人力资源部门每日必须人工浏览大量外部不可信来源发送的简历文件，如果这些文件含有病毒或后门并感染了人力资源同事的电脑，则会带来严重的敏感信息泄露事故。

目前，可通过杀毒软件对终端设备中的文件进行扫描，并对病毒等恶意文件进行查杀。但是，由于一些杀毒软件的引擎对某类样本识别率高，但对其它类型的样本识别率低或误报率高，因此单引擎的杀毒软件难以对复杂环境提供有效的安全保障。虽然多引擎技术已经开始应用于恶意文件查杀，但是由于需要通过每个杀毒引擎分别对文件处理，因此处理时间较长，且准确率仍有待提高、误报率也有待降低。

申请内容

本申请旨在至少在一定程度上解决相关技术中的技术问题之一。为此，本申请第一方面的目的在于提出一种基于多引擎系统的恶意程序检测方法，能够降低系统消耗，提高恶意程序检测的效率和准确率。

本申请第二方面的目的在于提出一种基于多引擎系统的恶意程序检测装置。

根据本申请第一方面实施例提出的一种基于多引擎系统的恶意程序检测方法，其中所述多引擎系统包括多个引擎，每个引擎分别对应有各自的擅长处理类型，所述方法包括以下步骤：分析待测程序的类型；根据所述待测程序的类型和所述多个引擎对应的擅长处理类型确定擅长处理所述待测程序的第一引擎；通过所述第一引擎对所述待测程序进行检测，并将所述第一引擎的检测结果作为所述多引擎系统对所述待测程序的检测结果。

根据本申请实施例的基于多引擎系统的恶意程序检测方法，通过分析待测程序的类型，利用最擅长处理该类型待测程序的引擎对该待测程序进行检测，与相关技术相比，智能地使用单引擎而不是多引擎检测程序，从而降低系统消耗，提高恶意程序检测的效率和准确 率。

根据本申请第二方面实施例提出的一种基于多引擎系统的恶意程序检测装置，其中所述多引擎系统包括多个引擎，每个引擎分别对应有各自的擅长处理类型，所述装置包括：第一分析模块，用于分析待测程序的类型；确定模块，用于根据所述待测程序的类型和所述多个引擎对应的擅长处理类型确定擅长处理所述待测程序的第一引擎；第一检测模块，用于通过所述第一引擎对所述待测程序进行检测，并将所述第一引擎的检测结果作为所述多引擎系统对所述待测程序的检测结果。

根据本申请实施例的基于多引擎系统的恶意程序检测装置，通过分析待测程序的类型，利用最擅长处理该类型待测程序的引擎对该待测程序进行检测，与相关技术相比，智能地使用单引擎而不是多引擎检测程序，从而降低系统消耗，提高恶意程序检测的效率和准确率。

附图说明

图1为根据本申请一个实施例的基于多引擎系统的恶意程序检测方法的流程图；

图2为根据本申请一个实施例的多个引擎对应的擅长处理类型的建立的流程图；

图3为根据本申请另一个实施例的基于多引擎系统的恶意程序检测方法的流程图；

图4为根据本申请又一个实施例的基于多引擎系统的恶意程序检测方法的流程图；

图5为根据本申请一个实施例的基于多引擎系统的恶意程序检测装置的结构示意图；

图6为根据本申请另一个实施例的基于多引擎系统的恶意程序检测装置的结构示意图；

图7为根据本申请又一个实施例的基于多引擎系统的恶意程序检测装置结构示意图；

图8为根据本申请再一个实施例的基于多引擎系统的恶意程序检测装置的结构图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本申请，而不能理解为对本申请的限制。

下面参考附图描述根据本申请实施例的基于多引擎系统的恶意程序检测方法和装置。

图1为根据本申请一个实施例的基于多引擎系统的恶意程序检测方法的流程图。

其中，本申请实施例的多引擎系统包括多个引擎，每个引擎分别对应有各自的擅长处理类型。

其中，引擎泛指鉴定样本是否为恶意的某种机制，目前几乎每个杀毒软件厂家都有自 己的引擎。例如，多引擎系统可包括不限于大蜘蛛、卡巴斯基、诺顿、迈克菲、熊猫卫士、金山、奇虎360等。

举例而言，多系统引擎可包括A、B和C三个引擎，各自对应的擅长处理类型分别为以非法扣费为目的的android恶意文件、以盗取账号为目的的木马文件，以攻击特定目标为目的的嵌入到Office中的恶意文件等。

具体地，如图1所示，根据本申请实施例的基于多引擎系统的恶意程序检测方法，包括以下步骤：

S1，分析待测程序的类型。

其中待测程序指一切待分析的不确定是否有安全风险的计算机文件。

在本发明的一个实施例中，可根据文件后缀名对待测程序的类型进行分析。例如：后缀为exe类的可能是病毒或木马，后缀为pdf、office类的可能是捆绑程序，后缀为apk的一般是吸费和盗取用户隐私程序。

S2，根据待测程序的类型和多个引擎对应的擅长处理类型确定擅长处理待测程序的第一引擎。

具体地，可判断待测程序的类型属于哪一个引擎所对应的擅长处理类型，并将待测程序的类型所属的擅长处理类型对应的引擎作为用于处理待测程序的第一引擎。

S3，通过第一引擎对待测程序进行检测，并将第一引擎的检测结果作为多引擎系统对待测程序的检测结果。

本申请实施例的基于多引擎系统的恶意程序检测方法，通过分析待测程序的类型，利用擅长处理该类型待测程序的引擎对该待测程序进行检测，智能地选择擅长处理待测程序的单引擎而不是多引擎检测程序，能够降低系统消耗，且响应速度更快，从而提高恶意程序检测的效率和准确率，降低误判率。

在本申请的实施例中，其中，多引擎系统中的每个引擎所对应的擅长处理类型可通过对大量历史数据的分析来获得。具体地，如图2所示，在本申请的实施例中，多个引擎对应的擅长处理类型的建立步骤如下：

S201，通过多个引擎对多个训练程序分别进行检测。

S202，获取每个引擎对多个训练程序的检测结果,。

具体地，可获取每个训练引擎对每个训练程序的识别结果(识别为恶意程序或者正常程序)，以及检测速度。

S203，对每个引擎对多个训练程序的检测结果进行统计分析，以确定每个引擎的擅长处理类型。

在本申请的一个实例中，多个训练程序中可包括多个正常程序和分别属于多个类型的 恶意程序，其中恶意程序为预先收集并通过人工分析归类的，可包括但不限于：以非法扣费为目的的android恶意文件、以盗取账号为目的的木马文件，以攻击特定目标为目的的嵌入到Office中的恶意文件。S203可具体包括：根据检测结果分别统计每个引擎对每个类型的恶意程序的检测精度和检测速度；对于每个类型的恶意程序，根据检测精度和检测速度确定对该类型的恶意程序检测效果最好的引擎，并将该类型作为检测效果最好的引擎的擅长处理类型。

其中，检测精度可包括识别准确率和误判率，识别准确率越高、误判率越低，则检测精度越高，识别准确率越低、误判率越稿，则检测精度越低。

在本申请的一个实施例中，可将经过一段时间，如经过多年收集到的已经确认是恶意文件的样本(即训练程序中的恶意程序)进行归类，并按类别发送给多个引擎，同时将已确定为正常文件的多个正常程序发送给多个引擎进行检测。例如，Office嵌入恶意文件类型的几千个训练程序以及几千个正常程序同时发送给五个不同引擎，并观察查杀结果。由于测试样本是否是恶意的我们是知道的，所以我们可以根据结果判断引擎是否能足量的发现恶意文件。同时，分析每个引擎对Office嵌入恶意文件类型的训练程序的检测结果，得到每个引擎对Office嵌入恶意文件类型的训练程序的识别准确率(即正确识别出Office嵌入恶意文件的概率)以及对正常程序的误判率(即将正常程序识别为恶意程序的概率)。结果发现微软的MSE(Microsoft Security Essentials，微软安全软件)杀毒引擎对嵌入到Office中的恶意文件检测速度最快，且检测精度最高，由此，在恶意程序检测中，将MSE的擅长处理类型确定为Office文件。而以微软为首的一系列引擎对安卓的恶意apk程序检测效果极差，所以apk类的待测程序可以直接推送给其他检测效果好的引擎。

此外，在本申请的一个实施例中，还可对多引擎系统中擅长处理某类型程序的引擎不断进行优化。图3为根据本申请另一个实施例的基于多引擎系统的恶意程序检测方法的流程图。如图3所示，本申请实施例的基于多引擎系统的恶意程序检测方法，包括以下步骤：

S301，分析待测程序的类型。

其中待测程序指一切待分析的不确定是否有安全风险的计算机文件。

在本发明的一个实施例中，可根据文件后缀名对待测程序的类型进行分析。例如：后缀为exe类的可能是病毒或木马，后缀为pdf、office类的可能是捆绑程序，后缀为apk的一般是吸费和盗取用户隐私程序。

S302，根据待测程序的类型和多个引擎对应的擅长处理类型确定擅长处理待测程序的第一引擎。

具体地，可判断待测程序的类型属于哪一个引擎所对应的擅长处理类型，并将待测程序的类型所属的擅长处理类型对应的引擎作为用于处理待测程序的第一引擎。

S303，通过第一引擎对待测程序进行检测，并将第一引擎的检测结果作为多引擎系统对待测程序的检测结果。

S304，通过第三方引擎对待测程序进行检测，并获取第三方引擎的检测结果。

应当理解，本申请的实施例中，S304可在S301-S303之前，也可在S301-S303之后，本申请对此不作限定。

S305，将第三方引擎的检测结果与多引擎系统对待测程序的检测结果进行比较。

其中，第三方引擎可为不不包括于多引擎系统中的任一引擎。

具体地，可将第三方引擎的检测精度和检测速度与多引擎系统对待测程序的检测精度和检测速度分别进行比较。如果第三方引擎的检测精度和检测速度都高于多引擎系统的检测精度和检测速度，则第三方引擎的检测结果优于多引擎系统对待测程序的检测结果。

S306，如果第三方引擎的检测结果优于多引擎系统对待测程序的检测结果，则使用第三方引擎对多引擎系统进行更新。

由此，通过多个引擎对应的擅长处理类型的建立，确保丰富的引擎资源用于恶意程序检测，而多引擎系统的更新使检测恶意程序的引擎不断优化，不断提高检测效率和准确率。

在本申请的一个实施例中，待测程序的类型可能与多个引擎对应的擅长处理的类型均不同。在这种情况下，可通过多引擎系统中的多个引擎分别对待测程序进行检测，并根据多个引擎的检测结果得到最终的检测结果。具体地，图4为根据本申请又一个实施例的基于多引擎系统的恶意程序检测方法的流程图。

如图4所示，基于多引擎系统的恶意程序检测方法可包括以下步骤：

S401，分析待测程序的类型。

其中待测程序指一切待分析的不确定是否有安全风险的计算机文件。

在本发明的一个实施例中，可根据文件后缀名对待测程序的类型进行分析。例如：后缀为exe类的可能是病毒或木马，后缀为pdf、office类的可能是捆绑程序，后缀为apk的一般是吸费和盗取用户隐私程序。

S402，根据待测程序的类型和多个引擎对应的擅长处理类型判断多个引擎对应的擅长处理类型是否存在与待测程序的类型相同的处理类型。

如果存在，则执行S406，否则执行S403。

S403，通过多个引擎分别对待测程序进行检测。

当多引擎系统的引擎不够丰富或待测程序的类型比较特殊时，可能存在待测程序类型与多个引擎对应的擅长处理类型不同的情况。在这种情况下，可将待测程序发送给多引擎系统中的所有引擎，以通过多个引擎分别对待测程序进行检测。

S404，获取多个引擎的检测结果。

每个引擎独立地对待测程序进行检测，最终获取所有引擎对待测程序的识别结果，即将待测程序识别为恶意程序还是正常程序。

S405，对多个引擎的检测结果进行统计分析，并根据统计分析结果确定多引擎系统对待测程序的检测结果。

其中，分析结果可根据少数服从多数来决定。例如，若判断待测程序为恶意程序的引擎数量多于判断待测程序为正常程序的引擎数量时，则检测结果为：该程序为恶意程序。

S406，确定多引擎系统中擅长处理待测程序的第一引擎。

在本申请的一个实施例中，以检测Office嵌入文件为例进行说明。已分析出文件类型为Office嵌入文件，对此类型文件查杀最准确的是微软的MSE杀毒引擎，从而将MSE杀毒引擎作为处理该文件的第一引擎。

S407，通过第一引擎对待测程序进行检测，并将第一引擎的检测结果作为多引擎系统对待测程序的检测结果。

在本申请的一个实施例中，将Office嵌入文件只交给MSE处理，而不再交给别的杀毒引擎。并将MSE对该文件的检测结果作为最终结果，这样就节约了时间，还能保证准确度。

根据本申请实施例的基于多引擎系统的恶意程序检测方法，通过分析待测程序的类型，并根据该类型智能选择单引擎或者多引擎对待测程序进行检测，从而能全面地对待测程序进行检测，提高恶意程序检测的效率和准确率，降低误判率。

为了实现上述实施例，本申请还提出一种基于多引擎系统的恶意程序检测装置。

图5为根据本申请一个实施例的基于多引擎系统的恶意程序检测装置的结构示意图。

其中，本申请实施例的多引擎系统包括多个引擎，每个引擎分别对应有各自的擅长处理类型。

其中，引擎泛指鉴定样本是否为恶意的某种机制，目前几乎每个杀毒软件厂家都有自己的引擎。例如，多引擎系统可包括不限于大蜘蛛、卡巴斯基、诺顿、迈克菲、熊猫卫士、金山、奇虎360等。

举例而言，多系统引擎可包括A、B和C三个引擎，各自对应的擅长处理类型分别为以非法扣费为目的的android恶意文件、以盗取账号为目的的木马文件，以攻击特定目标为目的的嵌入到Office中的恶意文件等。

如图5所示，本申请实施例的基于多引擎系统的恶意程序检测装置包括：第一分析模块1、确定模块2、第一检测模块3。

具体地，第一分析模块1用于分析待测程序的类型。

其中待测程序指一切待分析的不确定是否有安全风险的计算机文件。

在本发明的一个实施例中，第一分析模块1可根据文件后缀名对待测程序的类型进行 分析。例如：后缀为exe类的可能是病毒或木马，后缀为pdf、office类的可能是捆绑程序，后缀为apk的一般是吸费和盗取用户隐私程序。

确定模块2用于根据待测程序的类型和多个引擎对应的擅长处理类型确定擅长处理待测程序的第一引擎。

更具体地，确定模块2可判断待测程序的类型属于哪一个引擎所对应的擅长处理类型，并将待测程序的类型所属的擅长处理类型对应的引擎作为用于处理待测程序的第一引擎。

第一检测模块3用于通过第一引擎对待测程序进行检测，并将第一引擎的检测结果作为多引擎系统对待测程序的检测结果。

本申请实施例的基于多引擎系统的恶意程序检测装置，通过分析待测程序的类型，利用擅长处理该类型待测程序的引擎对该待测程序进行检测，智能地选择擅长处理待测程序的单引擎而不是多引擎检测程序，能够降低系统消耗，且响应速度更快，从而提高恶意程序检测的效率和准确率，降低误判率。

在本申请的实施例中，其中，多引擎系统中的每个引擎所对应的擅长处理类型可通过对大量历史数据的分析来获得。具体地，如图6所示，本申请实施例的基于多引擎系统的恶意程序检测装置还包括：第四检测模块4、第二获取模块5和第三分析模块6。

其中，第四检测模块4用于通过所述多个引擎对多个训练程序分别进行检测。

第二获取模块5用于获取每个引擎对所述多个训练程序的检测结果。更具体地，可获取每个训练引擎对每个训练程序的识别结果(识别为恶意程序或者正常程序)，以及检测速度。

第三分析模块6用于对每个引擎对多个训练程序的检测结果进行统计分析，以确定每个引擎的擅长处理类型。

在本申请的一个实例中，多个训练程序中可包括多个正常程序和分别属于多个类型的恶意程序，其中恶意程序为预先收集并通过人工分析归类的，可包括但不限于：以非法扣费为目的的android恶意文件、以盗取账号为目的的木马文件，以攻击特定目标为目的的嵌入到Office中的恶意文件。第三分析模块6可具体用于：根据检测结果分别统计每个引擎对每个类型的恶意程序的检测精度和检测速度；对于每个类型的恶意程序，根据检测精度和检测速度确定对该类型的恶意程序检测效果最好的引擎，并将该类型作为检测效果最好的引擎的擅长处理类型。

其中，检测精度可包括识别准确率和误判率，识别准确率越高、误判率越低，则检测精度越高，识别准确率越低、误判率越稿，则检测精度越低。

在本申请的一个实施例中，可将经过一段时间，如经过多年收集到的已经确认是恶意文件的样本(即训练程序中的恶意程序)进行归类，并按类别发送给多个引擎，同时将已 确定为正常文件的多个正常程序发送给多个引擎进行检测。例如，Office嵌入恶意文件类型的几千个训练程序以及几千个正常程序同时发送给五个不同引擎，并观察查杀结果。由于测试样本是否是恶意的我们是知道的，所以我们可以根据结果判断引擎是否能足量的发现恶意文件。同时，分析每个引擎对Office嵌入恶意文件类型的训练程序的检测结果，得到每个引擎对Office嵌入恶意文件类型的训练程序的识别准确率(即正确识别出Office嵌入恶意文件的概率)以及对正常程序的误判率(即将正常程序识别为恶意程序的概率)。结果发现微软的MSE(Microsoft Security Essentials，微软安全软件)杀毒引擎对嵌入到Office中的恶意文件检测速度最快，且检测精度最高，由此，在恶意程序检测中，将MSE的擅长处理类型确定为Office文件。而以微软为首的一系列引擎对安卓的恶意apk程序检测效果极差，所以apk类的待测程序可以直接推送给其他检测效果好的引擎。

此外，在本申请的一个实施例中，还可对多引擎系统中擅长处理某类型程序的引擎不断进行优化。

图7为根据本申请又一个实施例的基于多引擎系统的恶意程序检测装置结构示意图。如图7所示，本申请实施例的基于多引擎系统的恶意程序检测装置包括：第一分析模块1、确定模块2、第一检测模块3、第三检测模块7、比较模块8和更新模块9。

具体地，第一分析模块1用于分析待测程序的类型。

其中待测程序指一切待分析的不确定是否有安全风险的计算机文件。

在本发明的一个实施例中，分析模块1可根据文件后缀名对待测程序的类型进行分析。例如：后缀为exe类的可能是病毒或木马，后缀为pdf、office类的可能是捆绑程序，后缀为apk的一般是吸费和盗取用户隐私程序。

确定模块2用于根据待测程序的类型和多个引擎对应的擅长处理类型确定擅长处理待测程序的第一引擎。

更具体地，确定模块2可判断待测程序的类型属于哪一个引擎所对应的擅长处理类型，并将待测程序的类型所属的擅长处理类型对应的引擎作为用于处理待测程序的第一引擎。

第一检测模块3用于通过第一引擎对待测程序进行检测，并将第一引擎的检测结果作为多引擎系统对待测程序的检测结果。

第三检测模块7用于通过第三方引擎对待测程序进行检测，并获取第三方引擎的检测结果。

比较模块8用于将第三方引擎的检测结果与多引擎系统对待测程序的检测结果进行比较。

更具体地，比较模块8可将第三方引擎的检测精度和检测速度与多引擎系统对待测程序的检测精度和检测速度分别进行比较。如果第三方引擎的检测精度和检测速度都高于多 引擎系统的检测精度和检测速度，则第三方引擎的检测结果优于多引擎系统对待测程序的检测结果。

更新模块9用于在第三方引擎的检测结果优于多引擎系统对待测程序的检测结果时，使用第三方引擎对多引擎系统进行更新。

由此，通过多个引擎对应的擅长处理类型的建立，确保丰富的引擎资源用于恶意程序检测，而多引擎系统的更新使检测恶意程序的引擎不断优化，不断提高检测效率和准确率。

在本申请的一个实施例中，待测程序的类型可能与多个引擎对应的擅长处理的类型均不同。在这种情况下，可通过多引擎系统中的多个引擎分别对待测程序进行检测，并根据多个引擎的检测结果得到最终的检测结果。具体地，图8为根据本申请再一个实施例的基于多引擎系统的恶意程序检测装置的结构图。

如图8所示，基于多引擎系统的恶意程序检测装置可包括：第一分析模块1、确定模块2、第一检测模块3、第二检测模块10、第一获取模块11和第二分析模块12。

具体地，第一分析模块1用于分析待测程序的类型。

其中待测程序指一切待分析的不确定是否有安全风险的计算机文件。

在本发明的一个实施例中，第一分析模块1可根据文件后缀名对待测程序的类型进行分析。例如：后缀为exe类的可能是病毒或木马，后缀为pdf、office类的可能是捆绑程序，后缀为apk的一般是吸费和盗取用户隐私程序。

确定模块2用于根据待测程序的类型和多个引擎对应的擅长处理类型确定擅长处理待测程序的第一引擎。

更具体地，确定模块2可判断待测程序的类型属于哪一个引擎所对应的擅长处理类型，并将待测程序的类型所属的擅长处理类型对应的引擎作为用于处理待测程序的第一引擎。

在本申请的一个实施例中，以检测Office嵌入文件为例进行说明。已分析出文件类型为Office嵌入文件，对此类型文件查杀最准确的是微软的MSE杀毒引擎，从而将MSE杀毒引擎作为处理该文件的第一引擎。

第一检测模块3用于通过第一引擎对待测程序进行检测，并将第一引擎的检测结果作为多引擎系统对待测程序的检测结果。

在本申请的一个实施例中，将Office嵌入文件只交给MSE处理，而不再交给别的杀毒引擎。并将MSE对该文件的检测结果作为最终结果，这样就节约了时间，还能保证准确度。

第二检测模块10用于在待测程序的类型与多个引擎对应的擅长处理类型均不同时，通过多个引擎分别对待测程序进行检测；

当多引擎系统的引擎不够丰富或待测程序的类型比较特殊时，可能存在待测程序类型与多个引擎对应的擅长处理类型不同的情况。在这种情况下，可将待测程序发送给多引擎 系统中的所有引擎，以通过多个引擎分别对待测程序进行检测。

第一获取模块11用于获取多个引擎的检测结果。

每个引擎独立地对待测程序进行检测，最终获取所有引擎对待测程序的识别结果，即将待测程序识别为恶意程序还是正常程序。

第二分析模块12用于对多个引擎的检测结果进行统计分析，并根据统计分析结果确定多引擎系统对待测程序的检测结果。

其中，分析结果可根据少数服从多数来决定。例如，若判断待测程序为恶意程序的引擎数量多于判断待测程序为正常程序的引擎数量时，则检测结果为：该程序为恶意程序。

根据本申请实施例的基于多引擎系统的恶意程序检测装置，通过分析待测程序的类型，并根据该类型智能选择单引擎或者多引擎对待测程序进行检测，从而能全面地对待测程序进行检测，提高恶意程序检测的效率和准确率，降低误判率。

在本申请的描述中，需要理解的是，术语“中心”、“纵向”、“横向”、“长度”、“宽度”、“厚度”、“上”、“下”、“前”、“后”、“左”、“右”、“竖直”、“水平”、“顶”、“底”、“内”、“外”、“顺时针”、“逆时针”、“轴向”、“径向”、“周向”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本申请和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本申请的限制。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本申请的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

在本申请中，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”、“固定”等术语应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或成一体；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通或两个元件的相互作用关系。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本申请中的具体含义。

在本申请中，除非另有明确的规定和限定，第一特征在第二特征“上”或“下”可以是第一和第二特征直接接触，或第一和第二特征通过中间媒介间接接触。而且，第一特征在第二特征“之上”、“上方”和“上面”可是第一特征在第二特征正上方或斜上方，或仅仅表示第一特征水平高度高于第二特征。第一特征在第二特征“之下”、“下方”和“下面”可以是第一特征在第二特征正下方或斜下方，或仅仅表示第一特征水平高度小于第二特征。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、 或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。