Scott Guthrie谈Silverlight（二）

 

Scott Guthrie谈Silverlight（二）

译者：程化

 

Charles：你提到了WPF世界，你知道，WPF是对DirectX的抽象，这是为什么我们可以使用真3D的原因。很显然，Silverlight无法利用这个优势，因为DirectX无法在Mac上运行，对不对？

 

Guthrie：对，是这样。

 

Charles：所以，Silverlight可以处理矢量图形，但这不是真3D，或者是真3D？让我们谈谈这个。

 

Guthrie：我们得提到若干差异。其中之一是，Silverlight中有没有某些特定的3D图形API，比如，创建有若干物体的场景，放置光源和镜头，就像和Windows一起发布的WPF提供给你的那样。我们在Silverlight中没有那样的支持。主要原因是这要求有对性能说得过去的硬件设备加速的支持。在Silverlight中你可以相当程度地模拟3D。但是，在包中没有那种底层3D API。但是，你可以模拟。大家已经努力在用Flash，用Ajax之类的东西来模拟3D了，你可以用Silverlight模拟这些效果。你知道，如果你的样本能够满足3D的需要，你就可以这样做。但是，如果你想要像WPF提供的，超级丰富的3D图形，你应该用完整的WPF来做这件事。

 

Charles：当然。但是，你可以写出有趣的Silverlight类型的游戏。

 

Guthrie：喔，绝对如此，是的。

 

Charles：对Silverlight来说，我认为可以做到像比尔•盖茨总在说的那样：你喜欢做的事情是在Amazon上面用平常的方式进行购物，真的走在购物走廊中，这儿挑挑那儿拣拣。实际上，用这个技术，你可以开发出这种体验来。

 

Guthrie：你可以用Silverlight做到一点点。一个挑战是，通常说来，浏览器对3D支持得不好，浏览器通常不能很好地处理硬件加速。它们是用不支持硬件加速的图形API构造出来的。所以，要在浏览器中嵌入3D体验比较困难。如果很小心地处理在浏览器中的何处放置控件的话，你可以用WPF做到一点点。当然，你可以用浏览器外的独立程序来创造这种体验。我们想要为人们提供的一种能力是，让大家可以用Silverlight构造在浏览器中运行的应用程序，让程序可以工作在任何地方，我们想提供这种体验。如果你想做，你可以构造在浏览器外运行的，超级丰富的体验。你当然可以先做出一个Amzaon在线，然后在浏览器外提供Amazon购物的3D体验。

 

Charles：非常酷，现在我们提到了跨平台，现在支持的平台是Mac和Windows。这并不意味着其他的平台永远也不会得到支持，这并不意味着我们不会再支持其他任何东西。这是针对这个视频提的第一个问题，“对其他平台支持得怎样？” 你提到了合作伙伴，对其他平台的支持是可能的，大家可以实现这种支持？

 

Guthrie：是的，就支持的平台而言，我们当然没有任何宗教倾向。大家对我们有种先入为主的印象，有的人认为我们有所偏袒，但是我们没有。你知道，从团队的角度来看，当前我们仅仅选择针对Mac和Windows进行优化，主要因为这是两种当前在Internet上最常用的操作系统。它们占据了桌面操作系统的98％。我们也在观察移动设备系统。我们在观察如何能支持移动设备，从用户的角度来看，这是另一个领域，也许移动设备实际上是下一个能让我们接触到多数用户的操作系统领域。该领域有巨大的潜在用户。

 

Charles：那你们将来会用微型CLR来实现Silverlight，对不对？

 

Guthrie：啊，你知道，移动设备的挑战是，有120多种不同类型的操作系统，我们在密切关注这个领域，研究到底什么才是最好的实现方式。我想，很显然地，Linux和Clix等操作系统是值得考虑的。就支持哪些平台而言，我们并没有超级宗教化，基本上，我们挑出第一名，然后开始为其优化，给出我们的第一个版本，争取让我们的东西能接触到尽可能多的人。这就是我们为什么选择将Mac和Windows当作我们的目标平台的主要原因。

 

Charles：这很棒。

 

Guthrie：那么，未来会支持更多的平台，对未来会支持更多的平台我不会感到吃惊。但是，至少现在这样做，给了你创建体验，并且将这种体验传达给多达98％用户的能力。

 

Charles：那是很棒的一件事，而且你只需要写一次代码，而且你得用Visual Studio来写代码。

 

Guthrie：是的，这是很棒的一件事，我将在MIX上做关键演示，有个你可以看到的长长的视频。基本上，那是讲你可以用Visual Stuido Orcas写的那些很酷的东西。现在，假设你选择“File->New Project->Silverlight”，创建一个工程，你就得到了智能感知，你得到了调试支持，如果你愿意，你可以打开一个Blend表达式的工程，因为Blend和Visual Studio共享同样的工程格式，你可以用Blend来创建所有的UI，用Visual Studio来为其编程、调试。这样做行得通。在我们的发布中，实际上，我们甚至支持你从Visual Stuido对Mac进行调试。如果你在Visual Studio中创建的应用实际上运行在Mac上，你可以用“附加到进程上”的行为——敲入你Macintosh机器的IP地址，你会看到在Mac上所有运行托管代码的进程列表，你附加到Safari浏览器上，或Firefox浏览器上，设置一个端点，我们就可以工作了。这相当酷。

 

Charles：这简直不可思议。

 

Guthrie：这功能相当难做。但是，在本周就可以下载的版本中，这个功能被包含进去了。

 

Charles：太酷了。我是说，你们有没有通过和Apple合作才把这事搞定？你们是完全自己琢磨出来的吗？Mac是个相当封闭的操作系统，这是我为什么这样说的原因，在一定程度上来说，Mac相当封闭。

 

Guthrie：啊，是的，我们主要是靠自己完成的。你知道，我们有一些非常棒的工程师。当然，像在不同的操作系统间进行跨机器调试这种事，确实会带来一些拟真方面的挑战。但是，我们可以让所有东西顺利工作。从工程师的角度来看，最困难的事情是，各个浏览器有各不相同的插件感知机制。IE和Firefox不一样。有趣的是，Firefox和Safari使用了相同的接口API，它们实际上继承自古老的Netscape插件API。从表层的角度来看，事情都很好，你写一次代码，到处都可以用，但是，谈到实际上处理列表地址的语义，以及缓冲指针的语义，看起来Firefox和Safari是非常不同的。从工程师的角度来看，这是最困难的，这些东西没有文档记录。比如，我们传递给你这个指针，但是，是不是还保留了在未来某时刻不告诉你就释放指针的权利，或者，是你应该释放这个指针，还是我们释放这个指针？或者你以后再释放这个指针？由于各个浏览器不同的限制，我们在这里有若干的Bug需要追查。你知道，不光针对Firefox和Safari，也针对IE，试图找出浏览器与插件间的正确语义是很有趣的事情，但好处是，我们已经为你做了这个工作，在你的应用中，你不需要关心这事了。你可以在各个浏览器间获得一致的表现。

 

Charles：这让人惊叹。让我们谈谈，你们大家有没有碰到一些真正大的挑战，你最初产生这个点子时，你意识到了这将是非常艰难的一件事情吗？合作伙伴何时加入进来的？正如你之前提到的，始终都有合作伙伴。

 

Guthrie：合作伙伴始终都在。我们从早期就合作工作。我认为最困难的事实际上集中在下载包的大小上。你如何才能让下载包足够小。我们想要达到的目标是，最终发布的下载包，大小在2M到4M之间。当你想包括支持高清、全屏的视频Codec；当你想要包括支持MP3、WMA的音频Codec；当你想要丰富的矢量图形系统，让你能画图，能在任何分辨率下缩放图形；当你想要类型系统；当你想要能够运行Python、Ruby和JavaScript，你知道，当你逐渐增加这个列表时，控制大小很难办到。于是，一开始我们要做的很多事，基本上就是给人们一个预算，例如，“你有30K”。大家会说类似于“哇，你用30K做不了任何有趣的事情”，你就必须亲自去见这些人，关起门来说，“很高兴和你谈话，抱歉，你不能够进入我们的产品。”人们的反应是，“哇，你说什么啊？”现实的情况是，如果你真的非常专注，你可以把很多东西挤进很小的托管空间中。所以，我们重新实现了很多东西。我们确实在架构方面下了很多功夫，做了些重构。我最喜欢的例子是：我们有一个颜色枚举对象，就像.NET中枚举颜色的数据类型那样。我是说，它包含了成千的颜色，深黑、浅灰，如此等等，这是个很长的列表。这个枚举占了多大的空间？我们开始计算，考虑到每个字符串所占的空间，每个属性的每个域所占的空间，为了这个颜色枚举我们用了差不多9K。有多少颜色是你真正需要用来做强类型属性的硬编码的？也许6种，或者8、9种，其他所有颜色都可以只用十六进制值来表示。这样依赖，9K缩减到了几百个字节。这就是那种我们必须在所有地方进行的微级别决策。从运转项目的宏观层次上，我们持续不停地在关注：这是不是个很酷的场景？这是不是个很酷的特性？你不能用这样多的空间，你必须让它更小些。这些都是很好的工程方面的挑战。通常说来，对绝大多数特性我们都能让它非常紧凑，但这只是从工程的角度来说。这是个很艰巨的挑战。

 

Charles：绝对如此。现在让我来问你一个很好的问题（译者注：不是Charles在自吹，应该是在线看到的网友的问题）。如果我在Orcas中创建工程，例如，在Visual Studio中新建一个Silverlight工程，你知道，基本上说来，Visual Studio会让我可以引用我想用的任何库。假设我决定要引用一个Silverlight包不支持的库，这意味着什么？

 

Guthrie：很有趣。我们在第一个Alpha版本就提供这样好的工具支持的一个原因是，在Silverlight的CLR中，我们所用的程序集文件格式与完整桌面版本CLR相同。并且，我们使用相同的核心类库。有趣的事情是，Visual Studio提供给你的智能感知功能，从编译器的角度来看，是由和项目关联起来的被引用库程序集决定的。设想你创建了一个项目，你能不能说，“嘿，这儿有一个新版本的mscorlib，这儿有一个新版本的system.dll，这儿还有一个新版本的Silverlight.dll。”C#和VB的智能感知给不了你这样的智能感知。所以，我们对Silverlight做的事情实际上是创建了自己的mscorlib。它基于原来的mscorlib，但裁剪了一些在浏览器场景下没有意义的东西。我们让工具也支持这个mscorlib。同样，我们也模仿了调试API，如此一来对Silverlight，Visual Studio调试器也可以像平时那样附加到浏览器进程上。调试支持也内建在工具中。这极大地帮助了我们对工具方面的处理进行引导。很棒的一点是，如果你使用Silverlight的API子集来构造程序集的话，你就不光可以从Silverlight工程来引用，也可以从ASP.NET工程、WPF工程来引用，这没有问题。从Silverlight工程，如果你引用了，例如，一个用完整WPF构造的ASP.NET服务器控件，那么进行编译时你会看到编译器抱怨说它不知道这个API在哪儿。但是你知道，这至少比导致.NET崩溃强，而且这也不是某种完全不同的错误格式检查之类的东西。

 

Charles：这让人惊叹。我想我不得不提出来强调一下的是，你们让Silverlight甚至在设计期也遵循着沙盒原则。

 

Guthrie：是的。

 

Charles：这很重要，因为你知道，人们很容易在Visual Studio中添加引用，几乎可以引用任何东西。

 

Guthrie：我想，Silverlight提供给.NET开发人员的一个真正的机会是，如何在所有的不同领域都使用.NET。我认为，人们应该理解的一个重要点是，Silverlight没有替代HTML，它也完全不是设计来替代ASP.NET的，它真正的作用是使你可以在浏览器中写.NET代码。当你创建Silverlight应用程序的时候，你总是需要有一个服务器组件。任何地方都可以用.NET的真正优越的一点是：你可以XX Visual Studio，创建单个解决方案，你可以有一个ASP.NET工程，一个Silverlight工程，你可以在两者之间进行引用。Alpha版发布中有Visual Studio Orcas的插件，它给了你对Silverlight支持。它被设计为实际上可以配合ASP.NET和WCF Web Services工作。你可以ASP.NET工程中的Web Server引用与Silverlight工程关联起来，这样你的Silverlight工程就能够以很棒的强类型方式回调到ASP.NET应用中。你可以来回得数据，来回发送数据。你的Silverlight应用能够利用ASP.NET的角色管理系统，使用ASP.NET的成员。它可以很好地嵌入到你的ASP.NET应用中。作为MIX发布的一部分，我们还会发布一个包，它被称为ASP.NET的未来发布。它包含一些新的服务器端控件，特别设计来和Silverlight一起工作。这样一来，你可以非常轻松地用ASP.NET创建一个网页，你可以加上新的ASP XAML 控件，或ASP媒体控件，指向Silverlight工程，然后把整个ASP.NET工程就没事了。在ASP.NET应用中，不需要额外的代码。我们确实不光集中精力于努力创建Silverlight，同时也努力研究如何使Silverlight可以很好地加入到现存的.NET Web应用中。就Silverlight来说，我们得到了非常好的客户端－服务器对称性。

 

Charles：这非常酷，我必须要总结一下：我们在Channel 9上采访你已经有2、3次了，你支持的相关采访更多。我总是想要给你做做广告，因为你是首先看到.NET好处的人之一，尤其是服务器端，ASP.NET，是不是？你最初在ASP团队中，是这样吗？

 

Guthrie：啊，我启动了ASP.NET团队。当我们做ASP时，我在IIS团队中。

 

Charles：酷，你发起了战斗——这是托管代码，这东西非常优秀。现在我提这事，我不停唠叨这事的原因是，如果你看看自己所处的位置，我们在谈在基于浏览器的程序中写托管代码，而且不光在Windows上，还在Mac上，我认为这简直不可思议。我们往回看看，“哇，.NET真的已经是无处不在了”

 

Guthrie：是的，我认为，我的意思是，Silverlight真正的重大之处是，它真的打开了无穷多的可能性。实际上.NET有非常多的API，它们都很重要。许多API是为了使现存的场景能工作得更好。我认为Silverlight的有趣之处在于，以及从.NET的角度来看是个非常复杂的发布，它是关于使能某些现在就是无法做到的场景的。你知道，使能一类新的应用程序，在浏览器中运行，零摩擦的部署，运行在Internet上，你没必要担心是否某人已经安装了这个软件，是否有大量的再发布者的问题，或者，需要花20分钟安装某些东西，你仅仅需要点击URL，它就工作了，你知道，你确实可以在应用中加入更丰富的图形、媒体，以及类似于客户端的，用现在的JavaScript不可能做的计算。结果就是，构造了更加丰富的Channel 9，或者是下周举办的网球赛的更丰富的在线体验。我们有NetFlex等一大堆很酷的合作伙伴，它们展示给我们这是很棒的体验，你用当前的纯HTML或JavaScript就是无法做到。所以，它确实打开了跨平台和跨浏览器环境的机会。

 

Charles：太让人惊叹了。我是说，这是让人惊讶的工作。

 

Guthrie：我们正在到达目标……

 

Charles：你们正在到达目标，这非常酷，伙计，我认为，你刚刚提到，现在，我可以用Visual Studio这样的应用来创建，比如，三种不同的工程，对不对？我可以用来做我的Web工作，做我的站点，做我的服务器，我可以在同一个地方做所有这些，调试客户端和服务器。强大！

 

Guthrie：是的，你可以同时将调试器附加到浏览器客户端，以及ASP.NET服务器上。你可以想像这样一个过程：你的调试会话能自动跟踪从客户端向服务器回调，同样，因为LINQ同时支持服务器和客户端，你可以对SQL使用LINQ，对服务器上的实体使用LINQ，从数据库获取数据，创建分析后的结果，再将这些数据用Web Services发送到Silverlight。在Silverlight内部，你可以将数据绑定到WPF控件上，如果你想做，你还可以针对那些未连接的实体对象使用LINQ，对其做进一步的次级查询，再将数据绑定到其他东西上，然后你可以更新实体对象，将数据发送回服务器，更新数据库。这是Internet上在浏览器内进行的端到端集成，相当酷。

 

Charles：这意义太重大了。说起来我们真的很认真地在对待Web呢，是吧？Web 2.0了，伙计。

 

Guthrie：嗯，这样的应用会出现的，我想它会出现。你知道，从当前ASP.NET的背景来看，我认为，Silverlight真正可以让我们做的一件事情是，创建当前不可能的应用程序。在这个意义上，当前或者由于兼容性原因，或者由于过于复杂的原因，通常仅仅由于浏览器不支持的原因，有一类体验，有一类应用就是无法构造。Silverlight真的可以使你在这方面前进，开始琢磨这类工程，其结果当然会使用户获得愉悦的感受。

 

Charles：绝对如此。我们现在也使开发者很愉快，因为可以用托管代码了。

 

Guthrie：是的，非常希望从开发者的角度来看，这带来了很多乐趣。

 

Charles：绝对的。嘿，我确信你还有另一个会议，是不是？谢谢你的时间，我们真的很期待下周看到这个东西。

 

Guthrie：非常感谢。是的，我也非常期待。

 

Charles：好的，非常感谢，干得很棒，伙计。

 

Guthrie：非常感谢。