查看: 145|回复: 0

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

[复制链接]

该用户从未签到

发表于 2019-11-4 16:57:38 | 显示全部楼层 |阅读模式
微软推出的第一个版本的.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跨平台的奥秘[中篇]:复用之殇》。

相关技术服务需求,请联系管理员和客服QQ:2753533861或QQ:619920289
您需要登录后才可以回帖 登录 | 用户注册

本版积分规则

帖子推荐:
客服咨询

QQ:2753533861

服务时间 9:00-22:00

快速回复 返回顶部 返回列表