上一篇文章解析了一下Lifecycle的源碼剖析Lifecycle源碼，因為Lifecycle的應(yīng)用很廣泛，而JetPack的一些其他組件也涉及到了Lifecycle，LiveData也不例外，所以就在第一個寫了Lifecycle的文章，今天就來通過解析LiveData 的源碼來了解其原理。
LiveData簡介及基本使用
LiveData是谷歌開發(fā)的jetpack的一個組件，通過LiveData可以實現(xiàn)數(shù)據(jù)感知組件的生命周期，并且能在數(shù)據(jù)改變時通知那些監(jiān)聽了該該數(shù)據(jù)并且可見的組件。先來看看LiveData的基本用法：
LiveDala一般是配合ViewModel使用的，ViewModel不懂也沒關(guān)系，并不影響閱讀代碼：
public class MyViewModel extends ViewModel {
private MutableLiveData<LDBean> ldBeanLiveData;
public MutableLiveData<LDBean> getLdBeanLiveData(){
if(ldBeanLiveData==null)
ldBeanLiveData = new MutableLiveData<>();
return ldBeanLiveData;
}
}
MutableLiveData是LiveData的子類，它的作用主要是向外界暴露setValue和postValue方法，可以在其他地方調(diào)用這兩個方法來修改數(shù)據(jù)：
public class MutableLiveData<T> extends LiveData<T> {
public MutableLiveData(T value) {
super(value);
}
public MutableLiveData() {
super();
}
@Override
public void postValue(T value) {
super.postValue(value);
}
@Override
public void setValue(T value) {
super.setValue(value);
}
}
泛型用來接收數(shù)據(jù)類型，這里是LDBean類型，LDBean是一個實體類，只定義了一個屬性id：
public class LDBean {
private String id;
public LDBean(String id) {
this.id = id;
}
public String getId() {
return id;
}
public void setId(String id) {
this.id = id;
}
}
而在activity中又是如何才能監(jiān)聽LiveData數(shù)據(jù)變化的呢？
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
viewModel = new ViewModelProvider(this, new ViewModelProvider.NewInstanceFactory()).get(MyViewModel.class);
viewModel.getLdBeanLiveData().observe(this, new Observer<LDBean>() {
@Override
public void onChanged(LDBean ldBean) {
System.out.println(ldBean.getId());
}
});
}
viewModel是MyViewModel的一個實例，viewModel.getLdBeanLiveData()就是viewModel的成員變量ldBeanLiveData，所以知不知道ViewModel都不影響閱讀LiveData的代碼。一旦ldBeanLiveData調(diào)用setValue或者postValue，只要activity是可見的（生命周期在onStart()之后onStop()之前），都會回調(diào)到這個匿名內(nèi)部類Observer的onChanged方法：
viewModel.getLdBeanLiveData().setValue(new LDBean("1"));
viewModel.getLdBeanLiveData().postValue(new LDBean("2"));
不過setValue是在主線程調(diào)用的，而postValue是在子線程調(diào)用的。
這應(yīng)該就已經(jīng)知道了，實際上監(jiān)聽LiveData數(shù)據(jù)變化的并不是activity，而是這里的匿名內(nèi)部類Observer，而LiveData又是如何做到感知activity的生命周期的呢？又是如何做到將數(shù)據(jù)變化通知給Observer的呢？接下來就進(jìn)入源碼仔細(xì)研究吧。
LiveData源碼
先從LiveData的observe方法開始：
@MainThread
public void observe(@NonNull LifecycleOwner owner, @NonNull Observer<? super T> observer) {
assertMainThread("observe");
if (owner.getLifecycle().getCurrentState() == DESTROYED) {
return;
}
LifecycleBoundObserver wrapper = new LifecycleBoundObserver(owner, observer);
ObserverWrapper existing = mObservers.putIfAbsent(observer, wrapper);
if (existing != null && !existing.isAttachedTo(owner)) {
throw new IllegalArgumentException("Cannot add the same observer"
+ " with different lifecycles");
}
if (existing != null) {
return;
}
owner.getLifecycle().addObserver(wrapper);
}
注意這個方法只能在主線程中調(diào)用，入?yún)?code>LifecycleOwner和Observer類型，這里的owner就是activity,observer就是之前的那個匿名內(nèi)部類，這是一個接口，只有一個onChanged方法：
public interface Observer<T> {
void onChanged(T t);
}
LiveData的observe方法中首先會判斷如果'owner'的生命周期為銷毀狀態(tài)，就直接return,否則會將owner和observer封裝到一個LifecycleBoundObserver中去，先不看其他的，先看一下這個類的構(gòu)造方法和成員屬性：
class LifecycleBoundObserver extends ObserverWrapper implements LifecycleEventObserver {
@NonNull
final LifecycleOwner mOwner;
LifecycleBoundObserver(@NonNull LifecycleOwner owner, Observer<? super T> observer) {
super(observer);
mOwner = owner;
}
}
這個類繼承了ObserverWrapper實現(xiàn)了LifecycleEventObserver接口，看到這個就會想到Lifecycle，ObserverWithState中的成員變量mLifecycleObserver就是這個接口的實例，activity生命周期變化時就會調(diào)用到接口的onStateChanged方法，而這里應(yīng)該也是這樣，現(xiàn)在記住就行，后面還會再分析。成員變量mOwner就是activity，再看一下ObserverWrapper的構(gòu)造方法：
private abstract class ObserverWrapper {
final Observer<? super T> mObserver;
boolean mActive;
int mLastVersion = START_VERSION;
ObserverWrapper(Observer<? super T> observer) {
mObserver = observer;
}
}
成員變量mObserver就是構(gòu)造函數(shù)傳入的，mActive標(biāo)志了activity是否可見，具體如何賦值后面會說。mLastVersion表示了版本號， 先交代一下，后面再分析。
再回到LiveData的observe方法，新建了LifecycleBoundObserver對象wrapper以后，再將wrapper添加到mObservers中，mObservers是SafeIterableMap類型的對象，這是一個map結(jié)構(gòu)，每一個元素有前驅(qū)結(jié)點和后繼結(jié)點，這里就是一個觀察者模式，wrapper作為觀察者觀察LiveData的數(shù)據(jù)變化，緊接著再做一些容錯處理，最后再將wrapper加入到owner的lifecycle的觀察者列表中，因為wrapper也是LifecycleEventObserver的實例，所以wrapper能夠監(jiān)聽activity的生命周期變化。
到這里可以總結(jié)一下，調(diào)用了LiveData的observe方法后，首先會將傳入的activity和observer封裝成一個LifecycleBoundObserver對象，再讓這個對象同時作為觀察者觀察LiveData的數(shù)據(jù)變化和activity生命周期的變化，也就是一個觀察者同時觀察兩個被觀察者。
下面就分析兩個被觀察者發(fā)生變化時是如何通知被觀察者以及被觀察者接收到通知以后又是如何工作的：
組件生命周期變化時觀察者是如何工作的
從上一篇剖析Lifecycle源碼中知道，當(dāng)activity生命周期發(fā)生變化時,最終會調(diào)用LifecycleBoundObserver的onStateChanged方法：
@Override
public void onStateChanged(@NonNull LifecycleOwner source,
@NonNull Lifecycle.Event event) {
if (mOwner.getLifecycle().getCurrentState() == DESTROYED) {
removeObserver(mObserver);
return;
}
activeStateChanged(shouldBeActive());
}
當(dāng)被觀察者activity生命周期為destroyed的時候，會執(zhí)行removeObserver方法，注意這個removeObserver方法是LiveData的方法：
@MainThread
public void removeObserver(@NonNull final Observer<? super T> observer) {
assertMainThread("removeObserver");
ObserverWrapper removed = mObservers.remove(observer);
if (removed == null) {
return;
}
removed.detachObserver();
removed.activeStateChanged(false);
}
這個方法只能在主線程調(diào)用，首先會將該觀察者從LiveData的觀察者列表中刪除，再調(diào)用觀察者也就是LifecycleBoundObserver的detachObserver方法：
void detachObserver() {
mOwner.getLifecycle().removeObserver(this);
}
就是將觀察者從Lifecycle被觀察者列表中刪除，接著又會調(diào)用觀察者的activeStateChanged方法，先交代一下，這個方法會在被觀察的activity生命周期變化時被調(diào)用：
void activeStateChanged(boolean newActive) {
if (newActive == mActive) {
return;
}
// immediately set active state, so we'd never dispatch anything to inactive
// owner
mActive = newActive;
boolean wasInactive = LiveData.this.mActiveCount == 0;
LiveData.this.mActiveCount += mActive ? 1 : -1;
if (wasInactive && mActive) {
onActive();
}
if (LiveData.this.mActiveCount == 0 && !mActive) {
onInactive();
}
if (mActive) {
dispatchingValue(this);
}
}
mActive表示這個觀察者是不是活動狀態(tài)，當(dāng)被觀察的activity可見時（再強調(diào)一下：生命周期在onStart()之后onStop()之前的activiy是可見的），則該觀察者是活動的，mActive的值為true，被觀察的activity不可見則表示觀察者是不活動的，mActive的值為false，第一個if表示，如果activity的可見性發(fā)生變化也就是觀察者活動狀態(tài)發(fā)生改變時才會往下走，否則直接結(jié)束該方法，activity的可見性發(fā)生變化時，首先更新觀察者活動狀態(tài)，mActive的值為newActive，緊接著如果觀察者的活動狀態(tài)是由不活動轉(zhuǎn)化為活動時，則先將LiveData的處于活動狀態(tài)的觀察者個數(shù)加1，如果該觀察者是唯一一個處于活動狀態(tài)的觀察者，則調(diào)用LiveData的onActive方法；如果觀察者的活動狀態(tài)是由活動轉(zhuǎn)化為不活動時，則先將LiveData的處于活動狀態(tài)的觀察者個數(shù)減1，如果該觀察者是最后一個從活動狀態(tài)轉(zhuǎn)化為不活動狀態(tài)的觀察者時，也就是說LiveData中不存在活動狀態(tài)的觀察者時，則調(diào)用LiveData的onInactive方法；這兩個方法都是空方法，可以由開發(fā)人員自己繼承去做一些操作。最后，如果是由不活動狀態(tài)轉(zhuǎn)化為活動狀態(tài)，則會調(diào)用dispatchingValue方法：
void dispatchingValue(@Nullable ObserverWrapper initiator) {
if (mDispatchingValue) {
mDispatchInvalidated = true;
return;
}
mDispatchingValue = true;
do {
mDispatchInvalidated = false;
if (initiator != null) {
considerNotify(initiator);
initiator = null;
} else {
for (Iterator<Map.Entry<Observer<? super T>, ObserverWrapper>> iterator =
mObservers.iteratorWithAdditions(); iterator.hasNext(); ) {
considerNotify(iterator.next().getValue());
if (mDispatchInvalidated) {
break;
}
}
}
} while (mDispatchInvalidated);
mDispatchingValue = false;
}
這個方法是LiveData用來向觀察者分發(fā)數(shù)據(jù)的方法。這里有兩個boolean類型的標(biāo)志變量，mDispatchingValue和mDispatchInvalidated,mDispatchingValue的值表示當(dāng)前LiveData是否正在分發(fā)數(shù)據(jù)，mDispatchInvalidated可以設(shè)為true來表示當(dāng)前正在執(zhí)行的分發(fā)操作無效，如果當(dāng)前正在執(zhí)行分發(fā)操作，則將當(dāng)前正在執(zhí)行的分發(fā)操作置為無效，然后直接退出該方法，否則就進(jìn)行分發(fā)操作，將mDispatchingValue設(shè)為 true表示當(dāng)前正在執(zhí)行分發(fā)，然后就執(zhí)行do while循環(huán)，在循環(huán)里面執(zhí)行分發(fā)操作，每次循環(huán)以后都會判斷當(dāng)前分發(fā)如果無效再執(zhí)行一次循環(huán)分發(fā)數(shù)據(jù)，直到成功為止，首先會將分發(fā)操作置為有效，然后會判斷該方法的參數(shù)是否為null，不為null則只向傳入的觀察者分發(fā)數(shù)據(jù)，否則就會循環(huán)遍歷向所有的觀察者分發(fā)數(shù)據(jù)，每次循環(huán)還會判斷此次分發(fā)是否有效，因為也許分發(fā)過程中數(shù)據(jù)又發(fā)生了改變，那么就會退出遍歷循環(huán)重新分發(fā)，分發(fā)給每個過程中調(diào)用的是considerNotify方法：
private void considerNotify(ObserverWrapper observer) {
if (!observer.mActive) {
return;
}
// Check latest state b4 dispatch. Maybe it changed state but we didn't get the event yet.
//
// we still first check observer.active to keep it as the entrance for events. So even if
// the observer moved to an active state, if we've not received that event, we better not
// notify for a more predictable notification order.
if (!observer.shouldBeActive()) {
observer.activeStateChanged(false);
return;
}
if (observer.mLastVersion >= mVersion) {
return;
}
observer.mLastVersion = mVersion;
observer.mObserver.onChanged((T) mData);
}
首先分發(fā)操作只對處于活動狀態(tài)的觀察者執(zhí)行，如果觀察者處于非活動狀態(tài)，則直接退出該方法，接著會調(diào)用觀察者的shouldBeActive方法：
boolean shouldBeActive() {
return mOwner.getLifecycle().getCurrentState().isAtLeast(STARTED);
}
顧名思義，該方法就是判斷該觀察者是否應(yīng)該處于活動狀態(tài)，為了防止觀察者的活動狀態(tài)沒有及時更新，直接返回觀察者觀察的組件是否是可見的，如果觀察者不應(yīng)該處于活動狀態(tài)，那么就調(diào)用觀察者的activeStateChanged(false)更新狀態(tài)后退出方法，否則就會判斷版本號，這里解釋一下版本號的作用：
LiveData有一個版本號，觀察者也有一個最后版本號，每當(dāng)LiveData的數(shù)據(jù)發(fā)生變化時，版本號都會+1，而每次更新觀察者的數(shù)據(jù)時，都會將觀察者的最后版本號的值置為LiveData的當(dāng)前版本號，所以如果觀察者的最后版本號的值為LiveData的當(dāng)前版本號相等，則表示觀察者拿到的數(shù)據(jù)是最新的。
所以這里就會判斷觀察者的最后版本號如果不小于LiveData的當(dāng)前版本號，那么觀察者的數(shù)據(jù)就是最新的，就不需要更新，直接退出方法，否則就將最后版本號的值值為LiveData的當(dāng)前版本號，再更新數(shù)據(jù)，更新數(shù)據(jù)就是調(diào)用observer的onChanged方法。
再回到dispatchingValue方法，我們這里傳入的觀察者不為空，所以只需要更新該觀察者的數(shù)據(jù)。
跳得有點遠(yuǎn)，再回到觀察者的的onStateChanged，前面講的是activity生命周期為destroyed時的流程，當(dāng)不為destroyed時，則會先調(diào)用shouldBeActive()更新當(dāng)前的活動狀態(tài)，再調(diào)用activeStateChanged方法，而這個方法前面也已經(jīng)講過了，這里就不再贅述了。
到這里再總結(jié)一下，當(dāng)組件生命周期發(fā)生變化時，首先判斷是否為銷毀狀態(tài)，是的話就將觀察者從LiveData和Lifecycle的觀察者列表中刪除。否則就會判斷組件生命周期變化是否導(dǎo)致可見性發(fā)生了變化，是的話就更新觀察者當(dāng)前的活動狀態(tài)，如果是從非活動狀態(tài)轉(zhuǎn)為活動狀態(tài)，LiveData還需要向該觀察者分發(fā)最新數(shù)據(jù)，觀察者再根據(jù)版本號來決定是否需要更新。
LiveData更新數(shù)據(jù)時觀察者是如何工作的
LiveData更新數(shù)據(jù)是從setValue方法開始的：
@MainThread
protected void setValue(T value) {
assertMainThread("setValue");
mVersion++;
mData = value;
dispatchingValue(null);
}
這個方法很簡單，首先這個方法只能在主線程調(diào)用，接著會將版本號+1，然后更新數(shù)據(jù)，最后再將數(shù)據(jù)分發(fā)給所有觀察者。
接著再看一下另一個更新數(shù)據(jù)的方法postValue：
protected void postValue(T value) {
boolean postTask;
synchronized (mDataLock) {
postTask = mPendingData == NOT_SET;
mPendingData = value;
}
if (!postTask) {
return;
}
ArchTaskExecutor.getInstance().postToMainThread(mPostValueRunnable);
}
這里首先會通過加鎖判斷是否有其他子線程在更新，因為子線程更新數(shù)據(jù)是先將數(shù)據(jù)賦值給mPendingData以后再拿著mPendingData更新的，更新以后又會將mPendingData設(shè)為NOT_SET（其實不是這樣的，先這樣說比較好理解，后面會分析）,所以如果mPendingData為NOT_SET，則表示當(dāng)前線程可以更新，然后將value賦值給mPendingData以后再執(zhí)行更新操作，否則則表示當(dāng)前有其他線程正在更新，那么就把value賦值給mPendingData，讓這個正在更新的線程來幫自己更新，自己直接退出就行了，我們現(xiàn)在看一下是如何更新的：
ArchTaskExecutor.getInstance().postToMainThread(mPostValueRunnable);
public static ArchTaskExecutor getInstance() {
if (sInstance != null) {
return sInstance;
}
synchronized (ArchTaskExecutor.class) {
if (sInstance == null) {
sInstance = new ArchTaskExecutor();
}
}
return sInstance;
}
很容易看出是一個單例模式，返回一個ArchTaskExecutor對象，看一下它的相關(guān)成員變量和構(gòu)造函數(shù)：
private TaskExecutor mDelegate;
@NonNull
private TaskExecutor mDefaultTaskExecutor;
private ArchTaskExecutor() {
mDefaultTaskExecutor = new DefaultTaskExecutor();
mDelegate = mDefaultTaskExecutor;
}
這里可知mDelegate = mDefaultTaskExecutor = new DefaultTaskExecutor();
接下來看一下它的postToMainThread函數(shù)：
@Override
public void postToMainThread(Runnable runnable) {
mDelegate.postToMainThread(runnable);
}
可以看出這是一個靜態(tài)代理模式，代理給mDelegate執(zhí)行了，而mDelegate又是DefaultTaskExecutor類的實例，進(jìn)入DefaultTaskExecutor的postToMainThread方法：
@Override
public void postToMainThread(Runnable runnable) {
if (mMainHandler == null) {
synchronized (mLock) {
if (mMainHandler == null) {
mMainHandler = createAsync(Looper.getMainLooper());
}
}
}
//noinspection ConstantConditions
mMainHandler.post(runnable);
}
這里會通過DLC獲取一個Handler對象mMainHandler：
private static Handler createAsync(@NonNull Looper looper) {
if (Build.VERSION.SDK_INT >= 28) {
return Handler.createAsync(looper);
}
if (Build.VERSION.SDK_INT >= 16) {
try {
return Handler.class.getDeclaredConstructor(Looper.class, Handler.Callback.class,
boolean.class)
.newInstance(looper, null, true);
} catch (IllegalAccessException ignored) {
} catch (InstantiationException ignored) {
} catch (NoSuchMethodException ignored) {
} catch (InvocationTargetException e) {
return new Handler(looper);
}
}
return new Handler(looper);
}
其實就是一個主線程的Handler，然后再在主線程執(zhí)行runnable,這個runnable就是postToMainThread傳入的mPostValueRunnable：
private final Runnable mPostValueRunnable = new Runnable() {
@SuppressWarnings("unchecked")
@Override
public void run() {
Object newValue;
synchronized (mDataLock) {
newValue = mPendingData;
mPendingData = NOT_SET;
}
setValue((T) newValue);
}
};
最后還是調(diào)用了setValue方法更新數(shù)據(jù)，這里要解釋一下為什么之前說更新以后又會將mPendingData設(shè)為NOT_SET的說法不對，看完上面這個代碼就明白了，他這里是將mPendingData設(shè)為NOT_SET以后才更新數(shù)據(jù)的，之前說如果當(dāng)前線程試圖更新數(shù)據(jù)時發(fā)現(xiàn)有另外一個線程正在更新數(shù)據(jù)，那么就會將值交給mPendingData以后就交給另一個線程不管了，它判斷是否有另一個線程在更新數(shù)據(jù)的依據(jù)是mPendingData是否不為NOT_SET，意思就是說如果mPendingData不為NOT_SET那么另一個線程的更新的值是可以改變的，如果為NOT_SET，那么表示此時沒有更新操作，或者更新操作的值已經(jīng)無法改變了，那么就要自己親自執(zhí)行更新操作了，從代碼中就能看出來，當(dāng)將mPendingData的值賦給newValue以后，再怎么改變mPendingData的值也無法改變此次更新的結(jié)果了。
這就是LiveData的工作原理，個人感覺相對于Lifecycle要更好理解。
如果有什么不正確的地方歡迎指正！
