在低端设备上读取大型XML时，getXml（）的内存不足

Question

我有一个应用程序在Android 2.2.2上运行，并且在尝试读取较大（〜500kb）的XML文件时内存不足。

的XML文件位于/ RES/XML，它的阅读像这样（简化地）：

XmlResourceParser xmlParser = getResources().getXml(R.xml.myxml); 

这完全运行在大多数设备（尽管它需要几秒钟就可以完成）。然而，我正在测试低端设备（华为M835），并且在尝试加载时似乎耗尽内存..它永远不会完成该呼叫。

我得到的错误不是很有帮助 - 它只是一个没有适当的堆栈跟踪或任何东西的大转储。这里是我的全logcat的响应，一旦我执行上面的一行：

DEBUG(1700): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 
DEBUG(1700): Build fingerprint: 'Huawei/M835/hwm835/M835:2.2.2/HuaweiM835/C177B622:user/release-keys' 
DEBUG(1700): pid: 2798, tid: 2798 >>> com.mypackage.MyApplication <<< 
DEBUG(1700): signal 11 (SIGSEGV), fault addr 00000000 
DEBUG(1700): r0 46a95008 r1 00000000 r2 0011ce24 r3 00000018 
DEBUG(1700): r4 0013e8f0 r5 00000000 r6 a8125a48 r7 0011ce24 
DEBUG(1700): r8 beebc460 r9 4166ebc0 10 416ae1c0 fp 4166ebbc 
DEBUG(1700): ip 80000000 sp beebc3e8 lr a8119b8b pc afd0f110 cpsr a0000010 
DEBUG(1700):   #00 pc 0000f110 /system/lib/libc.so 
DEBUG(1700):   #01 pc 00019b88 /system/lib/libutils.so 
DEBUG(1700):   #02 pc 000459e6 /system/lib/libandroid_runtime.so 
DEBUG(1700):   #03 pc 00011cb4 /system/lib/libdvm.so 
DEBUG(1700):   #04 pc 0003c3d8 /system/lib/libdvm.so 
DEBUG(1700):   #05 pc 00023cb4 /system/lib/libdvm.so 
DEBUG(1700):   #06 pc 0001c244 /system/lib/libdvm.so 
DEBUG(1700):   #07 pc 0005155a /system/lib/libdvm.so 
DEBUG(1700):   #08 pc 00058faa /system/lib/libdvm.so 
DEBUG(1700):   #09 pc 00016c78 /system/lib/libdvm.so 
DEBUG(1700):   #10 pc 0001d35c /system/lib/libdvm.so 
DEBUG(1700):   #11 pc 0001c1f4 /system/lib/libdvm.so 
DEBUG(1700):   #12 pc 000513c8 /system/lib/libdvm.so 
DEBUG(1700):   #13 pc 0003ec58 /system/lib/libdvm.so 
DEBUG(1700):   #14 pc 0002e908 /system/lib/libandroid_runtime.so 
DEBUG(1700):   #15 pc 0002f7be /system/lib/libandroid_runtime.so 
DEBUG(1700):   #16 pc 00008c86 /system/bin/app_process 
DEBUG(1700):   #17 pc 0000d362 /system/lib/libc.so 
DEBUG(1700): code around pc: 
DEBUG(1700): afd0f0f0 1a00002b e88d0fe0 e2603000 e213301c 
DEBUG(1700): afd0f100 0a00000a e1530002 8202301c e1b0ce03 
DEBUG(1700): afd0f110 28b100f0 48b10300 28a000f0 48a00300 
DEBUG(1700): afd0f120 e3130004 1491a004 1480a004 e0422003 
DEBUG(1700): afd0f130 e2522020 3a000008 e3c1c01f e28cc040 
DEBUG(1700): code around lr: 
DEBUG(1700): a8119b68 2a006063 1c38d00e ee7cf7f5 28006160 
DEBUG(1700): a8119b78 200cd103 61204240 1c29e086 f7f51c3a 
DEBUG(1700): a8119b88 6965ee60 686a61a5 886b61e2 d8014293 
DEBUG(1700): a8119b98 d90a42ba 4a3f493e 18712005 686e18b2 
DEBUG(1700): a8119ba8 96009701 ee70f7f5 1c27e063 372418ab 
DEBUG(1700): stack: 
DEBUG(1700):  beebc3a8 00000000 
DEBUG(1700):  beebc3ac beebc3f8 [stack] 
DEBUG(1700):  beebc3b0 00000000 
DEBUG(1700):  beebc3b4 afd103f0 /system/lib/libc.so 
DEBUG(1700):  beebc3b8 00000003 
DEBUG(1700):  beebc3bc afd41724 /system/lib/libc.so 
DEBUG(1700):  beebc3c0 46a95008 
DEBUG(1700):  beebc3c4 c0000000 
DEBUG(1700):  beebc3c8 beebc460 [stack] 
DEBUG(1700):  beebc3cc 4166ebc0 
DEBUG(1700):  beebc3d0 416ae1c0 /dev/ashmem/dalvik-LinearAlloc (deleted) 
DEBUG(1700):  beebc3d4 afd0c741 /system/lib/libc.so 
DEBUG(1700):  beebc3d8 00000000 
DEBUG(1700):  beebc3dc afd103f0 /system/lib/libc.so 
DEBUG(1700):  beebc3e0 df002777 
DEBUG(1700):  beebc3e4 e3a070ad 
DEBUG(1700): #00 beebc3e8 00000000 
DEBUG(1700):  beebc3ec a8125a48 /system/lib/libutils.so 
DEBUG(1700):  beebc3f0 0011ce24 [heap] 
DEBUG(1700):  beebc3f4 beebc460 [stack] 
DEBUG(1700):  beebc3f8 4166ebc0 
DEBUG(1700):  beebc3fc 416ae1c0 /dev/ashmem/dalvik-LinearAlloc (deleted) 
DEBUG(1700):  beebc400 4166ebbc 
DEBUG(1700):  beebc404 46a95008 
DEBUG(1700):  beebc408 0013e8f0 [heap] 
DEBUG(1700):  beebc40c a8119b8b /system/lib/libutils.so 
DEBUG(1700): #01 beebc410 000a8b90 [heap] 
DEBUG(1700):  beebc414 1fe0106c 
DEBUG(1700):  beebc418 00000001 
DEBUG(1700):  beebc41c 0013e248 [heap] 
DEBUG(1700):  beebc420 ad3780f8 /system/lib/libandroid_runtime.so 
DEBUG(1700):  beebc424 0000aaa0 [heap] 
DEBUG(1700):  beebc428 0013e8f0 [heap] 
DEBUG(1700):  beebc42c 0013e248 [heap] 
DEBUG(1700):  beebc430 ad3780f8 /system/lib/libandroid_runtime.so 
DEBUG(1700):  beebc434 0000aaa0 [heap] 
DEBUG(1700):  beebc438 0013e8f0 [heap] 
DEBUG(1700):  beebc43c ad3459e9 /system/lib/libandroid_runtime.so 
ActivityManager(124): Process com.mypackage.MyApplication (pid 2798) has died. 

这个问题似乎发生，因为该设备只有堆大小分配22MB（？）。当阅读Runtime.getRuntime().maxMemory(),.totalMemory()和freeMemory()时，我分别得到22mb，2mb和0.5mb。因为显然只有0.5MB“免费”，所以它不能解析〜0.5mb的XML文件。

（测试时，我的其他测试设备上，我得到32MB，5MB，和2MB）

我的问题是：有没有什么办法来加载这个XML没有崩溃这样的应用程序？

顺便提一下，我在应用程序上有一些内存密集型位图操作，但是这不会引发任何错误...它仍然设法在24mb的限制下运行。我很难理解为什么简单的XML解析会给我带来很多麻烦。

这是一个未修改的ROM，该模型的股票商业安装。

我可以正确解析其他XML文件，甚至这个XML文件，只要它们更小。例如，我用这个文件的一个190kb版本取得了成功。

我读过SIGSEGV错误可能表示固件问题。尽管如此，这个问题似乎很清楚，因为它没有内存来解析大型XML，我想要想办法绕过这个错误。

Answer 1

要与getXML()使用预解析（因此加载它完全到内存中），所以你的情况我建议的XML移动到raw文件夹，并与SAXParser的，其解析阅读它的XML文件它读取它时的xml（只保留当前节点所需的内存）。

你所做的位图处理是本地完成的，而不是Java代码，它允许更好的内存管理，这就是为什么你没有这些问题。