前端时间看见java四种引用的介绍,
觉得软引用看起来可以用作内存优化.
然后看博客说,LRU内部是维护了一个有强引用的LinkedHashMap,他会根据算法将最靠前的资源从集合中移除.并没有使用到软引用.
所以请问一下,java的软引用或者弱引用在android中有应用场景吗?
LRU这样的做法,除了让缓存更大可能被复用到,还有其他优势吗?
20:56 增加
看到一篇博客说android2.3(api9)开始,内存回收器即使在内存充足的情况下,软引用和弱引用指向的对象依然有可能被回收.
那么这样的话利用弱引用来创建的Handler用于防止Handler内存泄露的方案是不是很不可靠?
//代码引用自博客
public class TestReferenceActivity extends BaseActivity {
static class MyHandler extends Handler {
private WeakReference<TestReferenceActivity> reference;
public MyHandler(Activity activity) {
//使用弱引用包裹当前的activity
reference = new WeakReference(activity);
}
}
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_test_reference);
//解决Handler可能造成的内存泄露
//通过弱引用实现,如果当前activity需要被回收了,而且Handle持有的
//activity是被弱引用包装的,则垃圾回收器可以释放掉此activity。
MyHandler myHandler = new MyHandler(this);
}
}
ソフト参照は、2.3 システム以降、元の機能が確かに制限されていますが、引き続き使用できますが、Android での GC 中にネイティブ JVM ほど簡単にリサイクルされません。具体的な用途については、この記事をお勧めします
ソフト参照と弱参照は使用できないわけではありませんが、その動作は予測できません。
弱参照リソースがいつリサイクルされるかを正確に知ることはできません。一般的な画像キャッシュの状況では、LRU アルゴリズムは弱参照よりも効率的であり、リソースの複数の作成/リサイクルを効果的に回避できます。
メモリ リークが発生しやすい特定の状況では、弱い参照の方が適しています。たとえば、AsyncTask では、メモリ リークを防ぐために弱い参照を使用できます。
ソフト参照は、画像の非同期読み込みなど、実際の Android 開発において非常に役に立ちます。また、imageloder はキャッシュの最適化を扱うときにもソフト参照を使用します。パフォーマンスの最適化にはあまり効果がありません。パフォーマンスの最適化が必要な場合は、実際には弱い参照を使用することをお勧めします。
回答後、質問の下にまだ質問があることがわかりました。実際、ハンドラーが OOM から保護されるのを防ぐためにソフト参照が使用されるのは、Android のメインスレッドが作成されるときの特別なメカニズムによるものです。 Looper オブジェクトは、ハンドラー オブジェクトを作成するときに、そのハンドラーを使用してメッセージを MessageQueue に入れるたびに、同時に別のオブジェクトを実装します。したがって、アクティビティが終了すると、メッセージが取り出される前に、このメッセージが常に存在し、メッセージはハンドラーへの参照を保持します。ハンドラーはアクティビティ内に作成され、アクティビティへの参照を保持します。 gc ではリサイクルできず、OOM が発生します。 Java のすべての非静的オブジェクトは現在のオブジェクトへの強参照を保持しますが、静的オブジェクトは現在のクラスへの弱い参照のみを保持します。これにより、アクティビティが終了するとメッセージが処理できなくなり、メッセージが永続的に保持されるという問題が解決されます。ハンドラーの参照を保持すると、ハンドラーはアクティビティへの参照を永続的に保持します。