Android-LiveData原理解析

LiveData是一种具有生命周期感知能力的可观察数据持有类。

LiveData可以保证屏幕上的显示内容和数据一直保持同步。

在项目中，LiveData一般是存放在ViewModel中，以保证app配置变更时，数据不会丢失。

使用流程其实很简单，就是自定义实现一个Observer观察者，然后在Activity或者Fragment中获取到ViewModel，通过ViewModel获取到对应的LiveData，然后给LiveData添加观察者监听，用来监听LiveData中的数据变化，在Observer的onChanged中使用监听回调数据。

在使用LiveData的时候需要注意，LiveData有两个设置数据的方法，一个是setValue，一个是postValue，setValue只能是在主线程使用，而postValue只能在子线程中使用。

LiveData添加观察者监听，可以看到LiveData的observe方法，使用了@MainThread注释，表明该观察者监听添加的方法，只能是在主线程中使用，如果不是在主线程中使用，则会抛出异常。

在LiveData添加观察者的时候，因为LifecycleBoundObserver实际上也是实现了LifecycleEventObserver接口的，所以在LifecyclinglifecycleEventObserver对观察者对象做封装的时候，也是直接返回传入的观察者对象，不做任何的处理

LifecycleBoundObserver中封装了LifecycleOwner对象和Observer对象，并且实现了LifecycleEventObserver接口，根据Lifecycle的原理，其实我们可以知道，LifecycleRegistryaddObserver方法，添加的就是LifecycleEventObserver实现了对象。

所以在Activity使用LiveData，添加观察者，其实其内部最终还是给Activity的LifecycleRegistry添加观察者，然后根据Activity的生命周期的变化对LiveData进行通知。

postValue的通知更新，其实就是调动任务栈分发任务，而被分发执行的任务实现如下：

从这里可以看到，其实postValue在分发的任务中，其内部实现的依然是setValue()方法，只不过是从子线程切换到了主线程进行执行。做了一次线程的切换。

在postValue方法中，其内部调用的是ArchTaskExecutor的postToMainThread方法。

在这里可以看到mDelegate其实就是DefaultTaskExecutor对象

所以mDelegatepostToMainThread(runnable)其实就是调用了DefaultTaskExecutorpostToMainThread方法。

在这里可以看到，mMainHandler其实就是通过主线程的Looper实例创建的Handler对象，所以这里Handler发送消息执行任务，就是在主线程中执行该任务。

LiveData在分发消息的时候，会调用dispatchingValue方法循环分发，当消息分发完成之后，其实并不会退出do-while循环，还会在调用considerNotify方法的内部调用observeractiveStateChanged(false);继续执行第二次dispatchingValue方法，也就是说递归执行，在第二次执行的时候，mDispatchingValue = true，就会执行将mDispatchInvalidated = true，那么就会完成dispatchingValue方法的第二次执行，被直接return，那么considerNotify()方法的执行也就完成，此时就会执行considerNotify之后的if条件，因为在dispatchingValue第二次执行的时候将mDispatchInvalidated设置为了true，就直接break跳出了循环，结束了消息的分发。

但是这样的情况，一般是在存在观察者处于ON_STOP或者已经是ON_DESTROY状态的时候。

如果观察者都是处于onResume，那么这个时候会因为mDispatchInvalidated=false而退出了循环，结束分发。

但是如果是先setValue，然后再设置Observer的话。

因为此时设置Observer的时候，当生命周期发生变化的时候，又会调用回调onStateChanged方法，进而调用activeStateChanged方法

因为在添加Observer之前，已经针对该LiveData设置了一个value，此时添加了观察者，那么又因为生命周期发生了变化，那么该观察者在调用dispatchingValue(this);传入的就不是null，则在do-while循环的if判断中，就会执行if条件，进而调用considerNotify()方法给传入的ObserverWrapper实现类分发消息，那么就会把之前设置的消息分发给了该观察者。

这样的情况就是LiveData的粘性事件。即后注册的观察者接收到了之前LiveData设置的value消息。

那么问题又一次来了，什么时候会触发调用LifecycleBoundObserver的onStateChanged方法呢？

通过LiveData的observe方法进行分析，我们可以知道给LiveData添加观察者的时候，其实就是通过给实现了LifecycleOwner接口的Activity的getLifecycle()方法获取到的LifecycleRegistry对象添加观察者，而LifecycleRegistry中的addObserver方法，就会先满足while条件，然后执行了ObserverWithStatedispatchEvent方法，此时就会调用到了LifecycleBoundObserveronStateChanged方法

这里为什么会满足while条件呢？calculateTargetState会获取当前Activity生命周期状态的前一个和后一个状态，然后取更小的那个状态，在addObserver的时候，calculateTargetState这里如果activity是onStart的状态，那么calculateTargetState取出的就是CREATED状态，如果activity是onResume的状态，那么这里取出的就是STARTED，不管怎么样都会大于INITIALIZED状态，那么就会满足while条件，此时第二个activity是在onCreate生命周期调用observe方法注册Observer

其实这里个人感觉，应该是在addObserver之后，因为第二个Activity(也就是添加addObserver的)发生了生命周期变化，从onCreate变成了onStart，从onStart变成onResume，此时就会调用moveToState，然后就会调用forwardPass()，然后就会分发消息，因为之前已经postValue或者setValue了，那么在这个LiveData里的mData就不会为null，有消息了，就可以优先分发一次。

满足while条件后，就会调用statefulObserverdispatchEvent(lifecycleOwner, upEvent(statefulObservermState));，这里最终就会调用LifecycleBoundObserver的

这里shouldBeActive()，在Activity的最后的生命周期是onResume的时候，就会满足true，那么此时activeStateChanged()传入的参数就是true，而初始的时候，mActive为false

此时mActive就会重新赋值为true，那么就会调用dispatchingValue()方法，此时dispatchingValue()的参数传入this，那么就不会为false。

一般常用的粘性事件解决方案，其实就是hook修改mLastVersion的值，让这个值变成与mVersion的值一致，但是如果是在onResume或者onStart的生命周期去添加注册观察者，那么常见的粘性事件解决方案中，因为会调用superobserve()，那么就会因为在LifecycleRegistryaddObserver方法中，满足while条件，从而又会进行LifecycleBoundObserver的onStateChanged方法的回调，这样又会出现粘性事件。这样的情况的解决方案，其实可以hook修改mVersion的值，在注册观察者之前，改成-1

关于Activity的生命周期相信不少人都觉得自己很了解了，毕竟大多数入门的时候都会首先学这个，但事实真的是这样吗？当初我也是这样想，直到在面试的时候栽了跟头~ 在哪跌倒就在哪爬起来，本文带你全面的了解一下Activity的生命周期，面试再问到也不怕啦

首先按照官方生命周期流程图逐个解释生命周期回调

当Activity首次创建的时候触发，这是生命周期的第一个方法，我们需要重写这个回调，并在调用setContentView()去加载界面布局资源，以及实例化一些变量。该方法有一个参数savedInstanceState，该参数包含Activity先前保存状态的Bundle对象。如果Activity是由于异常情况（切换横竖屏，内存不足等）被杀掉的，则Bundle对象的值不为null，否则Bundle的值为null。所以如果想要在onCreate()中做恢复工作需要对Bundle判断是否为空。不过建议在onRestoreInstanceState()方法中做恢复工作，因为该方法一旦被调用则Bundle不会为空。

表示Activity正在重新启动。一般情况下，当当前Activity从不可见重新变为可见状态时，onRestart就会被调用。这种情形一般是用户行为导致的，比如用户按Home键切换到桌面或打开了另一个新的Activity，接着用户又回到了这个Actvity。

表示Activity正在被启动，即将开始，这时Activity已经出现了，但是还没有出现在前台，无法与用户交互。这个时候可以理解为Activity已经显示出来，但是我们还看不到。

相信很多人会有疑问，什么叫Activity已经显示出来了，但是看不到？？？因为我们能看到的都是View或者和View有关联的东西，而Activity确实是没有什么直观的东西让我们看到的。所以这里说的看不到其实是看不到View，因为此时View还不是可见的，只有在onResume的时候才会把View设置为可见，想了解清楚的可以查看 Window和WindowManager的创建与Activity

此时Activity进入前台，具备与用户交互的能力。与onStart()都是对用户可见，但是onStart()时Activity是位于后台的，onResume()时Activity才显示到前台。 如果我们在onPause()中释放了组件，我们应该在onResume()中重新初始化。 我们应该在这里开始动画和初始化一些只有用户关注时才使用的组件。

当用户离开了Activity时会回调这个方法，比如说：

我们可以在这个方法中执行一些释放资源的 *** 作，比如broadcast receivers，sensors，以及一些用户在不交互时不需要的资源。

该方法执行的时间非常简短，因此不应该在这个方法保存程序或用户数据；在该方法完成之前，保存工作可能并未完成。而且会影响到新的Activity的显示，因为onPause()执行完，新Activity才会开始执行onCreate()。

当Activity对用户不再可见的时候会回调该方法，比如说启动一个新的Activity把屏幕全都遮住了。

之前说过不建议在onPause()做一些重量级的释放工作，应该交由onStop()去释放大多数资源。比如unregisterReceiver()，还有其他可能导致内存泄露的资源，因为系统可能在没有回调onDestroy()的时候就杀掉了进程。

在Activity被销毁之前会回调该方法，这也是Activity生命周期的最后一个回调。

如果在Activity调用了finish()或者由于内存紧张系统销毁了该Activity，也有可能是由于横竖屏的切换或者用户按了返回键都会导致该方法的回调，

我们应该在这个方法中回收之前没有回收掉的所有资源

ActivityA:onPause() ->ActivityB:onCreate()->ActivityB:onStart()->ActivityB:onResume()-> ActivityA:onStop()

当ActivityA调用完onPause()之后才会调用ActivityB的onCreate()，所以不要在onPause()中做耗时 *** 作，会影响新Activity的显示。

只有当ActivityB的onResume()调用完之后才会调用ActivityA的onStop()，因为此时ActivityB在最上面，ActivityA才是完全不可见的。

onPause()->onSaveInstanceState()->onStop()->onDestroy()->onCreate()->onStart()->onRestoreInstanceState()->onResume()

如果没有在AndroidManifest设置configChanges，则屏幕旋转的时候会吧Activity销毁再重建，并且重建后的Activity和原来的不是同一个实例。

如果设置了android:configChanges="orientation|screenSize"，则屏幕旋转时只会调用onConfigurationChanged()方法，并且不会销毁重建

首先每个应用最少有一个进程，我们的Activity都是运行在进程中的，当应用退到后台时，系统可能因为内存不足而杀掉优先级低的进程，那么再该进程中的Activity都会被杀死，这种情况是不会走Activity的生命周期的，只有杀掉单个Activity的时候才会走Activity的onDestroy()方法。

onPause()->onStop()->onDestroy()

当Activityd出Dialog获取PopupWindow是不会走任何生命周期的。

d出DialogActivity原来的Activity会执行onPause()，关闭DialogActivity原来的Activity执行onResume()

onPause()->onStop()->onRestart()->onStart()->onResume()

onPause()->onNewIntent()->onResume()

在Android系统中，Activity窗口的大小是由WindowManagerService服务来计算的。WindowManagerService服务会根据屏幕及其装饰区的大小来决定Activity窗口的大小。一个Activity窗口只有知道自己的大小之后，才能对它里面的UI元素进行测量、布局以及绘制。本文将详细分析WindowManagerService服务计算Activity窗口大小的过程。

一般来说，Activity窗口的大小等于整个屏幕的大小，但是它并不占据着整块屏幕。为了理解这一点，我们首先分析一下Activity窗口的区域是如何划分的。

我们知道，Activity窗口的上方一般会有一个状态栏，用来显示3G信号、电量使用等图标，如图1所示。

图1 Activity窗口的Content区域示意图

从Activity窗口剔除掉状态栏所占用的区域之后，所得到的区域就称为内容区域(Content Region)。顾名思义，内容区域就是用来显示Activity窗口的内容的。我们再抽象一下，假设Activity窗口的四周都有一块类似状态栏的区域，那么将这些区域剔除之后，得到中间的那一块区域就称为内容区域，而被剔除出来的区域所组成的区域就称为内容边衬区域(Content Insets)。Activity窗口的内容边衬区域可以用一个四元组(content-left, content-top, content-right, content-bottom)来描述，其中，content-left、content-right、content-top、content-bottom分别用来描述内容区域与窗口区域的左右上下边界距离。

我们还知道，Activity窗口有时候需要显示输入法窗口，如图2所示。

图2 Activity窗口的Visible区域示意图

这时候Activity窗口的内容区域的大小有可能没有发生变化，这取决于它的Soft Input Mode。我们假设Activity窗口的内容区域没有发生变化，但是它在底部的一些区域被输入法窗口遮挡了，即它在底部的一些内容是不可见的。从Activity窗口剔除掉状态栏和输入法窗口所占用的区域之后，所得到的区域就称为可见区域(Visible Region)。同样，我们再抽象一下，假设Activity窗口的四周都有一块类似状态栏和输入法窗口的区域，那么将这些区域剔除之后，得到中间的那一块区域就称为可见区域，而被剔除出来的区域所组成的区域就称为可见边衬区域(Visible Insets)。Activity窗口的可见边衬区域可以用一个四元组(visible-left, visible-top, visible-right, visible-bottom)来描述，其中，visible-left、visible-right、visible-top、visible-bottom分别用来描述可见区域与窗口区域的左右上下边界距离。

在大多数情况下，Activity窗口的内容区域和可见区域的大小是一致的，而状态栏和输入法窗口所占用的区域又称为屏幕装饰区。理解了这些概念之后，我们就可以推断，WindowManagerService服务实际上就是需要根据屏幕以及可能出现的状态栏和输入法窗口的大小来计算出Activity窗口的整体大小及其内容区域边衬和可见区域边衬的大小。有了这三个数据之后，Activity窗口就可以对它里面的UI元素进行测量、布局以及绘制等 *** 作了。

从前面Android应用程序窗口(Activity)的绘图表面(Surface)的创建过程分析一文可以知道，应用程序进程是从ViewRoot类的成员函数performTraversals开始，向WindowManagerService服务请求计算一个Activity窗口的大小的，因此，接下来我们就从ViewRoot类的成员函数performTraversals开始分析一个Activity窗口大小的计算过程，如图3所示。

图3 Activity窗口大小的计算过程

这个过程可以分为11个步骤，接下来我们就详细分析每一个步骤。

Step 1 ViewRootperformTraversals

这个函数定义在文件frameworks/base/core/java/android/view/ViewRootjava中，它的实现很复杂，一共有600-行，不过大部分代码都是用来计算Activity窗口的大小的，我们分段来阅读：

[java] view plaincopypublic final class ViewRoot extends Handler implements

ViewParent,

ViewAttachInfoCallbacks {

private void performTraversals() {

final View host = mView;

int desiredWindowWidth;

int desiredWindowHeight;

int childWidthMeasureSpec;

int childHeightMeasureSpec;

Rect frame = mWinFrame;

if (mFirst) {

DisplayMetrics packageMetrics =

mViewgetContext()getResources()getDisplayMetrics();

desiredWindowWidth = packageMetricswidthPixels;

desiredWindowHeight = packageMetricsheightPixels;

} else {

desiredWindowWidth = framewidth();

desiredWindowHeight = frameheight();

if (desiredWindowWidth != mWidth || desiredWindowHeight != mHeight) {

windowResizesToFitContent = true;

}

}

复制代码

这段代码用来获得Activity窗口的当前宽度desiredWindowWidth和当前高度desiredWindowHeight。

以上就是关于Android-LiveData原理解析全部的内容，包括:Android-LiveData原理解析、Activity的生命周期及常见回调顺序、android 如何获取当前界面最上面的activity等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！