Słabe korzyści referencyjne

MSDN ma dobre wyjaśnienie słabych odniesień . Kluczowy cytat znajduje się na dole, gdzie jest napisane:

Unikaj używania słabych odniesień jako automatyczne rozwiązanie pamięci problemy z zarządzaniem . Zamiast tego rozwijaj skuteczna polityka buforowania dla obsługa obiektów aplikacji.

Za każdym razem, gdy widziałem słabą referencję na wolności, była używana jako automatyczne rozwiązanie problemów z zarządzaniem pamięcią. Są prawdopodobnie lepsze rozwiązania problemów aplikacji.

Genialny prawdziwy przykład z WeakReference jest wyjaśniony w Android development tutorial .

W widoku znajduje się obraz (bitmapa) i kontener obrazu (ImageView). Jeżeli obraz będzie ładowany nie z pamięci (ale np. z dysku, sieci) to może zablokować wątek interfejsu i ekran. Aby tego uniknąć, można użyć zadania asynchronicznego.

Problem pojawia się po zakończeniu zadania asynchronicznego. Kontener obrazu może nie być użyteczny w ogóle w tym czasie (ekran jest zmieniony lub Android rozładowuje niewidoczne widok części po przewinięciu). WeakReference może tu pomóc, a ImageView będzie zbierana.

class BitmapWorkerTask extends AsyncTask<Integer, Void, Bitmap> {
    private final WeakReference<ImageView> imageViewReference;

    public BitmapWorkerTask(ImageView imageView) {
        imageViewReference = new WeakReference<ImageView>(imageView);
    }
    // Method for getting bitmap is removed for code clearness

    // Once complete, see if ImageView is still around and set bitmap.
    @Override
    protected void onPostExecute(Bitmap bitmap) {
        if (imageViewReference != null && bitmap != null) {
            final ImageView imageView = imageViewReference.get();
            if (imageView != null) {
                imageView.setImageBitmap(bitmap);
            }
        }
    }
}

P. S. przykład jest w Javie, ale może być zrozumiany przez programistów C#.
Źródło: http://developersdev.blogspot.ru/2014/01/weakreference-example.html