我為什麼想幹掉Unity3D?
這個問題容我不答，每個做技術的人總有一些完美主義。
你使用u3d的過程中是不是痛並快樂著呢。
就從兩個國內具有相當普遍性的痛點說起。
- il2cpp，unity作出了這個決策以來，導致每個程式設計師都擁有了大姨媽，每當接入ios平臺，就得再死上一次。每當看一眼打出來的包的容量，就會有一種壓力山大的感覺。
- unity的底層c++ api沒有公開，如果想要接入指令碼層，只能通過dotnet進行互操作，導致u3d平臺上難以實現比較完美的指令碼方案。首先效能就是一個問題
還有第三個痛點，一直是我的一塊心病。Unity不能在手機平臺斷點除錯，本來斷點除錯作為程式設計師的最後手段，居然被剝奪了。很是擔憂。
痛點這麼多，還一直賴在Unity3D，又是為什麼呢
因為unity3d還有一些優點，太過於吸引人。
- 成熟、穩定（穩定要打個折扣）的IDE
- 多平臺一鍵釋出（IOS這個一鍵也差了一點，是釋出為xcode專案）
- C#語言buf加持
有沒有可能解決痛點，保持優勢？
當然有
讓我們看一下unity3d的架構，這是個我隨便畫的示意圖
Unity3d的架構是以c++編寫的引擎框架為基礎，這裡很傳統。
反傳統之處在於unity3d完全將所有的介面置於monoruntime之後，unity本身的部分功能也是由dotnet開發，比如unityengine.ui
使用者程式碼更是完全限制為使用dotnet開發。
雖然unity提供了plugin機制，可以用其他語言混編，但是這些外掛均無法訪問unity底層c++程式碼（或許可以，我沒有見到任何資料）。
這導致了unity無法高效的接入c++實現的指令碼語言，lua在unity的實際表現有目共睹。
這是痛點2的原因，痛點1是unity自己作死，不多說。痛點3也是unity工作沒有做好。
解決痛點
有沒有一個架構，可以解決痛點123呢，答案是有。
基於xamarin方案，android、ios平臺均可斷點除錯
底層程式碼同時對monoruntime和指令碼層公開介面，可以插入c++實現的各種指令碼，比如lua，並取得原生效能。
使用者程式碼分為dotnet 和 指令碼兩種，兩者之間不互訪，通過底層介面互發訊息。
Il2cpp自然也不用擔心。
還有附加的好處，c# 5.0走起。
Xamarin平臺上現有monogame，他是都在monoruntime之後實現的，呼叫otk，也不能提供原生效能，也不可以插入原生指令碼。
該方案實現在於：
- 為xamarin編寫不同平臺的原生外掛，主要是繪圖、音效、觸控、鍵盤這些底層公開介面。主要是ios、android、當然pc也要，pc可以不用xamarin，改為windows+vs，這樣在windows除錯更給力。
- P/invoke匯出到dotnet,對接什麼指令碼層也做對應匯出。
這樣重度使用者程式碼用dotnet編寫，輕度易變程式碼用指令碼編寫，輕度程式碼為資源，任何平臺均可實現下載執行。
保持優勢
- c#加持，更優了，unity整合c# 3.5，xarmarin整合c# 5.0，你還想說什麼。
- 多平臺一鍵釋出，這個xamarin沒有做，需要我們自己做。
- 成熟穩定的場景編輯器，這個需要我們自己做。
場編怎麼做，抄襲unityeditor，unityeditor這個指令碼擴充套件比較方便，抄。
一鍵釋出怎麼做。在android很容易，我們已經做了原理測試程式，弄個模板apk檔案，解包，把資源放進去，再重新打包簽名，已經完全實現了。
Android上面的dotnet使用者程式碼我們也一鍵編譯成dll當資源放了進去，因為android上monoruntime用的jit，很容易實現。
在ios一鍵釋出要麻煩一點，需要用monoaot 將dotnet使用者程式碼編譯為.a,再用模板包重簽名。說實話aot弄成.a 我不知道怎麼弄。Ipa重簽名我也不知道怎麼弄。
但是aot弄成.a,我們可以找到unity原始碼學習，我們可以找暢遊的引擎原始碼學習。Ipa重簽名，國內一把越獄平臺都有這功能，還有個著名的軟體iresign，我們去找他的原始碼學習。至少我們知道方向在哪裡。
實現了一鍵釋出，我們還讓釋出階段不依賴xamarin了，xamarin僅需要出模板包。
這樣也可以幫使用者節省一個xamarin授權的費用。
這就是新FB引擎想去的方向。
如果你想支援贊助我們的工作
用支付寶：
lightsever@hotmail.com
李劍英
如果你是想要加入討論
用QQ群：223823428