unity开发的基本逻辑（个人理解）
自己瞎学unity，一直没绕过这个弯来，现在大概理解了，不知道为什么没有任何一篇教程解释这个概念，我把我自己的理解大概讲一下，轻喷。首先，unity里一切看得见摸得着的东西，一切载体，都是"gameObject"，我们可以叫它“游戏体”。
相机、画布、按钮、事件系统，都是一个单独的“游戏体”。
然后，赋予游戏体功能的，是它的"Component"，也就是“组件”。比如咱们给一个按钮挂上脚本组件，它才是有内容的按钮，给一个画布挂上缩放组件，它才能缩放 。
进而，一个“游戏体”的“变量”或是功能，虽然是“组件”赋予的，但是所有这些变量或是功能仍旧存放在它的“组件”里，而不是说它挂载了组件之后它自己就获得了这些变量和功能，比如一个小怪的血量，这个时候这个小怪是一个游戏体，而它有一个脚本组件。这个时候，它的血量，一直是存在于它的脚本组件的，而不是因为它的脚本提供了“血量”这个变量，这个游戏体它*自己*就具有“血量”这个属性。它的“血量”永远存在于它的脚本组件。
打个比方就是我们，人，是一个游戏体，手机是我们的一个组件，手机赋予了收发短信的功能，但是短信是存在手机里的，而不是我们*自己*身体里。这也就是为什么从一个“游戏体”取得它的“方法或是变量或者其他内容”时需要取得它的“组件”。就像你想从我这获得我的短信，需要得到我的手机而不是我本人。
这是逻辑一，“游戏体”是一切载体，“组件”赋予“游戏体”功能但这些功能和属性仍旧存在于“组件”上。
接着是逻辑二，关于实例化的问题。
首先明确一个基本概念，脚本定义的类本身是一个“概念的集合”，就是说脚本里的内容并不实际发生，而是这个类“全部都可以发生什么”。而实例化，则是创造一个遵循这个类的实际存在，这个实际存在会根据类对它的定义去执行它的行动。打个比方，“人类”是一个“概念的集合”，“人类”会吃饭，会睡觉，但是在“人类.cs”里吃饭和睡觉并没有发生，因为没有产生实例，而“你”和“我”则是“人类”的实例，“你”和“我”会根据“人类.cs”的定义去吃饭和睡觉。
在基于这个概念之后，让我们来厘清“实例化”的问题，这就是之前困扰我的，到底什么是“实例化”，为什么说“实例化”之后就会创造一个“东西”去运行脚本的内容。
对于unity的语境里，每一次“实例化”都会创造一个“游戏体”，也就是说“游戏体”就是实例化产生的那个“脚本的实例”。
这里我举个实际例子：
在Camera_S类下，我定义了一个提前做好的游戏体"gg"，
而后我在它的每帧方法里让它创建gg的实例，在开始运行前，
可以看到"层级"(H什么那个词)里只有一个提前做好的GameObject，而在运行后，
可以看到每帧都创建了一个GameObject的复制体。
也就是说我的“实例化”语句创造了这个GameObject。
然后，这也就解释了我一直以来的疑问，“为什么我之前从来没有创建过实例，但是却可以运行那些脚本？”
这是因为，在开始运行之前，我们在编辑器里进行操作，产生的那些游戏体，
都是实例。
只是这些实例不是经过我们自己写的“实例化”语句产生的，但是所有游戏运行以后才能知道该怎么创建的游戏体则必须经由脚本去创建 。
也就是说在unity里，“实例”就是“游戏体”，“实例化”会创建“游戏体”，“游戏体”是“组件”的载体，“组件”提供实际的功能。挂载同一个脚本的不同“游戏体”已经是不同的“实例”了，进而它们的变量可以不同，"gameObject1.A"和"gameObject2.A"已经不是一个东西了。
这是逻辑二。
我之前一直不理解“实例化”这个概念，最主要就是因为首先我不理解“游戏体”就是“实例”，所以我一度以为我之前在编辑器内完成的操作跟“实例化”和“获取组件”毫无关系，但是实际上我就是通过编辑器去提前完成了这些步骤 。
页:
[1]