编译器和解释器的区别

编译这个概念很简单，就是从一种语言翻译到另一种语言，当然这里的语言指的都是计算机上的语言，最常见的是高级语言到机器语言，gcc，msvc都属于这，出来就是一个可以跑的程序了。第二种就是高级语言到中间语言，Java用的是javac，产物叫 Java 字节码，C# 用的是 csc。产物是 MSIL。中间语言就是介于高级语言跟机器语言之间的一种语言。最不常见的是第三种，就是一种高级语言到另一种高级语言，这里用的例子是TypeScript 的编译器 tsc，它的产物是 JavaScript，也有人把这种叫 transpiler（翻译器？）当然它产出的 JS 代码人类比较难看懂，所以你把它的产物认为是“机器码”，好像也没有什么问题。

 几种编译器

可能还有更多种类的编译器我这儿没有列出来，不过编译器的工作流程是大体类似的。简化的流程就是：给一个输入，一般是代码文件，这个输入经过编译器之后产生一个输出，叫做产物

简化的编译器工作流程

当然实际的情况要复杂一些。我们拿GCC编译C代码做例子，它的输入是C源码，经过GCC编译之后，产出的是可执行文件，也就是“程序”。学过编程的应该能理解，程序运行一般还需要提供数据，这俩加一起就可以运行了。大部分程序的运行是需要操作系统支撑的，因此这里其实还有很多操作系统有关的知识。这里写了几个像ELF，Loader 还有 Relocation，其实还有很多就不展开讲了。

C语言编译和运行流程

 
我想说的重点是可执行文件，它一般是无法跨平台和架构的。就你一个C代码想跑在不同的系统和架构上，需要编译很多遍，就会形成这样一张表：

 面向多平台/架构的编译

如果你想支持这三个系统，两种架构，就要编译6遍。看着就很烦是吧，但是没办法，只要是编译到native，都是这个样子的。

所以总结一下编译器的特点（这里主要说编译到native情况）：

一、代码被编译之后才能产生可执行文件

二、编译只需要进行一次，可执行文件可以多次运行

三、代码本身可以是跨平台/架构，但是可执行文件是平台/架构相关的

编译器到这儿就说差不多了，下面说一下解释器Interpreter。解释器是直接解释代码并且执行，它的特点一是不需要中间产物，二是一般是一句一句执行的。所以解释器的工作流程是这样的：输入还是代码，然后代码和数据一起交给解释器，解释器直接就可以执行了。解释器的简化工作流程

以Python语言为例子，它的流程就是把Python源码和数据，交给Python解释器，然后解释器直接就运行了。大家注意跟C语言的区别，C语言是最终可执行文件跟操作系统交互，但是Python里面是解释器跟操作系统交互的，也就是说解释器把操作系统给隔离开了，把对操作系统的依赖挪到了解释器这一层。

Python程序的简化运行流程

 
解释器的特点就很好说了：

一、代码就是“可执行文件”（这里是加引号的，真正的可执行文件其实是解释器本身）

二、无需编译，直接运行

三、代码跨平台/架构，解释器本身不跨平台/架构

说完了这俩我想讲一个更有意思的东西，就是编译器往往比解释器要更“聪明”。为什么这么说呢？前面我们提到编译器是把整个代码编译形成二进制，而解释器是一句一句执行的。编译器对代码拥有更加充分的掌控能力，因此可以对代码进行更高级的编译优化。这里列出了几个大的优化技术方向：

一些编译优化技术

这些技术的原理跟实现都很复杂，因为我也不是专业做编译技术的，我在这儿就给大家举一个简单的例子。我用一个简单的C代码，给大家讲一下数据流分析技术里面的一种，叫“无用代码消除”。大家注意真正的编译器在进行优化的时候，并不一定从代码级别进行，也可能是从字节码和IR这种级别进行的，这里只是用C代码做例子方便讲解。

一个简单的C代码例子

 
这里总共三行代码，我们很容易可以看到，第二行这个b其实是没有用的。“无用代码消除”就可以将这种没有用的代码直接删除掉，不会进入最终的可执行文件，类似这样的编译优化技术还有很多。感兴趣的大家可以搜一下有关资料。

解释器的话就会比较“乖”，一句一句来。让干啥就干啥，当然代价就是无法使用很多优化技术，导致运行会相对“慢”一点。这里的“慢”也是打引号的。事实上解释器当中往往也存在编译过程，因此也能够使用编译优化技术，同时借助于JIT等技术，解释器也是可以做到很高的运行效率的，这篇文章就不细谈了。

那解释器的优势是什么呢？前面也提到了，有一点就是它很“便捷”，给我一段代码我直接就可以跑，部署起来非常简单，因此被广泛应用于各种脚本语言，例如 Python, Ruby 等。