第10章 化繁为简的翻译机——解释器模式
如果想看完整的设计模式系列，可以去这 android源码设计模式解析与实战目录
第10章 化繁为简的翻译机——解释器模式
- 10.1 解释器模式介绍
- 10.2 解释器模式的定义
- 10.3 解释器模式的使用场景
- 10.4 解释器模式的UML类图
- 10.5 解释器模式的简单实现
- 10.6 Android源码中的解释器模式实现
- 10.7 关于PackageManagerService
- 10.8 小结
10.1 解释器模式介绍
解释器模式(Interpreter Pattern) 是一种用得比较少的行为型模式，其提供了一种解释语言的语法或表达式的方式，该模式定义了一个表达式接口，通过该接口解释一个特定的上下文。在这么多的设计模式中，解释器模式在实际运用上相对来说要少很多，因为我们很少会自己去构造一个语言的文法。虽然如此，既然它能够在设计模式中有一席之地，那么必定有它的可用之处，本章会以 最直白的言语来阐述清楚解释器模式是如何工作的。
10.2 解释器模式的定义
给定一个语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。
与其他设计模式不同的是，解释器模式涉及编程语言理论知识较多，就拿上面对该模式的定义来说，可能会有很多读者根本看不懂这句话的意思，什么叫文法？为什么叫解释器？其又是如何表达的？要彻底搞懂其含义，我们首先要对文法有一个大体的认识。何谓文法？举个简单的例子大家一看就会懂，假设有如下短语。
这个只有5个字的短语我相信没人会说看不懂，有朋友会问，这与我们要讲的文法有什么关系呢？确实，这一个短语体现不了什么，那么我们再看几条。
那么上面的这些短语有什么规律呢？上面这些短语中的“我”可以看成是主语，而“是”则表示谓语，“程序员”“设计师”和“搬运工”这些名词则可看成宾语，也就是说上面的这些短语都可看成是一个“主谓宾”的结构，而这样的结构我们则称为一条文法，我们可以通过该文法来造出更多符合该文法的语句。当然文法的概念范围非常广，并不局限于主谓宾、定状补这样的语法结构，还是用上面的短语来举例，我们也可以把上面的这些短语看成是一条“我是[名词]”这样的结构，这也可以看作一条文法。
如上所述文法的概念范围很广，对于我们程序员来说更愿意接受abcd这类字符形式的表示方式，假设有如下以ab开头ef结尾中间排列N(N>=0)个cd的字符串。
随着N值的不同具体的字符串也会不一样，我们可以从中得到类似“abef”、“abcdef ”、“abcdcdef”之类的字符串。试想一下，是否可以将其表示为一个具体的表达式规则呢？答案是肯定的。在计算机科学中，我们将上述字符串中的“a” “b” “c” “d” “e”和“f”这6个字符称为一种形式语言的字符表，而这些字符组成的集合，如上面的“abed…cdef”这样由字符表构成的字符串则称为形式语言，注意，这里是“语言”不是“文法”。假如定义一个符号S(也可以是A、F、G等)，从符号S出发推导上述字符串，那么就可以得到如下的推导式：
其中符号“ ::= ”表示推导；符号“ * ”表示闭包，意思就是符号A可以有0或N个重复；S和A则称非终结符号，因为它们能推导出式子右边的表达式，同时又因为整个推导式是从S出发的，因此，这个S也称为初始符号；而abef和cd这些字符不能再被推导我们将之为终结符号。而上面的推导式意思也很简单，与我们小学时学的因式分解极其相似。像这样的从一个具体的符号出发，通过不断地应用一些产生式规则从而生成一个字符串的集合，我们将描述这个集合的文法称为形式文法，顾名思义，形式文法与形式语言相对应，用来描述形式语言。一般情况下，解释器模式中描述的也是形式语言，定义的也是形式文法，当然你也可以用来描述语言和文法，但它们的范畴都太大，而且对我们编程来说很少会涉猎。
我们对形式语言和形式文法有了一个初步的了解后再来审读一下解释器模式的定义：给定一个语言(如由abedef六个字符组成的字符串集合)，定义它的文法的一种表示(如上面给出的S::=abA *ef和A::=cd)，并定义一个解释器，该解释器使用该表示来解释语言中的句子。这样看起来相对来说是不是更好理解些了？现在只有解释器没说清楚了，究竟什么是解释器，它又是如何工作的呢？与其说成解释倒不如说成翻译更好理解，你也可以将解释器简单地理解为一个翻译机。还是用上面的例子中的文法来举例，其就是用来翻译类似“abef”、“abedef”和 “abededef”之类的字符串句子，这样一来是否对解释器模式的定义有了更进一步的理解了？在编程的时候我们很少会涉及如上那种标准的文法推导式，很多时候会直接使用类似“A*B”这样的字符串规则表达式表示文法，该文法表示"AigeAigeAigeStudio"、“Studio”、"AigeStudio” 之类的字符串。
10.3 解释器模式的使用场景
解释器模式的使用场景其实相当广泛，总的概括下来大致有如下两种。
（1）如果某个简单的语言需要解释执行而且可以将该语言中的语句表示为一个抽象语法树时，可以考虑使用解释器模式。
这种场景很好理解，如一个简单的含有加减运算的数学表达式：p+q+m-n，像这样的表达式其构成无非就两种，一种是以pqmn这类的具体参数表示的符号，其无法再被推导，如上面我们所述，其也被称为终结符号；另一种则是以“+”和“-”构成的算术运算符，在该运算符的两边总能找到有意义的具体计算参数，我们也称其为非终结符号，如上的数学表达式我们也可以将其表示为一棵抽象语法树，如图10-1所示。
那么为什么要说是“简单的语言”呢？试想一下，如果我们的表达式是p+q-m/n*x%y^z这样的呢？这个表达式看起来也不算“复杂”，先别急，等我们看完之后的内容你就会知道，这样的一个表达式对于使用解释器模式来解释是多么复杂。
（2）在某些特定的领域出现不断重复的问题时，可以将该领域的问题转化为一种语法规则下的语句，然后构建解释器来解释该语句。
如需要将一段阿拉伯数字转换为中文的数字，又或者将某个小写英文短语转换为大写，如aigestudio这样的字符串，我们需要将其转换为大写AIGESTUDIO，这时对于这样的转换来说，其实就是一个不断重复的问题，因为所有的阿拉伯或中文数字和大小写字母都是固定的，也就是说它们都是一个个终结符，不同的只是其具体内容而已，这时候就可以尝试使用解释器模式来解决类似的问题。
10.4 解释器模式的UML类图
解释器模式的通用UML类图如图10-2所示。
根据类图可以得出如下一个解释器模式的通用模式代码。
角色介绍
- AbstractExpression: 抽象表达式。
声明一个抽象的解释操作父类，并定义一个抽象的解释方法，其具体的实现在各个具体的子类解释器中完成。 - TerminalExpression：终结符表达式。
实现文法中与终结符有关的解释操作。文法中每一个终结符都有一个具体的终结表达式与之对应。 - NonterminalExpression：非终结符表达式。
实现文法中与非终结符有关的解释操作。 - Context：上下文环境类。
包含解释器之外的全局信息。 - Client：客户类。
解析表达式，构建抽象语法树，执行具体的解释操作等。
10.5 解释器模式的简单实现
如本章开头所说，解释器模式的应用范围相当广泛，一个比较常见的场景是对算术表达式的解释，如表达式"m + n + p”，如果我们使用解释器模式对该表达式进行解释，那么代表数字的m、n和p三个字母我们就可以看成是终结符号，而“+”这个算术运算符号则可当作非终结符号。同样地，我们可以先创建一个抽象解释器表示数学运算。
在该抽象解释器的解释方法interpret中，我们没有像前面的例子那样使用一个Context对象作为interpret方法的签名，在本例中运算的结果都是作为参数返回，因此，没有必要使用额外的对象存储信息。ArithmeticExpression有两个直接子类NumExpression和OperatorExpression，其中 NumExpression用于对数字进行解释。
代码很简单，逻辑也很明确，就不多说了。OperatorExpression依然是一个抽象类，其声明两
个ArithmeticExpression类型的成员变量存储运算符号两边的数字解释器，这两个成员变量会在构 造方法中被赋值。
OperatorExpression也有一个直接子类AdditionExpression，顾名思义其表示对加法运算进行解释，其逻辑都很简单，就不做过多说明了。
上面就是本例中所要使用到的所有解释器。除此之外，我们创建一个Calculator类来处理一些相关的业务。
这里要注意的是，为了简化问题我们约定表达式字符串的每个元素之间必须使用空格间隔开，如“1 + 22 + 333 + 4444”这样的表达式字符串则是合法的，而“1+22+333+4444”则不合法，因此，我们才能在Calculator的构造方法中通过空格来拆分字符串。Calculator类的逻辑很好理解，这里还是以“1 + 22 + 333 + 4444”这个字符串为例，首先将其拆分为有7个元素组成的字符串数组，然后循环遍历，首先遍历到的元素为1，那么将其作为参数构造一个NumExpression对象压入栈，其次是加号运算符，此时我们则将刚才压入栈的由元素1作为参数构造的NumExpression对象抛出作为加号运算符左边的数字解释器，而右边的数字解释器呢？我们只需要将当前数组下标+1获取到数组元素中加号右边的数字22，将其作为参数构造一个NumExpression对象即可，最后通过左右两个数字解释器作为参数构造一个AdditionExpression加法解释器对象压入栈即可，这个过程其实就是在构建语法树，只不过我们将其单独封装在了一个类里而不是在Client客户类里进行，最后，我们公布一个calculate方法执行解释并返回结果。后面的Client客户类就很简单了，构造一个Calculator对象，调用calculate方法输出结果即可。
上面我们只是简单地对加法运算定义了解释器，如果现在又想引入减法运算怎么办呢？很简单，定义一个减法解释器即可。
同样地，SubtractionExpression也继承于OperatorExpression，表示对运算符号的解释器，其实现逻辑也很简单不再多说。然后我们还需修改一下Calculator类中构建语法树的逻辑，添加一条对“-”号的分支判断处理即可。
这样，我们则可以处理我们的减法运算了。
具体的输出结果就不多说了，大家可自行尝试，这里我们可以看到解释器模式的一个优点，就是灵活性强，上面的例子中我们只实现了对加减法的解释计算，如果想实现更多的运算法则，如乘除取余等，只需创建对应的运算解释器即可，但是混合运算要比简单的加减法运算复杂得多，还要考虑不同符号的运算优先级，这也是文章开头我们说，在“简单的语言”中适用解释器模式。
从上面的两个例子中可以看到，具体的文法规则与解释器之间其实是有对应关系的，大多数情况下两者之间是一一对应的关系，即一条文法对应一个解释器，当然，我们也可以为一条文法创建多个不同的解释器，但是反过来就不行。这个很好理解，如上例中对于加法解释器我们实现的是对加法运算的解释，其对应一个解释器AdditionExpression，当然也可以再为其创建一个解释器XXXXXXExpression，但是一个解释器却不能即解释加法运算又解释减法运算， 否则就违背了解释器模式的定义。说到解释器模式的定义，我们提到过抽象语法树，而我们在上面两个例子中都有构建抽象语法树的相关逻辑，第一个例子中我们在客户类里构建由17个数字和一个数字或字母构成的语法树；而第二个例子则根据具体表达式动态构建相应的语法树。从这点可以看出解释器模式并不包含对抽象语法树的构建，其构建逻辑应由客户根据具体的情况去生成。
将一条具体的文法通过一个解释器解释，把复杂的文法规则分离为简单的功能进行解释，最后将其组合成一棵抽象语法树解释执行。至此，我们可以看到解释器模式的原理与本质：将复杂的问题简单化、模块化，分离实现、解释执行。
10.6 Android源码中的解释器模式实现
但是，我们依然可以在一些地方看到对解释器模式原理的应用。相信大家自从第一天学习Android起就知道AndroidManifest.xml这个应用配置文件，如果说我们的应用是一本书的话，这个配置文件就相当于书的目录，其中包含大量应用配置的声明定义，那么在Android中是如何读取这个配置文件的呢？这里就不得不说到PackageParser这个类，该类对AndroidManifest.xml中每一个组件标签创建了相应的类用以存储相应的信息。
如上代码所示，PackageParser为Activity、Service、Provider、Pemiission等构件在其内部以内部类的方式创建了对应的类，按照解释器模式的定义，这些类其实都对应AndroidManifest.xml文件中的一个标签，也就是一条文法，其在对该配置文件解析时充分运用了解释器模式分离实现、解释执行的特性。
在Andorid中，解析某个apk文件会调用到PackageManagerService (以下简称PMS)中的scanPackageLI方法，该方法有两种实现。
两者唯一的区别是签名列表中第一个参数，第一种实现为File类型的对象，而第二种实现为PackageParser.Package类型的对象。在具体解析某个文件时会先调用第一种实现解析apk文件，再调用第二种实现将解析后的信息保存至PMS。
这里重点分析PackageParser类，该类如上所说，承担着具体的解析重任，上述代码中首先调用了其parsePackage方法，该方法也有两种实现。
第一种实现就是上面代码中调用到的方法，其主要逻辑就是为第二种实现准备参数后调用第二个方法。
而parsePackage方法的第二种实现逻辑则要复杂得多，在其内部主要对整个AndroidManifest.xml配置文件进行具体的解析。
可以看到，parsePackage方法的主要作用其实就是对AndroidManifest.xml配置文件中manifest下的每个子节点进行解析，这里主要来看看parseApplication方法是如何对application节点进行解析的。
从程序中可以看到，parseApplication除了对application节点内的属性进行解析外，其主要逻辑 还是通过遍历解析其子节点，然后继续分别调用不同的解析方法对其进行解析，这里以parseActivity为例，parseActivity的具体逻辑执行如下。
这里要注意的是，parseActivity方法不仅承担着对Activity的解析，其同样承担着对Broadcast的解析。与parseApplication方法类似，parseActivity内部逻辑也是遍历其子标签，并调用相应的方法对其进行解析，如上述代码中的parseIntent和parseMetaData，其逻辑也很好理解，这里就不再多说了。
10.7 关于PackageManagerService
上面我们在分析PackageParser的时候提到PackageManagerService(以下简称PMS)，顾名思义其作用就是对我们的apk安装包进行管理的服务，其类定义在frameworks\base\services\java\com\ android\server\pm\PackageManagerService.java中，该类在Android API 19中有一万多行代码，虽然代码很多，但是，大部分逻辑都是在处理类似我们上面所说的文件解析和数据结构操作，作为 Android在Java层的服务之一，其与所有其他的服务一样都是由SystemServer所启动。
从程序中可以看到，在SystemServer的main方法中构造了一个ServerThread对象，然后调用其initAndLoop方法，initAndLoop方法逻辑相当多，其主要目的很简单，就是初始化各种系统服务，并启动消息循环开始接收处理消息。在initAndLoop方法中，通过PackageManagerService的静态main方法得到一个IPackageManager对象。
ServiceManager是Binder进程间通信机制的守护进程，其目的很简单，就是管理Android系统里的Binder对象。这里我们重点来看PackageManagerService的构造过程。
整个PackageManagerService的构造过程很长，但是，逻辑并不复杂，条理也很清晰，关于 PackageManagerService中的一些具体方法，大家可以自行查阅相关资料，这里不再赘述。总体来
说，PackageManagerService的作用就如它名字所描述的那样，主要用来管理应用程序包，其与其 他系统服务的通信也比较单一，并不复杂，因此，相对于Android中的一些核心服务来说还算是比较好理解的。
10.8 小结
优点
解释器模式的优点我们在本文的两个例子中已有所提及，最大的优点是其灵活的扩展性，当我们想对文法规则进行扩展延伸时，只需要增加相应的非终结符解释器，并在构建抽象语法树时，使用到新增的解释器对象进行具体的解释即可，非常方便。
缺点
解释器模式的缺点也显而易见，因为对于每一条文法都可以对应至少一个解释器，其会生成大量的类，导致后期维护困难；同时，对于过于复杂的文法，构建其抽象语法树会显得异常烦琐，甚至有可能会出现需要构建多棵抽象语法树的情况，因此，对于复杂的文法并不推荐使用解释器模式。