Kui oled alles Androidi maailmaga tutvumas, oled kindlasti kokku puutunud igavese dilemmaga, kuidas andmeid esitluskihis hallata. Pikka aega valitses LiveData ülimuslikult, kuid Kotlini korutiinide tulekuga on tekkinud palju võimsamad ja paindlikumad tööriistad. Me räägime StateFlow'st ja SharedFlow'st , mis on sisuliselt andmevoogude reaktiivse ja tõhusa haldamise loomulik areng.
Tõde on see, et kuigi need võivad esmapilgul tunduda sarnaste kontseptsioonidena, on igal neist oma eesmärk. Soov, et ekraan mäletaks, kus uudistevoog pooleli jäi, ei ole sama, mis soov saata kiire teade uudistevoo kohta, mida tuleks vaadata ainult üks kord. Segaduse vältimiseks analüüsime, kuidas need populaarsed vood toimivad ja miks peaksite oma tänapäevastes projektides LiveData välja jätma.
Voolu mõiste: külm või kuum?
StateFlow' ja SharedFlow' mõistmiseks tuleb kõigepealt aru saada külma ja kuuma voo erinevusest. Standardne voog on külm , mis tähendab, et see on nagu retsept: midagi ei juhtu enne, kui keegi otsustab selle käivitada (välja kutsub funktsiooni `collect`). Probleem on selles, et kui teil on kolm tellijat, siis käivitatakse tootja kood kolm korda, mis võib akut tühjendada või tekitada üleliigseid API-päringuid.
Siin tulevadki mängu kuumad voogud. Nii StateFlow kui ka SharedFlow on strateegiliselt kuumad voogud , mis tähendab, et tootja jääb aktiivseks olenemata sellest, kas keegi kuulab. See võimaldab mitmel kogujal jagada sama andmeallikat , takistades rakendusel sama töö korduvat tegemist – see on süsteemi sujuvuse säilitamiseks ülioluline.
StateFlow: ideaalne asendus LiveDatale
StateFlow on sisuliselt oleku konteiner. Selle peamine omadus on see, et see säilitab alati praeguse väärtuse , mida saab sünkroonselt pärida atribuudi .value abil. See on ideaalne tööriist kasutajaliidese oleku haldamiseks, näiteks kas ekraan laadib või kas profiiliandmeid on edukalt värskendatud.
Erinevalt LiveDatast nõuab StateFlow oma konstruktoris algväärtust , mis välistab käivitamisel nullolekutega kaasneva ebakindluse. Lisaks rakendab see liitmis- ja deduplikatsioonikäitumist : kui väljastate sama väärtuse kaks korda järjest, siis voog seda lihtsalt ignoreerib. See on suurepärane viis kasutajaliidese tarbetu värskendamise vältimiseks, kui andmed pole tegelikult muutunud.
Selle ViewModelis rakendamiseks on parim lähenemisviis kasutada privaatset MutableStateFlow varuvara ja avaldada see muutumatu StateFlow'na. See tagab, et ainult ViewModel saab olekut muuta, austades ühesuunalist andmevoogu ja takistades vaatel andmetega manipuleerimist.
SharedFlow: unikaalsete toimingute sündmuste buss
Kui StateFlow on „oleku” jaoks, siis SharedFlow on „sündmuste” jaoks. Kujutage ette, et soovite kuvada veateate dialoogi või navigeerida teisele ekraanile. StateFlow'i kasutamisel põhjustaks seadme pööramine uue koguja viimase väärtuse saamise ja sündmus käivituks uuesti – see on tõsine viga. SharedFlow lahendab selle, kuna seda saab konfigureerida kordusväärtusega null.
See voog on palju paindlikum ja võimaldab meil parameetreid, näiteks ületäitumispuhvrit, kohandada . Kui puhver täitub, saame saatja peatada või vanima või uusima väärtuse ära visata. Peamine eelis on see, et SharedFlow võimaldab teil saata korduvaid väärtusi ; kui teil on vaja saata sama "Ühenduse viga" teade kolm korda, teeb SharedFlow seda kõhklemata, samas kui StateFlow filtreerib need välja.
Tehniline võrdlus: StateFlow vs SharedFlow vs LiveData
Segaduste vältimiseks tehnilisel intervjuul või arhitektuuri kujundamisel on oluline arvestada kriitiliste punktidega. LiveData on lihtne ja haldab elutsüklit automaatselt , kuid see on väga seotud Androidiga. StateFlow ja SharedFlow, mis on osa Kotlin Coroutines'ist, on platvormist sõltumatud , mis lihtsustab oluliselt ühiktestimist ja puhaste domeenikihtide loomist.
- StateFlow: Sunnib algväärtuse, omab .value'i, deduplikeerib väärtusi ja sobib ideaalselt kasutajaliidese olekute jaoks.
- Jagatud voogSee ei vaja algväärtust, on kordusvõimaluse osas konfigureeritav ja õige valik lühiajaliste sündmuste jaoks.
- LiveDataSee ei nõua algväärtust, on elutsüklist teadlik, kuid asünkroonsete teisenduste puhul vähem võimas.
Ohutu koristamise olulisus
Väga levinud viga on käsu `collect` käivitamine lihtsa korutiini ulatuses tegevuses. See on ohtlik, sest voog jätkab andmete töötlemist isegi siis, kui rakendus on taustal , mis võib põhjustada krahhe või liigset protsessori kasutust. Kaasaegne lahendus on kasutada API-t `repeatOnLifecycle(Lifecycle.State.STARTED)`.
See funktsioon aktiveerib kogumise, kui vaade on nähtav, ja tühistab selle automaatselt, kui see jõuab olekusse STOPPED . Jetpack Compose'i puhul on soovitatav kasutada funktsiooni `collectAsStateWithLifecycle()` , mis integreerib selle loogika natiivselt ja tagab rakenduse tõhusa seadmeressursside kasutamise.
Külmade voogude muutmine kuumadeks
Vahel tuleb meil andmebaasist (näiteks Room) või repositooriumist voog, mis on külm. Selle soojendamiseks kasutame operaatoreid `stateIn` või `shareIn` . Need operaatorid vajavad `CoroutineScope`-i ja käivitusstrateegiat. Kõige levinum on `SharingStarted.WhileSubscribed(5000)`.
See konfiguratsioon on suurepärane, sest see hoiab voogu aktiivsena seni, kuni on tellijaid, ja kui ekraan on suletud, ootab see enne voo peatamist 5 sekundit. See on oluline, et ekraani pööramise ajal voogu ei hävitataks ega uuesti loodaks, vältides seega ebavajalikke päringuid serverile või kohalikule andmebaasile.
Nende tööriistade valdamine eeldab mõistmist, et olek peab olema püsiv ja StateFlow' abil dubleeritud, samas kui ühekordsed toimingud peaksid toimuma SharedFlow' kaudu. Kombineerides seda elutsükli teadlikkuse ja külmvoo teisendusega stateIn'i abil, saavutame robustse ja täielikult reaktiivse Androidi arhitektuuri, mis on optimeeritud reaalse jõudluse tagamiseks mobiilseadmetes. Jaga seda juhendit ja aita teistel selle teema kohta rohkem teada saada.
