Java 当另一个屏幕初始化变量时，Libgdx-android版本崩溃

所以我通过制作一个简单的游戏来尝试Libgdx。桌面版运行得很好，尽管我对android版有一些问题

第一个屏幕主菜单工作得很好。这里没问题

但是，当第二个屏幕游戏调用方法show并初始化spritebatch、camera等时，它会崩溃，即使它的show方法与第一个屏幕的show方法相同

public void show() {

    batch = new SpriteBatch();
    sr = new ShapeRenderer();

    camera = new OrthographicCamera(Gdx.graphics.getWidth(), Gdx.graphics.getHeight());

例如，前三行立即导致android版本崩溃。为变量指定唯一的名称也没有帮助

你知道我可能做错了什么吗

日志：

04-29 06:53:10.450: I/dalvikvm(915): Debugger is active
04-29 06:53:10.500: I/System.out(915): Debugger has connected
04-29 06:53:10.500: I/System.out(915): waiting for debugger to settle...
04-29 06:53:10.710: I/System.out(915): waiting for debugger to settle...
04-29 06:53:10.920: I/System.out(915): waiting for debugger to settle...
04-29 06:53:11.120: I/System.out(915): waiting for debugger to settle...
04-29 06:53:11.330: I/System.out(915): waiting for debugger to settle...
04-29 06:53:11.530: I/System.out(915): waiting for debugger to settle...
04-29 06:53:11.730: I/System.out(915): waiting for debugger to settle...
04-29 06:53:11.940: I/System.out(915): waiting for debugger to settle...
04-29 06:53:12.140: I/System.out(915): waiting for debugger to settle...
04-29 06:53:12.340: I/System.out(915): waiting for debugger to settle...
04-29 06:53:12.540: I/System.out(915): waiting for debugger to settle...
04-29 06:53:12.740: I/System.out(915): waiting for debugger to settle...
04-29 06:53:12.940: I/System.out(915): waiting for debugger to settle...
04-29 06:53:13.150: I/System.out(915): waiting for debugger to settle...
04-29 06:53:13.390: I/System.out(915): debugger has settled (1339)
04-29 06:53:13.820: D/dalvikvm(915): Trying to load lib /data/app-lib/com.me.game-1/libgdx.so 0xb3dc7ab8
04-29 06:53:13.820: D/dalvikvm(915): Added shared lib /data/app-lib/com.me.game-1/libgdx.so 0xb3dc7ab8
04-29 06:53:13.830: D/dalvikvm(915): No JNI_OnLoad found in /data/app-lib/com.me.game-1/libgdx.so 0xb3dc7ab8, skipping init
04-29 06:53:14.820: I/AndroidInput(915): sensor listener setup
04-29 06:53:15.330: I/Choreographer(915): Skipped 37 frames!  The application may be doing too much work on its main thread.
04-29 06:53:15.590: D/gralloc_goldfish(915): Emulator without GPU emulation detected.
04-29 06:53:15.650: I/AndroidGraphics(915): OGL renderer: Android PixelFlinger 1.4
04-29 06:53:15.650: I/AndroidGraphics(915): OGL vendor: Android
04-29 06:53:15.660: I/AndroidGraphics(915): OGL version: OpenGL ES-CM 1.0
04-29 06:53:15.660: I/AndroidGraphics(915): OGL extensions: GL_EXT_debug_marker GL_OES_byte_coordinates GL_OES_fixed_point GL_OES_single_precision GL_OES_read_format GL_OES_compressed_paletted_texture GL_OES_draw_texture GL_OES_matrix_get GL_OES_query_matrix GL_OES_EGL_image GL_OES_EGL_sync GL_OES_compressed_ETC1_RGB8_texture GL_ARB_texture_compression GL_ARB_texture_non_power_of_two GL_ANDROID_user_clip_plane GL_ANDROID_vertex_buffer_object GL_ANDROID_generate_mipmap 
04-29 06:53:15.660: I/AndroidGraphics(915): framebuffer: (5, 6, 5, 0)
04-29 06:53:15.660: I/AndroidGraphics(915): depthbuffer: (16)
04-29 06:53:15.670: I/AndroidGraphics(915): stencilbuffer: (0)
04-29 06:53:15.680: I/AndroidGraphics(915): samples: (0)
04-29 06:53:15.680: I/AndroidGraphics(915): coverage sampling: (false)
04-29 06:53:15.740: I/AndroidGraphics(915): Managed meshes/app: { }
04-29 06:53:15.740: I/AndroidGraphics(915): Managed textures/app: { }
04-29 06:53:15.760: I/AndroidGraphics(915): Managed shaders/app: { }
04-29 06:53:15.760: I/AndroidGraphics(915): Managed buffers/app: { }
04-29 06:53:16.430: D/dalvikvm(915): GC_FOR_ALLOC freed 111K, 6% free 3113K/3292K, paused 214ms, total 220ms
04-29 06:53:17.070: I/ARMAssembler(915): generated scanline__00000177:03545444_00001001_00000000 [ 94 ipp] (146 ins) at [0xaa8f41f0:0xaa8f4438] in 10000000 ns
04-29 06:53:17.290: I/ARMAssembler(915): generated scanline__00000177:03010144_00000000_00000000 [ 26 ipp] (63 ins) at [0xaa8f4440:0xaa8f453c] in 0 ns
04-29 06:53:22.620: I/System.out(915): hit

---

可能你创建了太多的SpriteBatch和ShaperEnder，这些对象需要大量的内存，当然，当你在android上运行它时，堆空间更少，没有Stacktrace和提供的代码，这是我们唯一能做的假设。是的，这是真的。只有在初始化新内容时才会发生崩溃。如果从上一个屏幕传递批处理，则不会导致崩溃。然而，将每一件事情都传递到新屏幕上会有点麻烦。哦，我添加了LogCat提供的信息。在堆栈跟踪中应该有一个异常，包含输入的类和行的列表。我不确定上面的内容是从哪里来的。可能是调试器/记录器。