Q新闻丨谷歌广告彻底放弃Flash，100%转向HTML5；将在.NET Core中被废止的技术；Angular发布1.5正式版

Posted 2021-04-26 InfoQ

1

谷歌广告彻底放弃Flash，100%转向html5

随着谷歌宣布Google Display Network将很快停止运行Flash广告，Adobe Flash漫长而痛苦的消亡过程还在继续。

在AdWords Google+页面上分享的“谷歌展示广告将100%转向HTML5”的博文中，谷歌表示“为了让更多的人在更多的设备上获得更好的浏览体验，Google Display Network和DoubleClick Digital Marketing现在将100%转向HTML5。”

从2016年6月30日开始，AdWords和DoubleClick将不再允许使用Flash构建的广告上传。自2017年1月2日开始，Flash广告将既不能在Google Display Network上运行，也不能通过DoubleClick运行。谷歌将继续向广告商提供AdWords帮助，帮助他们过渡到HTML5。

这一变化还影响到了谷歌的Flash转HTML5工具Swiffy，自2016年7月开始，将没有新的广告使用该工具转换。谷歌建议用户访问AdWords帮助页面获取更多将Flash广告转换为HTML5广告的资源信息。

大多数社区都没有对谷歌的新闻表示太大的吃惊，许多评论者对谷歌的声明表示欢迎。

Flash的未来饱受质疑已经有段时间了。2015年，InfoQ曾报导过，随着Adobe发布两个重大漏洞的声明，Mozilla在Firefox中“默认”屏蔽了Flash。而InfoQ的研究文章“Flash备受责难：您只使用HTML5/javascript吗？”中，HTML5获得的相关性评分为89%，而Adobe Flash的相关性评分不足50%。

显然，Adobe也促进了Flash的终结，该公司在2015年年底宣布将Flash Professional更名为Animate CC，以表明其将更加专注于HTML5。

2015年11月，Adobe高级产品营销经理Rich Lee写道，在使用Flash Professional创建的内容中，有超过三分之一的使用了HTML5。Lee表示，“由于HTML5的出现以及利用Web标准动画的需求”，该工具在过去几年中已经完全重写，“以便包含原生HTML5 Canvas和WebGL支持”。

在2016年2月8日确认Animate CC发布的博文“Animate CC来了”中，Lee表示，除名字发生变化之外，Animate是该公司“迄今为止最重大的发布”之一。

此次发布与谷歌AdWords的声明同时发生，这似乎不是一种巧合。Animate的主要特性包括“支持HTML5 Canvas模板并允许开发人员使用任何代码编辑器定制（比如，开发人员可以增加脚本用于Doubleclick或AOL跟踪）以及支持Typekit与HTML5 Canvas文档集成。”

Animate CC其他的改进和更新还包括使用最新版本的Combined CreateJS库取代了先前版本中使用的专用库。Adobe表示，这一变化的目的是减少来自已发布的HTML5 Canvas输出的服务器调用次数，以便提升性能。

Animate还增强了HTML5 Spritesheet UI，Spritesheet tab对PNG和JPEG设置提供了单独的控制，可以启用或禁止。Animate内容还可以从ActionScript、WebGL或HTML5 Canvas中导入到OAM（.oam）动画插件文件。

Adobe Flash运行时路线图上最近的更新是2015年3月，目前Adobe没有就Flash的未来提供任何更近的信息。

英文原文：http://www.infoq.com/news/2016/02/google-flash-ads-html5

2

将在.NET Core中被废止的技术

虽然有一部分现有的.NET应用程序，尤其是基于ASP.NET MVC的应用程序将能够比较简单地迁移至.NET Core，但另一部分.NET应用在迁移过程中可能会遇到某些问题。有一些问题是显而易见的，例如从WinForms或WPF应用迁移至Universal Windows Applications（UWP），而另一类些问题则更加微妙，这关系到.NET Framework核心功能中更底层的实现。

反射

反射API在.NET Core中产生了很大的变化。正如在WinRT中的应用方式一样，反射功能被分成一种轻量级的版本以及一种开销更大的版本。来自微软的Immo Landwerth写道：

在推出.NET Native时，我们利用了一种技术，它允许我们将应用与框架和第三方依赖进行静态链接。要使这种链接功能可行，它必须能够找出在你的应用没有使用的那部分框架功能。对于其他技术，例如C++来说，这一过程并不复杂，因为这种系统并不具备反射这样的动态能力。当然，在.NET Native中仍然支持反射，但我们希望让这个平台尽可能地降低开销，也就是说不必为你所不需要的特性增加开销。这一点对于反射来说尤其明显，因为它对于运行时以及编译器能够基于静态信息进行哪些操作施加了极大的限制。

因此，在理想的情况下，反射应当作为.NET Core中一个可选的组件，你可以选择在自己的应用中完全放弃使用它。麻烦在于，System.Object在进行Object.GetType()操作时将对反射产生依赖。为了打破这种依赖，我们决定让System.Type不再展现整个反射类型信息，而仅仅展示类型的名称。这也意味着在.NET Core中的System.Type不再包括GetMembers()等API，但仍然会暴露Name等API。

通过一个名为GetTypeInfo的扩展方法，可以得到在一般情况下能够从Type对象中获取的信息。TypeInfo类所包含的信息没有原来那么丰富，但微软最近决定在.NET Core中重新引入一部分反射API，这部分变更是超出原先计划之外的。

为了使代码更容易进行移植，.NET 4.5及之后的版本提供了对TypeInfo的某种支持，它与在.NET Core中使用的版本相类似。

App Domain

App Domain在CoreCLR中得以实现，但没有在.NET Native中实现。由于对App Domain的实现需要大量的运行时特性支持，因此目前还没有任何对它的支持计划。“对于代码的隔离，我们建议通过进程或容器实现。而对于程序集的动态加载，我们建议使用新的AssemblyLoadContext类。”

Remoting

现如今，已经很少有开发者还能够记起Remoting库的存在，更不要说如何使用它了。即使还有人在使用，他们也一直在抱怨它的性能、高复杂性以及总体表现的脆弱性。

如今，多个.NET应用在同一台机器上的通信基本都被WCF所取代，后者能够带来更好的性能，可用于管道或内存映射文件。对于跨机器的通信，微软推荐“使用一种低开销的纯文本协议，例如HTTP”。因此，微软并没有在.NET Core中支持Remoting的计划。

序列化

.NET Core将支持大多数序列化器，例如数据契约序列化、XML序列化、JSON.NET以及protobuf-net。而一个被排除在外的重要角色是二进制序列化。

通过这十年来的经验，我们终于了解到序列化是一项非常复杂的任务，支持序列化的类型在兼容性方面要面对沉重的负担。因此，我们已经决定让序列化成为一种协议，它将在可用的公开API的基础上实现。然而，二进制序列化的实现需要对类型本身的深入了解，因为这种方式可以对整个对象图进行序列化，甚至包括私有的状态信息。

沙箱

从理论上说，沙箱是一种优秀的思想，它允许部分信任代码以安全的方式执行。但在实践中，要想正确地应用它非常困难，哪怕是一点点微小的错误，也会导致安全性方面的漏洞。Immo Landwerth还表示，它“使实现变得更加困难，并且经常会给未使用沙箱的应用的性能带来负面影响。”

推荐的替代方案是使用独立的进程，通过一个具有有限权限的用户帐号运行这些进程。通过这种方式，运行时不必重复进行一些开销较大的权限检查工作，因为操作系统已经为你完成了这方面的任务。

其他组件

微软正考虑将下表中列举的组件进行开源，并移植到.NET Core。

• System.Data。虽然它的基础层功能，即提供者模型与SQL client 已经成为了.NET Core的一部分，但某些特性目前仍不可用，例如对于schema、DataTable和DataSet的支持。

• System.DirectoryServices。.NET Core目前并不支持通过该组件与LDAP或活动目录进行通信。

• System.Drawing。虽然从严格意义上来说，它应该属于一种客户端API，但还是有大量开发者在服务端通过绘图API实现缩略图或水印的生成。我们目前还不支持在.NET Core中使用这些API。

• System.Transactions。虽然ADO.NET支持事务，但并不包括对于分布式事务的支持，后者包括氛围事务（ambient transaction）及资源征集（enlistment）的概念。

• System.Xml.Xsl与System.Xml.Schema。.NET Core支持XmlDocument以及由Linq引入的XDocument，包括XPath在内。不过，目前还不支持XSD（XmlSchema）及XSLT（XslTransform）。

• System.Net.Mail。目前还不支持在.NET Core中通过这些API实现电子邮件的发送。

• System.IO.Ports。.NET Core目前还不支持与串行化端口的通信。

• System.Workflow。Windows Workflow Foundation（WF）目前在.NET Core中尚不可用。

• System.Xaml。在开发UWP应用时，开发者将使用WinRT XAML API。因此，.NET Core目前并不支持托管XAML框架，后者包括解析XAML、并实例化描述对象图的功能。

你是否有兴趣帮助我们移植某个组件？.NET Framework实现的部分源代码已经通过MIT许可进行了开源，作为Reference Source的一部分。我们正在设法让社区能够对我们的移植工作提供支持。如果你愿意参与这一项目，请发送邮件至[e-mail]。

英文原文：http://www.infoq.com/news/2016/02/Core-Discontinued

3

Angular发布1.5正式版，专注于向Angular 2的过渡

Angular团队最近发布了Angular 1.5的正式版，该版本实现了一次重大的升级，它让仍在使用1.X版本的开发者将能够更容易地过渡到Angular 2的开发。

Pete Bacon Darwin在此次发布声明的博客文章中写道，这次发布的目的是“改进Angular 2的升级路径。我们在这次发布中引入了一些新的特性，让开发者编写的Angular 1应用更接近于在Angular 2中应用的结构。”

此次发布中，新的module.component()辅助方法是向Angular 2进行过渡的最大变更。通过使用该方法，开发者就不必再遵循传统的directive定义对象风格编写directive了。如果读者已经熟悉Angular 2的写法，就应当注意到这种相似性。在文章中，作者通过一个示例表现了定义一个新component的方法：

myModule.component('myComponent', {  template: '<h1>Hello {{ $ctrl.getFullName() }}</h1>',  bindings: { firstName: '<', lastName: '<' },  controller: function() {    this.getFullName = function() {      return this.firstName + ' ' + this.lastName;    };  } });

在component出现之前，开发者通常只能使用directive，或是通过对controller的非常规使用才能够实现某些场景。但这并不是说component就将完全取代directive的作用了，比方说component就无法用于操作DOM，并且所有的component都必须通过自定义的HTML元素激活，而不支持通过元素的属性触发。按照以上方式定义的component可通过以下代码使用：

<my-component first-name="'Alan'" last-name="'Rickman'"></my-component>

新的component指南对于传统的directive与component之间的区别提供了更完整的说明。

• 单向绑定

• 生命周期钩子

• 绑定至必需的directive

• 支持多个slot的transclusion

• 默认transclusion内容

目前在使用1.4版本的开发者可以阅读迁移指南以了解迁移时需要进行哪些必要的变更，因为1.5版本中引入了一些破坏性的变更。

在可预见的一段时间内，1.5版本应当是最大的一次变更了。当InfoQ向Bacon Darwin问及1.X版本将何去何从时，他是这样回答的：

我们还没有开始计划Angular 1的下一次发布周期。由于离Angular 2正式发布的日期已经越来越近了，因此如果我们继续开发Angular 1，那么也会尽量使它更接近于Angular 2。如果为了实现这一点而必须引入破坏性的变更，那么可以预计1.6版本的出现。同时，我们还将继续Angular 1.5.x版本的开发，提供bug的修复以及一些较小的特性。总之，这与我们让Angular 1.X更易于迁移至Angular 2的目标并不冲突。

新的component router特性应当在本周的稍晚时间发布。

英文原文：http://www.infoq.com/news/2016/02/angular-1-5-released

---

本文系InfoQ原创首发，未经授权谢绝转载。

InfoQ原创翻译编辑&技术编辑招募中，简历快砸来：[e-mail]