前端时间看见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);
}
}
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Les références soft ont effectivement été limitées dans leurs fonctions d'origine après le système 2.3, mais elles peuvent toujours être utilisées, mais elles ne sont pas aussi facilement recyclées lors du GC sur Android que sur la JVM native. Pour un usage spécifique, je vous recommande cet article
Les références douces et les références faibles ne sont pas inutilisables, mais leur comportement est imprévisible.
Nous ne pouvons pas savoir exactement quand les ressources faiblement référencées seront recyclées. Dans les situations typiques de mise en cache d'images, l'algorithme LRU est plus efficace que les références faibles et peut efficacement éviter la création/recyclage multiple de ressources.
Les références faibles sont plus adaptées à certaines situations où des fuites de mémoire sont susceptibles de se produire. Par exemple, dans AsyncTask, nous pouvons utiliser des références faibles pour éviter les fuites de mémoire.
Les références logicielles sont en fait très utiles dans le développement actuel d'Android, comme le chargement asynchrone d'images. La plus typique est qu'imageloder utilise également des références logicielles pour l'optimisation du cache. ils ne sont pas efficaces dans l'optimisation des performances. Cela ne peut pas trop aider. Il a principalement un bon traitement pour oom, s'il y a un besoin d'optimisation des performances, il est en fait recommandé d'utiliser des références faibles
.Après avoir répondu, j'ai vu qu'il y avait encore une question sous la question. En fait, la raison pour laquelle des références logicielles sont utilisées pour empêcher le gestionnaire de MOO est due au mécanisme spécial d'Android lorsqu'un thread principal Android est créé. , il y en aura un autre en même temps. L'objet Looper implémentera un MessageQueue lorsque nous créerons l'objet gestionnaire, chaque fois que nous utiliserons le gestionnaire pour mettre un message dans MessageQueue. eue, ce message contiendra une référence à l'objet gestionnaire. Par conséquent, lorsque l'activité sera terminée et avant que le message ne soit supprimé, le message existera toujours et le message contiendra une référence au gestionnaire. l'activité et persistera. Il y a une référence à l'activité, donc cette activité ne peut pas être recyclée par gc, et oom se produira. Tous les objets non statiques en Java contiendront des références fortes à l'objet actuel, tandis que les objets statiques ne contiendront que de faibles références à la classe actuelle. Cela résout le problème selon lequel lorsque l'activité est terminée, le message ne peut pas être traité, ce qui entraîne l'affichage permanent du message. hold the handler Reference, le handler détient en permanence la référence à l’activité.