http://www.manew.com/thread-114496-1-1.html
談到目前的代碼熱更方案：沒什么特別的要求
<ignore_js_op>
toLua（效率比sLua高）
打算以傳統方式更新，熱更僅僅用於緊急更新 / 希望戰斗等性能敏感部分也能更新
xLua（性能在Lua系列中一般，但額外支持HotFix，可以更多使用C#代碼）
基本上普通的項目也就只能用這兩，也就是只有Lua一條路可走。
然而，由於Lua自身缺少編譯期間語法檢查以及缺乏必要的語言特性，在熟練的開發者手里開發效率和健壯性其實是不如其他強類型語言的。
——這點可能會有異議，我只能這么講：使用強類型語言的程序員都會有一些增加開發效率和代碼健壯性的“小技巧”，但這些技巧必須依附於語言特性以及某些只在強類型語言上才能使用的IDE功能。而且這樣做的優勢更多體現在項目的后期，也和團隊的協作模式有關，沒接觸到的人可能確實無法理解。
一些人可能會覺得lua比C#更好用，但在另一些人手里C#也確確實實能夠比lua提供更多的開發效率，保證更低的BUG概率，你不能因為自己“不知道，不用”，而認為他們的需求不存在。
現有的可使用強類型語言的代替方案如下：
- 使用ILRuntime解釋器（C#解釋器）
- 使用JS解釋器（V8），並且使用TypeScript
- 依然使用Lua解釋器，但是使用一門強類型語言編程，並翻譯至Lua
ILRuntime解釋器
按一般的思路來看，用ILRuntime是比較正統的解決方案，如果由Unity官方來推動代碼熱更的話恐怕就是這個，畢竟沒有哪個語言在提供代碼熱更的方案的時候，會主動換成另外一個腳本語言（點擊此處了解）
而且相比其他更冷門的解決方案，ILRuntime還是有一些實際產品的。
優點應該無需臃述，現在單說缺點：
- 慢
借用這位老兄的測試結果Unity中SLua、Tolua、XLua和ILRuntime效率評測 - CSDN博客。
在可使用JIT的安卓環境下，ILRuntime其實比lua擁有更好的性能。但是在不能使用JIT的IOS環境下，雖然在普通的API調用方面和lua差距不大，但是在純粹的簡單數值計算，循環，數組存取上，確實和lua有着非常大的差距（下圖的最后兩個Test）
<ignore_js_op>
雖然這個測試結果看上去很嚴重，但畢竟Test9是這樣的測試代碼
<ignore_js_op>
用來作為慢18倍的依據恐怕並不合適。
而在Test8里
<ignore_js_op>
只是循環內多了幾個簡單計算，兩者之間的差距就縮小了很多（僅3倍）。
由於ILRuntime在調用C#API時效率比Lua更高（無需類型轉換），綜合判斷，在實際的項目里很可能差距也就2，3倍，這並非不能接受的。在安卓JIT下更是可以和Lua拉平。
因為和外部的非熱更代碼使用的是同一語言，穿透調用性能較高，將性能敏感的代碼移動到非熱更區域會比Lua更加容易，細心處理搞不好性能還會更高。
如果實在擔心ILRuntime的性能問題。其實可以去查一下python和lua的性能對比——ILRuntime還真不一定比“一切皆對象”的python慢。
而網易的手游基本都是python，這個信息對說服老板使用此方案應該會有比較大的幫助。
此外，還有位老兄仿造xlua寫了一個基於ILRuntime的HotFix方案（點擊此處查看）
這樣給予了這個方案更大的使用靈活性，可以選擇新版本使用最高效的il2cpp代碼，而舊版本通過熱更部分使用效率較低的ILRuntime代碼。這樣雖然ILRuntime部分比lua慢，但是占比更大的il2cpp部分則比lua快，整體上反而比lua方案效率增加了。
而且不同與xLua，HotFix和正常更新並存的方案並不需要兩套代碼，實現成本其實不高。
（但要注意這庫是個新庫，雖然ILRuntime本身是經過驗證的方案，但他新加這套東西不好說有沒有問題，想用C# HotFix就要承擔這個風險。）
TypeScript
有人用，但我不了解，跳過吧。
由強類型語言翻譯至Lua
最理想的做法，是直接將C#翻譯成Lua。（點擊此處查看）
但據使用過的人評價，這個庫效果並不穩妥。沒用過，所以此言論僅供參考。
這里要說的是另一個轉換方案（點擊此處查看）
HaXe這個語言應該大部分人都沒聽說過，它本身就是一個“翻譯成其他語言”以實現跨平台的語言，所以沒有廠商背書也沒有社區影響，因為這個理由一直很冷。
但是在現在這個狀況下，還真沒有比這個更好的選擇了。
首先HaXe生成lua在coscos時代還真有項目這么用，它在生成lua代碼這方面的能力起碼被證實了。語言本身是ECMA系的，沒有學習難度，大概是個TS+AS的混合體，包括類型推斷等現代語言特性，至少是不比C#差的。唯一缺少的是方法重載，但是有不定向的參數默認值作為代替。
除此之外還有一些奇怪的語法糖特性，但是可以不用了解。
雖然需要學習新語言，但畢竟它沒有自己的標准庫，長得也和現有的語言差不多，其實是沒啥學習難度的。
事實上也沒有使用風險，因為它其實就是一個廣義的lua編輯器，最后輸出到Unity工程目錄的只有一個lua文件，可以搭配其他lua方案使用。
此外，它也支持輸出成C#源文件，也可以方便的把性能敏感代碼轉移到非熱更部分。（點擊此處查看）
不過Haxe直接用到Unity上還需要稍微做些工作。因為HaXe是強類型語言，你必須生成一組橋文件才能讓它調用Unity的API，和Lua需要生成的C#類橋文件差不多。這個庫給了生成的工具。
另外帶了幾個lua文件橋接了lua的一些功能（比如說協程）
HaXe的橋文件，實質就是指示翻譯器在翻譯成目標語言的途中讓某些代碼保持原樣，順帶實現代碼提示。學會這個用法后，就可以方便地寫出自己的擴展，不用擔心和其他語言的通信難度問題。https://haxe.org/manual/lf-externs.html。
這個庫也是前天才創建的新庫，但實際上主要是個示例工程，因為HaXe其實本來就可以直接用在Unity+???Lua上的。
現在也基本能用了，至少在我看來，HaXe這個方案是目前成本最低的，最安全的“干掉天殺的Lua”的辦法。
知乎@flashyiyi