.NET软件运行架构 之 打破编译器的界限

之前在学校的时候，接触到的编程语言都是解释型（如basic）或者编译型（如C）。

其有严格的compile-time与run-time的界限，

基于该语言开发的程序员都不用关心底层的具体编译相关实现，最多也就调整一下编译设置，如linux下gcc的makefile等。

由于近些年的所谓“平台”越来越多，所以语言越来越强调跨平台性。

于是我们可以看到来自sun公司一个伟大的发明——JAVA。

其打破了平台绑定编译器的界限，“write once,run everywhere”。

具体实现是，其“编译”期生成的是一个统一的中间代码，然后在各个平台通过移植一套 JAVA虚拟机，屏蔽底层相关接口。在运行的时候，动态去解释该中间代码。

然后微软仿照其思想推出了.NET框架并在WINDOWS应用平台“封杀”了JAVA（将J#移出vs等），并推出了自诩更为强大的C#。（我承认C#确实很强大，微软也真的是完全具有技术实力，只是其过分的进行平台垄断所为业界不齿所以许多人说其反话，OK，这里我们不对该问题深入讨论）

.NET运行框架也类似JAVA，基于.NET的开发语言 编译生成一套称为LI的中间代码，其具有很多特性（如该代码是面向对象的等）

然后该套代码在具体某平台的运行的时候，进行部分编译，这一步的好处是可以动态针对不同平台进行优化。如之前由程序员开发的语言最多通过编译宏或者一些其他方式针对固定平台或者固定几种平台进行优化。而.NET将这一部分针对平台的优化做到了LI向下运行时期。

那么在用户的感觉可能就是 某个程序第一次运行时、或者启动时很慢，运行的时候还是很快的。（和JAVA基于中间语言“解释器”的方式不同，JAVA是运行时候也很慢。。貌似现在有新的机制可以提升JAVA的运行速度，这里也不进行具体讨论。）

.NET还有一个很复杂的功能是其运行时动态编译——它只编译当前运行的一部分LI。这可以节省很多运行其机器的资源，也很符合逻辑。

总之我个人觉得.NET这套运行机制是比较复杂的，这其中开发过程投入果然是让微软耗费了几年研发时间整起来的庞大工程。

那么我们整理一下程序运行架构的转移方向：

解释型 -> 编译型 -> 中间代码解释型 -> 中间代码编译型

今后可能会怎么发展呢？

我觉得在个人用户电脑发展越来越强大的趋势下，硬件性能已经不是客户端的大问题，所以我觉得今后可能在终端使用的多是 灵活、强大 的脚本解释型为主语言。

而在前端对性能要求高、需硬件操作能力强大，则使用编译型为主的语言。