この問題を取り巻く状況を説明すると、物事が混乱するだけだと思うので、すぐに本題に入ります。
Android アプリケーションが JNI を介して少量のネイティブ メモリを割り当て、そのメモリへの参照を失った場合 (つまり、そのネイティブ メモリを管理するオブジェクトへの変数参照が null になり、使用しようとすると null ポインター例外がスローされます)。彼ら）：
これがアプリのライフサイクル全体で一度だけ発生する場合、それは本当に大したことですか?
メモリは最終的に上書きされ、とにかく再利用されませんか?
メモリリークを許可するのは悪い習慣だと理解しています。率直に言って、私はこれを完全に理解しています。ただし、ルールを破らなければならない場合がまれにあることも知っています (Effective Java の Joshua Bloch の言葉を言い換えると)。敬意を表して、なぜ私がこれを行っているのかについて議論したくはありません。私はこの特定の問題に対する答えを探しているだけです。
ありがとうございました！！！クリス
これがアプリのライフサイクル全体で一度だけ発生する場合、それは本当に大したことですか?
ほとんどの人にとって、「少量のネイティブ メモリ」が何を意味するかによって異なります。数 KB について話している場合、一度失われた場合は心配しません。一方、数 MB について話している場合は、おそらく状況が異なります...
とはいえ、既知のメモリ リークがあることは、他の問題を引き起こす可能性のある潜在的な設計上の問題の兆候です。また、将来のリファクタリングでアプリケーションのアーキテクチャが変更された場合、さらに問題になる可能性があります。
メモリは最終的に上書きされ、とにかく再利用されませんか?
確かに...最終的に。プロセスが終了すると、カーネルは割り当てられたすべてのリソースを解放します。私は Android の内部の仕組みにあまり詳しくありませんが、デスクトップ Linux システムよりもプロセスの寿命が長くなる傾向があることは理解しています。メモリがほとんどなく、スワップ領域がない組み込みデバイスの場合、これは問題になる可能性があります。特に、すべてのアプリケーション作成者がメモリ リークをいたるところに残し始めた場合はなおさらです。