a*原理 unity3d
2016-10-18 18:24:05 qq563129582 阅读数 1381

一些资料:

IL

IL是.NET框架中中间语言(Intermediate Language)的缩写。使用.NET框架提供的编译器可以直接将源程序编译为.exe或.dll文件,但此时编译出来的程序代码并不是CPU能直接执行的机器代码,而是一种中间语言IL(Intermediate Language)

优点:

使用中间语言的优点有两点,一是可以实现平台无关性,既与特定CPU无关;二是只要把.NET框架某种语言编译成IL代码,就实现.NET框架中语言之间的交互操作(这就是为什么unity3D里面可以c#和js混编)。(《C#程序设计及应用教程》(第2版),马骏 主编)
 
 
相关词条:

Xamarin

Xamarin(现以被微软收购)是mono项目的一个分支,但这里面最大的区别Xamarin是商业项目.mono做为跨平台的框架已得到越来越多的商业项目的肯定,令外界担心的版权问题\可靠性\稳定性也得到证实,使用mono最大的好处是可以使用其它平台众多的项目解决方案,而不必被限制在windows平台下贫乏而又昂贵的各种解决方案.

在Mac OS上,因为iOS的现有限制,面向iOS的C#代码会通过AOT编译技术直接编译为ARM汇编代码。而在Android上,应用程序会转换为IL,启动时再进行JIT编译。


Mono在Full AOT模式下的限制

调试时遇到一个Mono运行时异常:

ExecutionEngineException: Attempting to JIT compile method '...' 
while running with --aot-only.

 最后发现原因是使用了泛型接口,导致Mono需要JIT编译,但在iOS平台中,Mono是以Full AOT模式运行的,无法使用JIT引擎,于是引发了这个异常。

        Mono的AOT和.NET的Ngen一样,都是通过提前编译来减少JIT的工作,但默认情况下AOT并不编译所有IL代码,而是在优化和JIT之间取得一个平衡。由于iOS平台禁止JIT编译,于是Mono在iOS上需要Full AOT编译和运行。即预先对程序集中的所有IL代码进行AOT编译生成一个本地代码映像,然后在运行时直接加载这个映像而不再使用JIT引擎。目前由于技术或实现上的原因在使用Full AOT时有一些限制,具体可以参考MonoTouch的文档,这里提几条常见的:

  • 不支持泛型虚方法,因为对于泛型代码,Mono通过静态分析以确定要实例化的类型并生成代码,但静态分析无法确定运行时实际调用的方法(C++也因此不支持虚模版函数)。

  • 不支持对泛型类的P/Invoke。

  • 目前不能使用反射中的Property.SetInfo给非空类型赋值。

  • 值类型作为Dictionary的Key时会有问题,实际上实现了IEquatable<T>的类型都会有此问题,因为Dictionary的默认构造函数会使用EqualityComparer<TKey>.Default作为比较器,而对于实现了IEquatable<T>的类型,EqualityComparer<TKey>.Default要通过反射来实例化一个实现了IEqualityComparer<TKey>的类(可以参考EqualityComparer<T>的实现)。 解决方案是自己实现一个IEqualityComparer<TKey>,然后使用Dictionary<TKey, TValue>(IEqualityComparer<TKey>)构造器创建Dictionary实例。

  • 由于不允许动态生成代码,不允许使用System.Reflection.Emit,不允许动态创建类型。

  • 由于不允许使用System.Reflection.Emit,无法使用DLR及基于DLR的任何语言。

  • 不要混淆了Reflection.Emit和反射,所有反射的API均可用

JIT和AOT:

JIT:http://en.wikipedia.org/wiki/Just-in-time_compilation

AOT:http://en.wikipedia.org/wiki/AOT_compiler

http://www.mono-project.com/AOT


2014-11-13 18:31:00 weixin_34403693 阅读数 15

知乎的一个提问:unity3d跨平台原理

 

一些资料:

IL

IL是.NET框架中中间语言(Intermediate Language)的缩写。使用.NET框架提供的编译器可以直接将源程序编译为.exe或.dll文件,但此时编译出来的程序代码并不是CPU能直接执行的机器代码,而是一种中间语言IL(Intermediate Language)

优点:

使用中间语言的优点有两点,一是可以实现平台无关性,既与特定CPU无关;二是只要把.NET框架某种语言编译成IL代码,就实现.NET框架中语言之间的交互操作(这就是为什么unity3D里面可以c#和js混编)。(《C#程序设计及应用教程》(第2版),马骏 主编)
 
 
相关词条:

Xamarin

Xamarin(现以被微软收购)是mono项目的一个分支,但这里面最大的区别Xamarin是商业项目.mono做为跨平台的框架已得到越来越多的商业项目的肯定,令外界担心的版权问题\可靠性\稳定性也得到证实,使用mono最大的好处是可以使用其它平台众多的项目解决方案,而不必被限制在windows平台下贫乏而又昂贵的各种解决方案.

在Mac OS上,因为iOS的现有限制,面向iOS的C#代码会通过AOT编译技术直接编译为ARM汇编代码。而在Android上,应用程序会转换为IL,启动时再进行JIT编译。

 

 

Mono在Full AOT模式下的限制

调试时遇到一个Mono运行时异常:

1
2
ExecutionEngineException: Attempting to JIT compile method '...' 
while running with --aot-only.

        最后发现原因是使用了泛型接口,导致Mono需要JIT编译,但在iOS平台中,Mono是以Full AOT模式运行的,无法使用JIT引擎,于是引发了这个异常。

        Mono的AOT和.NET的Ngen一样,都是通过提前编译来减少JIT的工作,但默认情况下AOT并不编译所有IL代码,而是在优化和JIT之间取得一个平衡。由于iOS平台禁止JIT编译,于是Mono在iOS上需要Full AOT编译和运行。即预先对程序集中的所有IL代码进行AOT编译生成一个本地代码映像,然后在运行时直接加载这个映像而不再使用JIT引擎。目前由于技术或实现上的原因在使用Full AOT时有一些限制,具体可以参考MonoTouch的文档,这里提几条常见的:

  • 不支持泛型虚方法,因为对于泛型代码,Mono通过静态分析以确定要实例化的类型并生成代码,但静态分析无法确定运行时实际调用的方法(C++也因此不支持虚模版函数)。

  • 不支持对泛型类的P/Invoke。

  • 目前不能使用反射中的Property.SetInfo给非空类型赋值。

  • 值类型作为Dictionary的Key时会有问题,实际上实现了IEquatable<T>的类型都会有此问题,因为Dictionary的默认构造函数会使用EqualityComparer<TKey>.Default作为比较器,而对于实现了IEquatable<T>的类型,EqualityComparer<TKey>.Default要通过反射来实例化一个实现了IEqualityComparer<TKey>的类(可以参考EqualityComparer<T>的实现)。 解决方案是自己实现一个IEqualityComparer<TKey>,然后使用Dictionary<TKey, TValue>(IEqualityComparer<TKey>)构造器创建Dictionary实例。

  • 由于不允许动态生成代码,不允许使用System.Reflection.Emit,不允许动态创建类型。

  • 由于不允许使用System.Reflection.Emit,无法使用DLR及基于DLR的任何语言。

  • 不要混淆了Reflection.Emit和反射,所有反射的API均可用

 

JIT和AOT:

JIT:http://en.wikipedia.org/wiki/Just-in-time_compilation

AOT:http://en.wikipedia.org/wiki/AOT_compiler

http://www.mono-project.com/AOT

 

 

2015-03-27 10:13:20 skylin19840101 阅读数 3922

前言:

其实小匹夫在U3D的开发中一直对U3D的跨平台能力很好奇。到底是什么原理使得U3D可以跨平台呢?后来发现了Mono的作用,并进一步了解到了CIL的存在。所以,作为一个对Unity3D跨平台能力感兴趣的U3D程序猿,小匹夫如何能不关注CIL这个话题呢?那么下面各位看官就拾起语文老师教导我们的作文口诀(WhyWhatHow),和小匹夫一起走进CIL的世界吧~

Why?

回到本文的题目,U3D或者说Mono的跨平台是如何做到的?

如果换做小匹夫或者看官你来做,应该怎么实现一套代码对应多种平台呢?

其实原理想想也简单,生活中也有很多可以参考的例子,比如下图(谁让小匹夫是坐移动端开发的呢,只能物尽其用从自己身边找例子了T.T):

像这样一根线,管你是安卓还是ios都能充电。所以从这个意义上,这货也实现了跨平台。那么我们能从它身上学到什么呢?对的,那就是从一样的能源(电)到不同的平台(ios,安卓)之间需要一个中间层过度转换一下。

那么来到U3D为何能跨平台,简而言之,其实现原理在于使用了叫CIL(Common Intermediate Language通用中间语言,也叫做MSIL微软中间语言)的一种代码指令集,CIL可以在任何支持CLI(Common Language Infrastructure,通用语言基础结构)的环境中运行,就像.NET是微软对这一标准的实现,Mono则是对CLI的又一实现。由于CIL能运行在所有支持CLI的环境中,例如刚刚提到的.NET运行时以及Mono运行时,也就是说和具体的平台或者CPU无关。这样就无需根据平台的不同而部署不同的内容了。所以到这里,各位也应该恍然大了。代码的编译只需要分为两部分就好了嘛:

  1. 从代码本身到CIL的编译(其实之后CIL还会被编译成一种位元码,生成一个CLI assembly)
  2. 运行时从CIL(其实是CLI assembly,不过为了直观理解,不必纠结这种细节)到本地指令的即时编译(这就引出了为何U3D官方没有提供热更新的原因:在iOS平台中Mono无法使用JIT引擎,而是以Full AOT模式运行的,所以此处说的额即时编译不包括IOS

What?

上文也说了CIL是指令集,但是不是还是太模糊了呢?所以语文老师教导我们,描述一个东西时肯定要先从外貌写起。遵循老师的教导,我们不妨先通过工具来看看CIL到底长什么样。

工具就是ilasm了。下面小匹夫写一个简单的.cs看看生成的CIL代码长什么样。

C#代码:

class Class1
{
    public static void Main(string[] args)
    {
        System.Console.WriteLine("hi");
    }
}

CIL代码:

.class private auto ansi beforefieldinit Class1
       extends [mscorlib]System.Object
{
  .method public hidebysig static void  Main(string[] args) cil managed
  {
    .entrypoint
    // 代码大小       13 (0xd)
    .maxstack  8
    IL_0000:  nop
    IL_0001:  ldstr      "hi"
    IL_0006:  call       void [mscorlib]System.Console::WriteLine(string)
    IL_000b:  nop
    IL_000c:  ret
  } // end of method Class1::Main

  .method public hidebysig specialname rtspecialname 
          instance void  .ctor() cil managed
  {
    // 代码大小       7 (0x7)
    .maxstack  8
    IL_0000:  ldarg.0
    IL_0001:  call       instance void [mscorlib]System.Object::.ctor()
    IL_0006:  ret
  } // end of method Class1::.ctor

} // end of class Class1

好啦。代码虽然简单,但是也能说明足够多的问题。那么和CIL的第一次亲密接触,能给我们留下什么直观的印象呢?

  1. 以“.”一个点号开头的,例如上面这份代码中的:.class、.method 。我们称之为CIL指令(directive),用于描述.NET程序集总体结构的标记。为啥需要它呢?因为你总得告诉编译器你处理的是啥吧。
  2. 貌似CIL代码中还看到了private、public这样的身影。姑且称之为CIL特性(attribute)。它的作用也很好理解,通过CIL指令并不能完全说明.NET成员和类,针对CIL指令进行补充说明成员或者类的特性的。市面上常见的还有:extends,implements等等。
  3. 每一行CIL代码基本都有的,对,那就是CIL操作码咯。小匹夫从网上找了一份汉化的操作码表放在附录部分,当然英文版的你的vs就有。

直观的印象有了,但是离我们的短期目标,说清楚(或者说介绍个大概)CIL是What,甚至是终极目标,搞明白Uniyt3D为何能跨平台还有2万4千9百里的距离。

好啦,话不多说,继续乱侃。

参照附录中的操作码表,对照可以总结出一份更易读的表格。那就是如下的表啦。

主要操作 操作数范围/条件 操作数类型 操作数
缩写 全称 含义 缩写 全称 含义 缩写 全称 含义 缩写 全称 含义
ld load 将操作数压到堆栈当中,相当于:
push ax
arg argument 参数 ? ? 操作数中的数值 .0 ? 第零个参数 
.1 ? 第一个参数
.2 ? 第二个参数
.3 ? 第三个参数
.s xx (short) 参数xx
a address 操作数的地址 只有 .s xx,参见ldarg.s
loc local 局部变量 参见ldarg
fld field 字段(类的全局变量) 参见ldarg xx ? xx字段,eg:
ldfld xx
c const 常量 .i4 int 4 bytes C#里面的int,其他的类型例如short需要通过conv转换 .m1 minus 1 -1
.0 ? 0
.1 ? 1
……
.8   8
.s (short) 后面跟一个字节以内的整型数值(有符号的)
? ? 后面跟四个字节的整型数值
.i8 int 8 bytes C#里面的long ? ? 后面跟八个字节的整型数值
.r4 real 4 bytes C#里面的float ? ? 后面跟四个字节的浮点数值
.r8 real 8 bytes C#里面的double ? ? 后面跟八个字节的浮点数值
null null 空值(也就是0) ? ? ? ? ? ?
st store 计算堆栈的顶部弹出当前值,相当于:
pop ax
参见ld 
conv convert 数值类型转换,仅仅用纯粹的数值类型间的转换,例如int/float等 ? ? ? .i1 int 1 bytes C#里面的sbyte ? ? ?
.i2 int 2 bytes C#里面的short
.i4 int 4 bytes C#里面的int
.i8 int 8 bytes C#里面的long
.r4 real 4 bytes C#里面的float
.r8 real 8 bytes C#里面的double
.u4 uint 4 bytes C#里面的uint
.u8 uint 8 bytes C#里面的ulong
b/br branch 条件和无条件跳转,相当于:
jmp/jxx label_jump
br ? ? 无条件跳转 ? ? ? ? ? 后面跟四个字节的偏移量(有符号)
.s (short) 后面跟一个字节的偏移量(有符号)
false false 值为零的时候跳转 ? ? ? 参见br
true true 值不为零的时候跳转 ? ? ?
b eq equal to 相等 ? ? ?
ne not equal to 不相等 un unsigned or unordered 无氟好的(对于整数)或者无序的(对于浮点)
gt greater than 大于
lt less than 小于
ge greater than or equal to 大于等于
le less than or equal to 小于等于
call call 调用 ? ? ? ? ? (非虚函数) ?
? ? ? virt virtual 虚函数

在此,小匹夫想请各位认真读表,然后心中默数3个数,最后看看都能发现些什么。

基于堆栈

如果是小匹夫的话,第一感觉就是基本每一条描述中都包含一个”栈“。不错,CIL是基于堆栈的,也就是说CIL的VM(mono运行时)是一个栈式机。这就意味着数据是推入堆栈,通过堆栈来操作的,而非通过CPU的寄存器来操作,这更加验证了其和具体的CPU架构没有关系。为了说明这一点,小匹夫举个例子好啦。

大学时候学单片机(大概是8086,记不清了)的时候记得做加法大概是这样的:

add eax,-2

其中的eax是啥?寄存器。所以如果CIL处理数据要通过cpu的寄存器的话,那也就不可能和cpu的架构无关了。

当然,CIL之所以是基于堆栈而非CPU的另一个原因是相比较于cpu的寄存器,操作堆栈实在太简单了。回到刚才小匹夫说的大学时候曾经学过的单片机那门课程上,当时记得各种寄存器,各种标志位,各种。。。,而堆栈只需要简单的压栈和弹出,因此对于虚拟机的实现来说是再合适不过了。所以想要更具体的了解CIL基于堆栈这一点,各位可以去看一下堆栈方面的内容。这里小匹夫就不拓展了。

面向对象

那么第二感觉呢?貌似附录的表中有new对象的语句呀。嗯,的确,CIL同样是面向对象的。

这意味着什么呢?那就是在CIL中你可以创建对象,调用对象的方法,访问对象的成员。而这里需要注意的就是对方法的调用。

回到上表中的右上角。对,就是对参数的操作部分。静态方法和实例方法是不同的哦~

  1. 静态方法:ldarg.0么有被占用,所以参数从ldarg.0开始。
  2. 实例方法:ldarg.0是被this占用的,也就是说实际上的参数是从ldarg.1开始的。

举个例子:假设你有一个类Murong中有一个静态方法Add(int32 a, int32 b),实现的内容就如同它的名字一样使两个数相加,所以需要2个参数。和一个实例方法TellName(string name),这个方法会告诉你传入的名字。

class  Murong
{
    public void TellName(string name)
    {
        System.Console.WriteLine(name);
    }

    public static int Add(int a, int b)
    {
       return a + b;
    }
}

静态方法的处理:

那么其中的静态方法Add的CIL代码如下:

//小匹夫注释一下。
.method public hidebysig static int32  Add(int32 a,
                                           int32 b) cil managed
{
  // 代码大小       9 (0x9)
  .maxstack  2
  .locals init ([0] int32 CS$1$0000)   //初始化局部变量列表。因为我们只返回了一个int型。所以这里声明了一个int32类型。索引为0
  IL_0000:  nop
  IL_0001:  ldarg.0     //将索引为 0 的参数加载到计算堆栈上。
  IL_0002:  ldarg.1     //将索引为 1 的参数加载到计算堆栈上。
  IL_0003:  add          //计算
  IL_0004:  stloc.0      //从计算堆栈的顶部弹出当前值并将其存储到索引 0 处的局部变量列表中。
  IL_0005:  br.s       IL_0007
  IL_0007:  ldloc.0     //将索引 0 处的局部变量加载到计算堆栈上。
  IL_0008:  ret           //返回该值
} // end of method Murong::Add

那么我们调用这个静态函数应该就是这样咯。

Murong.Add(1, 2);

对应的CIL代码为:

  IL_0001:  ldc.i4.1 //将整数1压入栈中
  IL_0002:  ldc.i4.2 //将整数2压入栈中
  IL_0003:  call       int32 Murong::Add(int32,
                                         int32)  //调用静态方法

可见CIL直接call了Murong的Add方法,而不需要一个Murong的实例。

实例方法的处理:

Murong类中的实例方法TellName()的CIL代码如下:

.method public hidebysig instance void  TellName(string name) cil managed
{
  // 代码大小       9 (0x9)
  .maxstack  8
  IL_0000:  nop
  IL_0001:  ldarg.1     //看到和静态方法的区别了吗?
  IL_0002:  call       void [mscorlib]System.Console::WriteLine(string)
  IL_0007:  nop
  IL_0008:  ret
} // end of method Murong::TellName

看到和静态方法的区别了吗?对,第一个参数对应的是ldarg.1中的参数1,而不是静态方法中的0。因为此时参数0相当于this,this是不用参与参数传递的。

那么我们再看看调用实例方法的C#代码和对应的CIL代码是如何的。

//C#
Murong murong = new Murong(); murong.TellName("chenjiadong");

CIL:

.locals init ([0] class Murong murong)   //因为C#代码中定义了一个Murong类型的变量,所以局部变量列表的索引0为该类型的引用。
//....
IL_0009:  newobj     instance void Murong::.ctor() //相比上面的静态方法的调用,此处new一个新对象,出现了instance方法。
IL_000e:  stloc.0
IL_000f:  ldloc.0
IL_0010:  ldstr      "chenjiadong" //小匹夫的名字入栈
IL_0015:  callvirt   instance void Murong::TellName(string) //实例方法的调用也有instance

到此,受制于篇幅所限(小匹夫不想写那么多字啊啊啊!)CIL是What的问题大致介绍一下。当然没有再拓展,以后小匹夫可能会再详细写一下这块。

How?

记得语文老师说过,写作文最重要的一点是要首尾呼应。既然咱们开篇就提出了U3D为何能跨平台的问题,那么接近文章的结尾咱们就再来

提问:

Q:上面的Why部分,咱们知道了U3D能跨平台是因为存在着一个能通吃的中间语言CIL,这也是所谓跨平台的前提,但是为啥CIL能通吃各大平台呢?当然可以说CIL基于堆栈,跟你CPU怎么架构的没啥关系,但是感觉过于理论化、学术化,那还有没有通俗化、工程化的说法呢?

A:原因就是前面小匹夫提到过的,.Net运行时和Mono运行时。也就是说CIL语言其实是运行在虚拟机中的,具体到咱们的U3D也就是mono的运行时了,换言之mono运行的其实CIL语言,CIL也并非真正的在本地运行,而是在mono运行时中运行的,运行在本地的是被编译后生成的原生代码。当然看官博的文章,他们似乎也在开发自己的“mono”,也就是被称为脚本的未来的IL2Cpp,这种类似运行时的功能是将IL再编译成c++,再由c++编译成原生代码,据说效率提升很可观,小匹夫也是蛮期待的。

这里为了“实现跨平台式的演示”,小匹夫用mac给各位做个测试好啦:

从C#到CIL

新建一个cs文件,然后使用mono来运行。这个cs文件内容如下:

然后咱们直接在命令行中运行这个cs文件试试~

说的很清楚,文件没有包含一个CIL映像。可见mono是不能直接运行cs文件的。假如我们把它编译成CIL呢?那么我们用mono带的mcs来编译小匹夫的Test.cs文件。

mcs Test.cs

生成了什么呢?如图:

好像没见有叫.IL的文件生成啊?反而好像多了一个.exe文件?可是没听说Mac能运行exe文件呀?可为啥又生成了.exe呢?各位看官可能要说,小匹夫你是不是拿windows截图P的啊?嘿嘿,小匹夫可不敢。辣么真相其实就是这个exe并不是让Mac来运行的,而是留给mono运行时来运行的,换言之这个文件的可执行代码形式是CIL的位元码形态。到此,我们完成了从C#到CIL的过程。接下来就让我们运行下刚刚的成果好啦。

1
mono Test.exe

 

结果是输出了一个大大的“Hi”。这里,就引出了下一个部分。

从CIL到Native Code

这个“HI”可是在小匹夫的MAC终端上出现的呀,那么就证明这个C#写的代码在MAC上运行的还挺“嗨”。

为啥呢?为啥C#写的代码能跑在MAC上呢?这就不得不提从CIL如何到本机原生代码的过程了。Mono提供了两种编译方式,就是我们经常能看到的:JIT(Just-in-Time compilation,即时编译)和AOT(Ahead-of-Time,提前编译或静态编译)。这两种方式都是将CIL进一步编译成平台的原生代码。这也是实现跨平台的最后一步。下面就分头介绍一下。

JIT即时编译:

从名字就能看的出来,即时编译,或者称之为动态编译,是在程序执行时才编译代码,解释一条语句执行一条语句,即将一条中间的托管的语句翻译成一条机器语句,然后执行这条机器语句。但同时也会将编译过的代码进行缓存,而不是每一次都进行编译。所以可以说它是静态编译和解释器的结合体。不过你想想机器既要处理代码的逻辑,同时还要进行编译的工作,所以其运行时的效率肯定是受到影响的。因此,Mono会有一部分代码通过AOT静态编译,以降低在程序运行时JIT动态编译在效率上的问题。

不过一向严苛的IOS平台是不允许这种动态的编译方式的,这也是U3D官方无法给出热更新方案的一个原因。而Android平台恰恰相反,Dalvik虚拟机使用的就是JIT方案。

AOT静态编译:

其实Mono的AOT静态编译和JIT并非对立的。AOT同样使用了JIT来进行编译,只不过是被AOT编译的代码在程序运行之前就已经编译好了。当然还有一部分代码会通过JIT来进行动态编译。下面小匹夫就手动操作一下mono,让它进行一次AOT编译。

//在命令行输入
mono --aot Test.exe

结果:

从图中可以看到JIT time: 39 ms,也就是说Mono的AOT模式其实会使用到JIT,同时我们看到了生成了一个适应小匹夫的MAC的动态库Test.exe.dylib,而在Linux生成就是.so(共享库)。

AOT编译出来的库,除了包括我们的代码之外,还有被缓存的元数据信息。所以我们甚至可以只编译元数据信息而不变异代码。例如这样:

//只包含元数据的信息
mono --aot=metadata-only Test.exe

可见代码没有被包括进来。

那么简单总结一下AOT的过程:

  1. 收集要被编译的方法
  2. 使用JIT进行编译
  3. 发射(Emitting)经JIT编译过的代码和其他信息
  4. 直接生成文件或者调用本地汇编器或连接器进行处理之后生成文件。(例如上图中使用了小匹夫本地的gcc)

Full AOT

当然上文也说了,IOS平台是禁止使用JIT的,可看样子Mono的AOT模式仍然会保留一部分代码会在程序运行时动态编译。所以为了破解这个问题,Mono提供了一个被称为Full AOT的模式。即预先对程序集中的所有CIL代码进行AOT编译生成一个本地代码映像,然后在运行时直接加载这个映像而不再使用JIT引擎。目前由于技术或实现上的原因在使用Full AOT时有一些限制,不过这里不再多说了。以后也还会更细的分析下AOT。

 

总结:

好啦,写到现在也已经到了凌晨3:04分了。感觉写的内容也差不多了。那么对本文的主题U3D为何能跨平台以及CIL做个最终的总结陈词:

  1. CIL是CLI标准定义的一种可读性较低的语言。
  2. 以.NET或mono等实现CLI标准的运行环境为目标的语言要先编译成CIL,之后CIL会被编译,并且以位元码的形式存在(源代码--->中间语言的过程)。
  3. 这种位元码运行在虚拟机中(.net mono的运行时)。
  4. 这种位元码可以被进一步编译成不同平台的原生代码(中间语言--->原生代码的过程)。
  5. 面向对象
  6. 基于堆栈

如果各位看官觉得文章写得还好,那么就容小匹夫跪求各位给点个“推荐”,谢啦~

装模作样的声明一下:本博文章若非特殊注明皆为原创,若需转载请保留原文链接http://www.cnblogs.com/murongxiaopifu/p/4211964.html及作者信息慕容小匹夫

附录:

名称 说明
Add 将两个值相加并将结果推送到计算堆栈上。
Add.Ovf 将两个整数相加,执行溢出检查,并且将结果推送到计算堆栈上。
Add.Ovf.Un 将两个无符号整数值相加,执行溢出检查,并且将结果推送到计算堆栈上。
And 计算两个值的按位“与”并将结果推送到计算堆栈上。
Arglist 返回指向当前方法的参数列表的非托管指针。
Beq 如果两个值相等,则将控制转移到目标指令。
Beq.S 如果两个值相等,则将控制转移到目标指令(短格式)。
Bge 如果第一个值大于或等于第二个值,则将控制转移到目标指令。
Bge.S 如果第一个值大于或等于第二个值,则将控制转移到目标指令(短格式)。
Bge.Un 当比较无符号整数值或不可排序的浮点型值时,如果第一个值大于第二个值,则将控制转移到目标指令。
Bge.Un.S 当比较无符号整数值或不可排序的浮点型值时,如果第一个值大于第二个值,则将控制转移到目标指令(短格式)。
Bgt 如果第一个值大于第二个值,则将控制转移到目标指令。
Bgt.S 如果第一个值大于第二个值,则将控制转移到目标指令(短格式)。
Bgt.Un 当比较无符号整数值或不可排序的浮点型值时,如果第一个值大于第二个值,则将控制转移到目标指令。
Bgt.Un.S 当比较无符号整数值或不可排序的浮点型值时,如果第一个值大于第二个值,则将控制转移到目标指令(短格式)。
Ble 如果第一个值小于或等于第二个值,则将控制转移到目标指令。
Ble.S 如果第一个值小于或等于第二个值,则将控制转移到目标指令(短格式)。
Ble.Un 当比较无符号整数值或不可排序的浮点型值时,如果第一个值小于或等于第二个值,则将控制转移到目标指令。
Ble.Un.S 当比较无符号整数值或不可排序的浮点值时,如果第一个值小于或等于第二个值,则将控制权转移到目标指令(短格式)。
Blt 如果第一个值小于第二个值,则将控制转移到目标指令。
Blt.S 如果第一个值小于第二个值,则将控制转移到目标指令(短格式)。
Blt.Un 当比较无符号整数值或不可排序的浮点型值时,如果第一个值小于第二个值,则将控制转移到目标指令。
Blt.Un.S 当比较无符号整数值或不可排序的浮点型值时,如果第一个值小于第二个值,则将控制转移到目标指令(短格式)。
Bne.Un 当两个无符号整数值或不可排序的浮点型值不相等时,将控制转移到目标指令。
Bne.Un.S 当两个无符号整数值或不可排序的浮点型值不相等时,将控制转移到目标指令(短格式)。
Box 将值类转换为对象引用(O 类型)。
Br 无条件地将控制转移到目标指令。
Br.S 无条件地将控制转移到目标指令(短格式)。
Break 向公共语言结构 (CLI) 发出信号以通知调试器已撞上了一个断点。
Brfalse 如果 value 为 false、空引用(Visual Basic 中的 Nothing)或零,则将控制转移到目标指令。
Brfalse.S 如果 value 为 false、空引用或零,则将控制转移到目标指令。
Brtrue 如果 value 为 true、非空或非零,则将控制转移到目标指令。
Brtrue.S 如果 value 为 true、非空或非零,则将控制转移到目标指令(短格式)。
Call 调用由传递的方法说明符指示的方法。
Calli 通过调用约定描述的参数调用在计算堆栈上指示的方法(作为指向入口点的指针)。
Callvirt 对对象调用后期绑定方法,并且将返回值推送到计算堆栈上。
Castclass 尝试将引用传递的对象转换为指定的类。
Ceq 比较两个值。如果这两个值相等,则将整数值 1 (int32) 推送到计算堆栈上;否则,将 0 (int32) 推送到计算堆栈上。
Cgt 比较两个值。如果第一个值大于第二个值,则将整数值 1 (int32) 推送到计算堆栈上;反之,将 0 (int32) 推送到计算堆栈上。
Cgt.Un 比较两个无符号的或不可排序的值。如果第一个值大于第二个值,则将整数值 1 (int32) 推送到计算堆栈上;反之,将 0 (int32) 推送到计算堆栈上。
Ckfinite 如果值不是有限数,则引发 ArithmeticException。
Clt 比较两个值。如果第一个值小于第二个值,则将整数值 1 (int32) 推送到计算堆栈上;反之,将 0 (int32) 推送到计算堆栈上。
Clt.Un 比较无符号的或不可排序的值 value1 和 value2。如果 value1 小于 value2,则将整数值 1 (int32 ) 推送到计算堆栈上;反之,将 0 ( int32 ) 推送到计算堆栈上。
Constrained 约束要对其进行虚方法调用的类型。
Conv.I 将位于计算堆栈顶部的值转换为 native int。
Conv.I1 将位于计算堆栈顶部的值转换为 int8,然后将其扩展(填充)为 int32。
Conv.I2 将位于计算堆栈顶部的值转换为 int16,然后将其扩展(填充)为 int32。
Conv.I4 将位于计算堆栈顶部的值转换为 int32。
Conv.I8 将位于计算堆栈顶部的值转换为 int64。
Conv.Ovf.I 将位于计算堆栈顶部的有符号值转换为有符号 native int,并在溢出时引发 OverflowException。
Conv.Ovf.I.Un 将位于计算堆栈顶部的无符号值转换为有符号 native int,并在溢出时引发 OverflowException。
Conv.Ovf.I1 将位于计算堆栈顶部的有符号值转换为有符号 int8 并将其扩展为 int32,并在溢出时引发 OverflowException。
Conv.Ovf.I1.Un 将位于计算堆栈顶部的无符号值转换为有符号 int8 并将其扩展为 int32,并在溢出时引发 OverflowException。
Conv.Ovf.I2 将位于计算堆栈顶部的有符号值转换为有符号 int16 并将其扩展为 int32,并在溢出时引发 OverflowException。
Conv.Ovf.I2.Un 将位于计算堆栈顶部的无符号值转换为有符号 int16 并将其扩展为 int32,并在溢出时引发 OverflowException。
Conv.Ovf.I4 将位于计算堆栈顶部的有符号值转换为有符号 int32,并在溢出时引发 OverflowException。
Conv.Ovf.I4.Un 将位于计算堆栈顶部的无符号值转换为有符号 int32,并在溢出时引发 OverflowException。
Conv.Ovf.I8 将位于计算堆栈顶部的有符号值转换为有符号 int64,并在溢出时引发 OverflowException。
Conv.Ovf.I8.Un 将位于计算堆栈顶部的无符号值转换为有符号 int64,并在溢出时引发 OverflowException。
Conv.Ovf.U 将位于计算堆栈顶部的有符号值转换为 unsigned native int,并在溢出时引发 OverflowException。
Conv.Ovf.U.Un 将位于计算堆栈顶部的无符号值转换为 unsigned native int,并在溢出时引发 OverflowException。
Conv.Ovf.U1 将位于计算堆栈顶部的有符号值转换为 unsigned int8 并将其扩展为 int32,并在溢出时引发 OverflowException。
Conv.Ovf.U1.Un 将位于计算堆栈顶部的无符号值转换为 unsigned int8 并将其扩展为 int32,并在溢出时引发 OverflowException。
Conv.Ovf.U2 将位于计算堆栈顶部的有符号值转换为 unsigned int16 并将其扩展为 int32,并在溢出时引发 OverflowException。
Conv.Ovf.U2.Un 将位于计算堆栈顶部的无符号值转换为 unsigned int16 并将其扩展为 int32,并在溢出时引发 OverflowException。
Conv.Ovf.U4 将位于计算堆栈顶部的有符号值转换为 unsigned int32,并在溢出时引发 OverflowException。
Conv.Ovf.U4.Un 将位于计算堆栈顶部的无符号值转换为 unsigned int32,并在溢出时引发 OverflowException。
Conv.Ovf.U8 将位于计算堆栈顶部的有符号值转换为 unsigned int64,并在溢出时引发 OverflowException。
Conv.Ovf.U8.Un 将位于计算堆栈顶部的无符号值转换为 unsigned int64,并在溢出时引发 OverflowException。
Conv.R.Un 将位于计算堆栈顶部的无符号整数值转换为 float32。
Conv.R4 将位于计算堆栈顶部的值转换为 float32。
Conv.R8 将位于计算堆栈顶部的值转换为 float64。
Conv.U 将位于计算堆栈顶部的值转换为 unsigned native int,然后将其扩展为 native int。
Conv.U1 将位于计算堆栈顶部的值转换为 unsigned int8,然后将其扩展为 int32。
Conv.U2 将位于计算堆栈顶部的值转换为 unsigned int16,然后将其扩展为 int32。
Conv.U4 将位于计算堆栈顶部的值转换为 unsigned int32,然后将其扩展为 int32。
Conv.U8 将位于计算堆栈顶部的值转换为 unsigned int64,然后将其扩展为 int64。
Cpblk 将指定数目的字节从源地址复制到目标地址。
Cpobj 将位于对象(&、* 或 native int 类型)地址的值类型复制到目标对象(&、* 或 native int 类型)的地址。
Div 将两个值相除并将结果作为浮点(F 类型)或商(int32 类型)推送到计算堆栈上。
Div.Un 两个无符号整数值相除并将结果 ( int32 ) 推送到计算堆栈上。
Dup 复制计算堆栈上当前最顶端的值,然后将副本推送到计算堆栈上。
Endfilter 将控制从异常的 filter 子句转移回公共语言结构 (CLI) 异常处理程序。
Endfinally 将控制从异常块的 fault 或 finally 子句转移回公共语言结构 (CLI) 异常处理程序。
Initblk 将位于特定地址的内存的指定块初始化为给定大小和初始值。
Initobj 将位于指定地址的值类型的每个字段初始化为空引用或适当的基元类型的 0。
Isinst 测试对象引用(O 类型)是否为特定类的实例。
Jmp 退出当前方法并跳至指定方法。
Ldarg 将参数(由指定索引值引用)加载到堆栈上。
Ldarg.0 将索引为 0 的参数加载到计算堆栈上。
Ldarg.1 将索引为 1 的参数加载到计算堆栈上。
Ldarg.2 将索引为 2 的参数加载到计算堆栈上。
Ldarg.3 将索引为 3 的参数加载到计算堆栈上。
Ldarg.S 将参数(由指定的短格式索引引用)加载到计算堆栈上。
Ldarga 将参数地址加载到计算堆栈上。
Ldarga.S 以短格式将参数地址加载到计算堆栈上。
Ldc.I4 将所提供的 int32 类型的值作为 int32 推送到计算堆栈上。
Ldc.I4.0 将整数值 0 作为 int32 推送到计算堆栈上。
Ldc.I4.1 将整数值 1 作为 int32 推送到计算堆栈上。
Ldc.I4.2 将整数值 2 作为 int32 推送到计算堆栈上。
Ldc.I4.3 将整数值 3 作为 int32 推送到计算堆栈上。
Ldc.I4.4 将整数值 4 作为 int32 推送到计算堆栈上。
Ldc.I4.5 将整数值 5 作为 int32 推送到计算堆栈上。
Ldc.I4.6 将整数值 6 作为 int32 推送到计算堆栈上。
Ldc.I4.7 将整数值 7 作为 int32 推送到计算堆栈上。
Ldc.I4.8 将整数值 8 作为 int32 推送到计算堆栈上。
Ldc.I4.M1 将整数值 -1 作为 int32 推送到计算堆栈上。
Ldc.I4.S 将提供的 int8 值作为 int32 推送到计算堆栈上(短格式)。
Ldc.I8 将所提供的 int64 类型的值作为 int64 推送到计算堆栈上。
Ldc.R4 将所提供的 float32 类型的值作为 F (float) 类型推送到计算堆栈上。
Ldc.R8 将所提供的 float64 类型的值作为 F (float) 类型推送到计算堆栈上。
Ldelem 按照指令中指定的类型,将指定数组索引中的元素加载到计算堆栈的顶部。
Ldelem.I 将位于指定数组索引处的 native int 类型的元素作为 native int 加载到计算堆栈的顶部。
Ldelem.I1 将位于指定数组索引处的 int8 类型的元素作为 int32 加载到计算堆栈的顶部。
Ldelem.I2 将位于指定数组索引处的 int16 类型的元素作为 int32 加载到计算堆栈的顶部。
Ldelem.I4 将位于指定数组索引处的 int32 类型的元素作为 int32 加载到计算堆栈的顶部。
Ldelem.I8 将位于指定数组索引处的 int64 类型的元素作为 int64 加载到计算堆栈的顶部。
Ldelem.R4 将位于指定数组索引处的 float32 类型的元素作为 F 类型(浮点型)加载到计算堆栈的顶部。
Ldelem.R8 将位于指定数组索引处的 float64 类型的元素作为 F 类型(浮点型)加载到计算堆栈的顶部。
Ldelem.Ref 将位于指定数组索引处的包含对象引用的元素作为 O 类型(对象引用)加载到计算堆栈的顶部。
Ldelem.U1 将位于指定数组索引处的 unsigned int8 类型的元素作为 int32 加载到计算堆栈的顶部。
Ldelem.U2 将位于指定数组索引处的 unsigned int16 类型的元素作为 int32 加载到计算堆栈的顶部。
Ldelem.U4 将位于指定数组索引处的 unsigned int32 类型的元素作为 int32 加载到计算堆栈的顶部。
Ldelema 将位于指定数组索引的数组元素的地址作为 & 类型(托管指针)加载到计算堆栈的顶部。
Ldfld 查找对象中其引用当前位于计算堆栈的字段的值。
Ldflda 查找对象中其引用当前位于计算堆栈的字段的地址。
Ldftn 将指向实现特定方法的本机代码的非托管指针(native int 类型)推送到计算堆栈上。
Ldind.I 将 native int 类型的值作为 native int 间接加载到计算堆栈上。
Ldind.I1 将 int8 类型的值作为 int32 间接加载到计算堆栈上。
Ldind.I2 将 int16 类型的值作为 int32 间接加载到计算堆栈上。
Ldind.I4 将 int32 类型的值作为 int32 间接加载到计算堆栈上。
Ldind.I8 将 int64 类型的值作为 int64 间接加载到计算堆栈上。
Ldind.R4 将 float32 类型的值作为 F (float) 类型间接加载到计算堆栈上。
Ldind.R8 将 float64 类型的值作为 F (float) 类型间接加载到计算堆栈上。
Ldind.Ref 将对象引用作为 O(对象引用)类型间接加载到计算堆栈上。
Ldind.U1 将 unsigned int8 类型的值作为 int32 间接加载到计算堆栈上。
Ldind.U2 将 unsigned int16 类型的值作为 int32 间接加载到计算堆栈上。
Ldind.U4 将 unsigned int32 类型的值作为 int32 间接加载到计算堆栈上。
Ldlen 将从零开始的、一维数组的元素的数目推送到计算堆栈上。
Ldloc 将指定索引处的局部变量加载到计算堆栈上。
Ldloc.0 将索引 0 处的局部变量加载到计算堆栈上。
Ldloc.1 将索引 1 处的局部变量加载到计算堆栈上。
Ldloc.2 将索引 2 处的局部变量加载到计算堆栈上。
Ldloc.3 将索引 3 处的局部变量加载到计算堆栈上。
Ldloc.S 将特定索引处的局部变量加载到计算堆栈上(短格式)。
Ldloca 将位于特定索引处的局部变量的地址加载到计算堆栈上。
Ldloca.S 将位于特定索引处的局部变量的地址加载到计算堆栈上(短格式)。
Ldnull 将空引用(O 类型)推送到计算堆栈上。
Ldobj 将地址指向的值类型对象复制到计算堆栈的顶部。
Ldsfld 将静态字段的值推送到计算堆栈上。
Ldsflda 将静态字段的地址推送到计算堆栈上。
Ldstr 推送对元数据中存储的字符串的新对象引用。
Ldtoken 将元数据标记转换为其运行时表示形式,并将其推送到计算堆栈上。
Ldvirtftn 将指向实现与指定对象关联的特定虚方法的本机代码的非托管指针(native int 类型)推送到计算堆栈上。
Leave 退出受保护的代码区域,无条件将控制转移到特定目标指令。
Leave.S 退出受保护的代码区域,无条件将控制转移到目标指令(缩写形式)。
Localloc 从本地动态内存池分配特定数目的字节并将第一个分配的字节的地址(瞬态指针,* 类型)推送到计算堆栈上。
Mkrefany 将对特定类型实例的类型化引用推送到计算堆栈上。
Mul 将两个值相乘并将结果推送到计算堆栈上。
Mul.Ovf 将两个整数值相乘,执行溢出检查,并将结果推送到计算堆栈上。
Mul.Ovf.Un 将两个无符号整数值相乘,执行溢出检查,并将结果推送到计算堆栈上。
Neg 对一个值执行求反并将结果推送到计算堆栈上。
Newarr 将对新的从零开始的一维数组(其元素属于特定类型)的对象引用推送到计算堆栈上。
Newobj 创建一个值类型的新对象或新实例,并将对象引用(O 类型)推送到计算堆栈上。
Nop 如果修补操作码,则填充空间。尽管可能消耗处理周期,但未执行任何有意义的操作。
Not 计算堆栈顶部整数值的按位求补并将结果作为相同的类型推送到计算堆栈上。
Or 计算位于堆栈顶部的两个整数值的按位求补并将结果推送到计算堆栈上。
Pop 移除当前位于计算堆栈顶部的值。
Prefix1 基础结构。此指令为保留指令。
Prefix2 基础结构。此指令为保留指令。
Prefix3 基础结构。此指令为保留指令。
Prefix4 基础结构。此指令为保留指令。
Prefix5 基础结构。此指令为保留指令。
Prefix6 基础结构。此指令为保留指令。
Prefix7 基础结构。此指令为保留指令。
Prefixref 基础结构。此指令为保留指令。
Readonly 指定后面的数组地址操作在运行时不执行类型检查,并且返回可变性受限的托管指针。
Refanytype 检索嵌入在类型化引用内的类型标记。
Refanyval 检索嵌入在类型化引用内的地址(& 类型)。
Rem 将两个值相除并将余数推送到计算堆栈上。
Rem.Un 将两个无符号值相除并将余数推送到计算堆栈上。
Ret 从当前方法返回,并将返回值(如果存在)从调用方的计算堆栈推送到被调用方的计算堆栈上。
Rethrow 再次引发当前异常。
Shl 将整数值左移(用零填充)指定的位数,并将结果推送到计算堆栈上。
Shr 将整数值右移(保留符号)指定的位数,并将结果推送到计算堆栈上。
Shr.Un 将无符号整数值右移(用零填充)指定的位数,并将结果推送到计算堆栈上。
Sizeof 将提供的值类型的大小(以字节为单位)推送到计算堆栈上。
Starg 将位于计算堆栈顶部的值存储到位于指定索引的参数槽中。
Starg.S 将位于计算堆栈顶部的值存储在参数槽中的指定索引处(短格式)。
Stelem 用计算堆栈中的值替换给定索引处的数组元素,其类型在指令中指定。
Stelem.I 用计算堆栈上的 native int 值替换给定索引处的数组元素。
Stelem.I1 用计算堆栈上的 int8 值替换给定索引处的数组元素。
Stelem.I2 用计算堆栈上的 int16 值替换给定索引处的数组元素。
Stelem.I4 用计算堆栈上的 int32 值替换给定索引处的数组元素。
Stelem.I8 用计算堆栈上的 int64 值替换给定索引处的数组元素。
Stelem.R4 用计算堆栈上的 float32 值替换给定索引处的数组元素。
Stelem.R8 用计算堆栈上的 float64 值替换给定索引处的数组元素。
Stelem.Ref 用计算堆栈上的对象 ref 值(O 类型)替换给定索引处的数组元素。
Stfld 用新值替换在对象引用或指针的字段中存储的值。
Stind.I 在所提供的地址存储 native int 类型的值。
Stind.I1 在所提供的地址存储 int8 类型的值。
Stind.I2 在所提供的地址存储 int16 类型的值。
Stind.I4 在所提供的地址存储 int32 类型的值。
Stind.I8 在所提供的地址存储 int64 类型的值。
Stind.R4 在所提供的地址存储 float32 类型的值。
Stind.R8 在所提供的地址存储 float64 类型的值。
Stind.Ref 存储所提供地址处的对象引用值。
Stloc 从计算堆栈的顶部弹出当前值并将其存储到指定索引处的局部变量列表中。
Stloc.0 从计算堆栈的顶部弹出当前值并将其存储到索引 0 处的局部变量列表中。
Stloc.1 从计算堆栈的顶部弹出当前值并将其存储到索引 1 处的局部变量列表中。
Stloc.2 从计算堆栈的顶部弹出当前值并将其存储到索引 2 处的局部变量列表中。
Stloc.3 从计算堆栈的顶部弹出当前值并将其存储到索引 3 处的局部变量列表中。
Stloc.S 从计算堆栈的顶部弹出当前值并将其存储在局部变量列表中的 index 处(短格式)。
Stobj 将指定类型的值从计算堆栈复制到所提供的内存地址中。
Stsfld 用来自计算堆栈的值替换静态字段的值。
Sub 从其他值中减去一个值并将结果推送到计算堆栈上。
Sub.Ovf 从另一值中减去一个整数值,执行溢出检查,并且将结果推送到计算堆栈上。
Sub.Ovf.Un 从另一值中减去一个无符号整数值,执行溢出检查,并且将结果推送到计算堆栈上。
Switch 实现跳转表。
Tailcall 执行后缀的方法调用指令,以便在执行实际调用指令前移除当前方法的堆栈帧。
Throw 引发当前位于计算堆栈上的异常对象。
Unaligned 指示当前位于计算堆栈上的地址可能没有与紧接的 ldind、stind、ldfld、stfld、ldobj、stobj、initblk 或 cpblk 指令的自然大小对齐。
Unbox 将值类型的已装箱的表示形式转换为其未装箱的形式。
Unbox.Any 将指令中指定类型的已装箱的表示形式转换成未装箱形式。
Volatile 指定当前位于计算堆栈顶部的地址可以是易失的,并且读取该位置的结果不能被缓存,或者对该地址的多个存储区不能被取消。
Xor 计算位于计算堆栈顶部的两个值的按位异或,并且将结果推送到计算堆栈上。
2014-10-27 15:52:37 oSKyTonight 阅读数 1414

原文地址:http://www.xuanyusong.com/archives/2373

Assetbundle 是Unity Pro提供提供的功能,它可以把多个游戏对象或者资源二进制文件封装到Assetbundle中,提供了封装与解包的方法使用起来很便利。

1.预设

         Assetbundle可以将Prefab封装起来,这是多么方便啊! 而且我也强烈建议大家将Prefab封装成Assetbundle,因为Prefab可以将游戏对象身上带的游戏游戏组件、游戏脚本、材质都封装在一起。当从服务器上将Assetbundle下载以后直接Instantiate就可以放入游戏中。

         试想一下,如果只能将原始的二进制资源文件放在服务器上下载,当资源文件下载完毕后,需要动态的创建游戏对象、然后动态的将脚本绑定在游戏对象、动态的将贴图赋予游戏对象等等各种动态的操作。。所以强烈建议使用Prefa,不解释!!!!!

 

   另外,我在举个例子,因为模型有可能会带很多动画文件,那么这样一组模型资源就可能是多个FBX 文件 和 若干png贴图文件 材质文件。这时我只需要把原始模型放入Prefab中,它就会包含这个模型的所有组件、甚至包括它的动画资源、贴图。那么如下图所示,Mode就是模型的Prefab文件,那么我仅仅只需要把Mode这个预设打包成Assetbundle即可。 当我在服务器上下载这个Assetbundle并且载入游戏中就可以直接使用了,切换动画、换贴图都可以。。

Unity3D研究院之Assetbundle的原理(六十一) - 雨松MOMO程序研究院 - 1

2.二进制文件

       也并不是Assetbundle中全都要用预设,Assetbundle它也可以将二进制文件直接封装在里面,比如图片、声音、文本信息等等。

 3.场景文件

    在Unity中可以将一个场景保存在Scene中,Scene就会包含这个场景中的所有,那能不能把Scene也封装成Assetbundle中?答案是能,但是它不能在移动平台上用,因为移动平台上是不能更新脚本的,换句话来说就是即使将脚本绑定在Prefab中,然后下载Assetbundle后,所有脚本是不会执行的,后面说另外一种巧妙用法。

4.移动平台

        上面MOMO已经将Assetbundle 的使用原理大致介绍了一下 ,我们在谈谈移动平台。脚本不能更新是移动平台下最大的伤,这就意味着开发者无法绕过App store和 google Play这种在线商店升级应用程序。唯一能做到的就是更新资源、举个例子,游戏中在处理版本升级时,一般会有个大版本号和一个小版本号,大版本号就是 2.0、3.0这种 版本需要在AppStore中更新,大版本主要是升级游戏脚本,然后当小版本号,比如2.0.1 或2.0.2这种只是更新游戏中的资源,通过自己游戏的服务器就可以完成,通过Assetbundle在自己服务器上下载,然后适应在游戏中。如果非要更新脚本,或不得不更新脚本那么只能在Appstore或者google Play去更新大版本。

    移动平台上不能更新脚本,那么Prefab上绑定的脚本怎么办?在任何平台上都可以把脚本添加到Prefab上,然后打包成Assetbundle,只有移动平台上有点特殊,比如将Test.cs这条脚本绑定在Prefab中,最后程序通过服务器下载这个Assetbundle ,当载入工程中这条脚本是不会被执行的。

          但是如果本地工程有Test.cs这条脚本,那么Unity会自动将这条脚本绑定在下载的Prefab中,并且他们执行的非常好。如果本地工程中没有Test.cs这条脚本,那么Prefab上的脚本是永远都不会执行的。有时我们会在脚本中写一些Public的变量,有可能不同的Prefab上绑定的是相同的脚本,只是Inspector 脚本中的public参数不同。别担心这一点Assetbundle 中的Prefab也是没问题,所以说只要大版本中的脚本没问题,在小版本中只更新游戏资源是一点问题都么有的。

5.移动优化

        之前我们说过可以将游戏中的某个游戏对象封装成Assetbundle,也可以将游戏中的整个场景也封装成Assetbundle。但是我认为需要巧妙的使用封装场景,因为场景中肯定有很多公用的模型,如果打包场景的话那么内存与size就是 公用模型的size * N个场景,想想其实挺恐怖的。其实我们可以巧妙的使用,首先把场景中公用的部分和私有的部分统统放入Unity, 然后烘培整个场景。 当场景烘培完毕后把公用的模型部分在拿出去,场景只只保留私有的模型。还可以做一个工具将公用模型在场景中的坐标保存在XML中(每个场景文件会对应一个公用模型的XML信息),最后在将公用的模型分别封装在别的Assetbundle中。

       服务器上提供每个场景的Assetbundle ,和公用模型的Assetbundle,一般公用模型的Assetbundle可以放在常驻内存中(可能使用频繁、根据项目的不同而定)场景Assetbundle下载完毕后,现载入场景然后在根据场景对应的XML信息将公用模型部分动态的在添加到场景中,这样就完成了一个场景的构建。

6.总结

对游戏中所有资源进行打包,比如按类型分为五个大部分  界面,模型,特效,声音,场景,脚本。

界面部分:

公用资源包(可复用的资源包)和 每个界面独有得资源包(不可复用的资源包)统一使用Prefab 打包成.assetbundle 二进制格式。

模型部分:

按角色分类,统一使用Prefab 打包成.assetbundle 二进制格式。 模型部分包括模型文件与动画文件,每一个模型文件对应一组动画文件。(如果模型需要换装还需提供对应换装的模型与贴图) ,因为unity4的重定向动画不支持动态加载,所以目前不需要考虑 不同大小 不同规格 不同性别 的模型重定向动画。

特效部分: 统一使用Prefab 打包成.assetbundle 二进制格式。 

声音部分: 统一使用Prefab 打包成.assetbundle 二进制格式。 

场景部分:场景和前面的有点区别,场景需要导出烘培的光信息并且只能烘培场景之上永远不动的模型,但是这些永远不动的模型有可能会同时在多个场景中使用,所以场景烘培完毕后要把重复使用的对象删除,(运行游戏在动态的加载进来)场景中只保留该场景中永远不会变的模型,以及烘培的光照信息。 打包场景后会生成.unity3D 二进制格式,它和 assetbundle 打包方式是不同的。(另外,也可以考虑 json xml 二进制 来动态组装场景)。  

脚本部分:如果Prefab上是带脚本打包Assetbundle的话  脚本是不会被运行的(移动平台), 但是unity有一个技巧,Prefab上的脚本 如果本地有的话它会把本地的同名脚本绑定在Prefab对象上,它会很好的执行。 

Prefab打包技巧: Prefab打包时自身是不占多少空间的 <=1KB  但是Prefab上是可以关联  这五大部分 “界面,模型,特效,声音,场景,脚本”以及在Hierarchy视图中 坐标/缩放/旋转。 关联这些信息以后就会很大,所以为了避免资源的浪费尽量避免Prefab重复关联。

一个prefab下面可以同时关联多个游戏对象 ,这里举个例子如果你的 Prefab下面放了一个模型 它的大小可能是500k  ,在 Prefab下面放了十个完全相同模型 它的大小可能是501k 。 如果Prefab下面放了两个不同的模型,它的大小可能就会是 500k x 2 的size  ,也就是说Prefab与关联的数量是无关的 。 

加密部分: assetbundle 是可以转换成 字节数组 ,客户端与服务器约定一组解密 字节数组的算法就可以实现资源加密。

大版本升级: 

unity的版本升级其实主要是升级主程序中的脚本。 因为所有的资源都是assetbundle 和 .unity3d   这些资源放在本地或者服务器 解包的方式是完全一样,所以理论上我们的主程序包的大小可以做到很小,可以很好设置把多少资源放在包里 或者把所少资源放在服务器上。在运行的时候服务端应该把所有 assetbundle 和 .unity3d的资源文件的下载地址列表返回给客户端。

小版本升级:

小版本升级也就是更新资源,因为不能更新脚本, 在登陆的时候服务端应该把所有 assetbundle 和 .unity3d的资源文件的下载地址列表返回给客户端。

还有个需要考虑的地方,比如现在大版本是2.0.0 ,小版本已经是2.0.5 ,用户的手机上是一个1.5.0的包。 此时用户在打开游戏的时候 应当强制它去appstore中去下载大版本2.0.0 ,当用户下载完毕后登陆游戏,此时服务器告诉客户端现在已经是2.0.5的小版本了,这时候客户端去下载对应小版本的所有  assetbundle 和 .unity3d文件地址列表。

增量更新:理论上增量更新是可行的。因为unity不能更新脚本,所以在处理增量更新的话 需要在代码中做可以兼容增量更新的可能。

 

因为Assetbundle这块的代码比较多,我还是决定分成两篇文章来写,这篇文章先说原理、下篇文章说代码。欢迎大家来讨论!

前几天我和Unity鑫哥聊天,他告诉我IOS上是无法运行时更新脚本、但是Android上是可以运行时更新脚本,我回家也试了一下但是没能成功,后来我考虑即使成功了项目中我也不打算那么做,因为这样Android和IOS 做起来的差别就太多了, 另外Unity商店中有一个处理运行时更新脚本的插件 unityLua 大家可以去研究研究。


2015-03-19 16:09:19 As_Js_Python 阅读数 522

注:雨松MOMO 2013年06月17日 于 雨松MOMO程序研究院 发表


Assetbundle 是Unity Pro提供提供的功能,它可以把多个游戏对象或者资源二进制文件封装到Assetbundle中,提供了封装与解包的方法使用起来很便利。

1.预设

         Assetbundle可以将Prefab封装起来,这是多么方便啊! 而且我也强烈建议大家将Prefab封装成Assetbundle,因为Prefab可以将游戏对象身上带的游戏游戏组件、游戏脚本、材质都封装在一起。当从服务器上将Assetbundle下载以后直接Instantiate就可以放入游戏中。

         试想一下,如果只能将原始的二进制资源文件放在服务器上下载,当资源文件下载完毕后,需要动态的创建游戏对象、然后动态的将脚本绑定在游戏对象、动态的将贴图赋予游戏对象等等各种动态的操作。。所以强烈建议使用Prefa,不解释!!!!!

 

   另外,我在举个例子,因为模型有可能会带很多动画文件,那么这样一组模型资源就可能是多个FBX 文件 和 若干png贴图文件 材质文件。这时我只需要把原始模型放入Prefab中,它就会包含这个模型的所有组件、甚至包括它的动画资源、贴图。那么如下图所示,Mode就是模型的Prefab文件,那么我仅仅只需要把Mode这个预设打包成Assetbundle即可。 当我在服务器上下载这个Assetbundle并且载入游戏中就可以直接使用了,切换动画、换贴图都可以。。


2.二进制文件

       也并不是Assetbundle中全都要用预设,Assetbundle它也可以将二进制文件直接封装在里面,比如图片、声音、文本信息等等。

 3.场景文件

    在Unity中可以将一个场景保存在Scene中,Scene就会包含这个场景中的所有,那能不能把Scene也封装成Assetbundle中?答案是能,但是它不能在移动平台上用,因为移动平台上是不能更新脚本的,换句话来说就是即使将脚本绑定在Prefab中,然后下载Assetbundle后,所有脚本是不会执行的,后面说另外一种巧妙用法。

4.移动平台

        上面MOMO已经将Assetbundle 的使用原理大致介绍了一下 ,我们在谈谈移动平台。脚本不能更新是移动平台下最大的伤,这就意味着开发者无法绕过App store和 google Play这种在线商店升级应用程序。唯一能做到的就是更新资源、举个例子,游戏中在处理版本升级时,一般会有个大版本号和一个小版本号,大版本号就是 2.0、3.0这种 版本需要在AppStore中更新,大版本主要是升级游戏脚本,然后当小版本号,比如2.0.1 或2.0.2这种只是更新游戏中的资源,通过自己游戏的服务器就可以完成,通过Assetbundle在自己服务器上下载,然后适应在游戏中。如果非要更新脚本,或不得不更新脚本那么只能在Appstore或者google Play去更新大版本。

    移动平台上不能更新脚本,那么Prefab上绑定的脚本怎么办?在任何平台上都可以把脚本添加到Prefab上,然后打包成Assetbundle,只有移动平台上有点特殊,比如将Test.cs这条脚本绑定在Prefab中,最后程序通过服务器下载这个Assetbundle ,当载入工程中这条脚本是不会被执行的。

          但是如果本地工程有Test.cs这条脚本,那么Unity会自动将这条脚本绑定在下载的Prefab中,并且他们执行的非常好。如果本地工程中没有Test.cs这条脚本,那么Prefab上的脚本是永远都不会执行的。有时我们会在脚本中写一些Public的变量,有可能不同的Prefab上绑定的是相同的脚本,只是Inspector 脚本中的public参数不同。别担心这一点Assetbundle 中的Prefab也是没问题,所以说只要大版本中的脚本没问题,在小版本中只更新游戏资源是一点问题都么有的。

5.移动优化

        之前我们说过可以将游戏中的某个游戏对象封装成Assetbundle,也可以将游戏中的整个场景也封装成Assetbundle。但是我认为需要巧妙的使用封装场景,因为场景中肯定有很多公用的模型,如果打包场景的话那么内存与size就是 公用模型的size * N个场景,想想其实挺恐怖的。其实我们可以巧妙的使用,首先把场景中公用的部分和私有的部分统统放入Unity, 然后烘培整个场景。 当场景烘培完毕后把公用的模型部分在拿出去,场景只只保留私有的模型。还可以做一个工具将公用模型在场景中的坐标保存在XML中(每个场景文件会对应一个公用模型的XML信息),最后在将公用的模型分别封装在别的Assetbundle中。

       服务器上提供每个场景的Assetbundle ,和公用模型的Assetbundle,一般公用模型的Assetbundle可以放在常驻内存中(可能使用频繁、根据项目的不同而定)场景Assetbundle下载完毕后,现载入场景然后在根据场景对应的XML信息将公用模型部分动态的在添加到场景中,这样就完成了一个场景的构建。

6.总结

对游戏中所有资源进行打包,比如按类型分为五个大部分  界面,模型,特效,声音,场景,脚本。

界面部分:

公用资源包(可复用的资源包)和 每个界面独有得资源包(不可复用的资源包)统一使用Prefab 打包成.assetbundle 二进制格式。

模型部分:

按角色分类,统一使用Prefab 打包成.assetbundle 二进制格式。 模型部分包括模型文件与动画文件,每一个模型文件对应一组动画文件。(如果模型需要换装还需提供对应换装的模型与贴图) ,因为unity4的重定向动画不支持动态加载,所以目前不需要考虑 不同大小 不同规格 不同性别 的模型重定向动画。

特效部分: 统一使用Prefab 打包成.assetbundle 二进制格式。 

声音部分: 统一使用Prefab 打包成.assetbundle 二进制格式。 

场景部分:场景和前面的有点区别,场景需要导出烘培的光信息并且只能烘培场景之上永远不动的模型,但是这些永远不动的模型有可能会同时在多个场景中使用,所以场景烘培完毕后要把重复使用的对象删除,(运行游戏在动态的加载进来)场景中只保留该场景中永远不会变的模型,以及烘培的光照信息。 打包场景后会生成.unity3D 二进制格式,它和 assetbundle 打包方式是不同的。(另外,也可以考虑 json xml 二进制 来动态组装场景)。  

脚本部分:如果Prefab上是带脚本打包Assetbundle的话  脚本是不会被运行的(移动平台), 但是unity有一个技巧,Prefab上的脚本 如果本地有的话它会把本地的同名脚本绑定在Prefab对象上,它会很好的执行。 

Prefab打包技巧: Prefab打包时自身是不占多少空间的 <=1KB  但是Prefab上是可以关联  这五大部分 “界面,模型,特效,声音,场景,脚本”以及在Hierarchy视图中 坐标/缩放/旋转。 关联这些信息以后就会很大,所以为了避免资源的浪费尽量避免Prefab重复关联。

一个prefab下面可以同时关联多个游戏对象 ,这里举个例子如果你的 Prefab下面放了一个模型 它的大小可能是500k  ,在 Prefab下面放了十个完全相同模型 它的大小可能是501k 。 如果Prefab下面放了两个不同的模型,它的大小可能就会是 500k x 2 的size  ,也就是说Prefab与关联的数量是无关的 。 

加密部分: assetbundle 是可以转换成 字节数组 ,客户端与服务器约定一组解密 字节数组的算法就可以实现资源加密。

大版本升级: 

unity的版本升级其实主要是升级主程序中的脚本。 因为所有的资源都是assetbundle 和 .unity3d   这些资源放在本地或者服务器 解包的方式是完全一样,所以理论上我们的主程序包的大小可以做到很小,可以很好设置把多少资源放在包里 或者把所少资源放在服务器上。在运行的时候服务端应该把所有 assetbundle 和 .unity3d的资源文件的下载地址列表返回给客户端。

小版本升级:

小版本升级也就是更新资源,因为不能更新脚本, 在登陆的时候服务端应该把所有 assetbundle 和 .unity3d的资源文件的下载地址列表返回给客户端。

还有个需要考虑的地方,比如现在大版本是2.0.0 ,小版本已经是2.0.5 ,用户的手机上是一个1.5.0的包。 此时用户在打开游戏的时候 应当强制它去appstore中去下载大版本2.0.0 ,当用户下载完毕后登陆游戏,此时服务器告诉客户端现在已经是2.0.5的小版本了,这时候客户端去下载对应小版本的所有  assetbundle 和 .unity3d文件地址列表。

增量更新:理论上增量更新是可行的。因为unity不能更新脚本,所以在处理增量更新的话 需要在代码中做可以兼容增量更新的可能。


Unity3d 引擎原理详细介绍

阅读数 1827

体系结构为了更好地理解游戏的软件架构和对象模型,它获得更好的外观仅有一名Unity3D的游戏引擎和编辑器是非常有用的,它的主要原则。Unity3D引擎Unity3D的是一个屡获殊荣的工具,用于创建交互式3D应用程序在多个...

博文 来自: Xingaaaxing

Unity3d 引擎原理详细介绍

阅读数 35449

一、体系结构  为了更好地理解游戏的软件架构和对象模型,它获得更好的外观仅有一名Unity3D的游戏引擎和编辑器是非常有用的,它的主要原则。Unity3D引擎  Unity3D的是一个屡获殊荣的工具,用于创建交互式3D应用程序在多个platforms.Unity3D由游戏引擎和编辑器。该引擎包含的软件组件,在游戏的研究与开发中最常见的和经常性的任务。发动机所涵盖的主题包括声音,图

博文 来自: jbjwpzyl3611421

Unity3d 引擎原理详细介绍

阅读数 1545

体系结构  为了更好地理解游戏的软件架构和对象模型,它获得更好的外观仅有一名Unity3D的游戏引擎和编辑器是非常有用的,它的主要原则。Unity3D引擎  Unity3D的是一个屡获殊荣的工具,用于创建交互式3D应用程序在多个平台.Unity3D由游戏引擎和编辑器。该引擎包含的软件组件,在游戏的研究与开发中最常见的和经常性的任务。发动机所涵盖的主题包括声音,图形,物

博文 来自: Anzhongliu

Unity3d 引擎原理详细介绍

阅读数 1843

体系结构为了更好地理解游戏的软件架构和对象模型,它获得更好的外观仅有一名Unity3D的游戏引擎和编辑器是非常有用的,它的主要原则。Unity3D引擎Unity3D的是一个屡获殊荣的工具,用于创建交互式3D应用程序在多个平台.Unity3D由游戏引擎和编辑器。该引擎包含的软件组件,在游戏的研究与开发中最常见的和经常性的任务。发动机所涵盖的主题包括声音,图形,物理和网络功能。该引擎支持C#,B

博文 来自: aries__lee

Unity3D——镜面反射原理及实现

阅读数 2243

原文:http://gad.qq.com/user/myarticle?id=438905

博文 来自: zhangming19901120
没有更多推荐了,返回首页