干掉Unity3D

我为什么想干掉Unity3D?

这个问题容我不答,每个做技术的人总有一些完美主义。

你使用u3d的过程中是不是痛并快乐着呢。

就从两个国内具有相当普遍性的痛点说起。

  1. il2cpp,unity作出了这个决策以来,导致每个程序员都拥有了大姨妈,每当接入ios平台,就得再死上一次。每当看一眼打出来的包的容量,就会有一种压力山大的感觉。
  2. unity的底层c++ api没有公开,如果想要接入脚本层,只能通过dotnet进行互操作,导致u3d平台上难以实现比较完美的脚本方案。首先性能就是一个问题

还有第三个痛点,一直是我的一块心病。Unity不能在手机平台断点调试,本来断点调试作为程序员的最后手段,居然被剥夺了。很是担忧。

痛点这么多,还一直赖在Unity3D,又是为什么呢

因为unity3d还有一些优点,太过于吸引人。

  1. 成熟、稳定(稳定要打个折扣)的IDE
  2. 多平台一键发布(IOS这个一键也差了一点,是发布为xcode项目)
  3. C#语言buf加持

有没有可能解决痛点,保持优势?

当然有

让我们看一下unity3d的架构,这是个我随便画的示意图

干掉Unity3D

Unity3d的架构是以c++编写的引擎框架为基础,这里很传统。

反传统之处在于unity3d完全将所有的接口置于monoruntime之后,unity本身的部分功能也是由dotnet开发,比如unityengine.ui

用户代码更是完全限制为使用dotnet开发。

虽然unity提供了plugin机制,可以用其他语言混编,但是这些插件均无法访问unity底层c++代码(或许可以,我没有见到任何资料)。

这导致了unity无法高效的接入c++实现的脚本语言,lua在unity的实际表现有目共睹。

这是痛点2的原因,痛点1是unity自己作死,不多说。痛点3也是unity工作没有做好。

解决痛点

有没有一个架构,可以解决痛点123呢,答案是有。

干掉Unity3D

基于xamarin方案,android、ios平台均可断点调试

底层代码同时对monoruntime和脚本层公开接口,可以插入c++实现的各种脚本,比如lua,并取得原生性能。

用户代码分为dotnet 和 脚本两种,两者之间不互访,通过底层接口互发消息。

Il2cpp自然也不用担心。

还有附加的好处,c# 5.0走起。

Xamarin平台上现有monogame,他是都在monoruntime之后实现的,调用otk,也不能提供原生性能,也不可以插入原生脚本。

该方案实现在于:

  1. 为xamarin编写不同平台的原生插件,主要是绘图、音效、触摸、键盘这些底层公开接口。主要是ios、android、当然pc也要,pc可以不用xamarin,改为windows+vs,这样在windows调试更给力。
  2. P/invoke导出到dotnet,对接什么脚本层也做对应导出。

这样重度用户代码用dotnet编写,轻度易变代码用脚本编写,轻度代码为资源,任何平台均可实现下载执行。

保持优势

  1. c#加持,更优了,unity整合c# 3.5,xarmarin整合c# 5.0,你还想说什么。
  2. 多平台一键发布,这个xamarin没有做,需要我们自己做。
  3. 成熟稳定的场景编辑器,这个需要我们自己做。

场编怎么做,抄袭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

 

上一篇:SQL字符串分割解析


下一篇:CentOS下Lua 环境的搭建