ローエンドのデバイスで大きなXMLを読むときにgetXml（）のメモリが不足しています

Question

Android 2.2.2で動作するアプリケーションを持っていて、やや大きめの（〜500kb）XMLファイルを読み込もうとするとメモリが不足しています。

は、XMLファイルは、/ RES/XMLにあり、それは（簡略化して）このように読んでいます：

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

それが完了するまでに数秒かかるんが、これは（ほとんどのデバイス上で完璧に動作します）。私はローエンドのデバイス（Huawei M835）に対してテストを行っていますが、ロードしようとするとメモリが不足しているようです。その呼び出しは決して終了しません。

私が得るエラーはあまり有用ではありません - それは適切なスタックトレースや何もない大きなダンプです。 （？）

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. 

問題は、このデバイスが唯一のヒープサイズが割り当てられた22メガバイトを持っているために起こるようだ：私は上記の行を実行したら、ここに私の完全なlogcat応答です。 Runtime.getRuntime().maxMemory()、.totalMemory()、およびfreeMemory()を読むと、私はそれぞれ22MB、2MB、0.5MBとなります。明らかにわずか0.5MBの「空き」しかないので、〜0.5MBのXMLファイルを解析することはできません。

（つまり私の他の試験装置上で、私が得る32メガバイト、5メガバイト、および2メガバイトをテストする場合。）

私の質問です：そのようなアプリケーションをクラッシュすることなく、このXMLをロードする方法はありますか？

ちなみに私はアプリケーション上でメモリを大量に使用するビットマップ操作をしていますが、それでもエラーは発生しません。それでも24MBの制限値で動作します。私は、単純なXML構文解析がなぜ私に大きなトラブルを与えるのかを理解するのに苦労しています。

これは変更されていないROMで、そのモデルの商用インストールです。

私は、他のXMLファイル、またはこのXMLファイルであっても、サイズが小さい限り、適切に解析できます。たとえば、このファイルの190kbバージョンで成功しました。

私は、SIGSEGVエラーがファームウェアの問題を示している可能性があることを読みました。それでも、大きなXMLを解析するメモリがないため、このエラーを回避する方法を考えたいので、問題は起こっていることは明らかです。

Answer 1

あなたはgetXML()で使用するXMLファイルは事前に解析されます（したがって、完全にメモリにロード）するので、あなたのケースで私がrawフォルダにXMLを移動することをお勧めし、解析してSAXParser、でそれを読んでxmlはそれを読み込む（現在のノードに必要なだけメモリに保持する）。

あなたの行うビットマップ処理は、Javaコードではなく、ネイティブで実行されるため、メモリ管理が向上します。そのため、問題は発生しません。