跨平台.NET开发了解编程语言规范

作者:小菜 更新时间:2025-03-16 点击数:
简介:在许多年前,“语言”就等同于“平台”,例如C,C++以及最早的Ruby和Python等等。

但是随着技术发展,出现了一些通用的平台,例如.NET和Java,逐渐这

【菜科解读】

在许多年前,“语言”就等同于“平台”,例如C,C++以及最早的Ruby和Python等等。

但是随着技术发展,出现了一些通用的平台,例如.NET和Java,逐渐这些平台上的语言也越来越多。

再后来,某些语言在不同平台上的实现也越来越多,事情也变得有些复杂。

技术在发展,但是从目前社区的讨论中,我发现许多朋友的观念还没有跟上。

简单地说,如今的观念,一定要从“语言即平台”切换成“语言及平台”,当分清“语言”和“平台”这两个不同事物之后,许多问题才能讨论地清楚。

例如我写过一个太监系列《Why Java Sucks and C# Rocks》,其中谈的是C#和Java两个“语言”而不是两者的“平台”。

编程“语言”其实是一种“规范”,它涉及了程序员在使用这门语言时的文本表现形式(这里暂不考虑其他形式的语言),而“平台”则包括对这个规范的“实现”(广义的“平台”还包括整个生态环境等等)。

C#和Java分别处在各自的平台上,但许多语言其实是跨多种平台的。

例如Python,Ruby,Scala,Clojure,JavaScript等等,数不胜数。

同样,一个平台上也会出现多种语言。

而且事实上,由于.NET和Java这样的平台越来越成熟,语言的设计及实现者也都越来越倾向于让语言运行在“某个平台”上。

这么做可以尽可能地利用前人的成果,而不是什么都要自己从头做起。

其实基本的原则就是这么简单,但是真正在考虑问题的时候,可能就不是那么容易了,我们必须时刻保持清晰地头脑。

例如有个人说“C#比Java执行效率高(或低)”,这个说法是否正确?其实这种说法有很大问题。

因为我们知道,在这里C#和Java都是“语言”,它们的执行环境CLI及JVM一样都是“规范”,但“执行效率”是一种表现,这和“实现”得如何有很大关系。

例如,C#是运行在.NET平台还是Mono上(它们都是CLI规范的具体实现),Java是运行在JRockit还是Hotspot(前者是Oracle的JVM商业实现,后者是Sun的开源实现——当然现在也是Oracle的),亦或是Android的Dalvik上?很显然,不同实现之间的表现会有区别,不可一概而论,否则也不会出现 JavaScript引擎的效率之争了。

同理,有些人使用Hotspot上的Java性能来说明Java在Android上运行时的表现,这也是不对的 ——要知道Google在和Oracle的Java专利官司中不断强调Dalvik不是“Oracle那种Java”。

作为结论,Java在 Android上的表现的确不错,但论证方式也必须正确才行。

当然,有时候“规范”也会影响到“实现”,例如一个动态分发的语言,其性能基本百分百不如在编译期绑定的静态语言。

所以事情原本就是这么复杂,做一个思路清晰的程序员并不是件容易的事情。

顺便一提,女人在这方面的头脑一般都比较清楚,她们一般都知道骑白马的不一定是王子,也有可能是唐僧。

对于俗称“.NET程序员”的那一批人来说,分清“语言”和“平台”更是一件十分重要的事情,因为C#语言可以说是目前“平台”、“实现”最为广泛的“语言”之一了。

之前我为InfoQ写过一篇文章,其中提到Mono的创始人Miguel de Icaza给出的目前C#语言可执行平台的“不完全”列表,几乎覆盖了各种流行的操作系统及设备等等,例如:* Windows* Mac OS* Linux / BSD / Solaris* Windows Phone,Android,iOS* XBox 360,Wii,PS3* ……因此就拿C#这一种语言来说,“实现”也会各自略有不同,这便是所谓的“配置(Profile)”。

目前至少已经有这么多配置了:* .NET 4.0配置* Silverlight配置* Windows Phone 7配置* XBox360配置* Mono核心配置:与.NET配置相同,可以在Linux,MacOS X,Solaris,Windows和BSD里使用。

* .NET Micro Framework* Mono的iOS配置* Mono的Android配置* Mono的PS3配置* Mono的Wii配置* Moonlight配置(与Silverlight兼容)* Moonlight扩展配置(Silverlight和完整的.NET 4 API)“配置”之间的区别主要体现在执行环境的能力(例如iOS不支持运行时代码生成,因此支持AOT但不能JIT)以及类库的覆盖面上(例如XNA类库只存在于 Windows Phone及XBox 360等游戏平台),不过它们终究实现了一个核心规范,因此我们可以说在不同平台上都可以“使用.NET进行开发”。

Mono实在是一个了不得的作品,它让我知道了“跨平台原来可以这么做”。

之前我也写过有关跨平台的问题,其中谈到在“客户端的跨平台一般都很难得到最佳的体验”,这个论点的最佳证明便是Java。

但Mono走的却是另一条跨平台的道路,它在各平台上实现了核心的执行引擎和类库之外,解决“体验”的方式便是在各个平台上提供原生平台的绑定。

这样无论是在Mac OS,iOS,Android上都可以得到原生应用的体验。

我很奇怪为什么有些搞.NET的人一边说.NET的适用面太小,一边却忽视 Mono的成果,在我看来这完全是“自作孽不可活”,我愈发觉得是否接受Mono是判断一个.NET程序员是否优秀的重要准则。

其实Mono实在很火,因为他为广大.NET程序员扩展了工作领域,使用现有的知识来开发iOS等平台的应用程序,还可以共享代码,何乐而不为?前不久苹果发布了Mac上的App Store,于是MonoMac也立即推出了面向AppStore的打包器,Frank Krueger也开始着手移植它的作品iCircuit,成果显著。

因此在我看来,这才是一个现代.NET程序员该有的工作台:

当然,我知道大家都是聪明人,反对的理由总是找得到的,这里先随便列上几条。

有人说,用MonoTouch等.NET实现来做iOS开发“不正式”,我说,这个说法颇有“血统论”的意味,不过既然在Windows上用C++和 Delphi都很正式,那么为什么在iOS上使用Objective-C才是正途?有人说,MonoTouch性能一定不如Objective-C好,我说,这是猜测,即使性能不如Objective-C,看看各种案例也知道这在实践中并不是问题(事实上MonoTouch的前身便是Unity3D对 Mono的使用,而iOS上实在有太多游戏在使用Unity3D了)。

还有人说,MonoTouch或MonoDroid没有大公司支持,不靠谱,我说,您之前不是经常鄙视类似“开源没有微软靠谱”或是“微软开发人员只知道微软技术”这种说法的吗?还有人说……不过,这些说法还是挡不住出现基于MonoDroid的DeltaEngine,这是个跨平台的游戏引擎,在Mono的支持下可以运行在Linux,MacOS X,iOS和Android上,在微软.NET支持下可以运行在XBox 360,Windows Phone 7自然还有普通的Windows系统上。

在CES 2011上NVidia演示了一个游戏,Soul Craft,它运行在LG Optimus 2X,这个游戏正是使用了DeltaEngine。

对于我们来说,最大的限制其实还是眼界和思维,突破这一屏障也是我组织nBazaar技术沙龙的目的之一。

本周六将会举办第三届nBazaar技术交流会,具体信息请访问http://nbazaar.org/。

如果您还没有报名,也可以直接前来,也欢迎带上感兴趣的朋友或同事。

根据以往的经验,场地就像乳沟,挤挤总是有的……

跨平台,.NET,开发,了解,编程语言,规范,在,许多,

2D客户端场景编辑器的开发工作分享

前往文本编辑器专题 最近负责一款2D客户端场景编辑器的开发工作,获益良多。

现在就操作层面跟大家分享一下开发中的几个着重点。

1 事件响应模块:编辑器的操作极其复杂,如果没有一个清晰的事件分发流程,操作逻辑处理起来苦不堪言。

主要的思路是设定编辑模式,然后在每个编辑模式下再有多个子模式。

例如建筑编辑模式,放置建筑子模式等。

每个子模式下都有独立的鼠标和键盘响应处理,如左右键 按下弹起的响应等。

这样在进行逻辑处理时,先判断当前编辑器所处的模式和子模式,即可进入对应的响应操作。

2 场景对象层次:编辑器的操作几乎都是基于对象的,设定一个层次清晰的对象结构,在进行对象操作时则顺风顺水。

如:基本对象,建筑对象,建筑组对象等。

3 撤销重做模块:如果没有做过类似的编辑器,应该不会知道这模块的重要性。

在实际的场景编辑中,常常编辑错了,就想恢复到编辑前的状态,这就用到了撤销重做的功能。

主要的实现思路是,当某个操作需要撤销重做功能时,注册一个对应的操作类,保存相关的参数,有对应的执行函数和撤销函数。

然后再把这操作保存到一个全局的操作列表,每执行一次撤销操作则把最后一个操作从操作列表中移除。

因为记录了相关的数据,所以在执行撤销操作时,可以完全回到编辑前的状态。

4 区域管理模块障碍区,遮挡区,安全区,各种自定义区域等等,都是属于区域操作范畴。

这种操作用得最多的就是画刷,所以画刷的设计好坏影响重大。

5 编辑态文件即除了包括游戏数据外还保存很多游戏不用的数据,但在编辑器使用过程中却带来很多便利。

比较有利的一点是很多情况下导出的场景配置文件是二进制文件,所以看不到每个版本的修改内容,这时可通过对应的编辑态文件来对比。

客户端,场景,编辑器,的,开发工作,分享,前往,

图文释疑IISweb服务器是如何处理ASP.NET请求的

每次服务器接受到请求,都要先经IIS处理。

这不是一篇描述asp.net生命周期的文章,仅仅是关于IIS操作的。

在我们开始之前,先了解这些会有助于对全文的理解,同时欢迎反馈和建议。

什么是Web Server?每当我们通过VS运行ASP.NET网站时,VS集成的ASP.NET引擎会响应各种请求,这个引擎的名字叫“WebDev.WebServer.exe”。

当我们配置一个Web程序时,总会涉及到一个词“Web Server”,它的功能便是会响应所有请求。

什么是IIS?IIS(Internet Information Server)是微软Web Server的一种,用来配置ASP.NET站点。

IIS拥有自己的ASP.NET处理引擎来处理请求,因此,当一个请求到达时,IIS接收并处理请求,然后返回内容。

请求处理过程现在,你应能搞清楚Web Server和IIS的区别。

现在我们来看一下核心部分。

在继续之前,你需要搞清两个概念:1、工作进程(Worker Process)2、应用程序池(Application Pool)工作进程:在IIS中,工作进程(w3wp.exe)运行着ASP.NET应用程序,管理并响应所有的请求,ASP.NET所有的功能都运行在工作进程下,当请求到来时,工作进程会生成Request和Response相关的信息。

简而言之,工作进程就是ASP.NET程序的心脏。

应用程序池:应用程序池是工作进程的容器,通常用来隔开不同配置的工作进程。

当一个程序出错或进程资源回收时,其他池中的程序不会受到影响。

注:当一个应用程序池包含多个工作进程时,被叫做“Web Garden”。

如果我们看一下IIS 6.0的结构,就会发现,可以把它分成两部分:1、内核模块(Kernel Mode)2、用户模块(User Mode)内核模式是从IIS 6.0被引入的,它包含了一个叫HTTP.SYS的文件,每当请求进来时,会首先触发该文件的响应。

HTTP.SYS文件负责把请求传入相应的应用程序池中。

但HTTP.SYS如何知道应传给哪个应用程序池呢?当然不是随机抽取,每当创建一个应用程序池,该池的ID就会生成并在HTTP.SYS文件中注册,因此该文件才能确定将请求往哪传。

以上便是IIS处理请求的第一步。

接着,我们来看一下请求如何从HTTP.SYS传入应用程序池。

在IIS的用户模块中,通过Web Admin Services (WAS)从HTTP.SYS接收请求,并传入相应的应用程序池中。

当应用程序池接收到请求,会接着传给工作进程(w3wp.exe),该进程检查来请求的URL后缀以确定加载哪个ISAPI扩展。

ASP.NET加载时会附带自己的ISAPI扩展(aspnet_isapi.dll),以便在IIS中映射。

注意:如果先安装了asp.net,然后再安装IIS,就需要通过aspnet_regiis命令来注册ASP.NET中的ISAPI扩展。

一旦工作进程加载了aspnet_isapi.dll,就会构造一个HttpRuntime类,该类是应用程序的入口,通过ProcessRequest方法处理请求。

一旦这个方法被调用,一个HttpContext的实例就产生了。

可通过HTTPContent.Current获取到这个实例,且该实例会在整个生命周期中存活,我们通过它可以获取到一些常用对象,如Request,Response,Session 等。

之后HttpRuntime会通过HttpApplicationFactory类加载一个HttpApplication对象。

每一次请求都要穿过一堆HttpModule到达HttpHandler,以便被响应。

而这些HttpModule就被配置在HttpApplication中。

有一个概念叫“Http管道”,被叫做管道是因为它包含了一系列的HttpModule,这些HttpModule拦截请求并将其导向相应的HttpHandler。

我们也可自定义HttpModule,以便在请求响应之间做点特别的处理。

HttpHandler是“Http管道”的终点。

所有请求穿过HttpModule需抵达相应的HttpHandler,然后HttpHandler根据请求资源,产生并输出内容。

也正因此,我们请求任何aspx页面才会得到响应的Html内容。

结语每当请求web服务器上的某些信息时,该请求首先会到达Http.SYS,然后Http.SYS将其发送到相应的应用程序池,应用程序池传给工作进程并加载ISAPI扩展,然后HttpRuntime对象会被创建,并通过HttpModule和HttpHandler处理请求。

最后,ASP.NET页面生命周期就开始了。

图文,释疑,IISweb,服务器,是,如何,处理,ASP.N

加入收藏
               

跨平台.NET开发了解编程语言规范

点击下载文档

格式为doc格式

  • 账号登录
社交账号登录