我为什么想干掉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引擎想去的方向。 

如果你是想要加入讨论