新功能沟通

[loongly]

记录一些新功能计划

[loongly]

绑定代码不用每次构建都生成，这样不利于代码稳定，但是如果提前生成绑定代码不利于Unity的strip操作，造成代码膨胀。 可以考虑把提前生成的绑定代码作为代码库，构建时用到的接口再从这个库中取出来避免重复生成。 注意接口之间的引用关系

[loongly]

支持Android版本。 需要支持Android平台上mono runtime的setup 先使用jit模式运行。 考虑集成问题

[quicklyslow]

想了解一下这次更新 dev1 分支的主要改进，是因为之前有什么问题导致的。在群里看的时候没有能理解。

[loongly]

想了解一下这次更新 dev1 分支的主要改进，是因为之前有什么问题导致的。在群里看的时候没有能理解。

在issue页面沟通对项目更有益，后面功能修改都尽量以issue的形式跟踪。 这里提到的这次修改已经合并到主干升到了0.3版本，这次主要修改的是绑定策略：

• 上个版本是把Unity.dll直接拿到Mono内执行，把icall接口直接绑定到引擎内，使Mono内有一套完整的Unity接口，然后支持用户配置一些需要在il2cpp/mono内交叉调用的dll，并在C#层对这些dll生成‘Adapter’和‘Wrapper‘(类似c#和lua的绑定)，这样这些dll就可以作为插件提供给Mono环境。这个策略是我比较喜欢的，大部分执行代码运行在Mono内执行，il2cpp内的‘Adapter’仅作为插件打辅助。
• 这种策略好处是整个运行环境都在Mono内，如果是特定的项目甚至可以调整到完全避免跨虚拟机接口，同时也带来了问题，首先是修改门槛较高，自动生成的icall绑定代码并不完美(Unity的icall接口绑定应该是手动实现的)，需要手动调整c代码实现绑定。其次是Unity的挂载脚本，脚本上会记录状态信息。比如挂载的UGUI组件，向这些组件上注册事件其实就是修改了C#层的状态。针对这种情况可以直接把这类需要执行在il2cpp内的dll配置为生成Wrapper，但总感觉是在手动补漏(可能还有XGUI)。
• 新版本的策略是Unity的dll全部生成Wrapper(向lua绑定器看齐)，然后通过AST过滤器过滤出只执行icall调用同时不会修改任何状态的接口保留，这样同时在il2cpp/mono内执行的类型状态信息只有一份，通用性会更好，也降低了复杂度。

[loongly]

关于icall自动绑定的阻碍： Unity的C#对象和Native对象绑定并不是统一通过Object， icall接口传递到native的对象并不都是blitable的，比如传递一个FileStream - - C#层的对象越来越多的记录状态信息