3

私はここ数日、非常に大きなキャンバスを機能させることを試みてきました。

すべてをキャンバスに追加した後、キャンバスの幅が30,000になることもありますが、このコードをondrawメソッドに追加すると、水平方向のスクロールが非常に遅くなります。

次に、すべてをビットマップに追加してから、onDrawメソッドでビットマップを描画しようとしました。これは小さいビットマップでは正常に機能しましたが、幅が30,000のビットマップではメモリ不足エラーが発生します。

誰かが解決策を提案できますか？私は今何を試すべきかわかりません。

ありがとう

編集ビットマップをConfig.RGB_565に変更しようとしましたが、それでもメモリエラーが発生します。

4

4 に答える 4

5

大きな Canvas を扱うと、OutOfMemoryExceptions が継続的に発生します。Canvas は Bitmap に書き込み、30,000 by X Bitmap のようなものは大量のメモリを占有します。あなたの最善の代替手段は、表示したいものに対する表示画面の位置を追跡し、必要なものだけをキャンバスに書き込むことだと思います。

たとえば、ユーザーが 100 ピクセル下および左にスクロールした場合、1024 x 768 ディスプレイの場合、仮想の 30,000 x 30,000 キャンバス (全体を描画するわけではない) で 1124 および 868 に表示されるものをキャンバスに描画します。 ）。

于 2012-10-23T01:40:02.247 に答える
1

ArrayListにはいくつのエントリがありますか、かなり大きいようです。

私の理解では、onDraw（）ですべてを描画することにOoMの問題はありませんが、それは本当に遅いですか？その場合、最もよく似た理由は、大量のdrawTextを呼び出していることです。これは非常に遅いです。基本的に、描画する文字列が10000個ある場合、システムはそれらのすべてを測定する必要があります。指定された文字列が大きなキャンバスに表示されるかどうかを判断すると、実際の描画部分も遅くなります。

すべてのテキストを描画するのにかかる時間をテストして、これが当てはまるかどうかを確認できます。

それが実際に当てはまる場合、最も簡単な方法は、各文字/数字をビットマップにマップすることです。アーティストにPNGファイルを作成させるか、onCreate（Bundle）または他の-Activity-creationメソッドごとに1回、ビットマップをString-to-Bitmap HashMapに配置し、呼び出す代わりに

canvas.drawText(bellNumber, xPad, mOriginY, paint);

あなたは次のようなものを呼びます

canvas.drawBitmap(hash.get(bellNumber), src, dst, paint); //remember to reuse src & dst

これにより、文字列関連の描画オーバーヘッドが完全にバイパスされ、onDraw操作がかなり高速になります。

于 2012-10-27T16:46:43.800 に答える
1

ビットマップのサイズはデバイスによって制限されていますが、通常は特定のデバイスのサイズに依存します。また、ビットマップは、SDK ベースのアプリでメモリ リークを引き起こす主な原因の 1 つです。最善の策は、キャンバスを小さなセクションに分割するか、openGL でキャンバスをレンダリングするなどの他のオプションを検討することです (これにもサイズ制限がありますが、通常はレンダリングが高速になります)。

于 2012-10-29T05:08:29.487 に答える
0

Flynn81 は全体的に良い回答をしています。行ロジックを見て、私はいくつかの計算を行い、どの行を描画する必要があるかを予測しようとします. テキストを扱っているので、フォント メトリックを取得できます (テキストを測定します)。数字を扱っているように見えるので、「0123456789」のような文字列の高さを測定してみてください。

これをプロファイリングしたいかもしれませんが、線画をキャッシュできるかもしれません。

本当に勇気がある場合は、ListView とカスタム ドローアブル タイプを試してみてください。

于 2012-10-31T13:16:54.130 に答える