MonoTouch AOT编译器 - 大型方法失败

Question

我正在开发一款游戏,我们一直在以JSON格式存储我们的关卡信息.这些级别非常大,所以我们切换到只将它们存储在普通的C#中:

• 顶级方法具有用于级别/对象名称的switch语句
• 有几种自动生成的方法使用标准属性初始化程序"新建"对象树

例:

private OurObject Autogenerated_Object1()
{
   return new OurObject { Name = "Object1", X = 1, Y = 2, Width = 200, Height = 100 };
}

除了这些方法非常大并且具有其他对象的嵌套列表/字典等.

这加快了将级别从2-3秒加载到几分之一秒的时间(在Windows上).我们的数据大小也相当小,因为编译的IL与JSON相比.

问题是当我们在MonoDevelop中为MonoTouch编译这些时,我们得到:

mtouch exited with code 1

随着-v -v -v开启,我们可以看到错误:

MONO_PATH=/Users/jonathanpeppers/Desktop/DrawAStickman/Game/Code/iOS/DrawAStickman.iPhone/bin/iPhone/Release/DrawAStickmaniPhone.app /Developer/MonoTouch/usr/bin/arm-darwin-mono --aot=mtriple=armv7-darwin,full,static,asmonly,nodebug,outfile=/var/folders/4s/lcvdj54x0g72nrsw9vzq6nm80000gn/T/tmp54777849.tmp/monotouch.dll.7.s "/Users/jonathanpeppers/Desktop/DrawAStickman/Game/Code/iOS/DrawAStickman.iPhone/bin/iPhone/Release/DrawAStickmaniPhone.app/monotouch.dll"
AOT Compilation exited with code 134, command:
MONO_PATH=/Users/jonathanpeppers/Desktop/DrawAStickman/Game/Code/iOS/DrawAStickman.iPhone/bin/iPhone/Release/DrawAStickmaniPhone.app /Developer/MonoTouch/usr/bin/arm-darwin-mono --aot=mtriple=armv7-darwin,full,static,asmonly,nodebug,outfile=/var/folders/4s/lcvdj54x0g72nrsw9vzq6nm80000gn/T/tmp54777849.tmp/DrawAStickmanCore.dll.7.s "/Users/jonathanpeppers/Desktop/DrawAStickman/Game/Code/iOS/DrawAStickman.iPhone/bin/iPhone/Release/DrawAStickmaniPhone.app/DrawAStickmanCore.dll"
Mono Ahead of Time compiler - compiling assembly /Users/jonathanpeppers/Desktop/DrawAStickman/Game/Code/iOS/DrawAStickman.iPhone/bin/iPhone/Release/DrawAStickmaniPhone.app/DrawAStickmanCore.dll
* Assertion: should not be reached at ../../../../../mono/mono/mini/mini-arm.c:2758

在编译AOT时,方法中的行数是否有限制？我们可以通过一些论证mtouch来解决这个问题吗？有些文件工作正常,但特别是导致错误的文件有3000行方法.无论如何编译模拟器都能正常工作.

这仍然是一个实验,所以我们意识到这是一个非常疯狂的情况.

Answer 1

当您遇到 AOT 编译器中不应出现的条件时，就会出现这些断言。请将此类情况报告给http://bugzilla.xamarin.com

我们可以传递一些参数给 mtouch 来解决这个问题吗？

您也许可以通过使用 LLVM（或不使用它）来解决此问题，因为它是不同的代码生成引擎。根据这种情况发生的阶段（有些是共享的），您可能不会遇到相同的情况。

当然，LLVM 构建速度较慢并且不支持调试，因此这并不是适合所有情况的理想解决方法。