問題タブ [android-memory]

反対派へ：私の質問は一般化されているので、私はコードを貼り付けていません。誰かがそれを要求したらすぐにいくつか投稿します。

私のアプリケーションでは、JSONArrayアクティビティの開始時に非常に大きな形式でユーザーのプレイリストをロードし、このデータを解析してに表示しますListView。ユーザーが[更新]ボタンを押すと、操作全体が繰り返され、同じオブジェクトが上書きされます。アプリが使用するRAMの量は、更新のたびに0.4〜1MBの間でランダムに増加することに気づきました。理由を理解しようとしていますが、同じメモリアドレスが新しいデータで上書きされるだけですが、RAMの消費量が増えるのはなぜですか？また、更新を行う前に、使用されているすべてのオブジェクトをに設定しようとしましnullた。これにより、使用されるRAMの量は減少しましたが、約100KBしか減少しませんでした。

上書きされるだけの同じ変数があるので、その問題の説明はありません。サーバー応答のサイズは変更されていません。 このメモリリークを修正する方法はありますか？

何百もの効果音を含むアプリケーションを開発しています。いくつかのサウンドを再生した後、適用力が閉じます。問題がメモリの利用可能なスペースをすべて消費していることを理解しました。Release() メソッドを使用してみましたが、このメソッドが呼び出された後、サウンドを再度再生できません。また、 onDestroy() メソッドを使用してメディアプレーヤーのオブジェクトを null に設定しようとしましたが、これらの種類のオブジェクトは最終でなければならないため、これを行うことはできません。あなたの提案は何ですか？これが私のコードです：

Android 開発に関する多くのブログとベスト プラクティスは次のように述べています。

「考えられるすべての密度に対してビットマップを提供する必要はありません。Android は現在の密度に合わせてビットマップを (通常はロード時に) スケーリングします。」

参考リンク：https ://plus.google.com/105051985738280261832/posts/6eWwQvFGLV8

試してみたらうまくいきました。しかし、私は一つのことを理解できませんでした。

たとえば、ビュー ページャーにそれぞれ約 1.5 MB の 5 つの全画面画像を含むサンプル アプリを作成しました。

Galaxy Tab 2 のような 7 インチ MDPI デバイス用の重いイメージを作成し、「drawable-large-mdpi」フォルダーに配置しました。少しぎくしゃくしていましたが、クラッシュすることはなく、すべての画像をスクロールできました。

今、ほぼ大型の HDPI デバイスである Nexus 7 でアプリを使用しようとしました。ビットマップのデコード中にアプリが「OOM エラー」でクラッシュしました。

*イメージを大きな MDPI から大きな HDPI に移動すると、両方のデバイスでクラッシュすることなく正常に動作します。*

だから私は2つの質問があります。

1. この結果は、グラフィック アセットを最も密度の高いドローアブル フォルダーに配置して、その範囲内で自動的に縮小することしかできないという傾向がありますか?
2. 初めてクラッシュした理由は内部でどうなりますか?

私と何人かのチーム メンバーは、モバイルでフィールド上のデータを収集する Android アプリケーションを開発しました。

現在、このアプリケーションは本番環境に移行しています。したがって、一般の人はこのアプリケーションを使用します。また、アプリケーションで導入されたすべてのものと、このアプリケーションをエラーなく実行するために必要な最小ハードウェア要件を説明するドキュメントを作成する必要があります。

ハードウェアの最小要件を知るにはどうすればよいですか?

基本的に、私のアプリケーションには、約 4 つTextFields、3 つSpinners、および 2 つのDatesがあります。EditTextsImageViews

では、このアプリケーションを実行するために必要な最小メモリ要件を知るにはどうすればよいでしょうか。

ほとんどすべてのメモリが他のアプリケーションによって使い果たされているモバイル デバイスで、このアプリケーションを試してみました。私のアプリケーションは写真をキャプチャできません。そして、いくつかのアプリケーションを削除すると、アプリケーションは正常に動作します。

そのため、アプリケーションを実行するために必要な最小メモリ要件を知りたいのです。

私は 1 週間ずっと、Android のヒープ メモリ制御を掘り下げていました。

ストーリーは、ログイン画面の背景をより HD のものに変更したことです。それは深刻な問題を引き起こしました。以前より多くのメモリを消費するため、残りのアクティビティ、特にそこから大きな画像を開くと、メモリ不足の問題が発生します。

DDMS を使用して分析した後、最終的に解決策を見つけました。開始時に画像にビットマップ コントロールを追加し、ユーザーがアクティビティを終了するとリサイクルします。これが私のコードです：

ユーザーがアクティビティを終了または停止すると、次のようになります。

これにより、残りのアプリケーションは約 40% ～ 50% の空きメモリで実行されます。それがちょうど10％未満で実行される前に。

しかし、これはグッドエンドではありません。別の問題が発生しました。ユーザーがログアウトしてメイン画面に戻る機能があります。ただし、ログイン画面自体を実行するには、ヒープの約 80% が必要です。実行時 (ログイン後) に、残りのアクティビティを実行するには約 50% ～ 60% が必要です。

簡単に言えば、実行時からメイン画面を再びランチするのに十分なヒープメモリがありません!.

終了して再起動するときのコードは次のとおりです。

これらのコードを改善して、アプリケーション ヒープのすべてのメモリを解放し、メイン アクティビティを最初からやり直すにはどうすればよいですか? または、ログイン画面のメモリ使用量を減らすことしかできませんでした（これは本当に難しいとは思いません）。

ありがとうございました！

私のアプリケーションは、いくつかのフラグメントで構成されています。今まで、カスタム Application オブジェクトに格納されたそれらへの参照を持っていましたが、何か間違ったことをしていると思い始めています。

私の問題は、方向の変更後に mActivity へのすべてのフラグメントの参照が null になることに気付いたときに始まりました。そのため、方向の変更後に getActivity() を呼び出すと、NullPointerException がスローされます。getActivity() を呼び出す前に、フラグメントの onAttach() が呼び出されることを確認しましたが、それでも null が返されます。

以下は、アプリケーション内の唯一のアクティビティである MainActivity の削除されたバージョンです。

以下は、CustomApplication の削除されたバージョンです。この実装の背後にある私の考えは、アプリケーションのライフ サイクル全体で各フラグメントのインスタンスを 1 つだけ保証することでした。

複数のフラグメントを最適に実装する方法と、それらの状態を維持する方法に関するヒントに非常に興味があります。参考までに、私のアプリケーションはこれまでに 15 以上のフラグメントで構成されています。私はいくつかの調査を行いましたが、 FragmentManager.findFragmentByTag() は良い賭けのようですが、うまく実装できていません。

私の実装は、方向の変更後に mActivity 参照が null になるという事実を除いて、うまく機能しているようです。これにより、メモリ リークの問題もある可能性があると信じることができます。

さらにコードが必要な場合は、お知らせください。問題はアクティビティとアプリケーションの実装に関連していると強く信じているため、意図的にフラグメント コードを含めないようにしましたが、間違っている可能性があります。

御時間ありがとうございます。

私は Android が初めてで、画像閲覧用に ViewPager を実装しようとしています。UrlImageViewHelper というライブラリを使用して、URL 文字列から画像を読み込みます。最初の 4 ～ 5 枚の画像をスクロールした後、メモリ リークの問題が発生しています。

私が使用しているページアダプターコードは次のとおりです。

かなり基本的なコードですが、何か不足しているに違いありませんか? さらに情報を提供できる場合は、お知らせください。皆さんありがとう。

UrlImageViewHelper ライブラリ内のコード:

LogCat でスローされる例外は次のとおりです。

ご覧いただきありがとうございます。