如何評價雲風與xlua作者關於unity,c#,lua的討論，以及他後來給出的方案？

01-13

先是因為關注云風的微博，xlua發布之後，雲風發一條微博點出xlua中的一個問題，並且尖酸的用撞大運編程來形容，後來兩人在GitHub上開了帖討論了很多，後來帖算是歪了然後關閉了，詳情見直接在 cs 里調用 luaL_error 真的沒問題么？ · Issue #14 · Tencent/xLua，然這兩天又發了條微博提出一種方案，在 Unity3D 的 Mono 虛擬機中嵌入 Lua 的一個方案，我看不太懂，想聽聽大家的看法，同時他個人很推崇lua這門語言，另外這種lua方案到底好么，還是就是他個人的技術喜好

關鍵是你想看啥呢？看大家一致聲討雲風？你就心滿意足了？還是大家一起踩 xlua？你就能HI了？

如果正兒八經的請教，匿名幹嘛？

忽然明白了四個字，什麼叫做「好事之徒」，原來說的就是這。

要看戲就自己演，看不慣誰就自己上。

覺得冤的話，不改題目的情況下取昵，然後我就把我這答案改了。

&> lua方案到底好么

好，我們第一個上線的Unity項目是純C#的，痛過之後立刻把下一個開發了部分的項目轉全lua來熱更了

雲風大神的一句說得真好：

通常正確性第一，其次是簡潔性，它可以為正確性提供更多保障；最後才應該考慮性能。

技術上，雲風在博客中道出C#、Lua交互的核心是代碼通訊，可以從Mono底層直接支持和Lua進行通信，方案簡潔，實在犀利。

這讓我想起ZeroMQ文檔中的自我定位：代碼之間能夠通過Socket進行溝通的，ZeroMQ是一個非同步編程庫。

ZeroMQ:Fixing the world / 譯文

但是，同樣的一句話，我覺得如果放在項目實際開發，老闆的眼中，可以這樣說了。

通常「項目進度」第一，其次是正確性，它可以為正確性提供更多保障；最後才應該考慮簡潔性。

xLua提供了一個完整的開發產品，幫助開發者省了無數加班時間，這點是毋庸置疑的。要知道，做xLua的過程中，要經歷無數項目的挑剔、各種大牛的質疑，是相當不容易的。

反觀sharplua目前還是一些基礎代碼和概念，期待後續有更多。

所以，sharplua的想法很好，但你只能用xLua。

程序是這樣站隊的:接觸的第一個引擎是unity，站c#這邊；接觸更老引擎的，站lua這邊。

項目的性能問題，在關注ULua的性能優化。發現卻無從下手。

尖酸的用撞大運編程來形容。這個描述有問題，這只是基於問題討論。沒尖酸。

###

通常正確性第一，其次是簡潔性，它可以為正確性提供更多保障；最後才應該考慮性能。甚至性能好壞只應該是一種副產品，而不應喧賓奪主。

###

以下內容說明了在xlua和ulua上跨語言的考慮不夠完全，後來使用者很難去認真去看其中的代碼。

***

mono 和 lua 是兩個非常獨立的模塊，首先應該考慮設計層面的模塊間減少耦合度，提高內聚性，再考慮實現細節的優化。設計做簡單了，實現優化甚至是可有可無的東西。

提高內聚性後，交互變成批量處理的東西，在理論上存在更大的優化空間。比如聚合要處理的批量數據後（把要傳遞的參數聚合在一起），對 cache 更友好。

lua_pushstring 這種要保證異常處理的完備，每次調用都是要檢查的，而聚合在一起後，是通過 lua 自己的 error 機制統一處理例外情況，而不需要逐個做判斷。

總的來說，在設計層面考慮問題，不要陷入不必要的優化細節考慮上。

***

雲風大大在lua上使用和研究很深入。先正確性第一，簡潔性，最後考慮性能。在設計上不夠很好。優化的話，還是要去優化設計。這個先後我是非常認同。

xlua就不怎麼說了，坐等別人回答。題主問道到了 lua，來說幾句。

使用腳本語言來做熱更的方案這個不用多說了，lua的優點是速度快，JIT之後更快，並且體積很小，而我最喜歡的一點是它幾乎除了最基本的操作外沒有提供什麼東西，比較清靜。

相較於 C# 來說，用C++開發的遊戲更能體現出腳本語言的優勢，上一個項目除了引擎之外全部用lua寫，寫順手了，最近調到一個新項目，由於歷史和其他原因很多還是C++代碼，導致我現在經常不敢更新，實在是太慢了，用聯合編譯的話能好一些，全部重編能感受到速度提升很快，但是，還是不夠方便。

遊戲邏輯更改實在太頻繁了，而且難免出bug要修復，更新也不能每周都提一個大包，所以腳本語言對於手游來說還是很必要的，而lua又算是其中比較好的一個吧。

每次看到雲風在自己blog上寫各種關於lua的技術想法和實現，一開始會覺得是技術大牛一心專研技術，後來想想一門語言到一定程度不就是看怎麼用么，怎麼還需要解決這樣那樣的底層問題，甚至有些問題是他自己之前都沒有碰到過，層出不求。lua簡單，做腳本語言膠水，寫流程處理可以，但難堪大用，尤其複雜的邏輯，複雜邏輯必須要有面向對象的機制，lua沒有，只能用蹩腳的方式去模擬，看著就蛋疼。

鏈接的帖子沒看完，因為對討論的點沒興趣。這種通用庫寫起來蛋疼，用起來也不好用。

個人思路是結合項目具體情況做lua的封裝。這樣可以不支持很多情況。比如不支持傳lua function到C#；不允許lua保存C#對象的指針，要存存id；不允許C#保存lua 對象。反正各種不支持不允許，項目組約定好就行。