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é)束。
