Kotlin Flow響應(yīng)式編程,基礎(chǔ)知識(shí)入門
?Kotlin在推出多年之后已經(jīng)變得非常普及了。相信現(xiàn)在至少有80%的Android項(xiàng)目已經(jīng)在使用Kotlin開發(fā),或者有部分功能使用Kotlin開發(fā)。
關(guān)于Kotlin方面的知識(shí),我其實(shí)分享的文章并不算多,主要內(nèi)容都是集中在《第一行代碼 第3版》這本書當(dāng)中??赐赀@本書,相信你一定可以很好地上手Kotlin這門語(yǔ)言。
其實(shí)由于《第一行代碼 第3版》這本書只有Kotlin版本,銷量受到了很大的影響,遠(yuǎn)不及第2版的銷量。出版社數(shù)次跟我溝通過(guò),希望我能再出一個(gè)面向Java語(yǔ)言的版本,因?yàn)橛泻芏嗟淖x者,尤其是高校群體,還是想看Java語(yǔ)言的書,但是都被我拒絕了。
我之所以會(huì)拒絕,是因?yàn)镵otlin對(duì)于Android開發(fā)者來(lái)說(shuō)已經(jīng)非常重要了。如果你真的希望成為一名優(yōu)秀的Android開發(fā)者(這個(gè)標(biāo)準(zhǔn)在幾年后會(huì)降低為合格的Android開發(fā)者),那么Kotlin就必學(xué)不可。
因?yàn)楝F(xiàn)代化Android開發(fā)技術(shù)棧里面涉及到的方方面面的新知識(shí),幾乎已經(jīng)全面Kotlin化。如果還守著Java不放,那就意味著像協(xié)程、Compose等未來(lái)主流的Android技術(shù)棧都將完全與你無(wú)關(guān)。
而現(xiàn)在隨著Kotlin的普及率越來(lái)越高,我也終于打算去寫一些基于Kotlin語(yǔ)言的進(jìn)階技術(shù)內(nèi)容了。目前的計(jì)劃是把Flow和Compose的相關(guān)內(nèi)容都寫一寫,先從Flow開始寫起。那么我們的Kotlin Flow系列就此正式展開了。
我打算通過(guò)3篇文章,從Flow的基礎(chǔ)入門知識(shí)開始寫起,逐漸教會(huì)大家Flow的常見用法,適用場(chǎng)景,以及容易被人忽視的坑點(diǎn)和注意事項(xiàng)。希望大家通過(guò)學(xué)習(xí)這個(gè)系列的文章之后,都能比較熟練地使用Flow。
另外需要注意的是,F(xiàn)low基于Kotlin和協(xié)程這兩項(xiàng)技術(shù)。而本篇文章并不會(huì)介紹這兩項(xiàng)技術(shù),所以如果你還沒有入門Kotlin以及協(xié)程的話,建議還是先去閱讀《第一行代碼 第3版》進(jìn)行基礎(chǔ)知識(shí)部分的學(xué)習(xí)。
前言就說(shuō)到這里,那么我們正式開始吧。
Flow和響應(yīng)式編程
先說(shuō)說(shuō)響應(yīng)式編程。
從大概四五年前開始,響應(yīng)式編程逐漸進(jìn)入到移動(dòng)開發(fā)領(lǐng)域,并且變得越來(lái)越火熱。比較有代表性的那應(yīng)該就是在Android領(lǐng)域無(wú)人不知,無(wú)人不曉的RxJava框架。
其實(shí)我對(duì)于RxJava并不算很熟悉,當(dāng)初在網(wǎng)上也學(xué)過(guò)各種教程和文章,但由于工作上一直沒能用得上,所以我現(xiàn)在還能記得住的知識(shí)點(diǎn)已經(jīng)不太多了。
但是RxJava留給我至今的印象就是上手困難。這個(gè)響應(yīng)式編程的思維,它和傳統(tǒng)意義上比較簡(jiǎn)單直觀的程序順序執(zhí)行的思維就是不太一樣。
那么既然這種編程思維上手如此困難,為什么我們還要去學(xué)習(xí)和使用它呢?
為了要證明響應(yīng)式編程到底有多好,網(wǎng)上已經(jīng)有數(shù)不清的教程和文章在費(fèi)盡心思去解釋。因此這里我也就不再另辟蹊徑拍腦袋再去原創(chuàng)一個(gè)了,我直接就引用Google官方的講解示例。官方講解視頻鏈接:https://youtu.be/fSB6_KE95bU
比如說(shuō)有一頭小牛住在山腳下,山上有一個(gè)湖,小牛每天需要跑很遠(yuǎn)的路拎著水桶去湖邊打水。
每天要跑很遠(yuǎn)的路就算了,關(guān)鍵是這個(gè)湖還時(shí)不時(shí)會(huì)干枯掉,有時(shí)小牛到了湖邊發(fā)現(xiàn)湖已經(jīng)干了,就完全白跑了一趟。
時(shí)間久了明眼人都能發(fā)現(xiàn),這種打水的方式太愚蠢了。為什么不多花點(diǎn)時(shí)間去搞好基建,架一條從湖邊到山腳下的水管,這樣小牛就再也不用跑很遠(yuǎn)的路去打水了,每次想喝水只要打開水龍頭就可以了。而且判斷湖有沒有干枯也可以通過(guò)打開水龍頭看看有沒有水來(lái)判斷。
并且架設(shè)好了一條管道之后,以后也可以再去輕松架接其他管道。對(duì)于最終的用水端而言,這個(gè)過(guò)程甚至可以是無(wú)感知的,因?yàn)樗恍枰?fù)責(zé)打開和關(guān)閉水龍頭即可。
在上述的這個(gè)例子當(dāng)中,拎著水桶去湖邊打水就可以類比為我們平時(shí)一般的編程方式,需要什么東西就去調(diào)用對(duì)應(yīng)的函數(shù)。而通過(guò)架設(shè)水管引流,在水龍頭接水則可以類比為當(dāng)下最流行的響應(yīng)式編程。
哇,看到這么形象的對(duì)比和這么巨大的反差,是不是覺得響應(yīng)式編程的理念屌爆了,瞬間覺得自己以前的編程方式好low?
其實(shí)我第一次看到這種類比的時(shí)候也感慨怎么早沒發(fā)明出來(lái)這么牛逼的編程方式。但是后來(lái)經(jīng)過(guò)思考之后,我發(fā)現(xiàn)Google舉的這個(gè)例子其實(shí)也是經(jīng)不住推敲的。
在現(xiàn)在生活中,拎個(gè)水桶去打水這種又苦又累的活當(dāng)然誰(shuí)都不想干,擰擰水龍頭多輕松。但是在程序世界中,我們平時(shí)調(diào)用一個(gè)函數(shù)可不是這種又苦又累的話。相反,調(diào)用一個(gè)函數(shù)非常簡(jiǎn)單,只需要調(diào)用它獲取它的返回值即可。而看似輕松的水龍頭,你想要在程序里實(shí)現(xiàn)類似的功能(也就是所謂的響應(yīng)式編程),卻并不簡(jiǎn)單,這個(gè)水龍頭的開關(guān)沒那么容易把控。
所以,很多程序員嘗試了響應(yīng)式編程之后會(huì)覺得這都是什么玩意,好好的簡(jiǎn)單代碼非要寫得這么復(fù)雜。
沒錯(cuò),我也覺得響應(yīng)式編程的思維對(duì)初學(xué)者不夠友好,能把本來(lái)簡(jiǎn)單的代碼復(fù)雜化,但它卻也確實(shí)能解決一些本來(lái)不太容易解決的問題。
還拿剛才打水的例子來(lái)說(shuō),調(diào)用一個(gè)函數(shù)去打水這很簡(jiǎn)單,但如果這個(gè)打水的過(guò)程是非常耗時(shí)的怎么辦?在主線程里調(diào)用可能就會(huì)讓程序卡死了。因此這個(gè)時(shí)候你就需要考慮開子線程去打水,然后還要處理線程回調(diào)結(jié)果等一些事務(wù)。
但如果是響應(yīng)式編程的話,你需要做的仍然只是開開水龍頭就可以了。
總之,我個(gè)人的感覺是,隨著項(xiàng)目越來(lái)越復(fù)雜,你就越來(lái)越能感受到響應(yīng)式編程所帶來(lái)的優(yōu)勢(shì)。而如果項(xiàng)目比較簡(jiǎn)單的話,很多時(shí)候使用響應(yīng)式編程就是自己給自己找麻煩。
好了,以上就是我對(duì)于響應(yīng)式編程的一些分析。那么在Android領(lǐng)域,之前影響力最大的響應(yīng)式編程框架就是RxJava。但是你也發(fā)現(xiàn)了,它是RxJava(雖然它也可以在Kotlin上使用)。這讓Kotlin怎么忍呢?于是,Kotlin團(tuán)隊(duì)又開發(fā)出了一套專門用于在Kotlin上使用的響應(yīng)式編程框架,也就是我們這個(gè)系列的主角了:Flow。
Flow的基本用法
本篇文章中,我準(zhǔn)備通過(guò)一個(gè)最簡(jiǎn)單的例子來(lái)讓大家快速上手Flow的基本用法。由于過(guò)于簡(jiǎn)單了,在一些細(xì)節(jié)方面甚至都是錯(cuò)誤的。但是沒關(guān)系,細(xì)節(jié)方面我會(huì)在后面的文章中再深入介紹,當(dāng)前我們的目標(biāo)就是,能跑起來(lái)就行。
在Android Studio當(dāng)中新建一個(gè)FlowTest的項(xiàng)目,然后我們開始吧。
那么到底是一個(gè)什么例子呢?非常簡(jiǎn)單,就是在Android中實(shí)現(xiàn)一個(gè)計(jì)時(shí)器的效果,每秒鐘更新一次時(shí)間。但是必須要使用Flow的技術(shù)來(lái)實(shí)現(xiàn)。
首先第一步是添加依賴庫(kù),想要在Android項(xiàng)目中使用Flow,以下依賴庫(kù)是需要添加到項(xiàng)目當(dāng)中的:
其中前兩項(xiàng)是協(xié)程庫(kù),因?yàn)镕low是構(gòu)建在Kotlin協(xié)程基礎(chǔ)之上的,因此協(xié)程依賴庫(kù)必不可少。第三項(xiàng)是用來(lái)提供協(xié)程作用域的,同樣必不可少。
后兩項(xiàng)是ktx的擴(kuò)展庫(kù),這些倒不是必須的,但是能幫忙我們簡(jiǎn)化不少代碼的書寫,因此也建議添加上。
接下來(lái)開始定義布局,布局文件activity_main.xml中的內(nèi)容也非常簡(jiǎn)單,一個(gè)Button用于開始計(jì)時(shí),一個(gè)TextView用于顯示時(shí)間:
寫完這些,我們基本就將準(zhǔn)備工作都做好了,那么下面就要使用Flow技術(shù)來(lái)實(shí)現(xiàn)定時(shí)器功能了。
回想一下剛才的類比,響應(yīng)式編程就像是使用水龍頭來(lái)接水一樣。那么整個(gè)過(guò)程中最重要的部分一共有3處:水源、水管和水龍頭。
其中,水源也就是我們的數(shù)據(jù)源,這部分是需要我們自己處理的。
水龍頭是最終的接收端,可能是要展示給用戶的,這部分也需要我們自己處理。
而水管則是實(shí)現(xiàn)響應(yīng)式編程的基建部分,這部分是由Flow封裝好提供給我們的,并不需要我們自己去實(shí)現(xiàn)。
因此這下就清楚了,我們需要編寫的就是水源和水龍頭這兩部分。
先從水源開始寫起,定義一個(gè)MainViewModel類,并繼承自ViewModel,代碼如下所示:
這里使用flow構(gòu)建函數(shù)構(gòu)建出了一個(gè)timeFlow對(duì)象。
在flow構(gòu)建函數(shù)的函數(shù)體內(nèi)部,我們寫了一個(gè)while死循環(huán),每次循環(huán)都會(huì)將time變量加1,同時(shí)每次循環(huán)都會(huì)調(diào)用delay函數(shù)延遲1秒執(zhí)行。
這里的delay函數(shù)是一個(gè)協(xié)程當(dāng)中的掛起函數(shù),只有在協(xié)程作用域或其他掛起函數(shù)中才能調(diào)用。因此可以看出,flow構(gòu)建函數(shù)還會(huì)提供一個(gè)掛起函數(shù)的上下文給到函數(shù)體內(nèi)部。
剩下的emit函數(shù)可以理解為一個(gè)數(shù)據(jù)發(fā)送器,它會(huì)把傳入的參數(shù)發(fā)送到水管當(dāng)中。
總共就這么幾行代碼,是不是非常簡(jiǎn)單?這樣我們就把水源部分搞定了。
可能有的朋友會(huì)說(shuō),這個(gè)timeFlow變量是定義成的全局變量,一開始就會(huì)執(zhí)行,會(huì)不會(huì)我們還沒打算開始接水,這邊的水源就在源源不斷開始送水了?
在這種場(chǎng)景下不會(huì)。因?yàn)槭褂胒low構(gòu)建函數(shù)構(gòu)建出的Flow是屬于Code Flow,也叫做冷流。所謂冷流就是在沒有任何接受端的情況下,F(xiàn)low是不會(huì)工作的。只有在有接受端(水龍頭打開)的情況下,F(xiàn)low函數(shù)體中的代碼就會(huì)自動(dòng)開始執(zhí)行。
好了,那么接下來(lái)我們開始去實(shí)現(xiàn)水龍頭部分,代碼如下所示:
這段代碼最重點(diǎn)的部分在于,我們調(diào)用了MainViewModel中定義的timeFlow的collect函數(shù)。調(diào)用collect函數(shù)就相當(dāng)于把水龍頭接到水管上并打開,這樣從水源發(fā)送過(guò)來(lái)的任何數(shù)據(jù),我們?cè)谒堫^這邊都可以接收到,然后再把接收到的數(shù)據(jù)更新到TextView上面即可。
這段代碼雖然看上去很簡(jiǎn)單,但是存在著很多隱形的坑。由于Flow的collect函數(shù)是一個(gè)掛起函數(shù),因此必須在協(xié)程作用域或其他掛起函數(shù)中才能調(diào)用。這里我們借助lifecycleScope啟動(dòng)了一個(gè)協(xié)程作用域來(lái)實(shí)現(xiàn)。
另外,只要調(diào)用了collect函數(shù)之后就相當(dāng)于進(jìn)入了一個(gè)死循環(huán),它的下一行代碼是永遠(yuǎn)都不會(huì)執(zhí)行到的。因此,如果你的代碼中有多個(gè)Flow需要collect,下面這種寫法就是完全錯(cuò)誤的:
這種寫法flow2中的數(shù)據(jù)是無(wú)法得到更新的,因?yàn)樗鼔焊蛨?zhí)行不到。
正確的寫法應(yīng)該是借助launch函數(shù)再啟動(dòng)子協(xié)程去collect,這樣不同子協(xié)程之間就互不影響了:
其實(shí)上述的代碼還有一些坑在里面,但正如我前面所說(shuō),我們本篇文章的目標(biāo)是能跑起來(lái)就行,剩下的坑我們后面的文章再詳細(xì)討論。
現(xiàn)在可以運(yùn)行一下程序了,點(diǎn)擊界面上的Button,效果如下圖所示:
可以看到,計(jì)時(shí)器功能已經(jīng)成功實(shí)現(xiàn)了。
流速不均勻問題
關(guān)于Flow最基本的用法我感覺差不多就是這些,但最后我認(rèn)為還有一個(gè)知識(shí)點(diǎn)是值得講的。
由于Flow是一種基于觀察者模式的響應(yīng)式編程模型,水源發(fā)出了一個(gè)數(shù)據(jù),水龍頭這邊就會(huì)收到一個(gè)數(shù)據(jù)。但是水龍頭處理數(shù)據(jù)的速度不一定和水源發(fā)出數(shù)據(jù)的速度是一致的,如果水龍頭處理速度過(guò)慢,就可能出現(xiàn)管道阻塞的現(xiàn)象。
響應(yīng)式編程框架都可能會(huì)遇到這種問題,RxJava中還有專門的背壓策略來(lái)處理這類問題。Flow當(dāng)中其實(shí)也有,但是我們今天不討論這種過(guò)于高端的技巧,今天使用一個(gè)特別簡(jiǎn)單的方案就可以解決這個(gè)流速不均勻問題。
首先我們來(lái)復(fù)現(xiàn)一下這個(gè)問題的現(xiàn)象是什么樣的。修改MainActivity中的代碼,如下所示:
這里在timeFlow的collect函數(shù)處理中加了一個(gè)delay邏輯,讓它延遲3秒鐘。
要知道,在水源處我們是每秒種發(fā)送一條數(shù)據(jù),結(jié)果在水龍頭這里要3秒鐘才能處理一條數(shù)據(jù)。那么結(jié)果會(huì)是什么樣的呢?我們來(lái)看下效果吧:
可以看到,現(xiàn)在每3秒鐘計(jì)時(shí)器才會(huì)更新一次。如此一來(lái),我們的計(jì)時(shí)器就完全不準(zhǔn)了。
那么要如果解決這個(gè)問題呢?
這個(gè)問題的本質(zhì)是水龍頭處理數(shù)據(jù)速度過(guò)慢,導(dǎo)致管道中存在大量的積壓數(shù)據(jù),并且積壓的數(shù)據(jù)會(huì)一個(gè)個(gè)繼續(xù)傳遞給水龍頭,即使這些數(shù)據(jù)已經(jīng)過(guò)期了。
客戶端應(yīng)該保持在界面上始終顯示最新的數(shù)據(jù),如果是已經(jīng)過(guò)期的數(shù)據(jù),再展示給用戶是沒有價(jià)值的。
因此,只要有更新的數(shù)據(jù)過(guò)來(lái),如果上次的數(shù)據(jù)還沒有處理完,那么我們就直接把它取消掉,立刻去處理最新的數(shù)據(jù)即可。
在Flow當(dāng)中實(shí)現(xiàn)這樣的功能,只需要借助collectLatest函數(shù)就能做到,如下所示:
可以看到,這里我們稍微改動(dòng)了一下水龍頭處的實(shí)現(xiàn),不再調(diào)用collect函數(shù)去收集數(shù)據(jù),而是改成了collectLatest函數(shù)。
那么從名字上就能看出,collectLatest函數(shù)只接收處理最新的數(shù)據(jù)。如果有新數(shù)據(jù)到來(lái)了而前一個(gè)數(shù)據(jù)還沒有處理完,則會(huì)將前一個(gè)數(shù)據(jù)剩余的處理邏輯全部取消。
重新運(yùn)行一下程序,我們?cè)賮?lái)看一次效果:
沒有問題,現(xiàn)在計(jì)時(shí)器又能恢復(fù)正常工作了。
好了,到這里為止,Kotlin Flow系列的第一篇文章差不多就可以結(jié)束了。