2
私のplay-consoleでこれらのエラーが発生しています。誰かが部屋のOOMエラーをどのようにして最善に処理するかを知っていますか？ROOM OutOfMemoryErrorR（OOM）
java.lang.OutOfMemoryError:
at android.database.CursorWindow.nativeGetString (Native Method)
at android.database.CursorWindow.getString (CursorWindow.java:451)
at android.database.AbstractWindowedCursor.getString (AbstractWindowedCursor.java:51)
at org.walleth.data.transactions.TransactionDAO_Impl$8.compute (TransactionDAO_Impl.java:1272)
at org.walleth.data.transactions.TransactionDAO_Impl$8.compute (TransactionDAO_Impl.java:1212)
at android.arch.lifecycle.ComputableLiveData$2.run (ComputableLiveData.java:87)
at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1133)
at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:607)
at java.lang.Thread.run (Thread.java:762)
でmodule.gradleファイルにヒープサイズを増やしてください。 OOMは2つのトリガを持っています。メモリブロックをあまりにも大きく要求する（「ビットマップ」と思う）か、どこかでリークが原因でメモリが切れてしまっています。後者の場合、クラッシュしている場所では、最終的にはメモリが不足している場所がありますが、必ずしも漏れがある場所ではありません。あなたは、どのくらいの割り当てが失敗したかを示すこのクラッシュログの変形を取得していますか？ – CommonsWare
残念ながら、私は割り振りの大きさがわからないクラッシュログの変種を持っていません。しかし、それは巨大な文字列である可能性があります（データフィールドは場合によっては大きくなるかもしれません）。 - このOOMを捕まえることができ、このアイテムを無視する方法はありますか（契約の展開が最も可能性があり、 ） – ligi
制御できないバックグラウンドスレッドで発生しているため、特定の例外を非常にうまくキャッチする方法がなく、LiveDataは例外を伝播しません。あなたのDAOにLiveDataを返すのではなく、代わりにRxJavaタイプを使用することを検討してください。または、このクエリをDAOで同期させ、自分のバックグラウンドスレッドの@Queryメソッドを呼び出すように手配します。 – CommonsWare