3

Android Phone 用のアプリケーションを作成していますが、奇妙な「スロットリング」が発生しています。電話内で何かを処理するためにアプリケーションが行っていることを停止するために、セマフォが呼び出されているためだと思います。私は積極的ではありませんが。

これらのブレイクアウトを広める方法や、アプリケーションでいわばラグ スパイクがほとんどないことをユーザーに見えにくくする方法があるかどうかに興味があります。

編集:いくつかの詳細情報、私が現在実行しているのは画像の2次元配列です-インスタンス化された〜8000の時点で約80のみが描画されます。色合いが RGB0 (真っ黒) でない場合にのみ描画します。アップデートのランタイム ループは、プレイヤーに最も近い画像をチェックし、RGB 0.2f の基本的な最小限の照明を与えます。それ以外は、基本的なイベント ハンドラーと移動/ビュー ポート ループが更新されています。Androidネイティブではなく、Libgdxフレームワークを使用していることに注意してください。だからOpenGLなど

編集:問題はあなたが考えているものではないことに注意してください. 私は vector2 をレンダーで約 3800 回送信していましたが、「送信」するだけでなく、新しい Vector2 を宣言し、パラメーターをそのように送信していました。ガベージ コレクターは、この残虐行為を容認しません。フロートを 2 つだけ送信しているので、スムーズに実行されます。私の悪い._。

4

2 に答える 2

4

同時に複数のアクティブなプロセスが実行されていない限り、これは発生しません。

私の推測では (コードを確認せずに)、ガベージ コレクターが過剰に機能していると思われます。オブジェクトをループで初期化していますか? もしそうなら、代わりにオブジェクトを再利用できますか?

オブジェクトは何でも、特にビューです。ビューを再利用し、新しいビューを作成しないようにしてください。

考慮すべきもう 1 つのポイントは、レイアウト全体の再描画です。画面全体ではなく、一部だけを再描画できますか? (つまり、view.invalidate(rect);とは対照的に使用view.invalidate();)

最後に、レイアウトが深すぎませんか? できるだけ平らにするようにしてください。たとえば、RelativeLayoutネストされたの代わりに使用しますLinearLayouts

Romain Guy の Google I/O 2009 トーク をご覧ください。そこから得られる多くの情報。

更新後、 8K の画像を描画できることがわかりました。それらすべてをインスタンス化すると、おそらくメモリ内に他のものを入れる余地があまりないため、GC は収集できるものを継続的に収集する必要があります。つまり、システム全体の速度が低下します。同じビデオの約 53 ~ 55 分の Q&A をご覧ください。彼は、あなたのような状況では、ビットマップへのすべての参照をソフト参照の HashMap に持つことを提案しています。これにより、GC は必要に応じて未使用の画像を収集できます。それは他のものを集めることを妨げるでしょう。また、最初からすべてを行うのではなく、必要に応じてバッチでインスタンス化します。

于 2011-05-14T21:31:42.063 に答える
0

UI の描画/更新に遅延が見られる場合は、UI スレッドで実行時間の長いプロセス (ネットワーク、データベース、メディア、ビットマップのデコード) を実行している可能性があります。

バックグラウンド スレッドで実行時間の長いタスクを実行する必要があります。そのためにAsyncTaskを使用します。

于 2011-05-14T21:46:01.060 に答える