Namespaces

Variants
Actions

Please note that as of October 24, 2014, the Nokia Developer Wiki will no longer be accepting user contributions, including new entries, edits and comments, as we begin transitioning to our new home, in the Windows Phone Development Wiki. We plan to move over the majority of the existing entries over the next few weeks. Thanks for all your past and future contributions.

Windows Phone技能的迁移

From Wiki
Jump to: navigation, search
WP Metro Icon WP8.png
SignpostIcon Code 52.png
Article Metadata

兼容于
文章
WS_YiLunLuo 在 05 Jul 2012 创建
最后由 hamishwillee 在 19 Jul 2013 编辑

Contents

简介

上一篇wiki中,我们介绍了WinRT,今后可能会在Windows Phone 8上出现的一个运行时,它支持C++。大家知道,在Windows 8上,你还可以用JavaScript来开发程序。不过微软并没有announce今后Windows Phone 8会支持JavaScript。然而曾几何时,我们在开发Windows Phone应用程序:.NET vs. HTML这篇wiki中,已经看到了事实上Windows Phone 7已经可以使用HTML+JavaScript,只是这样的程序不能发布到Marketplace上。最近我们还翻译了一篇wiki,介绍了如何在Windows Phone 7上混合使用HTML/JavaScript和Silverlight/C#。

在开发Windows Phone程序(无论是现在还是未来)的过程中,有很多平台供我们选择。不过我们也意识到了有些人觉得更多的选择就意味着更大的混乱。这些混乱包括:难以将一种平台上的技能(例如Silverlight)迁移到另一平台;不同平台的开发人员之间难以交流;难以混用多个不同的平台。甚至有些人可能会抱怨说又要学习一种新的东西了。

但是事实上,不管平台如何千变万化,很多技能都是可以通用的。本文将会做一个高层的总结,看看在传统计算机上开发一个一般的应用程序,有哪些技能是可以跨平台利用的。这里的传统计算机包括任何基于x86,x64,以及ARM的设备,包括Windows Phone,因为手机现在真的已经和计算机很像了。希望阅读完本文,大家就不会再对新的技术和新的平台感到恐慌了。

平台的组成

上一篇wiki中,我们介绍了操作系统内核,运行时,和框架的关系。平台这个概念很难界定,你可以说某个框架就是一个平台,也可以说某个运行时是一个平台,但是通常很少有人会说操作系统的内核是平台。

无论如何,本文中所说的平台指的是大型框架+编程语言(注意这只是本文中使用的一个term,并不意味着这就是标准的平台定义)。例如HTML框架+JavaScript语言组成的平台,XAML框架+C#语言组成的平台,等等。绝大多数的应用程序都是基于框架,而不是直接基于运行时,进行开发的,原因在上一篇wiki中也说了,框架帮我们实现了很多常用的功能。没有框架,就连最基本的UI组件都要你自己去实现。当然,因为框架本身是基于运行时开发的,所以有时候我们还是不得不接触一些运行时相关的概念。

接下来,我们就编程语言,框架,和运行时分别叙述技能要如何迁移。

语言技能的迁移

这个世界上有很多很多编程语言,但是几乎所有的语言都拥有如下基本特性:

  • 基础数据类型。在没有运行时甚至操作系统内核的情况下,有些语言直接暴露了基础数据类型,例如C语言中的int。但是现代的语言通常都会视运行时的不同而不同。例如,C++语言若是使用CX语法用于WinRT环境中,编译器会自动将int转换成WinRT这个运行时所提供的Int32这个数据类型。
  • 条件/循环语句
  • 函数或者叫方法
  • 结构或者叫类(JavaScript中则就只有做对象)
  • 回调或者叫函数指针或者叫委托

所以,事实上无论你使用哪种语言,通常你都会找到这些熟悉的概念,剩下的只是学习一种新的语法。

目前最流行的是面向对象的编程语言,就连JavaScript也可以被封装成面向对象的语言,就向WinJS所做的那样。几乎所有面向对象的编程语言都提供了诸如继承这样的通用的概念。所以再一次,只要你会一种面向对象的语言,你就可以说你已经会了很多其它面向对象的语言,只是有些地方还不太熟悉而已。

当然,很多语言都有自己的特性,例如C#,VB,C++提供了lambda expression,但是JavaScript和Java都没有。不过如果你看出了lambda expression只是对委托(delegate)的一种封装,就不会感到意外了。如果一个语言没有lambda expression,你可以直接使用委托,或者和委托类似的回调,函数指针,之类的功能。而C#和VB中的LINQ语法(注意这边我们只讨论语法,而不包括LINQ to XML,LINQ to Entity这样的框架),说白了是一种简单的方式来写lambda expression,所以呢,其实其它语言也都提供了类似的功能,只是可能没有LINQ那么直接,需要直接使用lambda expression甚至是委托。

还有些人会说不同的语言的编译方式不同,在运行的时候有很多不同点,这里会有很多要注意的地方,因此一种语言的技能很难迁移到另外一种语言上去,不注意编译方式和运行时候的区别是学不好语言的。不过我们想指出的是,编译本身只是把一种语言翻译成另外一种语言而已。所谓的不同的语言在运行的时候有不同的行为,正如名字所说的那样,是和运行时甚至是操作系统内核(如果你没有运行时的话)有关的,而和语言本身无关。例如CLR和WinRT都是运行时。如果你要深入调查.NET的程序集加载,内存分配,JIT,等等,必须要了解的是CLR这个运行时,而不是C#这个语言。同样,Java这个语言本身其实没有太多好说的,但是Java这个名称同时也指代了一个运行时,只是那个运行时只支持Java这一种语言,所以就用同一个名称了。微软曾经推出过一个叫J#的语言,类似于Java语言,不过根本不用Java这个运行时,而是使用CLR运行时。所以,希望大家不要把语言和运行时搞错了。

同样,语言也不能和框架搞错。例如.NET提供的base class library是一个框架中的概念,它和语言无关。JavaScript提供的一些常见的类,C++的STL,Java中常见的类,也都应该归入框架,而不是语言。在这些底层的框架为我们实现了一些很常用的数据结构,但是假如你跳开框架,自己使用特定的语言写这些数据结构(正像很多学生被要求的那样),也是没有任何问题的。在这之上,还有像XAML,HTML,Silverlight等更高层的框架。如果你要对两个平台做比较,通常都要建立在运行时和框架的基础上,而绝不仅仅是停留在语言的层面。像网上流传的很多对于C#和Java的比较其实都把概念搞错了,他们往往会用一个语言的名字来指代一整个由语言,运行时,框架组成的体系。

综上所述,只要你会一种编程语言,你的技能通常就能很好地迁移到其它语言上。当你学习一种新的语言时,主要是要熟悉它的语法,而很多概念都是通用的。编程语言的学习真的很简单,要比学习人类语言容易多了,真正的不同在于运行时和框架。

运行时的技能迁移

运行时往往没有语言那么简单,但是运行时所提供的很多功能还是相似的。例如:

  • 组件加载。不同的运行时的组件加载方式可能完全不同。例如,WinRT,我们上次说过,会去读注册表。而CLR则是通过assembly binding的方式加载程序集。Java,我不是很清楚,不过应该和WinRT以及CLR有很大不同的。
  • 基本数据类型。刚才说过,事实上现在很多语言提供的基本数据类型都是基于运行时提供的。这一块不同的运行时都大同小异。
  • 内存管理。通常作为一个运行时,总会有自己的内存管理。例如WinRT使用的是智能指针,CLR和Java则有垃圾回收。不同运行时的内存管理机制不同,但是所要达的成目标都是一致的:让应用程序开发人员可以尽量不要关心内存如何分配,何时释放。
  • 安全机制。作为一个优秀的运行时,必须是安全的。运行时所负责的安全主要包括控制哪些操作系统内核提供的功能允许应用程序使用,哪些不允许。有些运行时,例如CLR,还提供了多个安全级别,在高安全级别中,代码只允许使用一部分功能,系统管理员可以配置其它安全级别,从而让某些程序可以有更多权限。
  • Building blocks。有些人认为building blocks应该隶属于框架,但是在本文中我们还是把它们归属于运行时,因为很多building blocks都不会直接被应用程序使用,通常都是被框架使用。只有少数高级场合中应用程序才会直接使用这些building blocks。当然,不同的运行时所提供的building blocks很可能就千差万别了。

虽然我们可以说几乎所有运行时都提供了上述功能,但是它们的机制往往有很大的不同。因此,学习运行时通常都要比学习语言来的困难。好在绝大多数的应用程序都不会直接和运行时打交道,更多的是使用某个框架。因此我们提议,大家在调查一个运行时的时候可以先从以上几个方面入手,将它和自己熟悉的另一个运行时做个比较。除了building blocks之外,许多时候调查运行时我们都只需要了解一些理论性的知识即可,当程序出现了问题,例如某个组件无法加载,或者发生了内存泄漏,或者你想当然地认为自己可以做的事但是运行时认为是不安全的时候,这些知识才真正会用得上。

框架的技能迁移

框架可能是最麻烦的一块,因为不同的框架所提供的功能都可能不同,更不要说即使功能相同,但是API也会完全不同了。

这个世界上有很多很多框架。今天我们仅仅讨论客户端使用的UI框架,而不会讨论服务器端使用的通信框架,数据访问框架,或者一些比较小的,诸如帮助你实现某个设计模式的框架,等等。UI框架本身也有很多,有些框架,例如Metro中的XAML框架和Silverlight,WPF,Windows Phone都是类似的,但也有所不同。而HTML,Java Swing,JavaFX,Flash,AIR,Windows Forms,等等,又有着显著的不同。注意Silverlight,WPF,Windows Phone也都使用了XAML,为了方便,如果没有特别指出,下文中的XAML就包括了全部这些。

但是,即使框架千差万别,很多UI框架还是提供了类似的基本功能。所以,虽然写法不同,但是很多概念还是可以通用的。我们可以把UI框架提供的功能归结为如下这些。注意并不是每个框架都提供了所有这些功能。

UI markup解析

如果某个UI框架没有提供这个功能(例如Windows Forms),要想不使用设计器而定制UI就会十分困难。因为你必须通过调用一大堆的代码来创建各种UI元素。因此,XAML和HTML这样的框架都提供了markup,让开发人员可以通过写标签的方式来定制UI。就UI而言,标签相比起代码更具有逻辑性。虽然标签不同,但是只要你会xml,就不会对这些markup感觉陌生。更何况很多标签的名称都是很显然的,例如Button(也有些框架用小写的button)。

2D图形

虽然运行时的building blocks中通常已经提供了2D图形的支持,但是那些API并不是非常好用。在上一篇wiki中,大家看到了为了用Direct2D实现一个hello world程序,都需要写很多很多代码。因此,有些框架为我们提供了更高层的API。例如,XAML中为我们提供了各种各样的shape,让我们可以直接通过创建一个标签,配置一些属性的方式来绘制图形,根本不需要考虑任何Direct2D相关的内容!类似的,HTML也提供了SVG,基本上和XAML中的shape是一致的,虽然语法有较大的不同。就算你用canvas,也要比Direct2D来得方便。你会发现,使用框架提供的2D图形功能,而不是直接用运行时,开发效率可以提高10到100倍!当然,有些高级场合下,例如需要使用shader effect,需要3D,或者高效需要绘制大量图形,你还是只能直接使用运行时。

2D图形不仅仅包括形状,也包括一些基本的变换,例如平移,旋转,等等。还有一些伪3D变换(perspective transform)XAML中的transform,HTML中的CSS transform,都提供了这一功能。

有少数框架也提供了3D的支持,例如WPF。但是目前大多数框架(包括非WPF的XAML框架)都没有提供3D支持。也有少数框架对shader effect提供了少量的支持,例如WPF和Silverlight(但不是Windows Phone和Metro)都支持pixel shader,但最高只支持到3.0,而且不支持vertex shader,geometry shader,hull shader,domain shader等其它shader功能。总的来说,目前框架对shader effect的支持还很不好。

诚然,XAML中的transform和CSS中的transform语法可以说是完全不同,不仅仅在markup中的写法不同,在代码中创建transform的方法也截然不同。但是,transform的概念都是一致的。许多时候你甚至不需要知道旋转矩阵(旋转变换的数学表示),就可以实现旋转的效果,这就是框架帮我们做的事。而如果某个框架(例如Windows Forms和Java Swing)并没有提供2D图形API,你就要考虑它是不是适合于你的场景了。Windows Forms用来做数据录入的工具是一个不错的框架,但是显然它不适用于针对消费者的产品,或者一些需要高级图形功能的场景。

位图

运行时的building blocks通常都提供了bitmap encoder和decoder。可是绝大多数的情况下,一个应用程序对位图所需要的操作就仅仅是将图片显示出来而已。因此,几乎所有框架都提供了一个专门的组件(注意我们不用控件这个单词,因为XAML中不把Image归为控件,毕竟它不继承自Control)。使用XAML中的Image和 HTML中的img,我们需要做的唯一的一件事就仅仅是提供图片的路劲,剩下的一切都会自动完成!就算Windows Forms,也提供了一个叫Image的控件(在Windows Forms中它真的被归为控件),你可以在代码中创建它,设置好路劲,一切都会水到渠成。

关于位图这一块,如果你只是要显示图片,我们的技能可以很轻松地被迁移到其它框架中去,框架再一次让我们的代码量可以减少大概10到100倍。当然,在一些高级场合中,你需要直接对位图进行编码/解码。这时候就不得不直接使用运行时了。

文本

几乎所有的应用程序都需要显示文本。而直接使用运行时的building blocks(例如DirectWrite)显示文本会非常非常困难,别忘了我们上次写了几百行代码,就为了显示hello world!因此,很多框架都为文本提供了简单易用的API,让我们通过一两行代码,或者甚至只是在markup中写一个标签,就能显示出文本。

有些框架提供的文本功能十分强大,例如,HTML通过CSS可以让你实现很多很多文字效果,最好的证明就是微软的Office Web Application(包括Word)和Google Docs都是使用HTML开发的!当然,就算Office Web Application也远远不如Word本身强大,但是少掉的主要是编辑功能,而不是文档阅读的功能。

也有些框架,例如XAML,对文本的支持略微少了一点,但是XAML依然提供了部分对flow document(用于RichTextBox)的支持。就连Windows Forms这样的框架,至少也提供了Label,让我们可以很方便地显示文本,虽然要添加样式会比较困难,因此Windows Forms不适用于开发文档阅读相关的程序。

如果你知道文本相关的一些概念,例如字体,字号,段落格式,等等,就会发现很多知识都是可以在各种框架之间都是可以通用的。

多媒体

我们曾经写过几篇wiki,说明了如何使用运行时提供的Media Foundation这样的building block来为视频/音频编码。大家应该意识到了这些API都很复杂,使用起来很麻烦。但是对于大多数程序而言,我们只需要播放事先编码好的电影就可以了。仅仅为了播放一个电影文件,都需要写上好几百行代码,这对于一般的程序而言负担实在是太大了。因此框架就提供了简单易用的组件,来让我们可以轻松播放电影。使用XAML的MediaElement,或者HTML的video/audio,你根本不用去考虑如何为一个电影文件进行解码,根本不用去管什么source reader和sink writer。你所需要做的,只是写这这样一个标签,设置好路劲,然后一切的一切都由框架帮你实现了!就算在Windows Forms中,你也可以嵌入一个Windows Media Player。

是真的,如果你只需要播放事先编码好的电影,不管用什么框架,都是很简单的。这一块的技能迁移起来非常容易。不过如果需要自行编码/解码,就不会那么方便了,你必须直接访问运行时。不过即使如此,一些视频/音频的概念(例如bit rate)还是可以通用的。

动画

如果用得好,动画对于提高用户体验是很有帮助的。不过通常并没有哪个运行时直接提供了对动画的支持。你可以使用一个定时器,但是那并不是一件很简单的事,因此有些框架就承担了这一责任,为我们提供了一个简单易用的动画模型。

不过,不同的框架提供的动画支持有较大的不同。例如XAML中使用的是Storyboard,HTML中使用的是CSS transition/animation,jQuery中提供了一些JavaScript API(若是你需要支持早期的浏览器,例如IE8,就不能用CSS3提供的动画了,所以不得不借助像jQuery这样的框架。当然,只要有可能,我们就推荐用CSS,因为更方便,而且支持硬件加速)。甚至还有不少框架根本没有提供动画支持,例如Windows Forms就是一个典型不提供动画支持的例子。

但是,我们或多或少还是可以找到一些通用的概念。例如,XAML和HTML的动画都是在一段时间内不断修改某个属性的值,例如从0到1。至于变化的过程,通常是通过一个ease function提供的,ease function的横坐标代表时间,纵坐标代表属性的值,因此ease function本身就是描述属性在每一时刻的值的函数。例如线性渐变就是一个一次函数,此外你还可以使用三角函数,一个会震荡的函数,等等。像Expression Blend这样的工具提供了可视化的设计,让你不需要理解数学公式都能直观地看出属性根据时间的变化情况。如果你会XAML中的动画,要迁移到HTML中,所要做的就只是修改语法,而这些概念全部是通用的。就算某个框架没有提供动画支持,你也可以自己用一个定时器,自己写一个函数,来实现动画,这可能会需要多2到10倍的工作吧。

布局

在那遥远的上个世纪,很多程序都使用绝对定位(想象一下XAML中的Canvas),这造成的问题是随着分辨率的不同,显示效果也会不同。如果分辨率太低,很可能用户会需要经常使用滚动条才能看清屏幕。如果分辨率太高,很可能屏幕上很大一块都是空白的。

如果你要自己控制布局,让程序的内容自动适应于环境大小,并不是一件简单的事。所以,有些框架提供了内置的布局支持。这里我们还是指出XAML和HTML都提供了强大的布局支持,就连Windows Forms,也提供了少量的布局支持,例如类似Grid的布局。

不同的框架对于布局的支持有较大的不同。但是有一些是通用的,例如XAML中的StackPanel和HTML中的block(由CSS提供)都是简单地将元素从上往下或者从左往右堆叠。而XAML Grid和CSS grid则提供了行和列的支持。这些布局都让你的界面元素可以自动适应环境大小,你自己只需要选择好一个合适的布局,而不需要担心如何计算元素的位置和大小。

当然,HTML由于拥有CSS,对于布局的支持是最强大的,它提供了很多诸如multi-column,flex box这样的很多其它框架所没有的布局。如果你是一个XAML开发人员,你必须额外地学习这些HTML特有的布局,并且在适当的时候使用。如果你是HTML开发人员想要迁移到其它框架,可能就不得不自行实现这些功能了。

控件

这里我们借用XAML的概念,所谓的控件,指的是一套预先设定好的行为。例如,button就是一个可以用来点击,并且在点击时可以触发一个事件的控件。控件本身不关心显示,显示是由style和template负责的。当然,control template是XAML特有的功能,HTML中就只有style。

几乎所有的UI框架都提供了各种基本控件,像button,textbox,等等。这又一次为我们省下了大量的工作。有些框架提供了复杂的高级的控件,例如WPF,Silverlight,Windows Forms都提供了DataGrid,但是其它主流框架(包括Windows Phone和Metro)并没有。我们在这边只能说,大家首先要了解的是控件的模型。例如,如果你要修改一个控件的外观,有哪些方法?除了HTML,你都可以修改一些和外观相关的属性,而XAML和HTML都提供了style,甚至XAML还有control template。不同的框架的控件模型可能有所不同,但是对于同一个框架而言,控件模型对于全部控件都是通用的。因此,就算你不能简单将一个框架中积累的技能迁移到另一个框架中,至少如果第三方针对你当前使用的框架写了一个新的控件,你还是可以应用现有的技能的。

至于某个具体的控件如何使用,恐怕就真的只能现学现用了。就算是最简单的button,在Windows Forms中它就只有一个Text属性,要显示图片必须用ImageButton。而在XAML中你可以将button的Content属性设置成任意东西,包括图片。在HTML中,你既可以写button这个标签,也可以写input type=”button”,而且还有普通按钮和submit按钮的区别。在控件这一块,恐怕技能真的不能很好地在不同的框架之间迁移。

数据绑定

很多程序都需要显示数据,这些数据绝不仅仅来自于数据库。例如,一个游戏中也往往有各种各样的数据。这就是为什么很多框架都提供了强大的数据绑定的支持。

大家可能还是会觉得失望,因为不同的框架的数据绑定又是不同的。例如Windows Forms要通过代码设置绑定,而XAML可以单纯使用markup,Metro中的HTML的数据绑定既会用到markup,也会用到代码,甚至不用Metro的话,你还不能用那一套数据绑定的引擎,而必须另找其它(例如使用jQuery Template)。有些人可能还是会感觉很头晕,用惯了XAML就很难在HTML中使用数据绑定。

但是,数据绑定相比起控件还是相对比较统一的。至少数据源,绑定对象,等等的基本概念是一致的。我们通常就是将binding target的某个属性绑定到binding source的某个属性,而若是数据源是一个集合,还可以让集合中的每个项都变成binding target中每个项的数据源。所以,至少你会发现这些概念很熟悉,剩下的工作是要学习一个新的数据绑定的语法。

此外,有些数据绑定的引擎,例如Metro中的HTML,可能并未提供一些像converter这样的高级功能。不过好在就算在Metro的HTML中,你还是可以使用jQuery Template的。

说到底,就算你不用数据绑定,直接在代码中通过设置属性的方式,显示和更新数据,工作量也不会多太多。只是代码逻辑可能会显得有点混乱了。

访问网络

在那遥远的上个世纪,大多数程序都是孤立的,不需要网络的。但是现代社会不同了!现在很少有什么程序是不需要网络的(当然,我们这边并不是说一些系统管理的工具)……让我们先不管云计算,只是单纯地考虑从网上下载数据以及上传数据到服务器,我们看到运行时已经提供了一些building blocks,让我们可以发送TCP/HTTP请求。

但是还是这个问题,运行时提供的API太底层了,通常并不是很好用。所以我们会需要框架给我们提供更方便的API。在这里Metro的XAML和HTML又一次为我们提供了强大的支持。Metro的XAML中的HttpClient,以及Metro的HTML的xhr,都是很好用而且功能很强大的API。而非Metro的XAML程序则是利用了.NET框架提供了一些组件,例如WebClient。非Metro的HTML程序通常选择了jQuery框架的ajax。它们的用法不同,但是概念却是完全一致的。

通过HTTP访问网络,无非就是发一个HTTP请求到一个服务器(通常称作REST service),这个请求有一个HTTP method,例如GET或POST就是常见的HTTP method,有一些header,例如Authorization header,有时候还有一个body。Body是可选的,它用来向服务器上传数据。

只要知道了这些概念,不管你用什么框架,要访问网络都不是一件难事。同样,如果你选择TCP或者其它拓扑,也是类似的。只是有些框架可能没有直接对一些拓扑提供支持。

框架技能迁移的总结

我们看到了框架这一级别相对而言比较混乱,不同的框架实现了各种不同的功能,甚至就算功能相同,很可能提供的API也千差万别。但是,无论如何我们还是可以找到一些共同点的。当你需要从某个框架迁移到另外一个框架时,请千万不要害怕,先看看目标框架中有没有熟悉的功能,然后看看这个功能怎么用,看看目标框架会不会提供了比现有框架更为强大的支持。有些时候(例如绘制2D图形,播放电影,等等),框架为我们省下的工作量是无可取代的,它们让我们可以少写100倍甚至更多的代码。但是也有些时候(例如数据绑定),框架帮我们省下的工作量并不是很多,更重要的,是帮助我们的代码进行分层管理,让逻辑更清晰。

革命性与非革命性的变化

事实上,无论平台如何变化,通常都不是革命性的变化。如上所述,开发语言虽然语法不同,但是概念都大同小异。运行时也往往都提供了类似的功能,只是机制不同。就算在框架级别上,还是可以找到不少能够通用的技能。所以,大家不要对变化感到害怕。新东西的出现都是有道理的。例如从上面大家可以看到,Windows Forms的功能真的太少太少,所以才会出现XAML。为了对各种各样的平台提供支持,XAML才会有WPF,Silverlight,Windows Phone,Metro等众多版本。它们互相之间大同小异,所以从一个XAML框架迁移到另外一个XAML框架并不会是一件很困难的事。而HTML并不是用来取代XAML的,只是HTML是另外一个很流行的框架,所以Metro才提供了对它的支持,让广大使用HTML的开发人员也能够针对Windows 8进行开发。支持HTML并不意味着微软打算背叛XAML开发人员。

也许有一天,我们的世界会发生翻天覆地的变化。例如,假设量子计算机真的流行起来,那应该是一场革命性的变化,连机器语言都会被彻底改掉。很难想象现在的高级语言能被编译成量子状态(quantum state),因为它们都是基于传统的0,1这样的位(bit),而不是基于|0>和|1>(这里用的是bra-ket notation),以及a|0>+b|1>这样的量子位(qubit)的!就单纯的如果两个状态都是合法的,它们的线性组合(或者说是superposition)也是合法的这一点,搞不好就会把我们现在的一切全部推翻,更不用说那些神秘莫测的quantum entanglement之类的概念呢……到时候我们可能真的每个人都必须去学习量子力学,学习线性代数,从头开始学习很多很多新的东西……

相比起这些,从某个XAML框架迁移到另一个XAML框架,从CLR迁移到WinRT,这样的微不足道,不会对硬件产生影响,不会将我们现有的技能彻底推翻的变化,真的不算什么,实在是不用让人害怕的啦。

总结

本文的目标在于协助某些对技术/平台发展感到恐惧的开发人员消除恐惧,了解有很多技能都可以迁移到新的平台上去。希望看完本文,大家对自己更有信心了,很多现有的技能都是有用的,而不会被淘汰掉!

This page was last modified on 19 July 2013, at 04:10.
225 page views in the last 30 days.

Was this page helpful?

Your feedback about this content is important. Let us know what you think.

 

Thank you!

We appreciate your feedback.

×