lifecycle：一个持有activity/fragment生命周期信息的类，允许其他对象观察此对状态
Event:从框架和lifecycle类派发的生命周期事件，也就是activity和fragment的各个状态会发Event
state:这个就好理解了，就是activity和fragment当前的状态
LifecycleOwner: 我的理解这是一个被观察者接口，他持有一个lifecycle，这个lifecycle就是被观察者中的事件，观察者想观察的事件，就是lifecycle的状态
在lifecycle抽象类中，定义了抽象方法，addOberrver和removeObserver,这是经典的被观察者
再回到lifecycleOwner的源码中
看，其实就是一个接口，一个获取lifecycle对象的方法
那么到这里，就知道了，只要实现了lifecycleOwner接口的对象，都会持有一个lifecycle的对象，那么实际上，lifecycleOwner本没有添加观察者的能力，添加观察者实际是在lifecycle对象中实现的
lifecycleOberver:前面被观察者找到了，那么观察者也应该现身了，就是他，也是一个接口，实现该接口的对象，通过注解的方式，被lifecycleOwner代理被观察者注册为观察者，此后就能观察到lifecycle的状态改变
从上面lifecycle的源码中可以看到，addOberver(LifecycleOberver oberver)，添加的观察者就是LifecycleOberver
更简洁了，就是一个接口，也就是说实现了这个接口的类，就可以是lifecycle的观察者
--------------------------------------------------------------------------------------------------------------------------------
我们来到Mvvm中
看看创建的BaseViewModel
继承了ViewModel抽象类，并实现了DefaultLifecycleObserver，不言而喻这里我们的BaseTestViewModel变成了一个实现了LifecycleObserver的观察者，并且我们可以重写onCreate获得被观察者，这个onCreate()来自哪里呢
来自
写的很明白了，当lifecycle的生命周期发生变换的时候，这些方法就会执行，那么此时我们是不是就变成了有生命周期感知了，那么我们继续追踪lifecycleOwner的来源
我们要使用的viewModel，继承自我们的BaseTestViewModel
这里插一段仓库层，也就是网络请求层，为了让仓库层也能感应生命周期的变化，我们需要做一些操作赋予它生命周期的感应功能
新建一个接口
这个接口就定义两个函数，onCreate()和onDestory(),参数就是被观察者，参数肯定是被观察者，因为我们要感知生命周期，那生命周期肯定就是被观察者的啊
写一个基类仓库层，实现接口
这样写的好处是可以在基类做一些其他的事情
来到我们实际的仓库层
在实际的仓库层中，我们就能获得生命周期被观察者LifecycleOwner，那么这里是获取到，获取的是谁呢？
我们回到刚刚的MainViewModel中，我们创建一个仓库层的对象，在MainViewModel的onCrate中调用仓库层的onCreate()，因为viewModel的onCreate是被观察者lifecycle的ON_START事件的回调，那么此时我们的仓库层，也就是拥有了生命周期被观察者，且我们仓库层和被观察者的ON_START事件和ON_DESTORY事件同步上了
到现在我们还没找到LifecycleOwner从哪里传来的呢？继续追踪
我们的MainViewModel是和自己的Activity绑定的，绑定在哪里执行呢，在我们封装的BaseActivity中，我们在这创建了viewModel，然后呢，直接给它注册到被观察者里面去啊！！
我们追踪Activity的继承关系，发现在ComponetActivity类中实现了LifecycleOwner和ViewModelStoreOwner接口
那么我们就发现了原来Activity就是一个被观察者啊，fragment同理啊，这俩原来早就实现了LifecycleOwner接口，都是被观察者啊
接下来我们来到关键的一行
/**
* 到这里就很明显了，追踪Activity的继承关系，会发现activity实现了一个接口“LifecycleOwner”，还记得不，这个被观察者的接口，只要实现了这个接口的类都是持有lifecycle的被观察者
* ViewModelProvider 这里是不是就是将被观察者owner注册观察者呢
*/
mViewModel = new ViewModelProvider(this,new ViewModelProvider.NewInstanceFactory()).get(vmClass);来到ViewModelProvider中
创建ViewModelProvider，它将通过给定的工厂创建viewmodel，并将它们保留在给定的ViewModelStoreOwner的存储中。
来到ViewModelStoreOwner,这个东西好像在哪见过，没错就是ComponetActivity中实现了这个接口，那也就是说activity就是一个ViewModelStoreOwner了
继续追踪到ViewModelStore
就是viewModel的管理，获取类，也就是说实现了ViewModelStoreOwner接口的类，都会有一个map用来管理viewModel
我们继续看ViewModelProvider的get(class)
也就是根据class的名称和class来找viewModel，找不到就创建viewModel，并且存到viewModelStore中，也就是创建的时候就会存到viewModelStore中去，viewModelStore中有get、put、clear方法，clear方法就是清空viewModel，看看调用的地方
有两个地方调用了一个是经典的ComponentActivity，一个是FragmentManagerViewModel中
一追踪就很明显能看到都是在ON_DESTORY的时候才会调用，也就是说，viewModel自创建后，只有在页面销毁的时候才会被clear掉，不然会一直存在。 也就是说viewModel的生命周期就是activity的创建到销毁
