小心 Unity 中的那些特殊名称
5.00/5 (5投票s)
小心 Unity 中的那些特殊名称
偶尔，你会意识到一个简单的事实：所有工具都有其自身的方式和方法，每个工具都有一些小技巧，如果不知道这些小技巧，可能会在意想不到的地方让你栽跟头，Unity 也是如此。
Unity 是一个非常强大的引擎和工具，但要掌握它，你必须了解它的工作原理、哪些方法行不通以及应该避免什么。
正如那句老话所提醒的
“能力越大，责任越大”
（而且很可能你会因此经常撞到低矮的门框上）
那些简单的事实之一就涉及到你在脚本和代码中给事物命名的规则（*你的类名，而不是属性或枚举*），我将在下面解释。
名字的意义？
仅使用 Unity 几分钟后，你应该清楚，有些名字是你根本不能用于 Unity 中的事物，最明显的例子是
- MonoBehaviour – 因为几乎所有东西都是 MonoBehaviour
- 基类型，如
Vector2、Point、Canvas– 因为 Unity 已经有了这些东西，虽然你可以使用它们，但你将无法获得基类的功能 - 保留名称 – 基本上是 Unity 命名空间内的任何名称。试试创建一个自己的“
UnityEngine”类，看看会发生什么！
还有更多，Unity 通常会在你做一些它认为愚蠢或不恰当的事情时预先警告你。
然而，对于你构建的平台，情况并非如此…… Unity 也会检查那些吗？
答案是，很遗憾，不。
你可以拥有任何你想要的颜色，只要它是红色
这一切的起因是，我当时正在帮助一家工作室（这也是我通常做的事情），测试他们的项目，并支持他们构建 Windows 10 UWP 版本（一次构建目标多个平台，太好了）。
在他们项目的编译版本中出现了一个错误，该错误表现为以下两种方式之一：
- 一个非常有帮助的加载项目问题，并伴随以下错误：“对象引用未设置为一个对象实例”（这信息量很小）
- 项目打开时没有问题，但构建时，你会突然被大量的错误信息淹没
– “类没有名为 x 的属性” 或
– “无法隐式转换类型 X 到 Y”
在这种情况下，我正在测试，开发者创建了一个名为“SplashScreen”的类（这似乎相当无害），然而，当你深入挖掘时，你会发现 Unity 和 Microsoft 平台都已经拥有一个名为 SplashScreen 的类型。Unity 能够在内部构建中处理自己的类型，确保项目中的 SplashScreen 类版本与 Unity 的 SplashScreen 版本不同（很可能是通过使用不同的命名空间）。然而，当涉及到平台构建时，你项目中使用的类将覆盖平台使用的类。
如果你测试了，它们就会出现
因此，让我们测试一下，以便在这种情况发生时你能更好地做好准备。据我所知，这只影响所有现代 Windows 平台，因为它们可以直接完全访问 Unity 项目（对于 .NET 项目来说这是一个非常有用的功能），尽管这也会影响你编写的任何被平台使用的插件（除非你遵循下一节中的步骤）。
为了重现这个问题，只需尝试以下操作：
- 创建一个新的空白项目
- 创建一个名为
SplashScreen的新脚本 - 将项目构建为任何“Windows 应用商店”平台
- 在 Visual Studio 或 MonoDevelop 中打开构建的项目
看，没有任何错误。现在，构建它。
你将看到一系列与 SplashScreen 类相关的错误，因为项目现在认为你的项目中的类应该优先于平台保留的类型。
那么，你不应该使用哪些名字？
现在，我已经进行了一些测试，但并不算非常广泛，所以我将列出我测试过并发现问题的名称。
如果你发现更多，请在下方评论，我会将其添加到列表中。
- 控件，而该控件又负责动画。
- App
- Application
- Window
- UnityPlayer (这个让我感到惊讶，因为 Unity 本身并没有警告不要使用它)
如果你知道更多，请随时在下方评论。
如何完全避免这个问题
需要注意的是，这会影响你基础项目中定义的任何类或类型。避免这些麻烦的一个简单方法是在你的类中使用自己的命名空间，这意味着你的代码不会与任何同名的其他代码或类型混淆（除了你自己的 
）。
要了解更多关于使用命名空间的信息，请查看 Unity Learn 网站上的这些参考资料：
- https://docs.unity3d.org.cn/Manual/Namespaces.html – 手册中关于命名空间的参考，包含一个基本示例
- https://unity3d.com/learn/tutorials/modules/intermediate/scripting/namespaces – 关于使用命名空间的学习视频
保持安全，编码愉快！