必要に応じて、コンテンツの保存と分類を行います。システムではさらに貴重になります。コレクションを定期的に実行しますが、だからと言って、アプリがメモリの割り当てと解放を行うタイミングや場所を無視してよいわけではありません。オブジェクトを解放する必要があります。このページでは、アプリ内のメモリ使用量を積極的に削減する方法について説明します。メモリ管理の概要をご覧ください。使用可能なメモリとメモリ使用量を監視するアプリのメモリ使用量に関する問題を解決するには、最初に問題を特定する必要があります。プロファイラを使用すると、以下の方法でメモリの問題を特定して診断できます。アプリによるメモリの割り当て方法を長期的に監視します。コレクションの実行タイミングがリアルタイムでグラフに表示されます。ヒープのスナップショットを取得します。エディタで対応するコードに移動します。さまざまな方法でアプリからメモリを再利用できます。必要に応じてアプリを完全に強制終了し、重要なタスクを実行するためにメモリを解放することもできます。クラスに実装すると、システムメモリのバランスを細かく調整して、システムがアプリプロセスを強制終了せずに済むようにできます。イベントに反応してオブジェクトを解放できます。コールバックを実装できます。14)で追加されました。イベントとほぼ同じ)を使用できます。量に基づき、デバイスごとに異なります。メモリ不足を回避するために、システムに対してクエリを実行し、現在のデバイスで使用可能なヒープスペースの量を確認できます。オブジェクトが返されます。このオブジェクトから、デバイスの現在のメモリ状態に関する情報(メモリの空き容量、メモリの合計容量、メモリの閾値(システムがプロセスの強制終了を開始するメモリレベル)など)を確認できます。含まれており、この値からデバイスのメモリが不足しているかどうかを判断できます。メソッドを使用する方法の例を示しています。クラス、コード構造は、他より多くのメモリを使用する傾向があります。コード内でメモリ効率の高い別の方法を選択することで、アプリのメモリ使用量を最小限に抑えることができます。アプリで起こり得る、メモリ管理に関する最悪のミスの一つです。アプリがバックグラウンドでの作業にサービスを必要としていても、ジョブを実行する必要がない限り、サービスを実行したままにしないでください。タスクが完了したら、必ずサービスを停止してください。しないと、誤ってメモリリークを引き起こす可能性があります。サービスを開始すると、システムは常にそのサービスのプロセスを実行し続けようとします。他のプロセスで使用できないままになるため、サービスのプロセスの負荷が非常に大きくなります。プロセスの数が減少し、アプリの切り替え効率が低下します。メモリの空き容量が少なく、実行中のすべてのサービスをホストするのに十分なプロセスを維持できない場合、システムでスラッシングが発生することもあります。一般に、メモリを常に利用できる状態にすることが求められるため、サービスをいつまでも利用し続けないようにする必要があります。実装することをおすすめします。プロセスのスケジュールを設定する方法について詳しくは、バックグラウンド処理の最適化をご覧ください。使用することをおすすめします。このクラスは、サービスを開始したインテントの処理が完了するとすぐに終了します。サービスでの実行をご覧ください。デバイスでの使用に最適化されていません。オブジェクトが必要になるため、メモリ効率が大幅に低下する可能性があります。つのオブジェクトがさらに作成される)が不要になるため、効率性が向上します。必要に応じて、いつでも生の配列に切り替えて、極めてシンプルなデータ構造にすることができます。コードの抽象化に注意する抽象化はコードの柔軟性と保守性の向上に役立つため、プログラミングに関するおすすめの方法としてよく使用されます。そのため、抽象化によるメリットがあまりない場合は、抽象化の使用は避けるべきです。設計した、構造化データをシリアル化するためのメカニズムです。言語やプラットフォームに依存せず、拡張することも可能です。バッファを使用してください。サイズの大幅な増大、実行速度の低下など)が発生する可能性があります。版」セクションをご覧ください。イベントは、アプリのパフォーマンスに影響しません。イベントが発生して、バッテリーがすぐに消費され、フレームのセットアップ時間がわずかに増加することがあります。コレクションに費やす時間が多くなるほど、バッテリーの消耗が速くなります。イベントが発生する回数が増加します。メモリチャーンは実際のところ、一定時間内に割り当てられた一時オブジェクトの数を表します。ループ内で複数の一時オブジェクトが割り当てられることがあります。オブジェクトが作成されることもあります。どちらの場合も、アプリによって大容量のオブジェクトが短時間で多数作成されます。コレクションが強制的に実行されます。言うまでもなく、コードの修正を行うには、メモリチャーンがよく発生する場所を特定する必要があります。プロファイラを使用します。コードの問題の場所を特定したら、パフォーマンスが重要な箇所で割り当ての回数を減らしてみます。ベースの割り当て構造に移動することを検討してください。プールがユースケースに役立つかどうかを評価することも考えられます。インスタンスを捨てるのではなく、プールに放出します。インスタンスが必要になったときは、そのオブジェクトを割り当てるのではなく、プールから取得できます。プールが適しているかどうかを判断するには、詳細なパフォーマンス評価が不可欠です。プールを使用するとパフォーマンスが低下する場合もあります。プールにより割り当てが回避されますが、それ以外のオーバーヘッドが生じます。プールのメンテナンスには通常、同期という無視できないオーバーヘッドがあります。インスタンスを消去して(メモリリークを回避するため)、獲得時に初期化を行うと、オーバーヘッドがゼロにならないことがあります。呼び出し回数は減りますが、呼び出しごとに必要となる処理の量は増加します。これは、処理量が存続中の(到達可能な)バイト数に比例するためです。メモリを大量に消費するリソースとライブラリを削除するコード内の一部のリソースやライブラリが、知らないうちにメモリを大量に消費していることがあります。アプリの全体のサイズ(サードパーティのライブラリや埋め込みリソースを含む)がアプリのメモリ使用量に影響を及ぼすこともあります。冗長または不要な、あるいは肥大化したコンポーネント、リソース、ライブラリをコードから削除することにより、アプリのメモリ消費を改善できます。全体のサイズを小さくするアプリの全体のサイズを小さくすることで、アプリのメモリ使用量を大幅に削減できます。フレーム、サードパーティ製ライブラリはすべて、アプリのサイズに影響する可能性があります。リソースのサイズを小さくし、外部依存関係を縮小するのに役立つツールが複数用意されています。アプリ全体のサイズを縮小する方法の詳細については、アプリのサイズを縮小する方法に関するガイドをご覧ください。使用する依存性注入フレームワークを使用すると、記述するコードをシンプル化し、テストやその他の設定変更に役立つ適応性に優れた環境を構築できます。使用を検討してください。アプリのコードをスキャンするためにリフレクションを使用しません。アプリでも使用できます。コストやメモリの使用は発生しません。リフレクションを使用する他の依存性注入フレームワークは、アノテーションのコードをスキャンすることによってプロセスを初期化する傾向があります。必要になることがあり、アプリの起動時に顕著な遅延を発生させる可能性があります。クライアントで使用すると効率性が低下する場合があります。デバイス用に最適化する必要が生じることがあります。使用量の観点からライブラリを分析してください。デバイス向けの一部のライブラリでも、実装の違いによって問題が発生することがあります。バッファの実装を持つことになります。ロギング、分析、画像の読み込みフレームワーク、キャッシュ保存などでも、複数の実装が生成されることがあります。リソースを削除できます。ライブラリの大規模な内部依存関係は削除できません。これらのライブラリで使用する機能では、低レベルの依存関係が必要になることがあります。手動で微調整して使用できるようにするのに時間がかかる)などには特に問題になります。個だけを使うために共有ライブラリを使用しないでください。使いもしない大量のコードやオーバーヘッドを含めるべきではありません。ライブラリを使用するかどうかを検討する際には、ニーズにぴったりマッチする実装を探してください。しないと、独自の実装を作成することになるかもしれません。ライセンスに記載のライセンスに従います。関連会社の商標または登録商標です。