Unity3D研究院之手游开发中所有特殊的文件夹

这里列举出手游开发中用到了所有特殊文件夹。

1.Editor

Editor文件夹可以在根目录下,也可以在子目录里,只要名子叫Editor就可以。比如目录:/xxx/xxx/Editor  和 /Editor 是一样的,无论多少个叫Editor的文件夹都可以。Editor下面放的所有资源文件或者脚本文件都不会被打进发布包中,并且脚本也只能在编辑时使用。一般呢会把一些工具类的脚本放在这里,或者是一些编辑时用的DLL。 比如我们现在要做类似技能编辑器,那么编辑器的代码放在这里是再好不过了,因为实际运行时我们只需要编辑器生成的文件,而不需要编辑器的核心代码。

2.Editor Default Resources

Editor Default Resources注意中间是有空格的,它必须放在Project视图的根目录下,如果你想放在/xxx/xxx/Editor Default Resources 这样是不行的。你可以把编辑器用到的一些资源放在这里,比如图片、文本文件、等等。它和Editor文件夹一样都不会被打到最终发布包里,仅仅用于开发时使用。你可以直接通过EditorGUIUtility.Load去读取该文件夹下的资源。

3.Gizmos

我觉得这个文件夹其实没什么用处,如下代码所示它可以在Scene视图里给某个坐标绘制一个icon。它的好处是可以传一个Vecotor3 作为图片显示的位置。 参数2就是图片的名子,当然这个图片必须放在Gizmos文件夹下面。

如果只想挂在某个游戏对象身上,那么在Inspecotr里面就可以直接设置。。


这里还是要说说OnDrawGizmos()方法,只要脚本继承了MonoBehaviour后,并且在编辑模式下就会每一帧都执行它。发布的游戏肯定就不会执行了,它只能用于在scene视图中绘制一些小物件。比如要做摄像机轨迹,那么肯定是要在Scene视图中做一个预览的线,那么用Gizmos.DrawLine 和Gizmos.DrawFrustum就再好不过了。

4.Plugins

如果做手机游戏开发一般 andoird 或者 ios 要接一些sdk 可以把sdk依赖的库文件 放在这里,比如 .so .jar .a 文件。这样打完包以后就会自动把这些文件打在你的包中。

5.Resources

可以在根目录下,也可以在子目录里,只要名子叫Resources就可以。比如目录:/xxx/xxx/Resources  和 /Resources 是一样的,无论多少个叫Resources的文件夹都可以。Resources文件夹下的资源不管你用还是不用都会被打包进.apk或者.ipa

Resource.Load :编辑时和运行时都可以通过Resource.Load来直接读取。

Resources.LoadAssetAtPath() :它可以读取Assets目录下的任意文件夹下的资源,它可以在编辑时或者编辑器运行时用,它但是它不能在真机上用,它的路径是”Assets/xx/xx.xxx” 必须是这种路径,并且要带文件的后缀名。

AssetDatabase.LoadAssetAtPath():它可以读取Assets目录下的任意文件夹下的资源,它只能在编辑时用。它的路径是”Assets/xx/xx.xxx” 必须是这种路径,并且要带文件的后缀名。

我觉得在电脑上开发的时候尽量来用Resource.Load() 或者 Resources.LoadAssetAtPath() ,假如手机上选择一部分资源要打assetbundle,一部分资源Resource.Load().那么在做.apk或者.ipa的时候 现在都是用脚本来自动化打包,在打包之前 可以用AssetDatabase.MoveAsset()把已经打包成assetbundle的原始文件从Resources文件夹下移动出去在打包,这样打出来的运行包就不会包行多余的文件了。打完包以后再把移动出去的文件夹移动回来。

6. StreamingAssets

这个文件夹下的资源也会全都打包在.apk或者.ipa 它和Resources的区别是,Resources会压缩文件,但是它不会压缩原封不动的打包进去。并且它是一个只读的文件夹,就是程序运行时只能读 不能写。它在各个平台下的路径是不同的,不过你可以用Application.streamingAssetsPath 它会根据当前的平台选择对应的路径。

有些游戏为了让所有的资源全部使用assetbundle,会把一些初始的assetbundle放在StreamingAssets目录下,运行程序的时候在把这些assetbundle拷贝在Application.persistentDataPath目录下,如果这些assetbundle有更新的话,那么下载到新的assetbundle在把Application.persistentDataPath目录下原有的覆盖掉。

因为Application.persistentDataPath目录是应用程序的沙盒目录,所以打包之前是没有这个目录的,直到应用程序在手机上安装完毕才有这个目录。

StreamingAssets目录下的资源都是不压缩的,所以它比较大会占空间,比如你的应用装在手机上会占用100M的容量,那么你又在StreamingAssets放了一个100M的assetbundle,那么此时在装在手机上就会在200M的容量。




--------------------------------------------


1.隐藏文件夹
以.开头的文件夹会被Unity忽略。在这种文件夹中的资源不会被导入,脚本不会被编译。也不会出现在Project视图中。
2.Standard Assets
在这个文件夹中的脚本最先被编译。
这个文件夹中的脚本会被导出到Assembly-CSharp-firstpass, Assembly-UnityScript-firstpass 或 Assembly-Boo-firstpass项目中,依语言而定。参考http://docs.unity3d.com/Documentation/Manual/ScriptCompileOrderFolders.html 。在这个文件夹中的脚本比其他脚本都要先编译。将脚本放在这个文件夹里,就可以用C#脚本来访问js脚本或其他语言的脚本。
3.Pro Standard Assets
跟Standard Assets相同,只不过里面的文件是给Pro版本的Unity使用的。
4.Editor
以Editor命名的文件夹允许其中的脚本访问Unity Editor的API。如果脚本中使用了在UnityEditor命名空间中的类或方法,它必须被放在名为Editor的文件夹中。Editor文件夹中的脚本不会在build时被包含。
在项目中可以有多个Editor文件夹。
注意:如果在普通的文件夹下,Editor文件夹可以处于目录的任何层级。如果在特殊文件夹下,那Editor文件夹必须是特殊文件夹的直接子目录。
5.Plugins
Plugins文件夹用来放native插件。它们会被自动包含进build中去。注意这个文件夹只能是Assets文件夹的直接子目录。
在Windows平台下,native 插件是dll文件;Mac OS X下,是bundle文件;Linux下,是.so文件。
跟Standard Assets一样,这里的脚本会更早的编译,允许它们被之外的脚本访问。
5.1.Plugins/x86
如果为32bit或64bit平台创建游戏,那么这个文件夹下的native plugin文件会被自动的包含在游戏build中。如果这个文件夹不存在,则Unity会查找Plugins文件夹下的native pluglins。
5.2.Plugins/x86_64
如果为32bit或64bit平台创建游戏,那么这个文件夹下的native plugin文件会被自动的包含在游戏build中。如果这个文件夹不存在,则Unity会查找Plugins文件夹下的native pluglins。


如果要创建universal build,建议你同时使用这两个文件夹。然后将32bit和64bit的native plugins放进相应的文件夹中。
5.3.Plugins/Android
在这个文件夹里放入Java.jar文件。用于java语言的plugins。.so文件也会被包含进来。参考http://docs.unity3d.com/Documentation/Manual/PluginsForAndroid.html
5.4.Plugins/iOS
A limited, simple way to automatically add (as symbolic links) any .a, .m, .mm, .c, or .cpp files into the generated Xcode project. Seehttp://docs.unity3d.com/Documentation/Manual/PluginsForIOS.html
If you need more control how to automatically add files to the Xcode project, you should make use of the PostprocessBuildPlayer feature. Doing so does not require you to place such files in the Plugins/iOS folder. Seehttp://docs.unity3d.com/Documentation/Manual/BuildPlayerPipeline.html


6.Resources
Resources文件夹允许你在脚本中通过文件路径和名称来访问资源。但还是推荐使用直接引用来访问资源。
放在这一文件夹的资源永远被包含进build中,即使它没有被使用。因为Unity无法判断脚本有没有访问了其中的资源。
项目中可以有多个Resources文件夹,因此不建议在多个文件夹中放同名的资源。
一旦build游戏,Resources文件夹中的所有资源被打包进游戏存放资源的archive中。这样在游戏的build中就不存在Resources文件夹了。即使脚本中仍然使用了资源在项目中的路径。参考http://docs.unity3d.com/Documentation/Manual/LoadingResourcesatRuntime.html
注意:当资源作为脚本变量被访问时,这些资源在脚本被实例化后就被加载进内存。如果资源太大,你可能不希望它被这样加载。那么你可以将这些大资源放进Resources文件夹中,通过Resources.Load来加载。当不再使用这些资源了,可以通过Destroy物体,再调用Resources.UnloadUnusedAssets来释放内存。
7.Editor Default Resources
这是为editor 脚本使用的文件夹。
8.Gizmos
Gizmos文件夹存放用Gizmos.DrawIcon方法使用的贴图、图标资源。放在Gizmos文件夹中的贴图资源可以直接通过名称使用,可以被Editor作为gizmo画在屏幕上。
9.WebPlayerTemplates
用来替换web build的默认网页。这个文件夹中的脚本都不会被编译。这个文件夹必须作为Assets文件夹的直接子目录。
10.StreamingAssets
这里的文件会被拷贝到build文件夹中,不会修改(移动和网页版不同,他们会被嵌入到最终build文件中)。它们的路径会因平台而有差异,但都可以通过Application.streamingAssetsPath来访问。
参考http://docs.unity3d.com/Documentation/Manual/StreamingAssets.html和http://docs.unity3d.com/Documentation/ScriptReference/Application-streamingAssetsPath.html。


参考文献:http://wiki.unity3d.com/index.php/Special_Folder_Names_in_your_Assets_Folder



我们在Unity3D开发的时候,经常会看到它会产生不少固定命名工程文件,诸如:

Assembly-CSharp-vs.csproj 
Assembly-CSharp-firstpass-vs.csproj

Assembly-CSharp-Editor-vs.csproj

Assembly-CSharp-Editor-firstpass-vs.csproj

看得不少人云里雾里的。那么,这些工程是如何产生的呢?各自的作用是什么?下面就来逐一解析。


一. 首先从脚本语言类型来看,Unity3D支持3种脚本语言,都会被编译成CLI的DLL

如果应用中含有C#脚本,那么Unity3D会产生以Assembly-CSharp为前缀的工程,名字中包含"vs的"是产生给Visual Studio使用的,不包含"vs"的是产生给MonoDevelop用的。

应用中包含的脚本语言

工程前缀

工程后缀

C#

Assembly-CSharp

csproj

JavaScript

Assembly-UnityScript

unityproj

Boo

Assembly-Boo

booproj


如果工程中这3中脚本都存在,那么Unity3D将会生成3种前缀类型的工程。


二. 对于每一种脚本语言,根据脚本放置的位置(其实也部分根据了脚本的作用,比如编辑器扩展脚本,就必须放在Editor文件夹下),Unity3D会生成4种后缀的工程。其中的firstPass就表示先编译,Editor表示放在Editor文件夹下的脚本。

下面以C#脚本为例。如果工程中只有C#脚本,不考虑为VS和MonoDevelop各自生成工程的差异性,我们可以得到4个工程文件:

Assembly-CSharp-firstpass-vs.csproj

Assembly-CSharp-Editor-firstpass-vs.csproj

Assembly-CSharp-vs.csproj 

Assembly-CSharp-Editor-vs.csproj

(1) 所有在Standard Assets,Pro Standard Assets或者 Plugins文件夹中的脚本会产生一个Assembly-CSharp-firstpass-vs.csproj文件,并且先编译;

(2) 所有在Standard Assets/Editor, Pro Standard Assets/Editor 或这Plugins/Editor文件夹中的脚本产生Assembly-CSharp-Editor-firstpass-vs.csproj工程,接着编译;

(3) 所有在Assets/Editor外面的, 并且不在(1),(2)中的脚本文件(一般这些脚本就是我们自己写的非编辑器扩展的脚本)会产生Assembly-CSharp-vs.csproj工程,被编译;

(4) 所以在Assets/Editor中的脚本产生一个Assembly-CSharp-Editor-vs.csproj工程,被编译。

之所有这样建立工程并按此顺序编译,也是因为DLL间存在的依赖关系所决定的。


好了,至此也说得比较清楚了,也不会因为见到那么多的工程文件而疑惑了。

最后问诸位一个小问题:

一个Unity3D的工程,最多可以产生多少个工程文件?

4*3*2 = 24个



你可能感兴趣的:(商业技术,Unity3D,c#,unity3d,mono,.net,特殊文件夹)