[原]C#与非托管——动机

Unity3D采用C#作为脚本开发语言，本来是可以直接提供代码局部更新机制的，可惜Mono和Unity3D迫于苹果的压力，在iOS上采用AOT模式运行，断绝了代码局部更新的路(任何一个具有很高知名度的引擎都不敢明着违反苹果的条款)，而Android的代码局部更新则被Unity3D做成了一个收费的售后服务项目。不过不是跨平台的机制都没有多大的意义，所以如果需要局部更新代码(大家也都称为热更新)，一般都需要采用脚本的方式，把大部分游戏内逻辑特别是变化很大的逻辑写在脚本里面，然后把脚本作为资源来做局部更新。

让Unity3D支持脚本有两种方案：

1. 使用不含动态生成代码的C#子集实现一个脚本解释器，典型实现有C#Light、KopiLua和UniLua；

2. 使用P/Invokes让C#能够调用已有的C/C++脚本解释器，典型实现有ulua、slua。

C#Light和升级版L#：

由于C#的语法特性较多，C#Light不太可能也没有必要实现所有的C#特性(如泛型)，因此按照C#的编程习惯比较容易遇到不兼容的问题需要调试或重写。虽然说减少了学习成本(不需要学习新的语言，直接以Unity3D支持C#进行开发)，但各种不支持的特性也算是一个很大的记忆负担。后来升级版的L#作者直接解析IL，编译直接利用VS的编译器，总算走出了语法解析的泥潭，但还是有很多特性不支持(目前已知的有引用、泛型、继承等)。此外C#对基础操作(比如读取内存偏移)性能较低，在做虚拟机时对脚本自身的运算效率低下。

KopiLua：

应该是最早出现的Unity3D支持lua的库了，不过作者自己就说了，是对着lua源代码line by line从C源码port到C#的，而且lua的C源码里面大量使用了宏在C#里面只能是函数调用，所以性能低下是可以预见。

UniLua：

专门用C#重写的lua虚拟机，如字符串之类的直接使用了C#原生类，效率还算不错。不过升级到lua5.2了，有人喜欢有人不喜欢吧。

ulua、slua：

后起之秀，配合上类似tolua++的代码预生成性能非常优越，瓶颈在于C#调用C/C++的native接口，所以交互部分需要精心设计，之后游戏逻辑就和开发quick-cocos-x游戏差不多了。

无论是直接使用ulua还是自己进行封装，ulua的实现以及C#的非托管调用都是必须了解的。因此接下来我会陆续写一些这方面的内容，备忘的同时方便他人~