[原]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#的语法特性较多,C#Light不太可能也没有必要实现所有的C#特性(如泛型),因此按照C#的编程习惯比较容易遇到不兼容的问题需要调试或重写。虽然说减少了学习成本(不需要学习新的语言,直接以Unity3D支持C#进行开发),但各种不支持的特性也算是一个很大的记忆负担。后来升级版的L#作者直接解析IL,编译直接利用VS的编译器,总算走出了语法解析的泥潭,但还是有很多特性不支持(目前已知的有引用、泛型、继承等)。此外C#对基础操作(比如读取内存偏移)性能较低,在做虚拟机时对脚本自身的运算效率低下。
应该是最早出现的Unity3D支持lua的库了,不过作者自己就说了,是对着lua源代码line by line从C源码port到C#的,而且lua的C源码里面大量使用了宏在C#里面只能是函数调用,所以性能低下是可以预见。
专门用C#重写的lua虚拟机,如字符串之类的直接使用了C#原生类,效率还算不错。不过升级到lua5.2了,有人喜欢有人不喜欢吧。
后起之秀,配合上类似tolua++的代码预生成性能非常优越,瓶颈在于C#调用C/C++的native接口,所以交互部分需要精心设计,之后游戏逻辑就和开发quick-cocos-x游戏差不多了。
无论是直接使用ulua还是自己进行封装,ulua的实现以及C#的非托管调用都是必须了解的。因此接下来我会陆续写一些这方面的内容,备忘的同时方便他人~