問題タブ [low-memory]

私のシナリオでは、アセットに圧縮された外部読み取り専用データベースを使用し、最初の実行時に内部ストレージに抽出/コピーしています。

この問題は、ユーザーのデバイスのディスクにコピーを完了するのに十分なメモリがない場合に発生します。

事前に利用可能なスペースを確認しますが、RAM が少ない場合、Android OS 自体が仮想メモリ/ページ ファイルを使用するため、空き MB の数は一定ではありません。

ファイル自体が完全かどうかを確認する方法を見つけたいのですが、これを達成する方法はありますか?

私のアプリには 3 つのプロセスと 2 つのサービスがあり、それらの関係は次のとおりです: (UI 開始と BKService のバインド、UI 開始と LinkService のバインド、次に BKService バインド LinkService)

プッシュ プロセスのメモリ使用量は、デーモン プロセスよりもはるかに少なくなります。

以下のように、dumpsys アクティビティ プロセスを使用して、adj タイプと値を確認します。

詳細な dumpsys アクティビティ プロセス情報は次のとおりです。

私が理解しているように、メモリ不足の状態では、強制終了シーケンスは次のようにする必要があります: UI プロセス、デーモン プロセス、プッシュ プロセス。(BKService は LinkService のクライアントであるため、LinkService は unBind の前に停止せず、同じ oom_adj 値を使用すると、LinkService のメモリ使用量が少なくなります)。

しかし実際には、強制終了のシーケンスは常に、UI プロセス、プッシュ プロセス、デーモン プロセスです。誰かがこれを説明できますか？

バインド C (LinkService bind BKService) の方向を変更すると、デーモン プロセスがプッシュ プロセスよりも先に強制終了されます。

理由がわかりません。誰か助けてください。よろしくお願いします。

私のアプリケーションでは、onLowmemory メソッドをオーバーライドします。毎回呼び出されます。そして、私の携帯は立ち往生しています。このメソッドでメモリを解放する方法。

私は以下のコードを使用しています:

system.gc のみを使用しています ... ありがとうございます。

DialogFragmentクラスによってラップされた警告ダイアログがあります。ダイアログには、項目のリストを表示するカスタム レイアウトがあります (ListView適切なアダプターと共に使用します)。アイテムのリストはかなり巨大で重要なので、この例のようにmyのFragmentクラス内に保存します。DialogFragmentonPause()

非常にまれな状況を除いて、すべてが完全に機能します。ダイアログウィンドウを開いたままにして（「ホーム」ボタンを押して）、デバイスのメモリが少なくなると、アプリのプロセスが強制終了されます。後でアプリケーションに戻ると、ダイアログを再作成しようとしますが、左に開いているダイアログに表示されていた項目のリストを復元できないため、クラッシュします (NullPointerExceptionダイアログのアダプター内に取得します)。ListViewこれはFragment、システムがアプリのプロセスを強制終了すると、ダイアログの状態を保存する も破棄されるDialogFragmentため、リスト アダプターのデータ ソースがないため、ダイアログを再作成できないために発生します。

私があなたに求めているのは、ダイアログ ウィンドウの状態を保存するより良い方法を提供して、アプリ プロセスが強制終了された後でも再作成できるようにすること、またはアイテムのリストがそのnull前にある場合にダイアログをキャンセルする方法を示すことです。再開されます (つまり、ダイアログの再作成中にどこかでダイアログをキャンセルすることを意味します)。時間がかかりすぎるため、データベースはそのデータを保存するための良い方法だとは思いません。アダプターの情報がない場合は、ダイアログの再作成を停止する方法を希望します。

アップデート：

アプリケーションのライフサイクル中にオブジェクトを保存する実装Parcelableは、本当に素晴らしいアイデアです。オブジェクトへの書き込みParcelは高速です (信頼してください。不適切に使用し始めるまで、ライフサイクルの変更の間に遅延は見られません)。また、アプリのインスタンスの状態を保存および復元するプロセスは、ActivityManagerプロセスによって管理されますActivity。また、アプリケーション全体をホストしているプロセスは Android システムによって破棄され、オブジェクトが保存されActivityManagerた場所を維持し、新しいプロセスでゼロから再作成されている場合はその状態を復元します。この練習をするように励ましてくれた@Naveedに感謝します！ParcelActivity

インスタンスの状態を保存することの本当の意味をまだ理解していない人への注意:

ライフサイクル イベントに沿ってインスタンスの状態を保存Activityするということは、アプリケーションの現在の UI またはユーザーの現在の進行状況に対してのみ意味のある情報の変更を維持することを意味しますが、アプリケーションまたはユーザーが明示的にアプリを停止した場合 ([戻る] ボタン) 後で再起動します。実際には一時的なこの特定の形式の情報は、プリミティブ Java 型のメソッドを使用するか、カスタム クラスでインターフェイスを実装することにより、オブジェクトのonSaveInstanceState()コールバック メソッド内に保存し、後でまたはcallbakcs で復元する必要があります。Bundleput...()ParcelableonCreate()onRestoreInstanceState()

ユーザーがアプリケーションを明示的に閉じるか、短時間だけ放置するかに関係なく、ユーザーにとって重要な他のすべてのデータは、SQLiteデータベースやSharedPreferencesシステムなどの永続的なストレージに保存する必要があります。アプリケーションには、以前の進行状況が再び必要です。この形式のデータは、コールバック メソッド内に保存する必要があります。これonPause()は、リソースを回復する必要がある場合にシステムがアプリのプロセスを破棄できるようになる前に呼び出されることが保証されている最後のメソッドであるためです。の後に呼び出されるメソッドでデータを保存することを選択した場合onPause()、つまりonStop()またはonDestroy()、非常に悪い (ただし、必ずしもまれではありません) 場合にシステムがアプリをすぐに強制終了することを決定した場合、これらのメソッドが呼び出されない可能性があるため、データが保存されないという大きなリスクがあります。

SharedPreferences別のこと:リスト、コレクション、またはバンドルを保存するように構築されていないため、少量のデータを保存する場合にのみ使用してください。アプリケーション用のデータベース インターフェイスを実装するのにさらに数時間費やすことを検討し、SQLiteそれをより快適に使用して大量の情報を維持することを検討してください。

特定のバックグラウンド操作を実行するために、長時間実行されているサービスがあります。今、私はいくつかのスレッドを読みました.RAMが少ない場合、より多くのページに対応するためにバックグラウンドLRUキャッシュを少しクリアする必要があるため、Androidはこれらのサービスを強制終了することを検討しています. そのため、Android に強制終了させ、サービス データを onTrimMemory コールバックに保存し (レベルが 80 の場合)、Android がサービスのプロセスを強制終了する前に、毎回このコールバックを取得できることを願っています。しかし、状況によっては、onTrimMemory でコールバックが得られず、プロセスが強制終了され、データが失われます。

プロセスが強制終了される前のログは次のとおりです。

私のプロセスは com.example.gaurav で、プロセスが強制終了される前に onTrimMemory ログはありません。ここにいる誰かが、それらのログが何を示しているか説明できますか? 私はすでにグーグルで検索しましたが、説得力のあるものは見つかりませんでした。フォアグラウンド サービス ソリューションに関しては、サービスの実行時間が長く、フォアグラウンドにすると多くのバッテリーが消費されるため、これは避けたいと思います。

@pskink、これはサービス中の onTrimMemory コールバック メソッドです。

また、次のようなログを時々取得します。

06-15 20:43:46.000 18420 18420 V MyService: トリム メモリ コールバック、レベル: 80

したがって、確かにログがないということではありません。

言語にもよりますが、最大 120,000 個の自然言語単語の大規模な辞書を保存する必要があります。プロファイリングにより、配列を使用するアルゴリズムがシステムの時間のボトルネックであることが示されているため、これらはメモリに保持する必要があります。(詳細は重要ではありませんが、これは基本的にスペルチェック/自動修正アルゴリズムです。) 16MB メモリを搭載した Android デバイスでは、Java に関連するメモリ オーバーヘッドStringにより、領域が不足します。Stringそれぞれに38 バイトのオーバーヘッドが関連付けられていることに注意してください。これにより、最大 5MB のオーバーヘッドが発生します。

一見すると、1 つのオプションは を置き換えるchar[]ことですString。(またはbyte[]、この場合は UTF-8 の方がコンパクトであるためです。) しかし、ここでもメモリ オーバーヘッドが問題になります。各 Java 配列には 32 バイトのオーバーヘッドがあります。

などの代替手段の 1 つは、すべての文字列を 1 つの巨大な文字列 (たとえば単一の として表される) に内部的に連結し、オフセットをその巨大な文字列に格納する、ArrayList<String>ほとんど同じインターフェイスを持つクラスを作成することです。byte[]各オフセットは 4 バイトを使用するため、よりスペース効率の高いソリューションが得られます。

私の質問は、a) 同様に低いオーバーヘッド*で問題を解決する他の解決策はありますか? b) すぐに利用できる解決策はありますか? Guava、trove 、およびPCJコレクション ライブラリを検索しても、何も得られません。

*オーバーヘッドを 4 バイト未満に抑えることができることはわかっていますが、効果は減少しています。

注意。HotSpot JVM で削除される圧縮文字列のサポート? JVMオプションはここでは役に立たないことを示唆してい-XX:+UseCompressedStringsます。