我為什么想干掉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