Слабые справочные преимущества - PullRequest
Новая
       9

Слабые справочные преимущества

73 голосов
/ 22 ноября 2008

Может кто-нибудь объяснить основные преимущества различных типов ссылок в C #?

  • Слабые ссылки
  • Мягкие ссылки
  • Фантомные ссылки
  • Сильные ссылки.

У нас есть приложение, которое потребляет много памяти, и мы пытаемся определить, является ли это областью, на которую нужно сфокусироваться.

Ответы [ 3 ]

61 голосов
/ 22 ноября 2008

Я полагаю, что софт и фантомные ссылки приходят с Java. Длинная слабая ссылка (передача true в конструктор WeakReference C #) может считаться похожей на Java PhantomReference. Если в C # есть аналог SoftReference, я не знаю, что это такое.

Слабые ссылки не увеличивают срок службы объекта, что позволяет собирать мусор после того, как все сильные ссылки вышли из области видимости. Они могут быть полезны для удержания больших объектов, которые дороги для инициализации, но должны быть доступны для сборки мусора, если они не используются активно.

Будет ли это полезно для уменьшения потребления памяти вашим приложением, будет полностью зависеть от специфики приложения. Например, если у вас есть небольшое количество кэшированных объектов, которые могут быть использованы в будущем, а могут и не быть использованы в будущем, слабые ссылки могут помочь улучшить потребление памяти кэшем. Однако, если приложение работает с очень большим количеством небольших объектов, слабые ссылки усугубят проблему, поскольку ссылочные объекты будут занимать столько же или больше памяти.

35 голосов
/ 22 ноября 2008

MSDN имеет хорошее объяснение слабых ссылок . Ключевая цитата внизу, где написано:

Избегайте использования слабых ссылок как автоматическое решение для памяти проблемы управления . Вместо этого развиваться эффективная политика кэширования для обработка объектов вашего приложения.

Каждый раз, когда я видел WeakReference в дикой природе, он использовался как автоматическое решение проблем управления памятью. Вероятно, есть лучшие решения проблем вашего приложения.

5 голосов
/ 30 января 2014

Яркий реальный пример с WeakReference объясняется в руководстве по разработке Android .

На изображении есть изображение (Bitmap) и контейнер изображения (ImageView). Если изображение будет загружено не из памяти (но, например, с диска, сети), оно может заблокировать поток пользовательского интерфейса и экран. Чтобы избежать этого, можно использовать асинхронную задачу.

Проблема возникает при завершении асинхронной задачи. Контейнер изображения может быть вообще бесполезен в это время (экран меняется или Android выгружает невидимую часть просмотра после прокрутки). Здесь может помочь WeakReference, и ImageView будет собирать мусор. 

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. пример написан на Java, но понятен для разработчиков на C #.
Источник: http://developersdev.blogspot.ru/2014/01/weakreference-example.html

...