ほとんどの場合、アプリでアンドロイド pdf ライター (apw) を正常に使用しています。ただし、PDF ドキュメントに高解像度を含めようとすると、メモリ不足の例外が発生します。
pdf ファイルを作成する直前に、ライブラリはコンテンツ自体を文字列 (未加工の pdf コンテンツを表す) に変換し、その後バイト配列に変換する必要があります。バイト配列は、ファイル出力ストリームでファイルに書き込まれます (Web サイトの例を参照)。
ビットマップ イメージのすべてのピクセルを文字列形式で表すとメモリを大量に消費するため、文字列が生成されるときにメモリ不足が予想されます。Android API を使用して画像をダウンサンプリングすることもできますが、画像を高解像度 (~2000 x 1000) で pdf に入れることが不可欠です。
PDFの高解像度画像を生成できるように見えるスキャナータイプのアプリがたくさんあるので、確かにそれを回避する方法があるはずです. 確かに、彼らは他のライブラリを使用しているかもしれませんが、このライブラリが無料で人気があることを考えると、このライブラリでそれを回避する方法を考え出した人が確実にいます(?)。
開発者にメールしましたが、返事はありませんでした。
潜在的な解決策（私が考えることができる）には次のものがあります。
ライブラリを変更して、たとえば PDF の最初の 10% を表す文字列を読み込み、チャンクごとにファイルに書き込みます。（編集）
実際の pdf コンテンツが pdfwriter オブジェクトに書き込まれているため、ライブラリを変更して stringoutput ストリーム、またはその他の出力ストリームを一時ファイル (または最終ファイル) に出力します。
しかし、相対的な Java 初心者 (さらには PDF 仕様の初心者) として、私はこれを自分で行うのに十分なほどライブラリを理解することができません。
誰かがこの問題に遭遇し、それを回避する方法を見つけましたか? 提案を危険にさらしたり、何らかの修正があるかどうかを確認するためにライブラリ自体を調べたりすることをいとわない人。
ご協力いただきありがとうございます。nme32
編集：
Logcat によると、クラッシュ前のヒープ サイズは 40 ～ 60 MB の範囲でした。デバイスによっては 50 MB の球場にありますが、Android は実行中のアプリに応じて利用可能なメモリを制限することを理解しています (そうでない場合は修正してください)。
画像をロードするとき、APWは基本的にそれをビットマップに変換すると思います。つまり、画像をピクセル単位で表してから文字列形式にします。つまり、使用する画像形式は関係ありません。ビットマップでもかまいません。