Jak buforować obrazy sieciowe we Flutterze i obniżyć koszty

Każde żądanie obrazu bez buforowania w aplikacji Flutter to wywołanie sieciowe, które kosztuje czas i transfer danych, a także cierpliwość użytkownika. W aplikacjach opartych na dużej liczbie obrazów ponowne wczytywanie tych samych zasobów to jedna z najczęstszych i najłatwiejszych do uniknięcia przyczyn słabej postrzeganej wydajności. Użytkownicy to zauważają. Na urządzeniach mobilnych, gdzie połączenie bywa niestabilne, zauważają to jeszcze bardziej.

Flutter daje tu dwie główne możliwości: wbudowany mechanizm, który nie wymaga konfiguracji, oraz pakiet cached_network_image, który zapewnia pełną kontrolę nad polityką cache'owania, czasem wygaśnięcia i obsługą błędów. W tym artykule omawiamy oba podejścia i wyjaśniamy, kiedy które z nich będzie właściwym wyborem. Te wskazówki przygotował zespół Flutter w Monterail, który od 2019 roku tworzy rozbudowane aplikacje Flutter oparte na dużej liczbie obrazów dla branży healthcare, fintech i aplikacji konsumenckich.

Dlaczego obrazy bez buforowania kosztują cię pieniądze

Każde ponowne pobranie obrazu to dodatkowe żądanie sieciowe, za które płaci twój serwer lub CDN, i dodatkowy czas oczekiwania po stronie użytkownika.

Na ekranie z dużą liczbą obrazów, na przykład z 20 miniaturami, implementacja bez buforowania ponownie pobierze wszystkie 20 przy każdym przebudowaniu widoku: podczas przewijania listy, przełączania kart czy powrotu na ekran.

Buforowanie ogranicza te 20 żądań do jednego na sesję, zmniejszając zarówno koszty transferu wychodzącego z CDN, jak i czas renderowania, od którego zależy, czy ekran sprawia wrażenie natychmiastowego, czy powolnego.

To, ile zaoszczędzisz, zależy od dwóch rzeczy: jak często żądanie jest obsługiwane z pamięci podręcznej zamiast z sieci oraz jak długo zbuforowana kopia pozostaje użyteczna, zanim trzeba ją pobrać ponownie. Oba pojęcia mają w obszarze cache'owania precyzyjne nazwy i wokół nich zbudowano API obrazów we Flutterze.

Trzy opcje:

W większości aplikacji produkcyjnych cached_network_image to wybór domyślny: pełna kontrola bez kosztów utrzymania własnej implementacji.

Co w tym kontekście oznacza buforowanie?

AWS opisuje buforowanie tak:

W informatyce cache to szybka warstwa przechowywania danych, która przechowuje podzbiór danych, zwykle o charakterze tymczasowym, tak aby kolejne żądania tych danych mogły być obsługiwane szybciej, niż byłoby to możliwe przy odwołaniu do ich podstawowego miejsca przechowywania. Buforowanie pozwala efektywnie ponownie wykorzystywać wcześniej pobrane lub obliczone dane.

Buforowanie wiąże się z terminami i pojęciami, które są niezbędne, by zrozumieć możliwości Fluttera. Według Cloudflare Learning Center:

Cache hit występuje wtedy, gdy „żądana informacja jest już w pamięci podręcznej i nie trzeba jej pobierać z rzeczywistego źródła prawdy”.

Cache miss występuje wtedy, gdy „pamięć podręczna jest pusta, więc żądane dane są pobierane z rzeczywistego źródła prawdy, a następnie zapisywane w pamięci podręcznej na potrzeby kolejnych odczytów”.

Korzystam też z trzeciej, przydatnej definicji. Stale cache występuje wtedy, gdy dane w źródle prawdy się zmieniły, przez co aplikacja może wyświetlać nieaktualne informacje.

Sprawdzenie, czy dane w pamięci podręcznej są nadal aktualne, zwykle zajmuje tyle samo czasu co ponowne wczytanie całych danych, co ogranicza korzyści z buforowania. W przypadku obrazów rzadziej stanowi to problem, bo często pozostają niezmienione przez długi czas, chyba że głównym celem aplikacji jest praca z obrazami często aktualizowanymi.

Dlaczego warto buforować obrazy w aplikacji Flutter?

Jeśli aplikacja ma przyciągać i utrzymywać użytkowników, musi dobrze radzić sobie z obrazami w rzeczywistych warunkach: przy problemach z połączeniem, wolnej sieci i podczas wielokrotnego przechodzenia przez ekrany z dużą liczbą obrazów.

Buforowanie obrazów sieciowych we Flutterze poprawia wydajność aplikacji i doświadczenie użytkownika na kilka sposobów:

• Po pierwszym załadowaniu obraz jest zapisywany lokalnie. Kolejne żądania pobierają go z pamięci podręcznej zamiast ponownie ściągać z internetu, co oszczędza czas i transfer danych.

• Wielokrotne wczytywanie tego samego obrazu obciąża transfer tylko raz, ponieważ cache hit nie generuje kosztu przesyłu.

• Zbuforowane obrazy ładują się wyraźnie poniżej sekundy, dzięki czemu użytkownik korzysta z aplikacji płynniej.

• Mechanizmy buforowania we Flutterze mogą wyświetlić placeholder, gdy nie uda się załadować obrazu.

• Większość implementacji buforowania we Flutterze zapobiega nadmiernemu zużyciu pamięci i zasobów, co ma znaczenie na słabszych urządzeniach mobilnych.

Jak Image.network domyślnie buforuje obrazy?

We Flutterze konstruktor Image.network odpowiada za podstawowe buforowanie obrazów.

Domyślnie obrazy sieciowe ładowane przez ten konstruktor są buforowane, aby poprawić wydajność i ograniczyć zbędne żądania sieciowe. Wszystkie obrazy sieciowe trafiają do cache niezależnie od nagłówków HTTP. Mechanizm buforowania w Image.network nie daje się jednak konfigurować i ma ograniczoną elastyczność.

Konstruktor Image.network pod spodem korzysta zarówno z ImageCache, jak i ImageProvider. Działa to tak:

• ImageProvider: konstruktor Image.network tworzy instancję NetworkImage, która jest klasą pochodną ImageProvider. Pobiera obraz z sieci i przekazuje go do frameworka Fluttera.

• ImageCache: ImageProvider (w tym przypadku NetworkImage) współpracuje z ImageCache, aby buforować obrazy. ImageCache to klasa narzędziowa we Flutterze, która przechowuje referencje do obrazów, by uniknąć zbędnego ładowania i renderowania, poprawić wydajność i ograniczyć wykorzystanie sieci.

Choć to wbudowane buforowanie działa bez konfiguracji, aplikacje produkcyjne często potrzebują większej kontroli.

Jak podaje dokumentacja Fluttera:

Jeśli podasz cacheWidth lub cacheHeight, silnik zdekoduje obraz do wskazanego rozmiaru. Niezależnie od tych parametrów obraz zostanie wyrenderowany zgodnie z ograniczeniami układu albo zadanymi width i height. Parametry te służą przede wszystkim do zmniejszenia zużycia pamięci przez ImageCache. (źródło: https://api.flutter.dev/flutter/widgets/Image/Image.network.html)

Uwaga: na platformie web dla obrazów sieciowych parametry cacheWidth i cacheHeight są ignorowane, ponieważ dekodowaniem obrazów zajmuje się przeglądarka, a własne rozmiary dekodowania nie są tam obsługiwane.

Poniżej znajdziesz przykład:

Kiedy warto użyć pakietu CachedNetworkImage?

Przy bardziej zaawansowanych potrzebach związanych z buforowaniem pakiet cached_network_image oferuje większe możliwości. To standardowe rozwiązanie dla programistów Fluttera, którzy chcą dostosować polityki cache'owania, obsługiwać wygaśnięcie cache albo w uporządkowany sposób radzić sobie z problemami sieciowymi.

Pakiet CachedNetworkImage

Pakiet cached_network_image zapewnia bardziej rozbudowany sposób ładowania i buforowania obrazów sieciowych, oferując więcej funkcji i elastyczności niż domyślny konstruktor Image.network.

Jak działa pakiet CachedNetworkImage

1. Żądanie sieciowe i ładowanie obrazu: widget CachedNetworkImage korzysta z CachedNetworkImageProvider do pobierania obrazów z sieci. Gdy pojawia się żądanie obrazu, provider sprawdza, czy obraz jest już zapisany w pamięci podręcznej. Jeśli nie, rozpoczyna żądanie sieciowe, aby go pobrać.

1. Mechanizm cache'owania: pakiet używa flutter_cache_manager do obsługi cache. flutter_cache_manager udostępnia klasę CacheManager, która przechowuje pobrane obrazy w systemie plików urządzenia. Cache manager można skonfigurować tak, aby kontrolować czas przechowywania, maksymalny rozmiar cache i inne parametry.

1. Klucz cache: każdy adres URL obrazu ma unikalny klucz cache, który pozwala zidentyfikować obraz i pobrać go z pamięci podręcznej. Domyślnie jako klucz cache używany jest sam URL.

1. Własny cache manager (więcej poniżej): programiści mogą przekazać własny cache manager, aby nadpisać domyślne działanie buforowania. To przydaje się przy ustawianiu własnych polityk cache, na przykład czasu przechowywania, albo przy wdrażaniu własnej strategii usuwania.

Możesz używać CachedNetworkImage bezpośrednio albo przez ImageProvider. Warto pamiętać, że zarówno CachedNetworkImage, jak i CachedNetworkImageProvider nadal oferują minimalne wsparcie dla weba i w tym środowisku nie zapewniają cache'owania.

Na innych platformach obrazy buforowane przez cached network images korzystają z flutter_cache_manager do zapisywania i odczytywania plików w katalogu cache aplikacji.

Jak obsłużyć placeholdery i błędy ładowania?

Zarówno w Image.network, jak i w CachedNetworkImage obsługa stanu ładowania i błędów jest prosta. Obsłuż każdy stan: jeśli obraz nie załaduje się poprawnie, użytkownik powinien zobaczyć coś użytecznego.

CachedNetworkImage dobrze wspiera placeholdery i widgety błędów. Dają one użytkownikowi wizualną wskazówkę, gdy obraz jest pobierany albo gdy pobranie się nie powiedzie, a parametry placeholder i errorWidget przyjmują dowolny przekazany widget.

Częsty wzorzec to rozmyty placeholder w niskiej rozdzielczości, który po załadowaniu zamienia się w pełny obraz, oraz ikona ponowienia w widżecie błędu, dzięki której użytkownik może spróbować jeszcze raz bez opuszczania ekranu. Pomaga to utrzymać spójne doświadczenie użytkownika, bo aplikacja daje informację zwrotną w trakcie ładowania albo przy błędzie, zamiast zostawiać puste miejsce lub ikonę uszkodzonego obrazu, którą użytkownik odczyta raczej jako błąd aplikacji niż skutek wolnego albo zerwanego połączenia po swojej stronie.

Jak skonfigurować katalog cache i zasady usuwania?

Nie twórz więcej niż jednej instancji CacheManager z tym samym kluczem, bo będą sobie nawzajem przeszkadzać.

Domyślnie pliki z cache są zapisywane w katalogu tymczasowym aplikacji, dzięki czemu system operacyjny może je usunąć w dowolnym momencie. Informacje o plikach są przechowywane w bazie danych z użyciem sqflite na Androidzie, iOS i macOS albo w zwykłym pliku JSON na innych platformach. Nazwa pliku bazy danych odpowiada kluczowi CacheManager, dlatego musi on być unikalny.

Pliki mogą zostać usunięte przez cache managera albo przez system operacyjny. Zwykle są przechowywane w folderze cache, który może być okresowo czyszczony, na przykład podczas aktualizacji aplikacji na Androidzie.

CacheManager używa dwóch kluczowych zmiennych, by określić, kiedy usunąć plik: maxNrOfCacheObjects i stalePeriod. Podczas czyszczenia cache, które działa stale, manager usuwa pliki przekraczające maksymalną liczbę obiektów w cache, zaczynając od najrzadziej używanych, oraz pliki, które nie były używane dłużej niż wynosi stale period.

Przykład:

Jakie ustawienia cache można skonfigurować?

CacheManager przyjmuje następujące parametry konfiguracyjne:

• Klucz cache (key): unikalny klucz identyfikujący cache. Służy do nazwy folderu przechowującego pliki oraz pliku bazy danych. Przydaje się, jeśli chcesz rozdzielić różne cache w obrębie aplikacji.

• Stale period (stalePeriod): czas, po którym elementy w cache są uznawane za nieaktualne i mogą zostać odświeżone z sieci.

• Maksymalna liczba obiektów w cache (maxNrOfCacheObjects): maksymalna liczba elementów przechowywanych w cache. Po przekroczeniu limitu jako pierwsze usuwane są pliki używane najdawniej.

• Repozytorium informacji o cache (repo): własna implementacja repozytorium do przechowywania metadanych cache. Domyślnie jest to CacheObjectProvider (sqflite) na Androidzie, iOS i macOS, NonStoringObjectProvider na webie oraz JsonCacheInfoRepository na innych platformach.

• Usługa plików (fileService): własna usługa pobierania plików. Domyślnie HttpFileService.

• System plików (fileSystem): określa, gdzie przechowywane są pliki z cache.

W porównaniu z Image.network daje to znacznie więcej możliwości konfiguracji. Parametry fadeIn i fadeOut pozwalają też na płynną animację podczas ładowania obrazu.

Jak wstępnie ładować obrazy, zanim będą potrzebne?

Funkcja precacheImage ładuje obrazy z wyprzedzeniem i zapisuje je w pamięci podręcznej. To szczególnie przydatne, bo pierwsze załadowanie zasobu może czasem powodować krótkie migotanie.

Dzięki użyciu precacheImage kolejne żądania tego samego obrazu są obsługiwane bezpośrednio z cache, co skraca czas ładowania i zapewnia płynniejsze interakcje użytkownika.

Co jeszcze poprawia wydajność obrazów?

Poza podstawowymi mechanizmami opisanymi wyżej warto wdrożyć jeszcze kilka praktyk, które dodatkowo poprawią wydajność:

1. Używaj obrazów o odpowiednim rozmiarze, aby zmniejszyć ilość danych, które trzeba pobrać i zbuforować.

2. Kompresuj obrazy, by zachować równowagę między jakością a rozmiarem pliku.

3. Wdróż zasady takie jak ładowanie obrazów tylko przez Wi‑Fi albo zapewnij, by aplikacja dobrze radziła sobie przy wolnym połączeniu.

4. Szybko wyświetlaj placeholdery w niskiej rozdzielczości, gdy główny obraz jeszcze się ładuje.

Co musi się zgadzać, zanim wdrożysz cached_network_image?

Buforowanie działa niezawodnie w środowisku produkcyjnym tylko wtedy, gdy spełnionych jest kilka warunków.

Każda instancja CacheManager w aplikacji musi mieć własny klucz, bo użycie tego samego klucza w dwóch instancjach CacheManager sprawia, że obie walczą o ten sam plik bazy danych i folder cache, uszkadzając jedno i drugie. Jeśli jakakolwiek część aplikacji działa w Flutter web, cached_network_image nie będzie tam warstwą cache'owania: zarówno CachedNetworkImage, jak i CachedNetworkImageProvider nie obsługują cache na tej platformie, więc buildy webowe i tak uderzają do sieci przy każdym żądaniu, niezależnie od konfiguracji.

Gdy buforowane obrazy są przypisane do konkretnego użytkownika, obowiązuje zgodność z przepisami i wymogi regulacyjne.

Zdjęcie profilowe, przesłany skan dokumentu tożsamości albo miniatura dokumentacji medycznej, które po wylogowaniu użytkownika lub usunięciu konta nadal pozostają w katalogu cache urządzenia, to dokładnie ten rodzaj zachowanych danych osobowych, który prawo do usunięcia danych wynikające z RODO i podobne regulacje każą usuwać z urządzenia, oprócz rekordu konta skasowanego na twoim serwerze. Praktycznym sposobem na domknięcie tej luki jest podpięcie wywołania czyszczenia cache managera do przepływów wylogowania i usuwania konta, tego samego wywołania, o którym mowa w FAQ poniżej.

Zanim uzależnisz długowieczną aplikację od tego pakietu, sprawdź tempo jego utrzymania. Historia wydań cached_network_image jest nierówna: wersja 3.4.1 pojawiła się w sierpniu 2024 roku, a kolejne wydanie, 4.0.0, dopiero w sierpniu 2026 roku. To dwuletnia przerwa zakończona jednorazowym przeskokiem do nowej głównej wersji. Ten skok nie jest zmianą typu drop-in replacement: 4.0.0 podnosi minimalnie wspieraną wersję Fluttera do 3.44.0 i Darta do 3.12.0 oraz zamienia wewnętrzne użycie flutter/material.dart na material_ui, aby wspierać kompilację do WebAssembly.

Przed aktualizacją sprawdź oba wymagania względem ograniczeń SDK w twojej aplikacji i przypnij wersję, na której testujesz, zamiast automatycznie przechodzić na najnowsze wydanie.

Co decyduje o tym, czy twoja strategia cache'owania zadziała?

Buforowanie obrazów sieciowych we Flutterze to jeden z najpewniejszych sposobów na poprawę wydajności aplikacji i doświadczenia użytkownika. Lokalne przechowywanie i ponowne wykorzystywanie obrazów zmniejsza liczbę żądań sieciowych i przyspiesza ładowanie.