JetPack源码分析之LiveData原理
学习LiveData 需要看一下Livecycle 的原理,在学习之前你需要知道下面的情况
1.livedata 在事件分发过程中对被观察者的状态做了一些判断,如果被观察者的状态是 State.STARTED 与 State.RESUMED 这两种状态的情况下,才会对数据做分发,并且分发的是最后一次数据
2.LiveData 是一个带有粘性的数据发生方式, 具体的实现是通过对比 观察者和被观察者两端的 版本号来实现的,分发的也是最后一条数据
3.LiveData 作为观察者,观察 LifecycleOwner 的生命周期事件,但是 同时也被我们添加的Observe 观察,所以他既是一个观察者,同时也是被观察者,所以在分析的过程,我们就需要从观察者和被观察两个角度同时来看整个过程,如果同时来看的话,会把自己绕晕
4. 关于Livecycle 的状态,我再贴一下上一篇博客的图片,方便大家理解
下面我们分析源码 --> 观察者角度
class MainActivity : AppCompatActivity() {
val liveData :MutableLiveData<String> by lazy { MutableLiveData() }
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
liveData.observe(this,{
})
}
}
这绑定的过程中 将 this 传入了进入,这个this就是被观察者,
@MainThread
public void observe(@NonNull LifecycleOwner owner, @NonNull Observer<? super T> observer) {
assertMainThread("observe");
if (owner.getLifecycle().getCurrentState() == DESTROYED) {
// ignore
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);
}
这里使用了LifecycleBoundObserver 来封装了一下,将 owner 传入了进去,接下来进去分析
class LifecycleBoundObserver extends ObserverWrapper implements LifecycleEventObserver {
@NonNull
final LifecycleOwner mOwner;
LifecycleBoundObserver(@NonNull LifecycleOwner owner, Observer<? super T> observer) {
super(observer);
mOwner = owner;
}
@Override
boolean shouldBeActive() {
return mOwner.getLifecycle().getCurrentState().isAtLeast(STARTED);
}
@Override
public void onStateChanged(@NonNull LifecycleOwner source,
@NonNull Lifecycle.Event event) {
Lifecycle.State currentState = mOwner.getLifecycle().getCurrentState();
if (currentState == DESTROYED) {
removeObserver(mObserver);
return;
}
Lifecycle.State prevState = null;
while (prevState != currentState) {
prevState = currentState;
activeStateChanged(shouldBeActive());
currentState = mOwner.getLifecycle().getCurrentState();
}
}
@Override
boolean isAttachedTo(LifecycleOwner owner) {
return mOwner == owner;
}
@Override
void detachObserver() {
mOwner.getLifecycle().removeObserver(this);
}
}
这个类算是一个比较简单的类, 但是这个里面有一个非常重要的方法,关乎这 LiveData 的使用特性,就是下面这个 shouldBeActive 方法
@Override
boolean shouldBeActive() {
return mOwner.getLifecycle().getCurrentState().isAtLeast(STARTED);
}
这个方法是获取到被观察者也是LifecycleOwner 的状态最少是STARTED 才会返回true,
当每次被观察者状态发生改变后会回调 onStateChanged 这个方法,他在一面判断了如果是DESTROYED 这个状态,就是就将当前这个观察者移除,其他都是同步状态,至于为什么说使用while ,还是在lifecycle 中说到的,我们的观察者可以在被观察者的任何生命周期中加入,如果实在onStart 或者onResume 中加入进来,中间会遗漏部分流程,导致 观察者部分代码逻辑异常
继续追踪activeStateChanged(shouldBeActive()); 这个方法
void activeStateChanged(boolean newActive) {
if (newActive == mActive) {
return;
}
// immediately set active state, so we'd never dispatch anything to inactive
// owner
mActive = newActive;
changeActiveCounter(mActive ? 1 : -1);
if (mActive) {// 至少是STARTED 状态才可以
dispatchingValue(this);
}
}
这里面就看到了上面第一条所说的至少在LifecycleOwner STARTED 这个状态才会继续分发数据 ,继续看 dispatchingValue(this) 这个方法,这个里面有一个需要注意的地方,在调用的时候传入了一个 this,这个逻辑非常重要
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;
}
可以看到 if (initiator != null) 这个判断应该是一个非空的判断 ,那么就进入到了 considerNotify(initiator); 这个方法
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);
}
为了保证数据的准确性,这个里面又重新判断了active state,同时粘性事件就是从这里发出来的, 我们来分析一下这个粘性事件是怎么来的
粘性事件的来源
发生场景1. 在ViewModel 中创建了一个 LiveData , 本次对这个LiveData 的数据进行了修改,修改后结束当前这个activity ,由于 这个viewmodel 是在 ViewModelProvider 中管理的,结束了activity 这个viewmodel并不一定会被销毁,重新打开activity 绑定的是上一次的viewmodle ,在绑定过程中就会发生这个粘性事件,
至于说observer.mLastVersion >= mVersion 这两个版本号再这个里面起了至关重要的作用,那么他们又为什么会发生不同步的呢
我们看下面代码
@MainThread
protected void setValue(T value) {
assertMainThread("setValue");
mVersion++;
mData = value;
dispatchingValue(null);
}
在livedata 在setValue 方法中,每次发射一个数据都会将自身持有的mVersion ++ ,默认值是-1 ,
同时observer 中也持有一个mLastVersion初始值是-1,在每次同步数据后,将 livedata的mVersion 赋值给observer 的mLastVersion,让版本同步,由于在上面这个案例中livedata 是viewmodel 持有的,但是viewmdoel 没有被销毁,那么 livedata 发送过数据之后版本号就不是-1了,而观察者observer 是我们重新创建的,他的值就是初始值,这样就存在粘性数据了,
只要livedata 的生命周期比activity长 或者早, 都会发生这种问题,解决这个问题的方式有好多种,大家可以自行百度一下
下面我们分析源码 --> 被观察者角度
作为被观察者的入口我们从postValue 来开始分析
protected void postValue(T value) {
boolean postTask;
synchronized (mDataLock) {
postTask = mPendingData == NOT_SET;
mPendingData = value;
}
if (!postTask) {
return;
}
ArchTaskExecutor.getInstance().postToMainThread(mPostValueRunnable);
}
@Override
public void postToMainThread(Runnable runnable) {
if (mMainHandler == null) {
synchronized (mLock) {
if (mMainHandler == null) {
mMainHandler = new Handler(Looper.getMainLooper());
}
}
}
//noinspection ConstantConditions
mMainHandler.post(runnable);
}
private final Runnable mPostValueRunnable = new Runnable() {
@SuppressWarnings("unchecked")
@Override
public void run() {
Object newValue;
synchronized (mDataLock) {
newValue = mPendingData;
mPendingData = NOT_SET;
}
setValue((T) newValue);
}
};
使用 ArchTaskExecutor.getInstance().postToMainThread 将Runnable 通过Handler 调度到 主线程来执行setValue 方法
@MainThread
protected void setValue(T value) {
assertMainThread("setValue");
mVersion++;
mData = value;
dispatchingValue(null);
}
到了这里又执行了 dispatchingValue(null); 注意这里的方法入参是null 继续看下面代码
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;
}
看到这个方法是不是很熟悉,对就是在创建过程中执行的方法,这里我们执行的else 中的代码,去除所有的观察者,遍历发送数据
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);
}
到了这里整个分析就结束了
