2

時間の経過とともに速度が低下するモバイル アプリケーションがあります。私の推測では (この記事の一部を参考にしています)、これはメモリの断片化が原因でアプリの速度が低下しているということですが、よくわかりません。これは、時間の経過に伴うアプリのメモリ使用量のきれいなグラフです。

フラグルロック http://kupio.com/image-dump/fragmented.png

グラフの 4 つのピークは、アプリでまったく同じタスクを 4 回実行したことを示しています。タスクを開始すると、大量のメモリが割り当てられ、しばらく待機してから (上の平らな線)、タスクを停止します。その時点で System.gc(); を呼び出します。そしてメモリがクリーンアップされます。

ご覧のとおり、まったく同じタスクを 4 回実行すると、実行に時間がかかります。グラフの最低点はすべて同じレベルに戻るため、タスク実行間のメモリ リークはないようです。

私が知りたいのは、メモリの断片化は実行可能な説明ですか、それとも、すでに多くのことを調べたことを念頭に置いて、最初に他の場所を探すべきですか? グラフの最低点は比較的低いため、この状態では、問題の原因となる小さなメモリ ホールが多数存在することはあり得ないため、メモリがあまり断片化されていないと推測されます。

ただし、j2me メモリ アロケータがどのように機能するかはわかりません。誰でもアドバイスできますか？他の誰かがこれに問題を抱えていて、アプリのメモリ プロファイルを認識していますか?

4

5 に答える 5

1

少し時間があれば、Memory Pool 手法を使用してメモリを再利用することで理論をテストできます。タスクの各実行では、プールからメモリを取得して返すことで、「同じ」メモリのチャンクを使用します。リリース時。

この調査を行った後もパフォーマンスの低下が見られる場合、問題の原因はメモリの断片化ではありません。結果をお知らせいただければ、さらにトラブルシューティングを行うことができます。

于 2010-01-31T11:02:14.707 に答える
0

これを実行しているOSは何ですか？Windows CE5（またはWindows Mobile）デバイスの使用経験があります。CE5のオペレーティングシステムレベルのメモリアーキテクチャはかなり壊れており、メモリを大量に消費するアプリケーションではまもなく失敗します。グラフには目盛りはありませんが、CE5ではすべてのプロセスが32MBのアドレス空間しか取得しません。VMと共有ライブラリもそのかなりの部分を占め、残りはほとんどありません。これを回避する唯一の方法は、コレクターに戻して後で再割り当てするのではなく、割り当てたメモリを再利用することです。もちろん、これはJavaで通常実行するよりもはるかに低レベルのプログラミングですが、このプラットフォームでは運が悪い可能性があります。

于 2010-02-09T01:17:14.253 に答える
0

メモリの断片化がそれを説明するでしょう...アプリのメモリ使用がページングを引き起こしているかどうかは明らかではありませんか? これにより、処理が遅くなり、同じ問題が発生する可能性があります。

于 2009-08-12T15:55:44.663 に答える
0

問題が本当にメモリの断片化である場合、それについてできることはあまりありません。

しかし、絶望してあきらめる前に、実行プロファイラーでアプリを実行して、予期しない場所での実行に多くの時間を費やしていないかどうかを確認してください。スローダウンは実際にはアルゴリズムの問​​題が原因である可能性があり、メモリの断片化とは関係ありません。人々がすでに言っているように、J2ME ガベージ コレクタは断片化の問題に悩まされるべきではありません。

于 2009-08-12T15:56:45.487 に答える
0

ガベージ コレクションの統計を調べることを検討してください。あなたの理論が正しいとすれば、最初の実行よりも最後の実行の方がはるかに多くなるはずです。別の考えとしては、他の何かがメモリを消費するため、アプリケーションのメモリが少なくなるということです。

つまり、プロファイラー時間:)

于 2009-08-12T16:31:49.770 に答える