Pokud se pouštíte do světa Androidu, jistě jste se setkali s věčným dilematem, jak zacházet s daty v prezentační vrstvě. Dlouhou dobu kralovala LiveData, ale s příchodem korutin Kotlin se objevily mnohem výkonnější a flexibilnější nástroje. Mluvíme o StateFlow a SharedFlow , které jsou v podstatě přirozeným vývojem pro reaktivní a efektivní správu datových toků.
Pravdou je, že i když se zpočátku mohou zdát jako podobné koncepty, každý z nich má svůj vlastní účel. Chtít, aby si obrazovka pamatovala, kde se kanál novinek skončil, není totéž jako chtít poslat rychlé oznámení o upozornění, které by se mělo zobrazit pouze jednou. Abychom se vyhnuli nejasnostem, pojďme si rozebrat, jak tyto horké streamy fungují a proč byste měli zvážit vynechání LiveData ve svých moderních projektech.
Koncept proudění: Studený nebo horký?
Abyste pochopili StateFlow a SharedFlow, musíte nejprve pochopit rozdíl mezi studeným a horkým tokem. Standardní tok je tzv. „cold“ , což znamená, že je jako recept: nic se neděje, dokud se někdo nerozhodne ho spustit (zavolá `collect`). Problém je v tom, že pokud máte tři odběratele, kód producenta se provede třikrát, což může vybít baterii nebo způsobit redundantní požadavky na API.
A právě zde přicházejí na řadu horké streamy. StateFlow i SharedFlow jsou strategicky horké , což znamená, že producent zůstává aktivní bez ohledu na to, zda někdo naslouchá. To umožňuje více kolektorům sdílet stejný zdroj dat , což brání aplikaci v opakovaném provádění stejné práce – což je zásadní pro udržení plynulosti systému.
StateFlow: Ideální náhrada za LiveData
StateFlow je v podstatě kontejner stavů. Jeho hlavní vlastností je, že vždy uchovává aktuální hodnotu , kterou lze synchronně dotazovat pomocí vlastnosti .value. Je to perfektní nástroj pro správu stavu uživatelského rozhraní, například zda se načítá obrazovka nebo zda byla data profilu úspěšně aktualizována.
Na rozdíl od LiveData vyžaduje StateFlow počáteční hodnotu ve svém konstruktoru, čímž eliminuje nejistotu spojenou s nulovými stavy při spuštění. Navíc implementuje chování konflace a deduplikace : pokud vygenerujete stejnou hodnotu dvakrát za sebou, tok ji jednoduše ignoruje. To je skvělé pro prevenci zbytečného obnovování uživatelského rozhraní, když se data ve skutečnosti nezměnila.
Pro implementaci tohoto v ViewModelu je nejlepším přístupem použít privátní záložní vlastnost MutableStateFlow a zpřístupnit ji jako neměnný StateFlow. To zajistí, že stav může měnit pouze ViewModel, respektuje jednosměrný tok dat a zabrání pohledu v manipulaci s daty.
SharedFlow: Sběrnice událostí pro jedinečné akce
Pokud je StateFlow pro „stav“, SharedFlow je pro „události“. Představte si, že chcete zobrazit chybové dialogové okno nebo přejít na jinou obrazovku. Pokud používáte StateFlow, otočení zařízení by způsobilo, že nový kolektor by obdržel poslední hodnotu a událost by se znovu spustila – což je vážná chyba. SharedFlow to řeší, protože jej lze nakonfigurovat s hodnotou přehrání nuly.
Tento tok je mnohem flexibilnější a umožňuje nám upravovat parametry, jako je přetečení vyrovnávací paměti . Pokud se vyrovnávací paměť zaplní, můžeme se rozhodnout pozastavit odesílatele nebo zahodit nejstarší či nejnovější hodnotu. Klíčovou výhodou je, že SharedFlow umožňuje odesílat opakované hodnoty ; pokud potřebujete odeslat stejnou zprávu „Chyba připojení“ třikrát, SharedFlow to udělá bez váhání, zatímco StateFlow by je odfiltroval.
Technické srovnání: StateFlow vs. SharedFlow vs. LiveData
Abyste se vyhnuli nejasnostem v technickém pohovoru nebo při návrhu architektury, je důležité zvážit kritické body. LiveData je jednoduchý a automaticky řídí životní cyklus , ale je velmi vázán na Android. StateFlow a SharedFlow, které jsou součástí Kotlin Coroutines, jsou nezávislé na platformě , což výrazně zjednodušuje jednotkové testování a vytváření čistých doménových vrstev.
- StateFlowVynucuje počáteční hodnotu, má příponu .value, deduplikuje hodnoty a je ideální pro stavy uživatelského rozhraní.
- SharedFlowNevyžaduje počáteční hodnotu, je konfigurovatelný z hlediska přehrávání a je tou správnou volbou pro prchavé události.
- Živá dataNevyžaduje počáteční hodnotu, je si vědom životního cyklu, ale je méně výkonný v asynchronních transformacích.
Důležitost bezpečné sklizně
Velmi častou chybou je spuštění metody `collect` v rámci jednoduchého rozsahu korutiny v aktivitě. To je nebezpečné, protože tok bude pokračovat ve zpracování dat, i když je aplikace na pozadí , což může způsobit pády nebo nadměrné využití CPU. Moderním řešením je použití API `repeatOnLifecycle(Lifecycle.State.STARTED)`.
Tato funkce způsobí, že se kolekce aktivuje, když je zobrazení viditelné, a automaticky se zruší, když dosáhne stavu STOPPED . Pro Jetpack Compose se doporučuje použít funkci `collectAsStateWithLifecycle()` , která tuto logiku nativně integruje a zajišťuje, že aplikace efektivně využívá zdroje zařízení.
Transformace studených proudů na teplé
Někdy máme tok dat přicházející z databáze (například Room) nebo repozitáře a je studený. Abychom ho zahřáli, používáme operátory `stateIn` nebo `shareIn` . Tyto operátory vyžadují `CoroutineScope` a strategii spouštění. Nejběžnější je `SharingStarted.WhileSubscribed(5000)`.
Tato konfigurace je skvělá, protože udržuje stream aktivní, dokud jsou přítomni odběratelé, a pokud je obrazovka zavřená, čeká 5 sekund, než stream zastaví. To je klíčové, aby se během rotace obrazovky stream nezničil a znovu nevytvořil, a tím se zabránilo zbytečným požadavkům na server nebo lokální databázi.
Zvládnutí těchto nástrojů zahrnuje pochopení toho, že stav musí být perzistentní a deduplikovaný pomocí StateFlow, zatímco jednorázové akce by měly procházet přes SharedFlow. Kombinací tohoto s uvědoměním si životního cyklu a transformací studeného toku pomocí stateIn dosahujeme robustní, plně reaktivní architektury Androidu optimalizované pro reálný výkon na mobilních zařízeních. Sdílejte tuto příručku a pomozte ostatním dozvědět se o tomto tématu.
