首先附上这两个项目的地址，这两个项目都是比较完善的lua解决方案，从效率和使用方式上说都不相伯仲，我最终选择了ulua，但是并不是说其具有压倒性优势。
uLua：http://ulua.org/index.html
sLua：https://github.com/pangweiwei/slua
引入lua，基本上就是为了热更新，不过后面苹果似乎对lua脚本的热更新也限制的很严格，拿脚本做热更新也要偷偷摸摸的去做。所以说我一贯的观点是游戏框架设计的合理些（比如技能、界面中可以用配置的，尽量不要硬编码），代码稳定些，多做些测试，不要总想着上线后再去修正什么致命bug。正常情况下，我们需要频繁更新的，应该是游戏资源或者是策划数值。我们新增一个功能或者一批界面的时候，进行一次全包的版本更新是合情合理的。玩家想玩新功能就去更新，不想玩新功能就不去更新，这样不会对现有玩家造成什么大的影响。反之，如果从来不考虑向前兼容，比如一个消息随便修改字段含义，或者打乱消息结构而又没有合理使用protobuf，那么就是游戏代码设计的不合理。
从开发效率上说，我反而认为c#写起来更顺手一些， 代码维护性也更强一些，毕竟地球上没有哪个IDE比vs更懂c#。从运行效率上说c#比最快的lua方案也要快50倍左右。
基于此，我对lua的使用是，将其限定在有限的模块内，让lua为游戏服务，而不是让游戏为lua妥协。这个跟cocos2dx+lua还不一样，毕竟合格的c++开发者很难招，并且开发效率跟脚本语言也没法比，作为2D游戏，绝大多数情况下lua的运行效率也满足需求。举个例子，界面部分可以用lua，基本上一个界面就是一个UI的prefab加上一个lua脚本。新手引导部分也可以使用lua，因为这个太有可能频繁改动了。任务部分可以考虑使用lua，这个变化性会比较大，并且不太可能频繁调用到。
再说解决方案的选择，候选方案有三个uLua sLua和L#。其他如unilua，个人感觉不是很完善。上面提到的三个无论从完善程度，还是运行效率都是符合需求的。
L#，感觉玩的有些脱了，没有特别关注，如果使用c#作为脚本，我其实宁愿放弃代码热更新，而在游戏框架上面多下一些功夫，一样可以满足大多数更新需求。
sLua和uLua的使用方式是类似的，效率上也差不多。这里要注意uLua要使用最新版本，因为早期的uLua是使用反射机制，脚本的运行效率比较糟糕。而新的uLua集成了cstolua，它的实现原理跟sLua类似，预先生成一批代码把Unity的类和函数导出给lua，然后lua再调用，这样无论是效率还是GC的角度上说都是比较完美的。
sLua有一篇benmark http://www.sineysoft.com/post/164 它展示了sLua的性能。但是我实际测试发现，最新版本的uLua其实很多情况下要比sLua还要快，可能快一倍左右。比如，循环200W次调用 v = Vector3(i,i,i) 。uLua消耗平均时间是0.7秒，而sLua时间则是1.4秒，c#原生调用为0.06秒。
具体时间可能跟平台和机器相关，不过从理论（实现思路）和实际结果来看，uLua并没有性能上的劣势。
在使用上，可以参考这篇文章:http://blog.csdn.net/neil3d/article/details/44200821 相关的教程很多，也就没有太多可以啰嗦的了。