.NET Core跨平台的奥秘[上篇]：历史的枷锁-.net-火龙果软件

.NET Core跨平台的奥秘[上篇]：历史的枷锁

来源：www.cnblogs.com 发布于： 2017-11-20

3542 次浏览

微软推出的第一个版本的.NET Framework是一个面向Windows桌面和服务器的基础框架，在此之后，为此微软根据设备自身的需求对.NET Framework进行裁剪，不断推出了针对具体设备类型的.NET Framework版本以实现针对移动、平板和嵌入式设备提供支持。除此之外，在Windows平台之外一致游荡着一只特立独行的猴子（Mono）。.NET平台看起来欣欣向荣，而实际上却日薄西山，就在这个时候微软走了一条唯一正确的道路，那就是基于跨平台理念重新设计的.NET Core，以及由此驱动地对整个.NET平台进行全新布局。

.NET Core跨平台的奥秘[上篇]：历史的枷锁

.NET Core跨平台的奥秘[中篇]：复用之殇

.NET Core跨平台的奥秘[下篇]：全新的布局

对于计算机从业人员来说，“平台（Platform）”是一个我们司空见惯的词语，在不同的语境中它具有不同的语义，比如它可以指代操作系统环境和CPU架构类型，也可以表示硬件设备类型。经过多年的苦心经营，微软已经为在Windows平台下构建了一个完整的支持多种设备的.NET生态系统。与此同时，通过借助于Mono和Xamarin，.NET已经可以被成功移植到包括Mac OS X、Linux、iOS、Android和FreeBSD等非Windows平台。

一、Windows下的.NET

微软在2002年推出了第一个版本的 .NET Framework，这是一个主要面向Windows 桌面（Windows Forms）和服务器（ASP.NET Web Forms）的基础框架。在此之后，PC的霸主地位不断受到其他设备的挑战甚至取代，为此微软根据设备自身的需求对.NET Framework作了相应的简化和改变，不断推出了针对具体设备类型的.NET Framework，主流的包括Windows Phone、Windows Store、Silverlight和.NET Micro Framework等，它们分别对移动、平板和嵌入式设备提供支持。由于这些不同的.NET Framework分支是完全独立的，这使我们很难开发一个支持多种设备的“可移植（Portable）”应用。

.NET Framework的层次结构

针对不同设备.NET Framework的独立性导致了在很多情况下我们不得不针对具体的设备平台进行编程，跨设备平台代码的重用显得异常困难。为了让读者朋友们对这个问题具有深刻地理解，我们从.NET Framework的结构开始讲起。从结构组成的角度来讲，.NET Framework由如下图所示的两个层析构成，它们分别是提供运行环境的CLR（Common Language Runtime）和提供API的FCL（Framework Class Library）。

CLR之于.NET等同于JVM之于Java，它是.NET虚拟机。作为一个运行时（Runtime），CLR为程序的执行提供一个托管（Managed）的执行环境，它是.NET Framework的执行引擎，为托管程序的执行提供内存分配、垃圾回收、安全控制、异常处理和多线程管理等方面的服务。CLR是.NET Framework的子集，但是两者却具有不同的版本策略。到目前为止，微软仅仅发布了4个版本的CLR，它们分别是1.0、1.1、2.0和4.0，.NET Framework 1.0和1.1分别采用CLR 1.0和1.1，CLR 2.0被.NET Framework 2.0和3.x共享，.NET Framework 4.x下的运行时均为CLR 4.0。

FCL是一个旨在为开发人员提供API的类库，由它提供的API又可以划分为如上图所示的两个层次。处于最底层的部分被称为BCL（Basic Class Library），它提供了一系列基础类型，它们用于描述一些基本的数据类型和数据结构（比如字符串、数字、日期/时间和集合等）和提供一些基础性的操作（比如IO、诊断、反射、文本编码、安全控制、多线程管理等）。在BCL之上的则是面向具体应用类型的API，我们大体上可以将它们划分为入下三种类型：

面向应用（比如ASP.NET、WPF和Windows Forms等）

面向服务（比如WCF、WF和Data Services等）

面向数据（比如ADO.NET、Entity Framework和LinQ to SQL等）

我们也可以采用另一种方式对FCL进行重新划分：将面向某种应用或者服务类型（比如Windows Forms、WPF、ASP.NET和WCF等）的部分成为AppModel，那么整个.NET Framework则具有了如下图所示的三层结构。

大而全的BCL

我们知道微软的.NET战略是在千禧年提出来的，两年之后第一个.NET Framework版本和IDE（VS.NET 2002）随之问世。在之后的10多年中，一系列版本的.NET Framework被先后推出。微软目前发布的最新.NET Framework版本为4.7，下图为你展示了整个.NET Framework不断升级的演进过程，以及各个版本提供的主要特性。

上图勾勒出.NET Framework这些年的发展历程旨在说明一个问题：作为整个.NET平台的基础框架，.NET Framework在不断升级过程中是自己变得更加强大和完备，但是在另一方面也是自己变得越来越臃肿。随着版本的不断升级，构成.NET Framework的应用模型、BCL和运行时（CLR）都在不断地膨胀（.NET Framework 2.0/3.x和.NET Framework 4.x分别采用CLR 2.0和CLR 4.0），下图很直观地说明了这个问题。

我们知道程序集是.NET最基本的部署单元，不论定义其中的多少类型被使用，CLR总是将整个程序集加载到内存中。对于上面介绍的构成.NET Framework的三个层次来说，应用模型是针对具体应用/服务类型的，相应的API通过独立的程序集来承载（比如ASP.NET的核心框架定义在程序集System.Web.dll中，承载整个Windows Forms框架的程序集则是System.Windows.Forms.dll），所以.NET Framework的各个应用模型是相互独立的。在开发某种类型的应用时，我们只需要引用应用模型对应的程序集就可以了，也就是说我们开发一个Windows Forms应用，是不需要去引用System.Web.dll程序集的。

但是BCL的绝大部分核心代码都定义在mscorlib.dll这个核心程序集中，所以BCL基本上来说是作为一个不可分割的整体存在于.NET Framework之中。.NET Framework需要对运行在本机各种类型的托管程序提供支持，针对所有应用类型的基础类型均需要定义在BCL中。在很多情况下，我们的应用可能仅仅需要使用到BCL一个很小的子集，但是我们不得不将定义整个程序集都加载到内存之中。

一方面BCL总是作为一个不可分割的整体被加载，另一方面其自身的尺寸也在随着.NET Framework的升级而不断地膨胀。对于客户端应用（比如Windows Forms/WPF应用）来说，这应该不算是一个大不了的问题，但是对于移动和服务端应用（包括部署于云端应用）来说，由此带来的对性能和吞吐量的响应就成了一个不得不考虑的问题。

理想的BCL消费方式是“按需消费”，我们需要那个部分就加载那个部分。由于作为独立部署单元的程序集总是作为一个整体被CLR加载到内存中，要完全实现这种理想的BCL消费方式，唯一的办法就是将其划分为若干小的单元，并分别定义到独立的程序集中。除此之外，按照模块化的原则对整个BCL进行拆分也是版本升级变得更加容易，如果现有版本具有需要修复的Bug，或者性能需要改进，那么只需要改动并升级相应的模块就可以了。下图展示了具有模块化BCL的.NET Framework层级结构。

多个设备平台独自为政

经过多年的经营，微软已经为我们构建了一个完整的支持多种设备的.NET生态系统，从最初单纯的桌面平台，逐渐扩展到移动、平板和嵌入式等平台。设备运行环境的差异性导致了针对它们的应用不能构建在一个统一的.NET Framework平台上，所以微软采用独立的.NET Framework平台来对它们提供针对性的支持。就目前来说，除了支持Windows 桌面和服务器设备的“完整版 .NET Framework”之外，微软还先后推出了一系列“压缩版.NET Framework”，这其中就包括Windows Phone、Windows Store、Silverlight和.NET Micro Framework等，它们分别对移动、平板和嵌入式设备提供支持。

这些.NET Framework并不是仅仅在AppModel层次提供针对相应设备平台的开发框架，它们提供的BCL和Runtime也是不同。换句话说，这些.NET Framework平台是完全独立的，不同.NET Framework平台之间的独立性很直观地体现在下图之中。目标平台的独立性导致我们很难编写能够在各个平台复用的代码，关于这一点我们会在下面一节“复用之伤”中做重点讨论。

二、非Windows下的.NET

尽管微软自身多年以来基本上都只在Windows平台下的一亩三分地上进行耕耘，但是.NET 则通过Mono和Xamarin将触角延伸到其他平台（Mac OS X、Linux、iOS和Android等）。虽然目前做得并不算完美，但是我们可以说.NET具备跨平台的能力。

从CLI谈起

.NET跨平台的能力建立在一种开放的标准或者规范之上，这个所谓的标准/规范就是CLI。CLI的制定旨在解决这样一个问题：由不同（高级）编程语言开发的.NET应用能够在无需任何更改的情况下运行于不同的系统环境下。要实现这个目标，必需有效地解决这里涉及到两种类型的差异，即编程语言的差异和运行时环境的差异。编程语言之间能够实现相互兼容、运行时环境能够得到统一，跨平台的伟业方能实现。

CLI全称为Common Language Infrastructure，其中Common Language说的是语言，具体来说是一种通用语言，它旨在解决各种高级开发语言的兼容性问题。Infrastructure指的则是运行时环境，旨在弥合不同平台之间执行方式的差异。Common Language是对承载应用的二进制内容的静态描述，Infrastructure则表示动态执行应用的引擎，所以CLI为可执行代码和执行引擎确立一个统一的标准。

编程语言有编译型和解释型之别，前者需要通过编译器进行编译以生成可执行代码，CLI涉及的Common Language指的是编译型语言。要实现真正的跨平台，最终需要解决的是可执行代码在不同平台之间的兼容和可移植的问题，而编程语言的选择仅仅决定了应用源文件的原始状态，应用的兼容性和可移植性由编译后的结果来决定。如果通过不同编程语言开发的应用通过相应的编译器编译后能够生成标准的目标代码，那么编程语言之间的差异就不再是一个问题了。

按照CLI的规定，用来描述可执行代码的是一种叫做CIL（Common Intermediate Language）的语言，这是一种介于高级语言和机器语言之间的中间语言。如下图所示，虽然程序源文件由不同的编程语言编写，但是我们可以借助相应的编译器将其编译成CIL代码。原则上讲，我们可以设计出新的编程语言并将其加入到.NET大家庭中，只需配以相应的编译器生成统一的CIL代码即可。我们也可以为现有的某个编程语言设计一种以CIL为目标语言的编译器使之成为.NET语言。CIL是一门中间语言，同时也是一门面向对象的语言，所以对于一个CIL程序来说，类型是基本的组成单元和核心要素。微软制定了一个名为CTS（Common Type System）的规范为CLI确立了一个统一的类型系统。

编程语言的差异通过编译器这个适配器得以“同一化”，运行环境的差异则可以通过虚拟机（VM：Virtual Machine）技术来解决。虚拟机是CIL的执行容器，它能够在执行CIL代码的过程中采用及时编译的方式将它动态地翻译成与当前执行环境完全匹配的机器指令。虚拟机屏蔽了不同操作系统之间的差异，让目标程序可以不做任何修改的情况下就能运行于不同的底层执行环境中，而CIL实际上是一种虚拟机语言。

从实现原理来看，让.NET能够跨平台其实不难，但是让各种相关的人员参与进行以构建一个健康而完善的跨平台.NET生态圈则注定不是一件一蹴而就的事情，这里涉及的利益相关方包括编程语言的设计者，以及设计和开发编译器、虚拟机、IDE以及其他相关工具的人，当然还包括广大的应用开发者。跨平台.NET生态环境必须建立在一个标准的规范之上，所以微软为此制定了CLI，然后提交给欧洲计算机制造商协会（ECMA：European Computer Manufacturers Association）并被后者接受，成为了一个编号为335的规范，所以CLI又被称为ECMA-335（顺便说一下，ECMA还接受了微软为C#这们编程语言制定的规范，即ECMA-334）。

Mono与Xamarin

CLI（ECMA-335）这一开放的规范在.NET诞生的那一刻起就赋予了它跨平台的基因，但是被烙上Windows这一印记的微软似乎根本就不曾想过将.NET推广到其他的平台，真正完成这一使命了是一个叫做Mono的项目。虽然Mono已经是一个不算年轻的项目了，但是依然有很多人对它不是很了解，所以我们不妨来简单介绍一下它的历史。

1999年，Miguel de Icaza创建了一家叫做Ximian的公司，这是一家旨在为GNOME项目（这是一个为类Unix系统提供桌面环境的GNU项目，GNOME是目前Linux最常用的桌面环境之一）开发软件和提供支持的公司。2000年6月，微软正式发布.NET Framework，Miguel de Icaza被个“基于互联网的全新开发平台”（.NET在发布的时候被标榜为“a new platform based on Internet standards”）深深吸引。同年11月，微软发布了CLI规范（ECMA-335）并为公众开放了独立实现的许可，Miguel de Icaza从中看到了商机，因为这实际上为.NET走向非Windows平台提供了可能。Miguel de Icaza在2001年7月开启了Mono这个项目，并采用C#作为主要的开发语言（目前支持VB .NET），所以针对CLI和C#的两个ECMA规范是构建Mono项目的理论基础，如果访问Mono的官方网站，我们会发现它是这样定义Mono的：“Mono is an open source implementation of Microsoft's .NET Framework based on the ECMA standards for C# and the Common Language Runtime.”

Mono的使命不仅仅局限于能够将.NET应用正常运行在其他非Windows平台，它还希望帮助开发人员能够直接在其他平台进行. NET应用的开发，所以Mono不仅仅根据CLI为相应的平台开发了作为虚拟机的CLR和编译器，还提供给了IDE和相应的开发工具（被称为MonoDevelop）。Mono的第一个正式版本（Mono 1.0）在项目开启差不多三年之后（2004年6月）发布。

2003年8月，Ximian被另一家叫做Novell的公司收购，后者继续支持Miguel de Icaza开发Mono项目，在这期间Mono陆续推出了若干Mono 2.x版本。2011年4月，Novell又被另一件叫做Attachmate的公司收购，后者决定放弃Mono，于是Miguel de Icaza带着整个Mono团队成立了一个家新的公司，起名为Xamarin。同年7月，Xamarin向原来的母公司Novell拿到了Mono的开发许可。在此之后的几年内，Xamarin先后发布了Mono 3.x、Mono 4.0和Mono 5.x，目前的最新版本为5.4。Mono现今的目标是实现.NET 4.5除WPF、WF和部分WCF外的所有特性，目前缺失的部分的开发正在通过一个叫做Olive（Mono的一个子项目）的项目进行着。

在Mono项目的基础之上，Xamarin开始开发以新公司命名的产品，其中最重要版本当属2013年2月发布的Xamarin 2.0。Xamarin 2.0由Xamarin.Android、Xamarin.iOS和Xamarin.Windows组成，它们使我们可以采用C#开发针对Android、iOS和Windows的Native应用。除此之外，Xamarin 2.0还携带着一个叫做Xamarin Studio（MonoDevelop的升级版）的IDE以及与一些与Visual Studio集成的工具。2014年5月Xamarin 3.0发布，作为其核心的Xamarin.Forms为不同平台的Native应用提供统一的控件，也就是说我们利用Xamarin.Forms API开发Native应用可以在无需做任何改变的情况下运行在Android、iOS和Windows上。

2016年2月，微软和Xamarin宣布双方签署协议达成了前者针对后者的收购。在2016年Build大会上，微软宣布将整个Xamarin SDK开源，并将它作为一个免费的工具集成到Visual Studio中，Visual Studio企业版的用户还可以免费使用Xamarin企业版的所有特性。

综上所述，由于.NET是建立在CLI这一标准的规范之上，所以它天生就具有了“跨平台”的基因。在微软发布了第一个针对桌面和服务器平台的.NET Framework之后，它开始 “乐此不疲” 地对这个完整版的.NET Framework进行不同范围和层次的 “阉割” ，进而造就了像Windows Phone、Windows Store、Silverlight和.NET Micro Framework的压缩版的.NET Framework。从这个意义上讲，Mono和它们并没有本质的区别，唯一不同的是Mono真正突破了Windows平台的藩篱。包括Mono在内的这些分支促成了.NET的繁荣，但我们都知道这仅仅是一种虚假的繁荣而已。虽然都是.NET Framework的子集，但是由于它们采用完全独立的运行时和基础类库，这使我们很难开发一个支持多种设备的“可移植（Portable）”应用，这些分支反而成为制约.NET发展的一道道枷锁。至于为什么“可移植（Portable）”.NET应用的开发如此繁琐，敬请关注中篇《.NET Core跨平台的奥秘[中篇]：复用之殇》。

3542 次浏览