首先附上這兩個項目的地址，這兩個項目都是比較完善的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 相關的教程很多，也就沒有太多可以囉嗦的了。