Unity3D逻辑热更新，第二代舒爽解决方案，L#使用简介
热更新
天下武功，无坚不破，唯快不破
热更新就是为了更快的把内容推到用户手中。
之前，我设计了C#Light，经过半年多的持续修补，勉强可用，磕磕绊绊。
感谢那些，试过，骂过，用过的朋友，在你们的陪伴下一路走来，也让我更坚定了要把这件事做好的决心。于是就有了C#Light的2.0，L#。
为什么叫L#呢？
因为这次是直接加载解析DLL执行，Load，有一个L
因为直接执行的东西叫做IL，有一个L
因为模拟CLR的工作，有一个L
于是，就有了L#
https://github.com/lightszero/LSharp
欢迎加QQ群223823428探讨：
L#为什么舒爽
上一篇已经解释了工作模式
你可以看到这一次变C#Light的"巧妙"利用VS、mono做语法检查变成真的使用vs、mono来编译
彻底的解决了C#Light语法支持不完整的问题
C#Light设计之初就确定了是c#的语法子集
编写起来，限制诸多，处处掣肘，只保留了C#的形
这一次，L#，形神兼备。而且不止是c#，L#支持C# vb.net unityscript f# boo,只要能编译成dotnet dll就可以
上一篇见这里http://www.cnblogs.com/crazylights/p/4216913.html
上一篇发布之后，L#的接口又做出了一些调整
Github 上有最新的源码https://github.com/lightszero/LSharp
其中有一个ForUnity目录，就是为Unity准备的
已经测试通过了IOS和WP8这两个极端环境
L#在C#Light基础上做出的改进
1.C#light的Context设计不明确
很多人都在疑惑何时该new，为何要new
L#彻底把这个设计修改为ThreadContext，脚本中的线程管理对象，在一个线程上只需要new一次，而且随时ThreadContext.active 就可获取。
以前C#Light 从回调中调用，就只能看到回调一部分脚本堆栈了。
L#修改了这个设计，一个线程上的脚本堆栈全是一体的，即使经过回调也完全可见，经过回调排错不再困难
2.改动了接口结构
更像反射，方便在反射和L#脚本中快速切换
L#的接口结构和反射一致，而且可以直接使用L#的调用方式调用反射。
更添加了快速切换反射和L#脚本的模式，发生难以判断的bug时，可以切到反射模式排查。
在支持反射的平台上，也可以切换到反射模式加速
快速切换的例子，有一个独立测试程序，Test01
3.注册改为可选
C#Light采用了先注册再调用的模式，很多人抱怨不便。
这其实是C#Light设计上的先天困难。
而IL解析DLL执行，DLL中的信息很完整，所以IL默认可以自动完成所有的类型注册
也依然保留手工注册的接口。
4.L#的神器CrossBind
L#设计了一个CrossBind方式，允许脚本直接继承程序中的接口
比如在程序中设计一个
Interface IState
{
void Abc();
}
脚本可以继承此接口，并返回兼容IState的实例给程序
脚本中已经实现了关于迭代器的两个CrossBind
也就是支持在脚本中使用yield语句。
L#的优化空间
很多人都关心L#的性能问题，L#的工作还没推进到那个阶段。
现在在Alpha阶段，欢迎小白鼠加入，一起踩踩坑。
根据目前的少量用户试用反馈，其Bug是比C#Light Alpha阶段少了很多的。
但是L#存在很大的优化空间
- 还有很多阶段有填Cache的空间
- 既然我们是模拟CLR的工作，对IL语句，自然也可以做出类似JIT的优化。
比如a.nop语句完全是浪费时间可以移除
b.stloc ldloc 这种两条连续，参数一致的语句，他的意义是保存变量并加载变量，我们就可以设计一条优化指令，stlocandstayinstack，保存变量并且保留在栈上。
c.很多算术运算都是ld到栈，计算，再存回，只要设计优化的自增运算指令，就可以三条变一条
3．可以考虑 unsafe 或者本地代码的引入
