Android官網(wǎng)最近推出了一個(gè)新的app程序框架,雖然目前正處于alpha階段,還未正式發(fā)布,但其中的實(shí)現(xiàn)原理和想法還是有必要先進(jìn)行學(xué)習(xí)的,首先就來(lái)看看新框架對(duì)于LifeCycle的處理。
相信Android開發(fā)者最頭疼的問(wèn)題之一就是android提供的組件(Activity,F(xiàn)ragment)包含了大量的生命周期,并且系統(tǒng)會(huì)自動(dòng)對(duì)生命周期進(jìn)行管理,稍不留神(應(yīng)用退到后臺(tái)或者資源緊缺)就會(huì)對(duì)相應(yīng)組件進(jìn)行回收,導(dǎo)致組件狀態(tài)丟失。
在新的框架中,提供了一套對(duì)于生命周期進(jìn)行管理的方法,接下來(lái)看看具體的實(shí)現(xiàn)過(guò)程。
一、實(shí)現(xiàn)示例
按照官網(wǎng)上的示例,我們首先需要實(shí)現(xiàn)了LifecycleObserver的類:
然后在繼承于LifecycleActivity的Activity中addObserver();
就這樣,MyLocationListener就已經(jīng)和MainActivity的生命周期進(jìn)行了綁定。
二、LifecycleRegistry是什么
可以看到getLifecycle()返回的就是LifecycleRegistry,LifecycleRegistry繼承于Lifecycle,Lifecycle是個(gè)抽象類,提供了注冊(cè)和刪除LifecycleObserver的方法,同時(shí)提供了進(jìn)行生命周期描述的Enum類。從方法的命名中可以想到,有點(diǎn)類似于采用了觀察者模式,對(duì)于注冊(cè)的對(duì)象在特定條件進(jìn)行回調(diào)。
接下來(lái)看看LifecycleRegistry是如何實(shí)現(xiàn)addObserver()的;
可以看到,首先實(shí)現(xiàn)一個(gè)ObserverWithState的對(duì)象,然后調(diào)用該對(duì)象的sync()方法;
sync()方法的作用其實(shí)就是當(dāng)綁定的Activity或Fragment生命周期改變時(shí),觸發(fā)綁定的listener進(jìn)行回調(diào)。
那么mCallback是如何綁定到對(duì)應(yīng)的Listener的呢?
三、GenericLifecycleObserver
mCallback的類名是GenericLifecycleObserver,是通過(guò)Lifecycling.getCallback()方法實(shí)現(xiàn)的。
可以看到真正示例化的方法是getGeneratedAdapterConstructor(klass)這方法;
看到Class.forName()方法,就知道采用的是反射來(lái)找到相應(yīng)的類,不過(guò)通過(guò)getAdapterName()已經(jīng)修改了要反射的類名,但我們并沒(méi)有寫過(guò)結(jié)束帶"_LifecycleAdapter"字符串的類,去哪里能找到這類呢?
別忘了我們?cè)赿ependencies中引入了這一句,會(huì)不會(huì)是通過(guò)apt生成的?
annotationProcessor "android.arch.lifecycle:compiler:1.0.0-alpha3"
順藤摸瓜,果然在build目錄對(duì)應(yīng)文件夾下會(huì)生成MyLocationListener_LifecycleAdapter類。
再看看它的實(shí)現(xiàn),原來(lái)我們先前聲明的@OnLifecycleEvent都會(huì)生成對(duì)應(yīng)的代碼。
到目前我們已經(jīng)理順了事件處理的流程。但另外一個(gè)問(wèn)題來(lái)了,這些事件是從哪里發(fā)出來(lái)的呢?
四、Event觸發(fā)源
我們知道Event處理是通過(guò)調(diào)用LifecycleRegistry的handleLifecycleEvent()來(lái)實(shí)現(xiàn)的,順藤摸瓜,哪里會(huì)調(diào)用handleLifecycleEvent()方法呢?
在android.arch.lifecycle.ReportFragment中,我們找到了調(diào)用handleLifecycleEvent()方法的地方。ReportFragment繼承Fragment,通過(guò)Fragment的生命周期來(lái)達(dá)到對(duì)綁定Listener生命周期的管理。這好像有點(diǎn)似曾相識(shí),不錯(cuò),在Glide里邊,Activity或Fragment也是通過(guò)這樣的方法,通過(guò)示例化一個(gè)沒(méi)有ui的fragment,對(duì)相應(yīng)事件的生命周期進(jìn)行管理。
那么ReportFragment是插入到相應(yīng)的Activity或Fragment當(dāng)中的呢?
找到LifecycleDispatcher這個(gè)類,原來(lái)是通過(guò)監(jiān)聽ActivityLifecycleCallbacks來(lái)實(shí)現(xiàn)對(duì)應(yīng)的綁定的,在onActivityCreated()的回調(diào)中插入ReportFragment。
到這里大概流程都已經(jīng)全部走通了,Event的觸發(fā)源就是通過(guò)綁定的ReportFragment在對(duì)應(yīng)生命周期的回調(diào)中觸發(fā)的。
那么最后一個(gè)問(wèn)題,LifecycleDispatcher的init()方法何時(shí)執(zhí)行的呢?
五、LifecycleDispatcher何時(shí)啟動(dòng)
啟動(dòng)的地方是一個(gè)叫LifecycleRuntimeTrojanProvider的類,該類繼承于ContentProvider,并且該類除了在onCreate()方法里有實(shí)現(xiàn),其他的都沒(méi)意義。
為什么要繼承ContentProvider呢,因?yàn)镃ontentProvider會(huì)在程序啟動(dòng)的時(shí)候默認(rèn)先執(zhí)行,這樣在程序啟動(dòng)的最開始,對(duì)于生命周期的管理就已經(jīng)開始了。
我們?cè)谧罱K生成的manifest.xml里邊也找到了該類。
至此,整個(gè)框架對(duì)于生命周期的管理流程已經(jīng)全部分析結(jié)束。