Unity 告别 UnityScript，未来将只支援 C#

[ShikiSuen]

作者: Richard Fine，润稿: Kelvin Lo

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 类型，支援建立及使用大型阵列，它们拥有原生程式控制的存储区域，以便于对记忆体分配拥有更多控制权，不必再担心 GC 回收机制
• 支援控制脚本编译，以便自订将哪些脚本整合进程式集

这些只是一小部分，我们还将继续支援一些新功能，并计划开启一些脚本专案。除了这些专案之外，我们也正利用最为合适的语言结构，来开放更多引擎底层 API。

目前 UnityScript 与 C# 在功能与效能不相上下，当然 C# 可以实现的内容 UnityScript 也能达到同样的效果。但说到开发生态，显然 C# 是赢家，不仅仅是因为 C# 教学与范例网路上到处都是，C# 语言也有丰富的工具，例如 Visual Studio 提供的代码重构与智慧提示。或许你会质疑 Unity Script 可以用就好了，也不需要那么多花俏的工具。

技术永远是不断发展的，随着我们升级执行核心支援最新的 C# 版本时，就会出现一些 C# 简单实现但 UnityScript 无法轻易实现或者不支援的功能。比如说目前 UnityScript 就不支援为方法参数（ method parameters ）提供预设值，并且 C# 语言支援的功能越来越多，例如 ref return 等都会造成同样问题。目前我们暂未在 API 中使用这些功能，但出于效能与 API 结构设计考虑，我们也希望赶快让这些新功能上线。

或者我们也可以选择花时间来弥补 UnityScript 所欠缺的功能，但时间成本昂贵，把时间花在维护 UnityScript 就代表无法进行其它工作，好比加新功能或修 Bug 等。这还不包括在执行核心中支援 UnityScript 需要的工作，以及文件制作更新工作等等。

所以我们换了个方向思考，如果弃用 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 也并非实际使用的脚本，可能只是 Asset Store 某个套件的范例程式，对实际专案并无影响。所以我们弃用 UnityScript 计划的第一步，就是从 Asset Store 开发者着手，先移除所有发布套件里的 UnityScript 脚本。

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

弃用计划

当然我们会一步一步舍弃 UnityScript，而不是一刀切断。主要计划步骤如下：

首先，从 6 月开始我们已经修订了 Asset Store 的套件审核条款，拒绝接受程式有包含 UnityScript 代码的套件。所有新送审的套件都必须使用 C# 程式（在执行此项规定前我们已与开发者有过许多讨论与沟通）。很快我们将会对 Asset Store 现有的套件进行检查，如果有 UnityScript 则会通知发行商将程式码转为 C#。如果一段时间后程式没转换为 C#，套件将会从 Asset Store 下架。

再来，可能你已经注意到了，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 编译器，不再将. js 档识别为脚本。也会从文档中移除 UnityScript 程式范例，脚本更新器也将不再支援 UnityScript。

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

关于 Boo

在历史纪录上 Unity 曾在 2014 年宣布放弃支援 Boo 语言。但 Boo 编译器仍存在现在的编辑器中，只因为 UnityScript 会用到了 Boo 的执行库，并且 UnityScript 编译器本身就是用 Boo 语言编写的。所以虽然我们没提但你仍可在 Unity 专案中使用. boo 文件。

但是剥离 UnityScript 支援之后，就代表 Boo 编译器也会被移除。目前所有使用 Unity 5.6 的专案中仅有 0.2% 的专案包含了. boo 档，仅有 0.006% 的专案拥有 3 个以上. boo 档案。

结论

希望本篇文章有清楚解释了弃用 UnityScript 将会为大家带来的影响，我们会依照流程：通知大家我们的计划 -> 推动 Asset Store 套件与编辑器 UI 更新，最后依照实际使用率的分析资料来决定是否执行。

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

原译文转载自 BlogSpot。由於 BlogSpot 在大陆无法访问，所以全文转载了过来。