告别UnityScript，Unity将仅支持C#脚本编程

UnityScript是Unity中类似于JavaScript的脚本语言，从Unity 1.0开始伴随至今，终于迎来了告别之旅。我们已经开始逐步弃用UnityScript，仅保留C#作为Unity脚本编程语言。

目前仅有3.6%的Unity项目重度使用UnityScript脚本语言进行开发，持续维护UnityScript将影响Unity对新脚本功能的支持，所以我们决定将弃用UnityScript。

弃用UnityScript原因

每次Unity决定放弃支持一些功能，都会先了解这些决定可能会为用户带来的不便。所以确保这些决定有其值得进行的理由对我们来说也至关重要。Unity脚本编程正在经历重大升级，其中一些重要功能包括：

• 脚本运行时升级，支持使用.NET 4.6与C# 6；

• JobSystem，支持轻松编写多线程代码，且避免竞争条件与死锁；

• NativeArray类型，支持创建及使用大型数组，它们拥有原生代码控制的存储区域，以便于对内存分配行为拥有更多控制权，从而不必再担心垃圾回收机制；

• 支持控制脚本编译管线，以便自定义将哪些脚本整合进程序集。

上述内容仅仅是一小部分，我们还将继续支持一些脚本新功能，并计划开展一些脚本项目。除了这些项目之外，我们也正利用最为合适的语言结构，更多地开放引擎底层API。

目前UnityScript与C#在功能与性能方面不相上下，C#可以实现的内容使用UnityScript也能达到同样的效果。而谈到开发生态，显然C#是赢家，不仅仅是因为C#教程与示例比比皆是，还有C#语言丰富的工具集，例如Visual Studio提供的代码重构与智能提示。可能这些工具目前还不足以成为C#取代UnityScript的理由，但这仅仅是目前。

技术总是不断发展的，随着我们升级脚本运行时并支持最新的C#版本，会出现一些使用C#轻而易举但UnityScript无法轻易实现或者不支持的内容。目前UnityScript就不支持为方法参数提供默认值，并且C#语言支持的功能越来越多，例如返回引用等，都是问题。目前我们暂未在API中使用这些功能，但出于性能与API结构设计考虑，我们也希望尽快利用这些新功能。

当然，也可以选择花时间来弥补UnityScript所欠缺的功能，但要持续维护UnityScript，就意味着该开发者无法进行其它工作，例如添加新功能或修复Bug等。这还不包括在脚本更新器中支持UnityScript需要的工作，以及相应的文档更新工作等等。

所以不如换个方向思考，如果弃用UnityScript，有多少用户会被影响呢？Unity编辑器会定期发送Unity项目相关数据，包括项目所使用的脚本类型与使用频率，我们可以据此统计出正在使用UnityScript的项目。统计结果如下：

• 截止目前使用Unity 5.6的项目中，包含至少一个.js文件的项目占14.6%。这个比例看起来相当高，但进一步分析数据，看看各项目中.js文件与总文件数（.js文件 + .cs文件）占比，会有新发现。

• 也就是说，85.4%的Unity项目完全使用C#语言，根本不包含UnityScript脚本。

• 9.5%的Unity项目大量使用C#语言，其中也包含一些UnityScript脚本，但脚本数量占脚本总数不足10%。还有1.5%的Unity项目所包含的UnityScript脚本占项目脚本总数在10～20%之间。

• 3.6%的Unity项目使用UnityScript语言的脚本占脚本总数20%以上。

• 仅有0.8%的Unity项目完全使用UnityScript。

以上数据表明，大量Unity开发者都没有重度使用UnityScript。甚至项目所包含的UnityScript也并非实际使用的脚本，可能只是资源商店某个插件的示例代码，对实际项目并无影响。所以我们弃用UnityScript计划的第一步，就是从资源商店发行商着手，移除所有插件中的UnityScript脚本。

对于那3.6%较多使用UnityScript的Unity项目，以及那些0.8%完全使用UnityScript的项目，我们表示很抱歉。我们明白这样的决定会对您产生影响，我们正采取一些措施来尝试让整个转换过程更加流畅，也希望大家能够理解并支持我们所做出的决定。

弃用计划

我们会逐步弃用UnityScript而非一刀切。主要计划步骤如下：

首先，从6月开始我们已经修订了Asset Store资源商店的插件提交条款，拒绝接受包含UnityScript代码的插件。所有新提交至资源商店的插件都必须使用C#代码（在执行此项规定前我们已与资源商店发行商进行讨论与沟通）。很快我们将会对资源商店的现有插件进行代码扫描，查看其中是否包含UnityScript文件，如果有则通知发行商将代码转换为C#。一段时间后，代码未转换为C#的插件将从资源商店下架。

其次，您可能已经注意到了，Unity 2017.2测试版的Create Assets菜单下已经不再包含Javascript（即UnityScript）选项。目前我们仅移除了此菜单项，Unity编辑器仍然支持UnityScript，您仍然可以从编辑器之外创建UnityScript文件（例如MonoDevelop）。这么做的原因是保证新用户不会继续使用UnityScript，以免浪费大家的学习成本。

另外，我们已经在开发UnityScript自动转换为C#的工具。目前该工具已有些成果，但仍在完善中。我们暂未决定是否将该工具集成到Unity编辑器，或单独开源提供。无论以何种方式，该工具都会在今年年底Unity 2017.2正式发布时供大家使用。后续也会单独介绍该工具，请大家保持关注。

最后，我们也将持续关注分析数据，并希望所有Unity项目可以尽快切换至C#，尤其是UnityScript脚本数量少于10%的那部分项目，需要移植的代码较少。但如果开发者无法完全弃用UnityScript，我们会暂停弃用计划并调查无法移植的原因。在彻底弃用UnityScript之前，我们将确保不遗漏任何重要信息。

在确认UnityScript使用率足够低之后，我们将不再支持UnityScript编译器，并且不再将.js文件识别为脚本代码。我们也会从文档中移除UnityScript代码示例，并且脚本更新器将不再支持UnityScript。

如果有需要，仍可从Unity的GitHub中下载UnityScript编译器，我们不会接受任何推送请求，但您可以创建自己的分支以实现您的需求。

关于Boo

我们在2014年宣布放弃在编辑器与文档中支持Boo语言。但Boo编译器仍存在与编辑器中，因为UnityScript用到了Boo的运行库，并且UnityScript编译器本身就是用Boo语言编写的。您仍可在Unity项目中使用.boo文件。

在取消支持UnityScript之后，也就意味着会移除Boo编译器。目前所有使用Unity 5.6的项目中仅有0.2%包含了.boo文件，仅有0.006%的项目拥有3个以上.boo文件。我们再次表示抱歉，但这也是必然之势。

结语

我们希望能够清楚了解弃用功能将为大家带来的所有影响，所以会依照这样的流程：通知大家我们的计划，推动资源商店插件与编辑器UI更新，最后基于实际使用率的数据来决定是否执行。

弃用某个功能看起来就像是退步，但这也是提高Unity开发效率的必经之路。我们希望集中精力为大家尽快修复现有问题并提供新功能，也希望大家能够理解并支持我们的决定。

推荐阅读

近期Unity官方活动

8月24日，Unity技术路演将来到湖南长沙，为当地开发者们带来最新Unity 2017功能演示与技术干货分享，Unity Ads广告服务详解以及VR Workshop开发教学。长沙的小伙伴们，快来报名吧：https://www.bagevent.com/event/760274

8月26日，2017年首次Unity技术开放日将在羊城广州正式开启，届时Unity官方技术团队及特邀嘉宾将为大家带来内容充实的Unity 2017技术干货分享，以及VR Workshop开发教学！广州的小伙伴们把握机会，赶快报名参与此次Unity技术开放日吧：https://www.bagevent.com/event/764254

点击“阅读原文”进入Unity官方中文社区！