八、预制（Prefab）
这个单独提出来，是因为它太常用了。也是Unity 的核心要素之一。原本Unity中的一个物体是你拖拽一个模型到场景中，或者创建一个几何体，或者灯光地形等，然后设置这个物体的偏移、旋转和缩放。然后绑定好脚本，设置好参数。如果想要第二个相同物体的话，复制一份。但是问题来了，如果有一个问题需要这n个物体都进行修改，那么就要操作n遍。这个时候预制就体现出威力了，你可以拖拽场景中的物体到下方的资源浏览窗口中，这样一个新的预制居创建出来了。场景中的n个物体都是通过预制创建的，那么直接修改预制，场景中的这些物体就都会相应的进行改变。同样，修改完场景中的属性，然后点击属性窗口中的Apply按钮，预制也会被修改。唯一例外的组件是Transform组件，它不会被预制修改。除此之外的其他组件，包括脚本配置的参数都会被修改。
可以简单的理解为预制就是一个配置文件，记录了物体和相关的配置参数。而很多时候，我也确实拿它来做脚本配置，比如实现技能系统的时候，每个技能都是一个预制，给它绑定好对应的脚本，配置好技能参数，然后游戏中释放技能的时候实例化这个预制就可以了。
之前有一个问题一直困扰着我，我想要预制支持这样一个功能，它其中的参数可以序列化到场景文件中，但是又不会受到Apply按钮的影响。这样我就可以方便的把一个预制拖动到场景中，复制n份，分别做场景编辑的配置，而且不用担心我一不小心点了Apply按钮把所有的场景全玩砸了。 不过现在想来，这个功能完全可以不用预制来实现，扩展一下菜单功能直接生成并组装好物体就可以了。
总之，Unity中尽量使用预制来加载模型和其他资源，而不要直接使用，这个是一个正确的思路和方向。非常方便，并且易于维护。
九、文件系统和AssetsBundle
既然讲到Prefab了，就顺带把Unity的文件系统也讲解一下。
在手游兴起之前，Unity特长是页游开发，这个是虚幻等引擎不具备的功能。文件打包系统和AssetsBundle就是其中重要的一环。
Unity游戏运行的是一个场景，默认会加载一个场景，代码中可以通过Application.LoadLevel来加载其他场景。游戏运行时只会存在一个场景，加载一个新的场景，旧的场景资源会被释放掉。当然Application.LoadLevelAdditive可以把一个场景添加到当前场景上。每个脚本都可以使用DontDestroyOnLoad函数，声明当前对象不会在场景加载的时候被销毁掉，常用于单例模式。
Unity打包游戏资源的时候会根据当前场景中依赖的资源进行筛选，没有被使用到的资源是不会被打包的。图片被打包的时候还会根据配置进行纹理压缩，这个功能非常方便而且强大，借助于这个功能，你不需要各个平台维护一套资源，Unity自动帮助你搞定了。 当然Unity把转化后的文件缓存起来了，所以切换平台的时候这些文件会重新压缩一遍。所以我建议一个平台checkout一份工程，这样就可以避免多平台切换时的时间消耗了。
Unity导出后的资源命名为level(N)和sharedassets(N).assets，你不能直接读取一个文件，所有文件必须存在于场景中，或者是被场景中的某一个物件的脚本引用到。
这种模式在制作简单的游戏或者小游戏的时候很方便，但是游戏大了就力不从心了。我们实际游戏开发中大多数碰到的还是动态加载的情况。比如我现在的游戏就只有一个场景，里面只存放了几个简单的管理类。所有需要的界面、场景都是运行时动态加载的。这个时候我们需要把资源（更确切的说是预制，Unity会自动根据依赖关系进行资源查找和打包）放到Resources文件夹下。放到这个文件夹下的资源无论场景有没有使用到都会被导出，并且代码中可以使用Resources.Load("文件路径")来加载这个物件。加载好物件后再通过Instantiate函数实例化这个对象，然后就可以正常使用了。
最后再说一说AssetsBundle，这个也是一个小的文件系统。我们为了减少安装包的体积，或者是为了自动更新资源，必须要使用AssetsBundle来打包资源。我们可以通过扩展编辑器来写一个ExportResource的函数，将指定的文件打包成AssetsBundle，然后可以将这个包放到服务器上面，游戏运行的时候动态下载并加载。可以说一个mmo的实现必然要使用到这个功能。它是对Unity相对封闭的文件系统的一个开放接口。
十、物件属性的配置和编辑器扩展
这个是非常出彩的功能，借助于反射机制，这个功能无比的便捷和强大。你只要写一个脚本，然后添加一个public的变量，然后就可以在编辑器中设置这个值了。当然Unity只识别内建类型，自己定义的类要加上[System.Serializable]来声明。
Unity的编辑器扩展功能非常强大，你可以轻易的重写属性窗口中的显示内容和显示方式，也可以添加一个按钮来实现某个特殊功能。Unity 的内建GUI最大的用途就是这里了。
十一、关于Editor文件夹的说明
如果你看下Unity自动生成的vs工程，会发现工程数目有可能会达到七八个。 Unity所有编辑器相关的脚本文件都要放到Editor文件夹下面（是不是根目录无所谓，只要名字叫Editor就可以了），这些文件会单独生成一个Unity-Editor的工程。所有包含UnityEditor的代码只能在编辑器模式下运行，不能发布到windows或者android上面。
（第三部分是关于Unity 功能的，第四部分就到了实际游戏解决方案的部分了）