公司网站制作需要找广告公司么,ps做网站设计稿,手机版oa系统,wordpress 知识 管理微软推出的第一个版本的.NET Framework是一个面向Windows桌面和服务器的基础框架#xff0c;在此之后#xff0c;为此微软根据设备自身的需求对.NET Framework进行裁剪#xff0c;不断推出了针对具体设备类型的.NET Framework版本以实现针对移动、平板和嵌入式设备提供支持。… 微软推出的第一个版本的.NET Framework是一个面向Windows桌面和服务器的基础框架在此之后为此微软根据设备自身的需求对.NET Framework进行裁剪不断推出了针对具体设备类型的.NET Framework版本以实现针对移动、平板和嵌入式设备提供支持。除此之外在Windows平台之外一致游荡着一只特立独行的猴子Mono。.NET平台看起来欣欣向荣而实际上却日薄西山就在这个时候微软走了一条唯一正确的道路那就是基于跨平台理念重新设计的.NET Core以及由此驱动地对整个.NET平台进行全新布局。 对于计算机从业人员来说“平台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由如下图所示的两个层析构成它们分别是提供运行环境的CLRCommon Language Runtime和提供API的FCLFramework Class Library。 CLR之于.NET等同于JVM之于Java它是.NET虚拟机。作为一个运行时RuntimeCLR为程序的执行提供一个托管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.1CLR 2.0被.NET Framework 2.0和3.x共享.NET Framework 4.x下的运行时均为CLR 4.0。 FCL是一个旨在为开发人员提供API的类库由它提供的API又可以划分为如上图所示的两个层次。处于最底层的部分被称为BCLBasic 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版本和IDEVS.NET 2002随之问世。在之后的10多年中一系列版本的.NET Framework被先后推出。微软目前发布的最新.NET Framework版本为4.7下图为你展示了整个.NET Framework不断升级的演进过程以及各个版本提供的主要特性。 上图2-3勾勒出.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的绝大部分核心代码都定义在mscorelib.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的规定用来描述可执行代码的是一种叫做CILCommon Intermediate Language的语言这是一种介于高级语言和机器语言之间的中间语言。如下图所示虽然程序源文件由不同的编程语言编写但是我们可以借助相应的编译器将其编译成CIL代码。原则上讲我们可以设计出新的编程语言并将其加入到.NET大家庭中只需配以相应的编译器生成统一的CIL代码即可。我们也可以为现有的某个编程语言设计一种以CIL为目标语言的编译器使之成为.NET语言。CIL是一门中间语言同时也是一门面向对象的语言所以对于一个CIL程序来说类型是基本的组成单元和核心要素。微软制定了一个名为CTSCommon Type System的规范为CLI确立了一个统一的类型系统。 编程语言的差异通过编译器这个适配器得以“同一化”运行环境的差异则可以通过虚拟机VMVirtual Machine技术来解决。虚拟机是CIL的执行容器它能够在执行CIL代码的过程中采用及时编译的方式将它动态地翻译成与当前执行环境完全匹配的机器指令。虚拟机屏蔽了不同操作系统之间的差异让目标程序可以不做任何修改的情况下就能运行于不同的底层执行环境中而CIL实际上是一种虚拟机语言。 从实现原理来看让.NET能够跨平台其实不难但是让各种相关的人员参与进行以构建一个健康而完善的跨平台.NET生态圈则注定不是一件一蹴而就的事情这里涉及的利益相关方包括编程语言的设计者以及设计和开发编译器、虚拟机、IDE以及其他相关工具的人当然还包括广大的应用开发者。跨平台.NET生态环境必须建立在一个标准的规范之上所以微软为此制定了CLI然后提交给欧洲计算机制造商协会ECMAEuropean Computer Manufacturers Association并被后者接受成为了一个编号为335的规范所以CLI又被称为ECMA-335顺便说一下ECMA还接受了微软为C#这们编程语言制定的规范即ECMA-334。 Mono与Xamarin CLIECMA-335这一开放的规范在.NET诞生的那一刻起就赋予了它跨平台的基因但是被烙上Windows这一印记的微软似乎根本就不曾想过将.NET推广到其他的平台真正完成这一使命了是一个叫做Mono的项目。虽然Mono已经是一个不算年轻的项目了但是依然有很多人对它不是很了解所以我们不妨来简单介绍一下它的历史。 1999年Miguel de Icaza创建了一家叫做Ximian的公司这是一家旨在为GNOME项目这是一个为类Unix系统提供桌面环境的GNU项目GNOME是目前Linux最常用的桌面环境之一开发软件和提供支持的公司。2000年6月微软正式发布.NET FrameworkMiguel 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 Microsofts .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外的所有特性目前缺失的部分的开发正在通过一个叫做OliveMono的一个子项目的项目进行着。 在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 StudioMonoDevelop的升级版的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跨平台的奥秘[中篇]复用之殇》。 原文地址http://www.cnblogs.com/artech/p/how-to-cross-platform-01.html.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com
