だから私は一種の粒子シミュレーターを書いています。それが何であるかを知っているなら、「落ちる砂ゲーム」のようなものですが、今は障害物にぶつかっています。私がこれを行っている方法は、基本的に現在位置 (int x, int y) を持つパーティクル オブジェクトを持っていることです。私がそれらを描画/移動する方法は、Android パネルのスレッドと onDraw イベントを使用することです。onDraw が呼び出されるたびに、すべてのパーティクルをループし、底に当たらない限り 1 ピクセル下に移動してから描画します。これは約 200 個のパーティクルに到達するまでは非常にスムーズで、その後 fps が大幅に低下します。私はこれが私がやっている方法で計算が重いことを知っています.
前もって感謝します。
OpenGL ESハードウェア アクセラレーションとrenderscriptを調べることをお勧めします。コードに関してより効率的なソリューションは得られません（それについては他の回答を参照してください）。ただし、使用する処理能力が大幅に向上します。GPU でシミュレーション全体を実行することもできます (実装の詳細がわからない可能性があります)。
編集
また、まだ Java で処理を行うことにした場合は、DDMS でのメソッド プロファイリングを確認する必要があります。これにより、パフォーマンスのボトルネックがどこにあるかを視覚化できます。
これには、個々のピクセルの描画機能を使用していると思いますか？それは確かに遅いでしょう。
それを改善する方法がいくつかあります。まず、ピクセルをメモリ内のビットマップに配置し、ビットマップ全体を同時に描画します。第 2 に、パーティクルは常に 1 ピクセルだけ下に移動するため、すべてを再プロットする代わりに、ビットマップの一部をスクロールできます。Android にスクロールがない場合は、ビットマップを 1 ピクセル下に描画し、スクロールの上のパーティクル用に新しいビットマップを開始します。底の粒子を修正する必要がありますが、それらの数は少なくなります。
私はこれまでにこのようなことをしたことはありませんが、いくつかの複雑なセル オートマトンを実行しました。これが曖昧すぎる場合は申し訳ありません。
ここでの基本的な考え方は、「落下し続ける」または「動かない」必要があるすべてのパーティクルをマークし、それらを複雑な処理から除外することです (「落下」リスト用の特別な短い/高速プロセッサを使用 - 必要なのは、それぞれをドロップすることだけです)。ピクセル単位)。
最終的には、多くの高速粒子が得られます。山/湖にいるものと雨が降っているもの。残りの粒子は、斜面の端、湖の頂上、またはその他の複雑な位置にある粒子です。速い粒子があるほど多くないはずです。
粒子の種類ごとに色を付けて視覚的にマークします。複雑な粒子は明るい赤です。それでも遅い場合を見つけて、他にどのような高速プロセッサを作成する必要があるかを確認してください。たとえば、大量の砂の山を作ると、斜面に沿って赤い領域がたくさん作成されることに気付くかもしれません。山の斜面に沿った「ローリング ゾーン」のスピードアップに投資したいと思うかもしれません。
それが理にかなっていることを願っています。何かを見つけたら、戻って編集することを忘れないでください。
画像を少しぼかすと、一度に半分の粒子を移動するだけで、おそらく4分の1だけを移動して、すべてを印刷できます。これにより、計算が削減され、ユーザーには表示されず、すべての粒子が移動しているように感じられます。
しかし、あなたが何を選んだとしても、すべてのユーザーが強力なAndroidデバイスを持っているわけではないので、強い制限を課すべきだと思います。
よろしく、ステファン
粒子同士が近接していれば、3 つ以上の粒子を表すオブジェクトを作成できると思います。
画面に複数の粒子を表示すると、粒子のセットが見過ごされることがあります。