Fragment.viewBinding(viewBindingFactory: (View) -> T) =
+ FragmentViewBindingDelegate(this, viewBindingFactory)
+```
+
+然后，使用我们定义的委托来重构`ProfileFragment`，注意在Fragment中使用需要注意传入布局Id,因为在代理getValue的时候会获取requireView:
+
+```kotlin
+class ProfileFragment : Fragment(R.layout.profile) {
+ private val binding by viewBinding(ProfileBinding::bind)
+ override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
+ super.onViewCreated(view, savedInstanceState)
+ // Use viewBinding
+ }
+}
+```
+
+很好，我们去掉了创建和销毁ViewBinding的样板代码，现在只需要声明一个委托属性就可以了，是不是简单了？
+
+Android的新库ViewBinding是一个去掉项目中`findViewByid()`很好的解决方案，同时它也替代了著名的`Butter Knife`。ViewBinding 与Kotlin委托属性的巧妙结合，可以让你的代码更加简洁易读。
+
+完整的代码可以查看github:[https://github.com/kirich1409/ViewBindingPropertyDelegate](https://links.jianshu.com/go?to=https%3A%2F%2Fgithub.com%2Fkirich1409%2FViewBindingPropertyDelegate)
+
+## 与findViewById的区别
+
+与使用 findViewById 相比，视图绑定具有一些很显著的优点：
+- Null 安全
+ 由于视图绑定会创建对视图的直接引用，因此不存在因视图ID无效而引发Null指针异常的风险。此外，如果视图仅出现在布局的某些配置中，则绑定类中包含其引用的字段会使用@Nullable标记。
+- 类型安全
+ 每个绑定类中的字段均具有与它们在XML文件中引用的视图相匹配的类型。这意味着不存在发生类转换异常的风险。
+
+这些差异意味着布局和代码之间的不兼容将会导致构建在编译时（而非运行时）失败。
+
+## 与DataBinding的对别
+ViewBinding与DataBinding均会生成可用于直接引用视图的绑定类。但是，ViewBinding旨在处理更简单的用例，与DataBinding相比，具有以下优势:
+- 更快的编译速度
+ 视图绑定不需要处理注释，因此编译时间更短。
+- 易于使用
+ 视图绑定不需要特别标记的XML布局文件，因此在应用中采用速度更快。在模块中启用视图绑定后，它会自动应用于该模块的所有布局。
+
+反过来，与数据绑定相比，视图绑定也具有以下限制:
+- 视图绑定不支持布局变量或布局表达式，因此不能用于直接在XML布局文件中声明动态界面内容。
+- 视图绑定不支持双向数据绑定。
+
+考虑到这些因素，在某些情况下，最好在项目中同时使用视图绑定和数据绑定。您可以在需要高级功能的布局中使用数据绑定，而在不需要高级功能的布局中使用视图绑定。
+
+# 参考
+
+- [View Binding 与Kotlin委托属性的巧妙结合，告别垃圾代码！](https://www.jianshu.com/p/bf4e81501fbb)
+- [Make Android View Binding great with Kotlin](https://proandroiddev.com/make-android-view-binding-great-with-kotlin-b71dd9c87719)
+- [How to Simplify your Android View Binding Delegation](https://medium.com/easyread/how-to-simplify-your-android-view-binding-delegation-d07812b2a616)
+
+## 目录
+
+- [上一篇:1.简介](https://github.com/CharonChui/AndroidNote/blob/master/Jetpack/architecture/1.%E7%AE%80%E4%BB%8B.md)
+- [下一篇:3.Lifecycle简介](https://github.com/CharonChui/AndroidNote/blob/master/Jetpack/architecture/3.Lifecycle%E7%AE%80%E4%BB%8B.md)
+
+---
+
+- 邮箱 ：charon.chui@gmail.com
+- Good Luck! `
diff --git "a/Jetpack/architecture/3.Lifecycle\347\256\200\344\273\213.md" "b/Jetpack/architecture/3.Lifecycle\347\256\200\344\273\213.md"
new file mode 100644
index 00000000..40ab61cf
--- /dev/null
+++ "b/Jetpack/architecture/3.Lifecycle\347\256\200\344\273\213.md"
@@ -0,0 +1,958 @@
+3.Lifecycle简介
+===
+
+## 背景
+
+在Android应用程序开发中，解耦很大程度上表现为系统组件的生命周期与普通组件之间的解耦。普通组件在使用过程中通常需要依赖于系统组件的生命周期。有时候，我们不得不在系统组件的生命周期回调方法中，主动对普通组件进行调用或控制。因为普通组件无法主动获知系统组件的生命周期事件。
+
+我们希望我们对自定义组件的管理，不依赖于页面生命周期的回调方法。同时，在页面生命周期发生变化时，也能够及时收到通知。这在组件化和架构设计中显得尤为重要。
+
+为此，Google提供了LifeCycle作为解决方案。LifeCycle可以帮助开发者创建可感知生命周期的组件。这样，组件便能够在其内部管理自己的生命周期，从而降低模块间的耦合度，并降低内存泄漏发生的可能性。LifeCycle不只对Activity/Fragment有用，在Service和Application中也能大显身手。
+
+```xml
+dependencies {
+ def lifecycle_version = "2.3.1"
+ def arch_version = "2.1.0"
+
+ // ViewModel
+ implementation "androidx.lifecycle:lifecycle-viewmodel-ktx:$lifecycle_version"
+ // LiveData
+ implementation "androidx.lifecycle:lifecycle-livedata-ktx:$lifecycle_version"
+ // Lifecycles only (without ViewModel or LiveData)
+ implementation "androidx.lifecycle:lifecycle-runtime-ktx:$lifecycle_version"
+
+ // Saved state module for ViewModel
+ implementation "androidx.lifecycle:lifecycle-viewmodel-savedstate:$lifecycle_version"
+
+ // Jetpack Compose Integration for ViewModel
+ implementation "androidx.lifecycle:lifecycle-viewmodel-compose:1.0.0-alpha04"
+
+ // Annotation processor
+ kapt "androidx.lifecycle:lifecycle-compiler:$lifecycle_version"
+ // alternately - if using Java8, use the following instead of lifecycle-compiler
+ implementation "androidx.lifecycle:lifecycle-common-java8:$lifecycle_version"
+
+ // optional - helpers for implementing LifecycleOwner in a Service
+ implementation "androidx.lifecycle:lifecycle-service:$lifecycle_version"
+
+ // optional - ProcessLifecycleOwner provides a lifecycle for the whole application process
+ implementation "androidx.lifecycle:lifecycle-process:$lifecycle_version"
+
+ // optional - ReactiveStreams support for LiveData
+ implementation "androidx.lifecycle:lifecycle-reactivestreams-ktx:$lifecycle_version"
+
+ // optional - Test helpers for LiveData
+ testImplementation "androidx.arch.core:core-testing:$arch_version"
+}
+
+```
+
+
+
+## 示例
+
+`Android`开发中，经常需要管理生命周期。举个栗子，我们需要获取用户的地址位置，当这个`Activity`在显示的时候，我们开启定位功能，然后实时获取到定位信息，当页面被销毁的时候，需要关闭定位功能。
+
+```kotlin
+internal class MyLocationListener(
+ private val context: Context,
+ private val callback: (Location) -> Unit
+) {
+
+ fun start() {
+ // connect to system location service
+ }
+
+ fun stop() {
+ // disconnect from system location service
+ }
+}
+
+class MyActivity : AppCompatActivity() {
+ private lateinit var myLocationListener: MyLocationListener
+
+ override fun onCreate(...) {
+ myLocationListener = MyLocationListener(this) { location ->
+ // update UI
+ }
+ }
+
+ public override fun onStart() {
+ super.onStart()
+ myLocationListener.start()
+ // manage other components that need to respond
+ // to the activity lifecycle
+ }
+
+ public override fun onStop() {
+ super.onStop()
+ myLocationListener.stop()
+ // manage other components that need to respond
+ // to the activity lifecycle
+ }
+}
+
+```
+
+虽然此示例看起来没问题，但在真实的应用中，最终会有太多管理界面和其他组件的调用，以响应生命周期的当前状态。管理多个组件会在生命周期方法（如 `onStart()` 和 `onStop()`）中放置大量的代码，这使得它们难以维护。
+
+此外，无法保证组件会在 Activity 或 Fragment 停止之前启动。在我们需要执行长时间运行的操作（如 `onStart()` 中的某种配置检查）时尤其如此。这可能会导致出现一种竞态条件，在这种条件下，`onStop()` 方法会在 `onStart()` 之前结束，这使得组件留存的时间比所需的时间要长。
+
+```kotlin
+class MyActivity : AppCompatActivity() {
+ private lateinit var myLocationListener: MyLocationListener
+
+ override fun onCreate(...) {
+ myLocationListener = MyLocationListener(this) { location ->
+ // update UI
+ }
+ }
+
+ public override fun onStart() {
+ super.onStart()
+ Util.checkUserStatus { result ->
+ // what if this callback is invoked AFTER activity is stopped?
+ if (result) {
+ myLocationListener.start()
+ }
+ }
+ }
+
+ public override fun onStop() {
+ super.onStop()
+ myLocationListener.stop()
+ }
+
+}
+
+```
+
+`android.arch.lifecycle`包提供的类和接口可帮助您用简单和独立的方式解决这些问题。
+
+`Lifecycle`类是一个持有组件(`activity`或`fragment`)生命周期信息的类，其他对象可以观察该状态。`Lifecycle`使用两个重要的枚举部分来管理对应组件的生命周期的状态:
+
+- `Event`:生命周期事件由系统来分发，这些事件对应于`Activity`和`Fragment`的生命周期函数。
+
+- `State`:`Lifecycle`对象所追踪的组件的当前状态
+
+
+
+## LifeCycle的原理
+
+Jetpack为我们提供了两个类:
+
+- LifecycleOwner: 被观察者
+- LifecycleObserver: 观察者
+
+即通过观察者模式，实现对页面生命周期的监听。
+
+```java
+public class AppCompatActivity extends FragmentActivity implements AppCompatCallback,
+ TaskStackBuilder.SupportParentable, ActionBarDrawerToggle.DelegateProvider {
+}
+public class FragmentActivity extends ComponentActivity implements
+ ActivityCompat.OnRequestPermissionsResultCallback,
+ ActivityCompat.RequestPermissionsRequestCodeValidator {
+}
+
+public class ComponentActivity extends androidx.core.app.ComponentActivity implements
+ LifecycleOwner,
+ ViewModelStoreOwner,
+ SavedStateRegistryOwner,
+ OnBackPressedDispatcherOwner {
+ private final LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);
+ public Lifecycle getLifecycle() {
+ return mLifecycleRegistry;
+ }
+}
+public class Fragment implements ComponentCallbacks, OnCreateContextMenuListener, LifecycleOwner,
+ ViewModelStoreOwner, SavedStateRegistryOwner {
+}
+```
+
+ComponentActivity和Fragment已经默认实现了LifecycleOwner接口。
+
+
+
+### LifecycleOwner
+
+那什么是`LifecycleOwner`呢？实现`LifecycleOwner`接口就表示这是个有生命周期的类，他有一个`getLifecycle()`方法是必须实现的。
+
+```java
+/**
+ * A class that has an Android lifecycle. These events can be used by custom components to
+ * handle lifecycle changes without implementing any code inside the Activity or the Fragment.
+ *
+ * @see Lifecycle
+ */
+@SuppressWarnings({"WeakerAccess", "unused"})
+public interface LifecycleOwner {
+ /**
+ * Returns the Lifecycle of the provider.
+ *
+ * @return The lifecycle of the provider.
+ */
+ @NonNull
+ Lifecycle getLifecycle();
+}
+```
+
+从以上源码可知，Activity和Fragment已经替我们实现了被观察者应该实现的那一部分代码。因此，我们不需要再去实现这部分代码。当我们希望监听Activity的生命周期时，只需要实现观察者那一部分的代码，即让自定义组件实现LifecycleObserver接口即可。该接口没有接口方法，无须任何具体实现。
+
+对于前面提到的监听位置的例子。可以把`MyLocationListener`实现`LifecycleObserver`,然后在`Lifecycle（Activity／Fragment）`的`onCreate`方法中初始化。这样`MyLocationListener`就能自行处理生命周期带来的问题。
+
+### 自定义LifecycleOwner
+如果想在自定义的类中实现`LifecyclerOwner`，就需要用到[LifecycleRegistry](https://developer.android.com/reference/android/arch/lifecycle/LifecycleRegistry)类,并且需要自行发送`Event`:
+
+```java
+class MyActivity : Activity(), LifecycleOwner {
+ private lateinit var lifecycleRegistry: LifecycleRegistry
+
+ override fun onCreate(savedInstanceState: Bundle?) {
+ super.onCreate(savedInstanceState)
+
+ lifecycleRegistry = LifecycleRegistry(this)
+ lifecycleRegistry.markState(Lifecycle.State.CREATED)
+ }
+
+ public override fun onStart() {
+ super.onStart()
+ lifecycleRegistry.markState(Lifecycle.State.STARTED)
+ }
+
+ override fun getLifecycle(): Lifecycle {
+ return lifecycleRegistry
+ }
+}
+```
+
+### LifecycleObserver
+
+```java
+/**
+ * Marks a class as a LifecycleObserver. It does not have any methods, instead, relies on
+ * {@link OnLifecycleEvent} annotated methods.
+ *
+ * @see Lifecycle Lifecycle - for samples and usage patterns.
+ */
+@SuppressWarnings("WeakerAccess")
+public interface LifecycleObserver {
+
+}
+```
+
+注释上写的很明白，该接口依赖OnLifecycleEvent的注解方法
+
+```java
+@Retention(RetentionPolicy.RUNTIME)
+@Target(ElementType.METHOD)
+public @interface OnLifecycleEvent {
+ Lifecycle.Event value();
+}
+public enum Event {
+ /**
+ * Constant for onCreate event of the {@link LifecycleOwner}.
+ */
+ ON_CREATE,
+ /**
+ * Constant for onStart event of the {@link LifecycleOwner}.
+ */
+ ON_START,
+ /**
+ * Constant for onResume event of the {@link LifecycleOwner}.
+ */
+ ON_RESUME,
+ /**
+ * Constant for onPause event of the {@link LifecycleOwner}.
+ */
+ ON_PAUSE,
+ /**
+ * Constant for onStop event of the {@link LifecycleOwner}.
+ */
+ ON_STOP,
+ /**
+ * Constant for onDestroy event of the {@link LifecycleOwner}.
+ */
+ ON_DESTROY,
+ /**
+ * An {@link Event Event} constant that can be used to match all events.
+ */
+ ON_ANY
+}
+```
+
+
+
+## 示例改进
+
+
+
+
+```kotlin
+class MainActivity : AppCompatActivity() {
+ override fun onCreate(savedInstanceState: Bundle?) {
+ super.onCreate(savedInstanceState)
+ setContentView(R.layout.activity_main)
+ // lifecycle是LifecycleOwner接口的getLifecycle()方法得到的
+ lifecycle.addObserver(MyObserver())
+ }
+}
+```
+
+在Activity中只需要引用MyObserver即可，不用再关心Activity生命周期变化对该组件所带来的影响。生命周期的管理完全交给MyObserver内部自行处理。在Activity中要做的只是通过getLifecycle().addObserver()方法，将观察者与被观察者绑定起来。
+
+```kotlin
+class MyObserver : LifecycleObserver {
+
+ @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
+ fun connectListener() {
+ ...
+ }
+
+ @OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
+ fun disconnectListener() {
+ ...
+ }
+}
+```
+
+上面的`lifecycle.addObserver(MyObserver()) `的完整写法应该是`aLifecycleOwner.getLifecycle().addObserver(new MyObserver())`而`aLifecycleOwner`一般是实现了`LifecycleOwner`的类，比如`Activity/Fragment`
+
+```kotlin
+internal class MyLocationListener(
+ private val context: Context,
+ private val lifecycle: Lifecycle,
+ private val callback: (Location) -> Unit
+): LifecycleObserver {
+
+ private var enabled = false
+
+ @OnLifecycleEvent(Lifecycle.Event.ON_START)
+ fun start() {
+ if (enabled) {
+ // connect
+ }
+ }
+
+ fun enable() {
+ enabled = true
+ // 查询状态
+ if (lifecycle.currentState.isAtLeast(Lifecycle.State.STARTED)) {
+ // connect if not connected
+ }
+ }
+
+ @OnLifecycleEvent(Lifecycle.Event.ON_STOP)
+ fun stop() {
+ // disconnect if connected
+ }
+}
+```
+
+
+
+对于组件中那些需要在页面生命周期发生变化时得到通知的方法，我们需要在这些方法上使用＠OnLifecycleEvent（Lifecycle.Event.ON_XXX）标签进行标识。这样，当页面生命周期发生变化时，这些被标识过的方法便会被自动调用。
+
+LifeCycle完美解决了组件对页面生命周期的依赖问题，使组件能够自己管理其生命周期，而无须在页面中对其进行管理。这无疑大大降低了代码的耦合度，提高了组件的复用程度，也杜绝了由于对页面生命周期管理的疏忽而引发的内存泄漏问题，这在项目工程量大的情况下是非常有帮助的。
+
+## 使用LifecycleService解耦Service与组件
+
+拥有生命周期概念的组件除了Activity和Fragment，还有一个非常重要的组件是Service。为了便于对Service生命周期的监听，达到解耦Service与组件的目的，Android提供了一个名为LifecycleService的类。该类继承自Service，并实现了LifecycleOwner接口。与Activity/Fragment类似，它也提供了一个名为getLifecycle()的方法供我们使用。
+
+想要使用LifecycleService必须先增加lifecycle-service的依赖:
+
+```
+implementation 'androidx.lifecycle:lifecycle-service:2.3.1'
+```
+
+
+
+```java
+public class LifecycleService
+ extends Service implements LifecycleOwner
+java.lang.Object
+ ↳ android.content.Context
+ ↳ android.content.ContextWrapper
+ ↳ android.app.Service
+ ↳ androidx.lifecycle.LifecycleService
+```
+
+```java
+public class LifecycleService extends Service implements LifecycleOwner {
+
+ private final ServiceLifecycleDispatcher mDispatcher = new ServiceLifecycleDispatcher(this);
+
+ @CallSuper
+ @Override
+ public void onCreate() {
+ mDispatcher.onServicePreSuperOnCreate();
+ super.onCreate();
+ }
+
+ @CallSuper
+ @Nullable
+ @Override
+ public IBinder onBind(@NonNull Intent intent) {
+ mDispatcher.onServicePreSuperOnBind();
+ return null;
+ }
+
+ @SuppressWarnings("deprecation")
+ @CallSuper
+ @Override
+ public void onStart(@Nullable Intent intent, int startId) {
+ mDispatcher.onServicePreSuperOnStart();
+ super.onStart(intent, startId);
+ }
+
+ // this method is added only to annotate it with @CallSuper.
+ // In usual service super.onStartCommand is no-op, but in LifecycleService
+ // it results in mDispatcher.onServicePreSuperOnStart() call, because
+ // super.onStartCommand calls onStart().
+ @CallSuper
+ @Override
+ public int onStartCommand(@Nullable Intent intent, int flags, int startId) {
+ return super.onStartCommand(intent, flags, startId);
+ }
+
+ @CallSuper
+ @Override
+ public void onDestroy() {
+ mDispatcher.onServicePreSuperOnDestroy();
+ super.onDestroy();
+ }
+
+ @Override
+ @NonNull
+ public Lifecycle getLifecycle() {
+ return mDispatcher.getLifecycle();
+ }
+}
+```
+
+
+
+## 整个应用进程的生命周期ProcessLifecycleOwner
+
+具有生命周期的系统组件除Activity、Fragment、Service外，还有Application。很多时候，我们会遇到这样的需求：我们想知道应用程序当前处在前台还是后台，或者当应用程序从后台回到前台时，我们能够得到通知。有不少方案能够实现该需求，但都不够好。在此之前，Google并没有为该需求提供官方解决方案，直到LifeCycle的出现。
+
+
+
+需要先添加lifecycle-process的依赖:
+
+```
+implementation 'androidx.lifecycle:lifecycle-process:2.3.1'
+```
+
+```java
+
+/**
+ * Class that provides lifecycle for the whole application process.
+ *
+ * You can consider this LifecycleOwner as the composite of all of your Activities, except that
+ * {@link Lifecycle.Event#ON_CREATE} will be dispatched once and {@link Lifecycle.Event#ON_DESTROY}
+ * will never be dispatched. Other lifecycle events will be dispatched with following rules:
+ * ProcessLifecycleOwner will dispatch {@link Lifecycle.Event#ON_START},
+ * {@link Lifecycle.Event#ON_RESUME} events, as a first activity moves through these events.
+ * {@link Lifecycle.Event#ON_PAUSE}, {@link Lifecycle.Event#ON_STOP}, events will be dispatched with
+ * a delay after a last activity
+ * passed through them. This delay is long enough to guarantee that ProcessLifecycleOwner
+ * won't send any events if activities are destroyed and recreated due to a
+ * configuration change.
+ *
+ *
+ * It is useful for use cases where you would like to react on your app coming to the foreground or
+ * going to the background and you don't need a milliseconds accuracy in receiving lifecycle
+ * events.
+ */
+@SuppressWarnings("WeakerAccess")
+public class ProcessLifecycleOwner implements LifecycleOwner {
+```
+
+
+
+ProcessLifecycleOwner的使用方式与Activity、Fragment和Service是类似的，其本质也是观察者模式。由于我们要观察的是整个应用程序，因此，需要在Application中进行相关代码的编写。
+
+```kotlin
+class StApplication : Application() {
+ companion object {
+ private lateinit var instance: Application
+ fun getInstance() = instance
+ }
+
+ override fun onCreate() {
+ super.onCreate()
+ instance = this
+ ProcessLifecycleOwner.get().lifecycle.addObserver(MyApplicationObserver())
+ }
+}
+class MyApplicationObserver : LifecycleObserver {
+ @OnLifecycleEvent(Lifecycle.Event.ON_CREATE)
+ fun onCreate() {
+
+ }
+ // 前台出现时调用
+ @OnLifecycleEvent(Lifecycle.Event.ON_START)
+ fun onStart() {
+ Log.e("@@@", "onStart")
+ }
+ // 前台出现时调用
+ @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
+ fun onResume() {
+ Log.e("@@@", "onResume")
+ }
+ // 退出到后台时调用
+ @OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
+ fun onPause() {
+ Log.e("@@@", "onPause")
+ }
+ // 退出到后台时调用
+ @OnLifecycleEvent(Lifecycle.Event.ON_STOP)
+ fun onStop() {
+ Log.e("@@@", "onStop")
+ }
+}
+```
+
+当应用程序从后台回到前台，或者应用程序被首次打开时，会依次调用Lifecycle.Event.ON_START和Lifecycle.Event.ON_RESUME。
+
+ 当应用程序从前台退到后台（用户按下Home键或任务菜单键），会依次调用Lifecycle.Event.ON_PAUSE和Lifecycle.Event.ON_STOP。需要注意的是，这两个方法的调用会有一定的延后。这是因为系统需要为“屏幕旋转，由于配置发生变化而导致Activity重新创建”的情况预留一些时间。也就是说，系统需要保证当设备出现这种情况时，这两个事件不会被调用。因为当旋转屏幕时，你的应用程序并没有退到后台，它只是进入了横/竖屏模式而已。
+
+## 源码分析
+
+从上面的代码中基本可以看到了大体的实现过程。
+
+首先Activity、Fragment、Service、Application会去实现LifecycleOwner接口，它内部会去使用lifecycleRegistry，而lifecycleRegistry会在系统组件(Activity、Fragment、Service、Application)的声明周期方法中发送Event，给LifecycleObserver实现者中声明了对应注解的方法。
+
+这里使用Fragment类进行源码分析:
+
+```java
+public class Fragment implements ComponentCallbacks, OnCreateContextMenuListener, LifecycleOwner,
+ ViewModelStoreOwner, SavedStateRegistryOwner {
+ LifecycleRegistry mLifecycleRegistry;
+
+ private void initLifecycle() {
+ mLifecycleRegistry = new LifecycleRegistry(this);
+ mSavedStateRegistryController = SavedStateRegistryController.create(this);
+ // >= Android 4.4才支持
+ if (Build.VERSION.SDK_INT >= 19) {
+ mLifecycleRegistry.addObserver(new LifecycleEventObserver() {
+ @Override
+ public void onStateChanged(@NonNull LifecycleOwner source,
+ @NonNull Lifecycle.Event event) {
+ if (event == Lifecycle.Event.ON_STOP) {
+ if (mView != null) {
+ mView.cancelPendingInputEvents();
+ }
+ }
+ }
+ });
+ }
+ }
+
+ void performCreate(Bundle savedInstanceState) {
+ mChildFragmentManager.noteStateNotSaved();
+ mState = CREATED;
+ mCalled = false;
+ mSavedStateRegistryController.performRestore(savedInstanceState);
+ onCreate(savedInstanceState);
+ mIsCreated = true;
+ if (!mCalled) {
+ throw new SuperNotCalledException("Fragment " + this
+ + " did not call through to super.onCreate()");
+ }
+ mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_CREATE);
+ }
+
+ @Override
+ @NonNull
+ public Lifecycle getLifecycle() {
+ return mLifecycleRegistry;
+ }
+}
+```
+
+整体比较简单，首先是addObserver()添加，然后就是在Fragment对应的声明周期方法中去调用了mLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_CREATE);所以继续看一下mLifecycleRegistry类及其handleLifecycleEvent()方法:
+
+```java
+/**
+ * An implementation of {@link Lifecycle} that can handle multiple observers.
+ *
+ * It is used by Fragments and Support Library Activities. You can also directly use it if you have
+ * a custom LifecycleOwner.
+ */
+public class LifecycleRegistry extends Lifecycle {
+ // 使用了WweakReference
+ private final WeakReference mLifecycleOwner;
+ public LifecycleRegistry(@NonNull LifecycleOwner provider) {
+ this(provider, true);
+ }
+
+ private LifecycleRegistry(@NonNull LifecycleOwner provider, boolean enforceMainThread) {
+ mLifecycleOwner = new WeakReference<>(provider);
+ // 初始状态
+ mState = INITIALIZED;
+ // 是否强制主线程使用，默认为true
+ mEnforceMainThread = enforceMainThread;
+ }
+
+ public void addObserver(@NonNull LifecycleObserver observer) {
+ enforceMainThreadIfNeeded("addObserver");
+ State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;
+ ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);
+ ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);
+
+ if (previous != null) {
+ return;
+ }
+ LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
+ if (lifecycleOwner == null) {
+ // it is null we should be destroyed. Fallback quickly
+ return;
+ }
+
+ boolean isReentrance = mAddingObserverCounter != 0 || mHandlingEvent;
+ State targetState = calculateTargetState(observer);
+ mAddingObserverCounter++;
+ while ((statefulObserver.mState.compareTo(targetState) < 0
+ && mObserverMap.contains(observer))) {
+ pushParentState(statefulObserver.mState);
+ final Event event = Event.upFrom(statefulObserver.mState);
+ if (event == null) {
+ throw new IllegalStateException("no event up from " + statefulObserver.mState);
+ }
+ statefulObserver.dispatchEvent(lifecycleOwner, event);
+ popParentState();
+ // mState / subling may have been changed recalculate
+ targetState = calculateTargetState(observer);
+ }
+
+ if (!isReentrance) {
+ // we do sync only on the top level.
+ sync();
+ }
+ mAddingObserverCounter--;
+ }
+
+ public void handleLifecycleEvent(@NonNull Lifecycle.Event event) {
+ // 检查是不是主线程
+ enforceMainThreadIfNeeded("handleLifecycleEvent");
+ moveToState(event.getTargetState());
+ }
+
+ private void moveToState(State next) {
+ if (mState == next) {
+ return;
+ }
+ mState = next;
+ // 都是已经正在执行的状态，直接return
+ if (mHandlingEvent || mAddingObserverCounter != 0) {
+ mNewEventOccurred = true;
+ // we will figure out what to do on upper level.
+ return;
+ }
+ mHandlingEvent = true;
+ sync();
+ mHandlingEvent = false;
+ }
+
+ private void sync() {
+ LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
+ if (lifecycleOwner == null) {
+ throw new IllegalStateException("LifecycleOwner of this LifecycleRegistry is already"
+ + "garbage collected. It is too late to change lifecycle state.");
+ }
+ while (!isSynced()) {
+ mNewEventOccurred = false;
+ // no need to check eldest for nullability, because isSynced does it for us.
+ // 比较的是出现的顺序，如果下一个周期小于当前周期，就执行backwardPass
+ if (mState.compareTo(mObserverMap.eldest().getValue().mState) < 0) {
+ // 对Lifecycle.State的前后顺序的比较也就反应了声明周期状态的变换，比如活动此时的生命周期为Resumed（此时mObserverMap中保存的状态为Resumed），而下一个变换的状态为Started(此时的mState为Started)，从声明周期中可以知道此时执行的时onPause（），对应的LIfecycle.Event为ON_PAUSE，那么上述逻辑中此时执行的是
+ backwardPass(lifecycleOwner);
+ }
+ Map.Entry newest = mObserverMap.newest();
+ if (!mNewEventOccurred && newest != null
+ && mState.compareTo(newest.getValue().mState) > 0) {
+ forwardPass(lifecycleOwner);
+ }
+ }
+ mNewEventOccurred = false;
+ }
+
+ private void forwardPass(LifecycleOwner lifecycleOwner) {
+ Iterator> ascendingIterator =
+ mObserverMap.iteratorWithAdditions();
+ while (ascendingIterator.hasNext() && !mNewEventOccurred) {
+ Map.Entry entry = ascendingIterator.next();
+ ObserverWithState observer = entry.getValue();
+ while ((observer.mState.compareTo(mState) < 0 && !mNewEventOccurred
+ && mObserverMap.contains(entry.getKey()))) {
+ pushParentState(observer.mState);
+ final Event event = Event.upFrom(observer.mState);
+ if (event == null) {
+ throw new IllegalStateException("no event up from " + observer.mState);
+ }
+ observer.dispatchEvent(lifecycleOwner, event);
+ popParentState();
+ }
+ }
+ }
+
+ private void backwardPass(LifecycleOwner lifecycleOwner) {
+ Iterator> descendingIterator =
+ mObserverMap.descendingIterator();
+ while (descendingIterator.hasNext() && !mNewEventOccurred) {
+ Map.Entry entry = descendingIterator.next();
+ // 获取当前保存的 ObserverWithState 从中提取状态
+ ObserverWithState observer = entry.getValue();
+ while ((observer.mState.compareTo(mState) > 0 && !mNewEventOccurred
+ && mObserverMap.contains(entry.getKey()))) {
+ // 如果保存的状态大于 要变化的状态 向前修改，查找对应周期变化的事件
+ Event event = Event.downFrom(observer.mState);
+ if (event == null) {
+ throw new IllegalStateException("no event down from " + observer.mState);
+ }
+ pushParentState(event.getTargetState());
+ // 发送事件
+ observer.dispatchEvent(lifecycleOwner, event);
+ popParentState();
+ }
+ }
+ }
+ /**
+ * Returns the {@link Lifecycle.Event} that will be reported by a {@link Lifecycle}
+ * leaving the specified {@link Lifecycle.State} to a lower state, or {@code null}
+ * if there is no valid event that can move down from the given state.
+ *
+ * @param state the higher state that the returned event will transition down from
+ * @return the event moving down the lifecycle phases from state
+ */
+ public static Event downFrom(@NonNull State state) {
+ switch (state) {
+ case CREATED:
+ return ON_DESTROY;
+ case STARTED:
+ return ON_STOP;
+ case RESUMED:
+ return ON_PAUSE;
+ default:
+ return null;
+ }
+ }
+
+
+ /**
+ * Returns the {@link Lifecycle.Event} that will be reported by a {@link Lifecycle}
+ * leaving the specified {@link Lifecycle.State} to a higher state, or {@code null}
+ * if there is no valid event that can move up from the given state.
+ *
+ * @param state the lower state that the returned event will transition up from
+ * @return the event moving up the lifecycle phases from state
+ */
+ @Nullable
+ public static Event upFrom(@NonNull State state) {
+ switch (state) {
+ case INITIALIZED:
+ return ON_CREATE;
+ case CREATED:
+ return ON_START;
+ case STARTED:
+ return ON_RESUME;
+ default:
+ return null;
+ }
+ }
+}
+```
+
+发送event是用的ObserverWithState类的observer.dispatchEvent(lifecycleOwner, event);，这里继续看一下ObserverWithState类:
+
+```java
+ static class ObserverWithState {
+ State mState;
+ LifecycleEventObserver mLifecycleObserver;
+
+ ObserverWithState(LifecycleObserver observer, State initialState) {
+ // 根据observer创建GenericLifecycleObserver对象
+ mLifecycleObserver = Lifecycling.lifecycleEventObserver(observer);
+ mState = initialState;
+ }
+
+ void dispatchEvent(LifecycleOwner owner, Event event) {
+ State newState = getStateAfter(event);
+ mState = min(mState, newState);
+ mLifecycleObserver.onStateChanged(owner, event);
+ mState = newState;
+ }
+ }
+```
+
+会先调用Lifecycling.lifecycleEventObserver()方法创建一个LifecycleEventObserver对象:
+
+```java
+// Lifecycling.lifecycleEventObserver()
+ static LifecycleEventObserver lifecycleEventObserver(Object object) {
+ boolean isLifecycleEventObserver = object instanceof LifecycleEventObserver;
+ boolean isFullLifecycleObserver = object instanceof FullLifecycleObserver;
+ if (isLifecycleEventObserver && isFullLifecycleObserver) {
+ return new FullLifecycleObserverAdapter((FullLifecycleObserver) object,
+ (LifecycleEventObserver) object);
+ }
+ if (isFullLifecycleObserver) {
+ return new FullLifecycleObserverAdapter((FullLifecycleObserver) object, null);
+ }
+
+ if (isLifecycleEventObserver) {
+ return (LifecycleEventObserver) object;
+ }
+
+ final Class klass = object.getClass();
+ int type = getObserverConstructorType(klass);
+ if (type == GENERATED_CALLBACK) {
+ List> constructors =
+ sClassToAdapters.get(klass);
+ if (constructors.size() == 1) {
+ GeneratedAdapter generatedAdapter = createGeneratedAdapter(
+ constructors.get(0), object);
+ return new SingleGeneratedAdapterObserver(generatedAdapter);
+ }
+ GeneratedAdapter[] adapters = new GeneratedAdapter[constructors.size()];
+ for (int i = 0; i < constructors.size(); i++) {
+ adapters[i] = createGeneratedAdapter(constructors.get(i), object);
+ }
+ return new CompositeGeneratedAdaptersObserver(adapters);
+ }
+ return new ReflectiveGenericLifecycleObserver(object);
+ }
+```
+
+这个方法的目的是根据不同类型的obsever来创建对应的LifecycleEventObserver接口的实现类，它的实现类会重写onStateChanged()方法，这里以ReflectiveGenericLifecycleObserver为例:
+
+```java
+class ReflectiveGenericLifecycleObserver implements LifecycleEventObserver {
+ private final Object mWrapped;
+ private final CallbackInfo mInfo;
+
+ ReflectiveGenericLifecycleObserver(Object wrapped) {
+ mWrapped = wrapped;
+ // 将当前observer类的class文件传入getInfo方法
+ mInfo = ClassesInfoCache.sInstance.getInfo(mWrapped.getClass());
+ }
+
+ @Override
+ public void onStateChanged(LifecycleOwner source, Event event) {
+ // 调用callbackInfo.invokeCallbacks()
+ mInfo.invokeCallbacks(source, event, mWrapped);
+ }
+}
+```
+
+而CallbackInfo类的实现：
+
+```java
+CallbackInfo getInfo(Class klass) {
+ CallbackInfo existing = mCallbackMap.get(klass);
+ if (existing != null) {
+ return existing;
+ }
+ existing = createInfo(klass, null);
+ return existing;
+}
+
+ private CallbackInfo createInfo(Class klass, @Nullable Method[] declaredMethods) {
+ Class superclass = klass.getSuperclass();
+ Map handlerToEvent = new HashMap<>();
+ if (superclass != null) {
+ CallbackInfo superInfo = getInfo(superclass);
+ if (superInfo != null) {
+ handlerToEvent.putAll(superInfo.mHandlerToEvent);
+ }
+ }
+
+ Class[] interfaces = klass.getInterfaces();
+ for (Class intrfc : interfaces) {
+ for (Map.Entry entry : getInfo(
+ intrfc).mHandlerToEvent.entrySet()) {
+ verifyAndPutHandler(handlerToEvent, entry.getKey(), entry.getValue(), klass);
+ }
+ }
+ // 获取所有observer声明的方法
+ Method[] methods = declaredMethods != null ? declaredMethods : getDeclaredMethods(klass);
+ boolean hasLifecycleMethods = false;
+ for (Method method : methods) {
+ // 判断方法上是否有OnLifecycleEvent的注解
+ OnLifecycleEvent annotation = method.getAnnotation(OnLifecycleEvent.class);
+ if (annotation == null) {
+ continue;
+ }
+ hasLifecycleMethods = true;
+ Class[] params = method.getParameterTypes();
+ int callType = CALL_TYPE_NO_ARG;
+ if (params.length > 0) {
+ callType = CALL_TYPE_PROVIDER;
+ if (!params[0].isAssignableFrom(LifecycleOwner.class)) {
+ throw new IllegalArgumentException(
+ "invalid parameter type. Must be one and instanceof LifecycleOwner");
+ }
+ }
+ // 获取注解对应的event
+ Lifecycle.Event event = annotation.value();
+
+ if (params.length > 1) {
+ callType = CALL_TYPE_PROVIDER_WITH_EVENT;
+ if (!params[1].isAssignableFrom(Lifecycle.Event.class)) {
+ throw new IllegalArgumentException(
+ "invalid parameter type. second arg must be an event");
+ }
+ if (event != Lifecycle.Event.ON_ANY) {
+ throw new IllegalArgumentException(
+ "Second arg is supported only for ON_ANY value");
+ }
+ }
+ if (params.length > 2) {
+ throw new IllegalArgumentException("cannot have more than 2 params");
+ }
+ // 封装参数和方法
+ MethodReference methodReference = new MethodReference(callType, method);
+ verifyAndPutHandler(handlerToEvent, methodReference, event, klass);
+ }
+ CallbackInfo info = new CallbackInfo(handlerToEvent);
+ // 保存下来
+ mCallbackMap.put(klass, info);
+ mHasLifecycleMethods.put(klass, hasLifecycleMethods);
+ return info;
+ }
+```
+
+而invokeCallback()方法就会去回调执行observer中声明了注解的方法，实现如下:
+
+```java
+void invokeCallbacks(LifecycleOwner source, Lifecycle.Event event, Object target) {
+ invokeMethodsForEvent(mEventToHandlers.get(event), source, event, target);
+ invokeMethodsForEvent(mEventToHandlers.get(Lifecycle.Event.ON_ANY), source, event,
+ target);
+}
+
+private static void invokeMethodsForEvent(List handlers,
+ LifecycleOwner source, Lifecycle.Event event, Object mWrapped) {
+ if (handlers != null) {
+ for (int i = handlers.size() - 1; i >= 0; i--) {
+ handlers.get(i).invokeCallback(source, event, mWrapped);
+ }
+ }
+}
+```
+
+
+
+
+
+
+- [上一篇: 2.ViewBinding简介](https://github.com/CharonChui/AndroidNote/blob/master/Jetpack/architecture/2.ViewBinding%E7%AE%80%E4%BB%8B.md)
+- [下一篇: 4.ViewModel简介](https://github.com/CharonChui/AndroidNote/blob/master/Jetpack/architecture/4.ViewModel%E7%AE%80%E4%BB%8B.md)
+
+
+---
+
+- 邮箱 ：charon.chui@gmail.com
+- Good Luck! `
\ No newline at end of file
diff --git "a/Jetpack/architecture/4.ViewModel\347\256\200\344\273\213.md" "b/Jetpack/architecture/4.ViewModel\347\256\200\344\273\213.md"
new file mode 100644
index 00000000..5ec5a6bf
--- /dev/null
+++ "b/Jetpack/architecture/4.ViewModel\347\256\200\344\273\213.md"
@@ -0,0 +1,354 @@
+4.ViewModel简介
+===
+
+`Android`系统提供控件，比如`Activity`和`Fragment`，这些控件都是具有生命周期方法，这些生命周期方法被系统调用。
+
+当这些控件被销毁或者被重建的时候，如果数据保存在这些对象中，那么数据就会丢失。比如在一个界面，保存了一些用户信息，当界面重新创建的时候，就需要重新去获取数据。当然了也可以使用控件自动再带的方法，在`onSaveInstanceState`方法中保存数据，在`onCreate`中重新获得数据，但这仅仅在数据量比较小的情况下。如果数据量很大，这种方法就不能适用了。
+
+另外一个问题就是，经常需要在`Activity`中加载数据，这些数据可能是异步的，因为获取数据需要花费很长的时间。那么`Activity`就需要管理这些数据调用，否则很有可能会产生内存泄露问题。最后需要做很多额外的操作，来保证程序的正常运行。
+
+同时`Activity`不仅仅只是用来加载数据的，还要加载其他资源，做其他的操作，最后`Activity`类变大，就是我们常讲的上帝类。也有不少架构是把一些操作放到单独的类中，比如`MVP`就是这样，创建相同类似于生命周期的函数做代理，这样可以减少`Activity`的代码量，但是这样就会变得很复杂，同时也难以测试。
+
+`ViewModel`是专门用于存放应用程序页面所需的数据。ViewModel将页面所需的数据从页面中剥离出来，页面只需要处理用户交互和展示数据。
+
+
+ViewModel类是一种业务逻辑或屏幕级状态容器。
+它用于将状态公开给界面，以及封装相关的业务逻辑。
+它的主要优点是，它可以缓存状态，并可在配置更改后持久保留相应状态。这意味着在activity之间导航时或进行配置更改后(例如旋转屏幕时)，界面将无需重新提取数据。
+
+Viewmodel解决两个问题:
+
+1. 数据的变更与view隔离，也就是解耦
+2. 开发者不需要额外去关心因为屏幕旋转带来的数据恢复问题
+
+## 依赖
+
+```
+dependencies {
+ def lifecycle_version = "2.3.1"
+
+ // ViewModel
+ implementation "androidx.lifecycle:lifecycle-viewmodel-ktx:$lifecycle_version"
+}
+```
+
+
+
+
+
+实现`ViewModel`
+---
+
+ViewModel是一个抽象类，其中只有一个onCleared()方法。当ViewModel不再被需要，即与之相关的Activity都被销毁时，该方法会被系统调用。我们可以在该方法中执行一些资源释放的相关操作。注意，由于屏幕旋转而导致的Activity重建，并不会调用该方法。
+
+```kotlin
+class TimerViewModel : ViewModel() {
+ private val timer: Timer = Timer()
+ private var timeChangeListener: OnTimeChangeLister? = null
+ private var currentSecond: Int = 0
+ fun start() {
+ timer.schedule(timerTask {
+ currentSecond++
+ timeChangeListener?.onTimeChanged(currentSecond)
+ }, 1000, 1000)
+ }
+
+ override fun onCleared() {
+ super.onCleared()
+ timer.cancel()
+ }
+
+ fun setOnTimeChangeListener(listener: OnTimeChangeLister) {
+ timeChangeListener = listener
+ }
+
+ interface OnTimeChangeLister {
+ fun onTimeChanged(second: Int)
+ }
+}
+```
+
+ViewModel的实例化过程，是通过ViewModelProvider来完成的。ViewModelProvider会判断ViewModel是否存在，若存在则直接返回，否则它会创建一个ViewModel。
+
+```kotlin
+class MainActivity : AppCompatActivity() {
+ override fun onCreate(savedInstanceState: Bundle?) {
+ super.onCreate(savedInstanceState)
+ setContentView(R.layout.activity_main)
+ val tv = findViewById(R.id.tv)
+ val model = ViewModelProvider(this).get(TimerViewModel::class.java)
+ model.setOnTimeChangeListener(object : TimerViewModel.OnTimeChangeLister {
+ override fun onTimeChanged(second: Int) {
+ runOnUiThread {
+ tv.text = second.toString()
+ }
+ }
+ })
+ model.start()
+ }
+}
+```
+
+运行程序并旋转屏幕。当旋转屏幕导致Activity重建时，计时器并没有停止。这意味着，横/竖屏状态下的Activity所对应的ViewModel是同一个，它并没有被销毁，它所持有的数据也一直都存在着。
+
+
+
+
+
+
+`ViewModel`的生命周期
+---
+
+`ViewModel`在获取`ViewModel`对象时会通过`ViewModelProvider`的传递来绑定对应的声明周期。
+`ViewModel`只有在`Activity finish`或者`Fragment detach`之后才会销毁。
+
+
+
+
+
+
+在`Fragments`间分享数据
+---
+
+有时候一个`Activity`中的两个或多个`Fragment`需要分享数据或者相互通信，这样就会带来很多问题，比如数据获取，相互确定生命周期。
+
+使用`ViewModel`可以很好的解决这个问题。假设有这样两个`Fragment`，一个`Fragment`提供一个列表，另一个`Fragment`提供点击每个`item`现实的详细信息。
+
+
+```java
+public class SharedViewModel extends ViewModel {
+ private final MutableLiveData- selected = new MutableLiveData
- ();
+
+ public void select(Item item) {
+ selected.setValue(item);
+ }
+
+ public LiveData
- getSelected() {
+ return selected;
+ }
+}
+
+public class MasterFragment extends Fragment {
+ private SharedViewModel model;
+ public void onCreate(Bundle savedInstanceState) {
+ super.onCreate(savedInstanceState);
+ model = ViewModelProviders.of(getActivity()).get(SharedViewModel.class);
+ itemSelector.setOnClickListener(item -> {
+ model.select(item);
+ });
+ }
+}
+
+public class DetailFragment extends LifecycleFragment {
+ public void onCreate(Bundle savedInstanceState) {
+ super.onCreate(savedInstanceState);
+ SharedViewModel model = ViewModelProviders.of(getActivity()).get(SharedViewModel.class);
+ model.getSelected().observe(this, { item ->
+ // update UI
+ });
+ }
+}
+```
+
+两个`Fragment`都是通过`getActivity()`来获取`ViewModelProvider`。这意味着两个`Activity`都是获取的属于同一个`Activity`的同一个`ShareViewModel`实例。
+这样做优点如下:
+
+- `Activity`不需要写任何额外的代码，也不需要关心`Fragment`之间的通信。
+- `Fragment`不需要处理除`SharedViewModel`以外其他的代码。这两个`Fragment`不需要知道对方是否存在。
+- `Fragment`的生命周期不会相互影响
+
+
+
+
+`ViewModel`和`SavedInstanceState`对比
+---
+
+`ViewModel`使得在`configuration change`（旋转屏幕等）保存数据变的十分方便，但是这不能用于应用被系统杀死时持久化数据。举个简单的例子，有一个界面展示国家信息。
+不应该把整个国家信息放到`SavedInstanceState`里，而是把国家对应的`id`放到`SavedInstanceState`，等到界面恢复时，再通过`id`去获取详细的信息。这些详细的信息应该被存放在数据库中。
+
+
+
+
+
+
+Jetpack ViewModel 并不等价于 MVVM ViewModel
+
+经常有小伙伴将Jetpack ViewModel 和 MVVM ViewModel，其实这二者根本没有在同一个层次，MVVM ViewModel是MVVM架构中的一个角色，看不见摸不着只是一种思想。 而Jetpack ViewModel是一个实实在在的框架用于做状态托管，有对应的作用域可跟随Activity/Fragment生命周期，但这种特性恰好可以充当MVVM ViewModel的角色，分隔数据层和视图层并做数据托管。
+
+所以结论是Jetpack ViewModel可以充当MVVM ViewModel 但二者并不等价
+
+
+但jetpack的组件是可以分别使用的，所以可以先熟悉各个组件，然后往自己的项目里套。我个人觉得特别好的组件有：ViewModel，LiveData，Room，Navigation，极好的架构梳理觉得一般的：data-binding，view-binding，感觉有一定用，但也有成本，不用也行觉得不好用的：Paging，感觉封装太死板。如果前后端同步是紧要业务行为，那么我宁愿自己写这个功能
+
+
+
+## ViewModel原理
+
+```kotlin
+val model = ViewModelProvider(this).get(TimerViewModel::class.java)
+```
+
+首先看ViewModelProvider的源码:
+
+```java
+public class ViewModelProvider {
+ private final Factory mFactory;
+ private final ViewModelStore mViewModelStore;
+
+ /**
+ * Creates {@code ViewModelProvider}. This will create {@code ViewModels}
+ * and retain them in a store of the given {@code ViewModelStoreOwner}.
+ *
+ * This method will use the
+ * {@link HasDefaultViewModelProviderFactory#getDefaultViewModelProviderFactory() default factory}
+ * if the owner implements {@link HasDefaultViewModelProviderFactory}. Otherwise, a
+ * {@link NewInstanceFactory} will be used.
+ */
+ public ViewModelProvider(@NonNull ViewModelStoreOwner owner) {
+ this(owner.getViewModelStore(), owner instanceof HasDefaultViewModelProviderFactory
+ ? ((HasDefaultViewModelProviderFactory) owner).getDefaultViewModelProviderFactory()
+ : NewInstanceFactory.getInstance());
+ }
+
+ public ViewModelProvider(@NonNull ViewModelStore store, @NonNull Factory factory) {
+ mFactory = factory;
+ mViewModelStore = store;
+ }
+
+ public T get(@NonNull Class modelClass) {
+ String canonicalName = modelClass.getCanonicalName();
+ if (canonicalName == null) {
+ throw new IllegalArgumentException("Local and anonymous classes can not be ViewModels");
+ }
+ return get(DEFAULT_KEY + ":" + canonicalName, modelClass);
+ }
+ public T get(@NonNull String key, @NonNull Class modelClass) {
+ ViewModel viewModel = mViewModelStore.get(key);
+
+ if (modelClass.isInstance(viewModel)) {
+ if (mFactory instanceof OnRequeryFactory) {
+ ((OnRequeryFactory) mFactory).onRequery(viewModel);
+ }
+ return (T) viewModel;
+ } else {
+ //noinspection StatementWithEmptyBody
+ if (viewModel != null) {
+ // TODO: log a warning.
+ }
+ }
+ if (mFactory instanceof KeyedFactory) {
+ viewModel = ((KeyedFactory) mFactory).create(key, modelClass);
+ } else {
+ viewModel = mFactory.create(modelClass);
+ }
+ mViewModelStore.put(key, viewModel);
+ return (T) viewModel;
+ }
+
+}
+```
+
+
+
+
+
+ViewModelProvider接收一个ViewModelStoreOwner对象作为参数。在以上示例代码中该参数是this，指代当前的Activity。这是因为我们的Activity继承自ComponentActivity，而在androidx依赖包中，ComponentActivity默认实现了ViewModelStoreOwner接口。
+
+```java
+public class ComponentActivity extends androidx.core.app.ComponentActivity implements
+ LifecycleOwner,
+ ViewModelStoreOwner,
+ SavedStateRegistryOwner,
+ OnBackPressedDispatcherOwner {
+
+ public ViewModelStore getViewModelStore() {
+ if (getApplication() == null) {
+ throw new IllegalStateException("Your activity is not yet attached to the "
+ + "Application instance. You can't request ViewModel before onCreate call.");
+ }
+ if (mViewModelStore == null) {
+ NonConfigurationInstances nc =
+ (NonConfigurationInstances) getLastNonConfigurationInstance();
+ if (nc != null) {
+ // Restore the ViewModelStore from NonConfigurationInstances
+ mViewModelStore = nc.viewModelStore;
+ }
+ if (mViewModelStore == null) {
+ mViewModelStore = new ViewModelStore();
+ }
+ }
+ return mViewModelStore;
+ }
+}
+```
+
+```java
+public interface ViewModelStoreOwner {
+ /**
+ * Returns owned {@link ViewModelStore}
+ *
+ * @return a {@code ViewModelStore}
+ */
+ @NonNull
+ ViewModelStore getViewModelStore();
+}
+```
+
+ViewModelStore类的代码是:
+
+```java
+public class ViewModelStore {
+
+ private final HashMap mMap = new HashMap<>();
+
+ final void put(String key, ViewModel viewModel) {
+ ViewModel oldViewModel = mMap.put(key, viewModel);
+ if (oldViewModel != null) {
+ oldViewModel.onCleared();
+ }
+ }
+
+ final ViewModel get(String key) {
+ return mMap.get(key);
+ }
+
+ Set keys() {
+ return new HashSet<>(mMap.keySet());
+ }
+
+ /**
+ * Clears internal storage and notifies ViewModels that they are no longer used.
+ */
+ public final void clear() {
+ for (ViewModel vm : mMap.values()) {
+ vm.clear();
+ }
+ mMap.clear();
+ }
+}
+```
+
+从ViewModelStore的源码可以看出，ViewModel实际上是以HashMap的形式被缓存起来了。ViewModel与页面之间没有直接的关联，它们通过ViewModelProvider进行关联。当页面需要ViewModel时，会向ViewModelProvider索要，ViewModelProvider检查该ViewModel是否已经存在于缓存中，若存在，则直接返回，若不存在，则实例化一个。因此，Activity由于配置变化导致的销毁重建并不会影响ViewModel，ViewModel是独立于页面而存在的。也正因为此，我们在使用ViewModel时，需要特别注意，不要向ViewModel中传入任何类型的Context或带有Context引用的对象，这可能会导致页面无法被销毁，从而引发内存泄漏。
+
+
+
+## ViewModel与AndroidViewModel
+
+前面提到过，在使用ViewModel时，不能将任何类型的Context或含有Context引用的对象传入ViewModel，因为这可能会导致内存泄漏。但如果你希望在ViewModel中使用Context，该怎么办呢？可以使用AndroidViewModel类，它继承自ViewModel，并接收Application作为Context。这意味着，它的生命周期和Application是一样的，那么这就不算是一个内存泄漏了。
+
+
+
+
+
+在上面的示例中，我们通过自定义接口OnTimeChangeListener来完成ViewModel与页面之间的通信。这不是一个好的方案。Jetpack为我们提供了LiveData组件来解决这个问题。通过LiveData，当ViewModel中的数据发生变化时，页面能自动收到通知，进而更新UI。
+
+
+
+- [上一篇: 3.Lifecycle简介](https://github.com/CharonChui/AndroidNote/blob/master/Jetpack/architecture/3.Lifecycle%E7%AE%80%E4%BB%8B.md)
+- [下一篇: 5.LiveData简介](https://github.com/CharonChui/AndroidNote/blob/master/Jetpack/architecture/5.LiveData%E7%AE%80%E4%BB%8B.md)
+
+
+---
+
+- 邮箱 ：charon.chui@gmail.com
+- Good Luck! `
\ No newline at end of file
diff --git "a/Jetpack/architecture/5.LiveData\347\256\200\344\273\213.md" "b/Jetpack/architecture/5.LiveData\347\256\200\344\273\213.md"
new file mode 100644
index 00000000..45363359
--- /dev/null
+++ "b/Jetpack/architecture/5.LiveData\347\256\200\344\273\213.md"
@@ -0,0 +1,430 @@
+5.LiveData简介
+===
+
+ViewModel的主要作用是存放页面所需要的各种数据。我们在示例代码中定义了接口，当数据发生变化时，采用接口的方式实现对页面的通知。对此前面已经做了相关说明，通过接口的方式对页面进行通知是可行的，但如果要观察的数据很多，则需要定义大量的接口，代码会显得十分冗余。为此，Jetpack提供了LiveData组件。
+
+LiveData是一个可被观察的数据容器类。具体说来，可以将LiveData理解为一个数据的容器，它将数据包装起来，使数据成为被观察者，当该数据发生变化时，观察者能够获得通知。我们不需要自己去实现观察者模式，LiveData内部已经默认实现好了，我们只要使用就可以了。
+
+LiveData取代了上一章中所定义的接口，帮助我们完成ViewModel与页面之间的通信。
+
+> LiveData is an observable data holder class. Unlike a regular observable, LiveData is lifecycle-aware, meaning it respects the lifecycle of other app components, such as activities, fragments, or services. This awareness ensures LiveData only updates app component observers that are in an active lifecycle state.
+
+`LiveData`是一种持有可被观察数据的类。和其他可被观察的类不同的是，`LiveData`是有生命周期感知能力的，这意味着它可以在`activities`,`fragments`,或者`services`生命周期是活跃状态时更新这些组件。那么什么是活跃状态呢？上篇文章中提到的`STARTED`和`RESUMED`就是活跃状态，只有在这两个状态下`LiveData`是会通知数据变化的。
+
+要想使用`LiveData`（或者这种有可被观察数据能力的类）就必须配合实现了`LifecycleOwner`的对象使用。在这种情况下，当对应的生命周期对象`DESTROYED`时，才能移除观察者。这对`Activity`或者`Fragment`来说显得尤为重要，因为他们可以在生命周期结束的时候立刻解除对数据的订阅，从而避免内存泄漏等问题。
+
+
+
+
+使用`LiveData`的优点:
+
+- `UI`和实时数据保持一致 因为`LiveData`采用的是观察者模式，这样一来就可以在数据发生改变时获得通知，更新`UI`。
+- 避免内存泄漏,观察者被绑定到组件的生命周期上，当被绑定的组件销毁（`destory`）时，观察者会立刻自动清理自身的数据。
+- 不会再产生由于`Activity`处于`stop`状态而引起的崩溃 例如:当`Activity`处于后台状态时，是不会收到`LiveData`的任何事件的。
+- 不需要再解决生命周期带来的问题`LiveData`可以感知被绑定的组件的生命周期，只有在活跃状态才会通知数据变化。
+- 实时数据刷新,当组件处于活跃状态或者从不活跃状态到活跃状态时总是能收到最新的数据
+- 解决`Configuration Change`问题,在屏幕发生旋转或者被回收再次启动，立刻就能收到最新的数据。
+- 数据共享,如果对应的`LiveData`是单例的话，就能在`app`的组件间分享数据。
+
+## LiveData与ViewModel
+
+ViewModel用于存放页面所需要的各种数据，不仅如此，我们还可以在其中放一些与数据相关的业务逻辑。例如，我们可以在ViewModel中进行数据的加工、获取等操作。因此，ViewModel中的数据可能会随着业务的变化而变化。对页面来说，它并不关心ViewModel中的业务逻辑，它只关心需要展示的数据是什么，并且希望在数据发生变化时，能及时得到通知并做出更新。LiveData的作用就是，在ViewModel中的数据发生变化时通知页面。因此，LiveData通常被放在ViewModel
+
+
+
+
+
+
+
+使用`LiveData`:
+
+- 创建一个持有某种数据类型的`LiveData`(通常是在`ViewModel`中)
+- 创建一个定义了`onChange()`方法的观察者。这个方法是控制`LiveData`中数据发生变化时，采取什么措施 (比如更新界面)。通常是在`UI Controller`(`Activity/Fragment`)中创建这个观察者。
+- 通过`observe()`方法连接观察者和`LiveData`。`observe()`方法需要携带一个`LifecycleOwner`类。这样就可以让观察者订阅`LiveData`中的数据，实现实时更新。
+
+
+创建`LiveData`对象
+---
+
+LiveData是一个抽象类，不能直接使用。通常我们使用的是它的直接子类MutableLiveData。
+
+`LiveData`是一个数据的包装。具体的包装对象可以是任何数据，包括集合（比如`List`）。`LiveData`通常在`ViewModel`中创建，然后通过`getter`方法获取。具体可以看一下代码:
+
+```kotlin
+class TimerViewModel : ViewModel() {
+ private val timer: Timer = Timer()
+ private var currentSecond: MutableLiveData = MutableLiveData()
+ fun start() {
+ timer.schedule(timerTask {
+ var value = currentSecond.value
+ val plus = value?.plus(1)
+ currentSecond.postValue(plus)
+ }, 1000, 1000)
+ }
+
+ fun getCurrentSecond() : LiveData {
+ return currentSecond
+ }
+ override fun onCleared() {
+ super.onCleared()
+ timer.cancel()
+ }
+}
+```
+
+观察`LiveData`中的数据
+---
+
+
+通常情况下都是在组件的`onCreate()`方法中开始观察数据，原因有以下两点:
+
+- 系统会多次调用`onResume()`方法
+- 确保`Activity/Fragment`在处于活跃状态时立刻可以展示数据。
+
+```kotlin
+class MainActivity : AppCompatActivity() {
+ override fun onCreate(savedInstanceState: Bundle?) {
+ super.onCreate(savedInstanceState)
+ setContentView(R.layout.activity_main)
+ val tv = findViewById(R.id.tv)
+ val model = ViewModelProvider(this).get(TimerViewModel::class.java)
+ // 得到ViewModel中的LiveData
+ val liveData = model.getCurrentSecond() as MutableLiveData
+ liveData.observe(this, object : Observer {
+ override fun onChanged(t: Int?) {
+ tv.text = t.toString()
+ }
+ })
+ // 重置
+ liveData.postValue(0)
+ model.start()
+ }
+}
+```
+
+更新`LiveData`对象
+---
+
+
+如果想要在`UI Controller`中改变`LiveData`中的值呢？（比如点击某个`Button`把性别从男设置成女）。`LiveData`并没有提供这样的功能，但是`Architecture Component`提供了`MutableLiveData`这样一个类，可以通过`setValue(T)`和`postValue(T)`方法来修改存储在`LiveData`中的数据。`MutableLiveData`是`LiveData`的一个子类，从名称上也能看出这个类的作用。举个直观点的例子:
+
+```java
+mButton.setOnClickListener(new OnClickListener() {
+ @Override
+ public void onClick(View v) {
+ String anotherName = "John Doe";
+ mModel.getCurrentName().setValue(anotherName);
+ }
+})
+```
+调用`setValue()`方法就可以把`LiveData`中的值改为`John Doe`。同样通过这种方法修改`LiveData`中的值同样会触发所有对这个数据感兴趣的类。那么`setValue()`和`postValue()`有什么不同呢？区别就是`setValue()`只能在主线程中调用，而`postValue()`可以在子线程中调用。
+
+
+
+## observeForever
+
+LiveData还提供了一个名为observeForever()的方法，使用起来与observe()没有太大差别。它们的区别主要在于，当LiveData所包装的数据发生变化时，无论页面处于什么状态，observeForever()都能收到通知。因此，在用完之后，一定要记得调用removeObserver()方法来停止对LiveData的观察，否则LiveData会一直处于激活状态，Activity则永远不会被系统自动回收，这就造成了内存泄漏。
+
+
+
+## 源码
+
+从上面的使用中，我们知道主要有两个重要的方法，分别是observe()方法和setValue()方法:
+
+```java
+ @MainThread
+ public void observe(@NonNull LifecycleOwner owner, @NonNull Observer 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;
+ }
+ // 将Observer与Activity的生命周期关联在一起。因此，LiveData能够感知页面的生命周期。它可以检测页面当前的状态是否为激活状态，或者页面是否被销毁。只有在页面处于激活状态（Lifecycle.State.ON_STARTED或Lifecycle.State.ON_RESUME）时，页面才能收到来自LiveData的通知，若页面被销毁（Lifecycle.State.ON_DESTROY），那么LiveData会自动清除与页面的关联，从而避免可能引发的内存泄漏问题。
+ owner.getLifecycle().addObserver(wrapper);
+ }
+```
+
+```java
+
+ /**
+ * Sets the value. If there are active observers, the value will be dispatched to them.
+ *
+ * This method must be called from the main thread. If you need set a value from a background
+ * thread, you can use {@link #postValue(Object)}
+ *
+ * @param value The new value
+ */
+ @MainThread
+ protected void setValue(T value) {
+ assertMainThread("setValue");
+ mVersion++;
+ mData = value;
+ dispatchingValue(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, ObserverWrapper>> iterator =
+ mObservers.iteratorWithAdditions(); iterator.hasNext(); ) {
+ // 遍历mObservers，调用considerNotify()更新数据
+ considerNotify(iterator.next().getValue());
+ if (mDispatchInvalidated) {
+ break;
+ }
+ }
+ }
+ } while (mDispatchInvalidated);
+ mDispatchingValue = false;
+ }
+```
+
+```java
+// 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;
+ //回调onChanged()方法
+ observer.mObserver.onChanged((T) mData);
+ }
+```
+
+
+
+
+
+
+`Room`和`LiveData`配合使用
+---
+
+`Room`可以返回`LiveData`的数据类型。这样对数据库中的任何改动都会被传递出去。这样修改完数据库就能获取最新的数据，减少了主动获取数据的代码。
+
+继承`LiveData`扩展功能
+---
+
+`LiveData`的活跃状态包括:`STARTED`或者`RESUMED`两种状态。那么如何在活跃状态下把数据传递出去呢？下面是示例代码:
+
+```kotlin
+class StockLiveData(symbol: String) : LiveData() {
+ private val stockManager = StockManager(symbol)
+
+ private val listener = { price: BigDecimal ->
+ value = price
+ }
+
+ override fun onActive() {
+ stockManager.requestPriceUpdates(listener)
+ }
+
+ override fun onInactive() {
+ stockManager.removeUpdates(listener)
+ }
+}
+```
+
+上面有三个重要的方法:
+
+- onActive()： 当LiveData对象具有活动观察者时调用该方法
+- onInactive(): 当LiveData对象没有任何活动观察者时调用该方法
+- setValue(T): 更新LiveData实例的值，并通知任何活动的观察者有关更改的信息
+
+可以像下面这样使用`StockLiveData`:
+```kotlin
+public class MyFragment : Fragment() {
+ override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
+ super.onViewCreated(view, savedInstanceState)
+ val myPriceListener: LiveData = ...
+ myPriceListener.observe(viewLifecycleOwner, Observer { price: BigDecimal? ->
+ // Update the UI.
+ })
+ }
+}
+```
+上面`observe()`方法中的第一个参数传递的是`fragment`的实例，该`fragment`实现了`LifecycleOwner`接口。这样做是为了将`observer`和`Lifecycle`对象绑定到一起，这意味着:
+- 如果当前的`Lifecycle`对象不是出于活跃期，就算`value`值有改变也不会回调到`observer`中
+- 在`Lifecycle`对象销毁后哦，`observer`对象也会自动移除
+
+实际上`LiveData`对象是适应生命周期也就意味着你需要在多个`activities`,`fragments`和`services`中进行共享，所以通常我们会将`LiveData`的示例设计成单例的:
+```kotlin
+class StockLiveData(symbol: String) : LiveData() {
+ private val stockManager: StockManager = StockManager(symbol)
+
+ private val listener = { price: BigDecimal ->
+ value = price
+ }
+
+ override fun onActive() {
+ stockManager.requestPriceUpdates(listener)
+ }
+
+ override fun onInactive() {
+ stockManager.removeUpdates(listener)
+ }
+
+ companion object {
+ private lateinit var sInstance: StockLiveData
+
+ @MainThread
+ fun get(symbol: String): StockLiveData {
+ sInstance = if (::sInstance.isInitialized) sInstance else StockLiveData(symbol)
+ return sInstance
+ }
+ }
+}
+class StockLiveData(symbol: String) : LiveData() {
+ private val stockManager: StockManager = StockManager(symbol)
+
+ private val listener = { price: BigDecimal ->
+ value = price
+ }
+
+ override fun onActive() {
+ stockManager.requestPriceUpdates(listener)
+ }
+
+ override fun onInactive() {
+ stockManager.removeUpdates(listener)
+ }
+
+ companion object {
+ private lateinit var sInstance: StockLiveData
+
+ @MainThread
+ fun get(symbol: String): StockLiveData {
+ sInstance = if (::sInstance.isInitialized) sInstance else StockLiveData(symbol)
+ return sInstance
+ }
+ }
+}
+```
+这样就可以在`fragment`中像如下这样使用:
+```kotlin
+class MyFragment : Fragment() {
+
+ override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
+ super.onViewCreated(view, savedInstanceState)
+ StockLiveData.get(symbol).observe(viewLifecycleOwner, Observer { price: BigDecimal? ->
+ // Update the UI.
+ })
+ }
+}
+```
+
+转换LiveData
+---
+
+你可能有时会在`LiveData`分发给`observers`之前想要修改一下存储在`LiveData`中的值，或者你想根据当前的值进行修改返回另一个值。`Lifecycle`提供了`Transformations`类来通过里面的`helper`方法解决这种问题。
+
+- `Transformations.map()`
+
+可以将`LiveData`中的数据进行改变。
+
+
+```java
+val userLiveData: LiveData = UserLiveData()
+val userName: LiveData = Transformations.map(userLiveData) {
+ user -> "${user.name} ${user.lastName}"
+}
+```
+将`LiveData`中的`User`数据转换成`String`
+
+
+- `Transformations.switchMap()`
+
+```java
+private fun getUser(id: String): LiveData {
+ ...
+}
+val userId: LiveData = ...
+val user = Transformations.switchMap(userId) { id -> getUser(id) }
+
+```
+
+
+和上面的`map()`方法很像。区别在于传递给`switchMap()`的函数必须返回`LiveData`对象。
+和`LiveData`一样,`Transformation`也可以在观察者的整个生命周期中存在。只有在观察者处于观察`LiveData`状态时,`Transformation`才会运算。`Transformation`是延迟运算的（`calculated lazily`），而生命周期感知的能力确保不会因为延迟发生任何问题。
+
+如果在`ViewModel`对象的内部需要一个`Lifecycle`对象，那么使用`Transformation`是一个不错的方法。举个例子:假如有个`UI`组件接受输入的地址，返回对应的邮政编码。那么可以 实现一个`ViewModel`和这个组件绑定:
+```java
+class MyViewModel(private val repository: PostalCodeRepository) : ViewModel() {
+
+ private fun getPostalCode(address: String): LiveData {
+ // DON'T DO THIS
+ return repository.getPostCode(address)
+ }
+}
+```
+
+看代码中的注释，有个`// DON'T DO THIS`(不要这么干),这是为什么？有一种情况是如果`UI`组件被回收后又被重新创建，那么又会触发一次`repository.getPostCode(address)`询，而不是重用上次已经获取到的查询。那么应该怎样避免这个问题呢？看一下下面的代码:
+
+```java
+class MyViewModel(private val repository: PostalCodeRepository) : ViewModel() {
+ private val addressInput = MutableLiveData()
+ val postalCode: LiveData = Transformations.switchMap(addressInput) {
+ address -> repository.getPostCode(address) }
+
+ private fun setInput(address: String) {
+ addressInput.value = address
+ }
+}
+
+```
+
+`postalCode`变量的修饰符是`public`和`final`，因为这个变量的是不会改变的。哎？不会改变？那我输入不同的地址还总返回相同邮编？先打住，`postalCode`这个变量存在的作用是把输入的`addressInput`转换成邮编，那么只有在输入变化时才会调用`repository.getPostCode()`方法。这就好比你用`final`来修饰一个数组，虽然这个变量不能再指向其他数组，但是数组里面的内容是可以被修改的。绕来绕去就一点:当输入是相同的情况下，用了`switchMap()`可以减少没有必要的请求。并且同样，只有在观察者处于活跃状态时才会运算并将结果通知观察者。
+
+
+
+
+合并多个`LiveData`中的数据
+---
+
+`MediatorLiveData`是`LiveData`的子类，可以通过`MediatorLiveData`合并多个`LiveData`来源的数据。同样任意一个来源的`LiveData`数据发生变化，`MediatorLiveData`都会通知观察他的对象。说的有点抽象，举个例子。比如`UI`接收来自本地数据库和网络数据，并更新相应的`UI`。可以把下面两个`LiveData`加入到`MeidatorLiveData`中:
+
+- 关联数据库的`LiveData`
+- 关联联网请求的`LiveData`
+相应的`UI`只需要关注`MediatorLiveData`就可以在任意数据来源更新时收到通知。
+
+
+
+- [上一篇: 4.ViewModel简介](https://github.com/CharonChui/AndroidNote/blob/master/Jetpack/architecture/4.ViewModel%E7%AE%80%E4%BB%8B.md)
+- [下一篇: 6.DataBinding简介](https://github.com/CharonChui/AndroidNote/blob/master/Jetpack/architecture/6.DataBinding%E7%AE%80%E4%BB%8B.md)
+
+
+
+
+---
+
+- 邮箱 ：charon.chui@gmail.com
+- Good Luck! `
\ No newline at end of file
diff --git "a/Jetpack/architecture/6.DataBinding\347\256\200\344\273\213.md" "b/Jetpack/architecture/6.DataBinding\347\256\200\344\273\213.md"
new file mode 100644
index 00000000..e093432c
--- /dev/null
+++ "b/Jetpack/architecture/6.DataBinding\347\256\200\344\273\213.md"
@@ -0,0 +1,24 @@
+# 6.DataBinding简介
+
+
+
+https://developer.android.com/topic/libraries/data-binding
+
+
+
+
+
+
+
+
+- [上一篇:5.LiveData简介](https://github.com/CharonChui/AndroidNote/blob/master/Jetpack/architecture/5.LiveData%E7%AE%80%E4%BB%8B.md)
+- [下一篇:7.Room简介](https://github.com/CharonChui/AndroidNote/blob/master/Jetpack/architecture/7.Room%E7%AE%80%E4%BB%8B.md)
+
+
+
+
+
+---
+
+- 邮箱 ：charon.chui@gmail.com
+- Good Luck!
\ No newline at end of file
diff --git "a/ArchitectureComponents/6.Room(\345\205\255).md" "b/Jetpack/architecture/7.Room\347\256\200\344\273\213.md"
similarity index 98%
rename from "ArchitectureComponents/6.Room(\345\205\255).md"
rename to "Jetpack/architecture/7.Room\347\256\200\344\273\213.md"
index aeb29823..c5d92b14 100644
--- "a/ArchitectureComponents/6.Room(\345\205\255).md"
+++ "b/Jetpack/architecture/7.Room\347\256\200\344\273\213.md"
@@ -1,4 +1,4 @@
-6.Room(六)
+7.Room简介
===
`Room`是一个持久化工具，和`ormlite`、`greenDao`类似，都是`ORM`工具。在开发中我们可以利用`Room`来操作`sqlite`数据库。
@@ -507,8 +507,8 @@ static final Migration MIGRATION_2_3 = new Migration(2, 3) {
```
-[上一篇: 5.ViewModel(五)](https://github.com/CharonChui/AndroidNote/blob/master/ArchitectureComponents/5.ViewModel(%E4%BA%94).md)
-[下一篇: 7.PagingLibrary(七)](https://github.com/CharonChui/AndroidNote/blob/master/ArchitectureComponents/7.PagingLibrary(%E4%B8%83).md)
+- [上一篇:6.DataBinding简介](https://github.com/CharonChui/AndroidNote/blob/master/Jetpack/architecture/6.DataBinding%E7%AE%80%E4%BB%8B.md)
+- [下一篇:8.PagingLibrary简介](https://github.com/CharonChui/AndroidNote/blob/master/Jetpack/architecture/8.PagingLibrary%E7%AE%80%E4%BB%8B.md)
---
diff --git "a/Jetpack/architecture/8.PagingLibrary\347\256\200\344\273\213.md" "b/Jetpack/architecture/8.PagingLibrary\347\256\200\344\273\213.md"
new file mode 100644
index 00000000..e6c0f804
--- /dev/null
+++ "b/Jetpack/architecture/8.PagingLibrary\347\256\200\344\273\213.md"
@@ -0,0 +1,14 @@
+8.PagingLibrary简介
+===
+
+
+
+
+
+- [上一篇:7.Room简介](https://github.com/CharonChui/AndroidNote/blob/master/Jetpack/architecture/7.Room%E7%AE%80%E4%BB%8B.md)
+- [下一篇:9.App Startup简介](https://github.com/CharonChui/AndroidNote/blob/master/Jetpack/architecture/9.App%20Startup%E7%AE%80%E4%BB%8B.md)
+
+---
+
+- 邮箱 ：charon.chui@gmail.com
+- Good Luck! `
\ No newline at end of file
diff --git "a/Jetpack/architecture/9.App Startup\347\256\200\344\273\213.md" "b/Jetpack/architecture/9.App Startup\347\256\200\344\273\213.md"
new file mode 100644
index 00000000..bd7e22b7
--- /dev/null
+++ "b/Jetpack/architecture/9.App Startup\347\256\200\344\273\213.md"
@@ -0,0 +1,610 @@
+# 9.App Startup简介
+
+[App Startup](https://developer.android.google.cn/topic/libraries/app-startup)
+
+App Startup库提供了一种直接，高效的方法，可以在应用程序启动时初始化组件。第三方库开发人员和应用程序开发人员都可以使用App Startup来简化启动顺序并显式设置初始化顺序。
+
+App Startup允许共享单个内容提供者来进行组件的初始化，而无需为需要初始化的每个组件定义单独的内容提供者。这可以大大缩短应用程序的启动时间。
+
+这里提到了内容提供者，会让人摸不到头脑，内容提供者会应用初始化有什么关系？
+
+## 背景
+
+我们在使用一些第三方库时一般都需要在Application.onCreate()方法中进行一些init或者install等初始化操作:
+
+```kotlin
+class StApplication : Application() {
+ override fun onCreate() {
+ Fresco.initialize(this)
+ LitePalApplication.initialize(this)
+ Adxxx.init(this)
+ ....
+ }
+}
+```
+
+但是在之前[LeakCanary源码分析](https://github.com/CharonChui/AndroidNote/blob/master/SourceAnalysis/LeakCanary%E6%BA%90%E7%A0%81%E5%88%86%E6%9E%90.md)的文章中曾经介绍过LeakCanary是如何做到不用任何一行Java代码就能实现监测内存泄露功能的。 这里我们回顾一下:
+
+## How does LeakCanary get installed by only adding a dependency?[¶](https://square.github.io/leakcanary/faq/#how-does-leakcanary-get-installed-by-only-adding-a-dependency)
+
+On Android, content providers are created after the Application instance is created but before Application.onCreate() is called. The `leakcanary-object-watcher-android` artifact has a non exported ContentProvider defined in its `AndroidManifest.xml` file. When that ContentProvider is installed, it adds activity and fragment lifecycle listeners to the application.
+
+对于Application的onCreate()方法，官方文档中是这样说的:
+
+Called when the application is starting, before any activity, service, or receiver objects(excluding content providers)have been created.
+
+看到这里，大呼内行...这个实现太巧妙了。尽然是通过在AndroidManifest.xml中注册一个内容提供者，这个内容提供者的创建会在Application.onCreate()之前，在它创建的时候去做install的操作。
+
+```xml
+
+
+
+```
+
+
+
+```kotlin
+/**
+ * Content providers are loaded before the application class is created. [AppWatcherInstaller] is
+ * used to install [leakcanary.AppWatcher] on application start.
+ */
+internal sealed class AppWatcherInstaller : ContentProvider() {
+
+ /**
+ * [MainProcess] automatically sets up the LeakCanary code that runs in the main app process.
+ */
+ internal class MainProcess : AppWatcherInstaller()
+
+ /**
+ * When using the `leakcanary-android-process` artifact instead of `leakcanary-android`,
+ * [LeakCanaryProcess] automatically sets up the LeakCanary code
+ */
+ internal class LeakCanaryProcess : AppWatcherInstaller()
+
+ override fun onCreate(): Boolean {
+ val application = context!!.applicationContext as Application
+ // 调用install方法进行初始化
+ AppWatcher.manualInstall(application)
+ return true
+ }
+
+ override fun query(
+ uri: Uri,
+ strings: Array?,
+ s: String?,
+ strings1: Array?,
+ s1: String?
+ ): Cursor? {
+ return null
+ }
+
+ override fun getType(uri: Uri): String? {
+ return null
+ }
+
+ override fun insert(
+ uri: Uri,
+ contentValues: ContentValues?
+ ): Uri? {
+ return null
+ }
+
+ override fun delete(
+ uri: Uri,
+ s: String?,
+ strings: Array?
+ ): Int {
+ return 0
+ }
+
+ override fun update(
+ uri: Uri,
+ contentValues: ContentValues?,
+ s: String?,
+ strings: Array?
+ ): Int {
+ return 0
+ }
+}
+```
+
+
+
+## 通过ContentProvider进行初始化的优缺点
+
+优点:
+
+大大简化了我们的接入成本，无须任何Java代码即可使用。
+
+缺点:
+
+- ContentProvider会增加许多额外的耗时。
+
+ 应用和库往往需要在Application.onCreate()之前初始化组件，如: WorkManager、ProcessLifecycleObserver、FirebaseApp 等。这往往通过使用ContentProvider来实现不同依赖的初始化。通过 App Startup，您无需为每个组件单独定义ContentProvider进行初始化，而可以定义多个 Initializer去共享相同的ContentProvider。每减少一个ContentProvider通常会有约2ms的收益，这可以显著提高应用启动速度。
+
+ 毕竟ContentProvider是Android四大组件之一，这个组件相对来说是比较重量级的。也就是说，本来我的初始化操作可能是一个非常轻量级的操作，依赖于ContentProvider之后就变成了一个重量级的操作了。假如一个应用使用了很多第三方库，而每个库都会用一个ContentProvider进行初始化，那就会大大影响应用的启动时间。
+
+ 关于ContentProvider的耗时，Google官方也有给出一个测试结果：
+
+ 在一台搭载Android 10系统的Pixel2手机上测试的情况。可以看到，一个空的ContentProvider大约会占用2ms的耗时，随着ContentProvider的增加，耗时也会跟着一起增加。如果你的应用程序中使用了50个ContentProvider，那么将会占用接近20ms的耗时。
+
+ 注意这还只是空ContentProvider的耗时，并没有算上你在ContentProvider中执行逻辑的耗时。这个测试结果告诉我们，虽然刚才所介绍的使用ContentProvider来进行初始化的设计方式很巧妙，但是如果每个第三方库都自己创建了一个ContentProvider，那么最终我们App的启动速度就会受到比较大的影响。
+ 有没有办法解决这个问题呢？
+
+ 所以得出结论，当集成的库使用的ContentProvider达到一定个数之后，确实能减少耗时，但是减少的不多，比如这里我们是10个ContentProvider集成App Startup后能减少的耗时在10ms左右，一般一个项目集成了五十个使用ContentProvider的库，耗时减少应该能在20ms之内。
+
+ 所以App Startup解决的就是这个耗时时间，虽然不多，但是也确实有减少耗时的功能。
+
+- Android会以不确定的顺序初始化内容提供者
+
+
+
+## App Startup原理
+
+
+
+
+
+
+
+App Startup提供了一种更高效的方法，可在应用程序启动时初始化组件并显式定义其依赖关系它可以将所有用于初始化的ContentProvider合并成一个，从而使App的启动速度变得更快。而且它还可以指定不同组件初始化的依赖关系。
+
+两点特性：
+
+- 可以共享单个Contentprovider。
+- 可以明确地设置初始化顺序。
+
+具体来讲，App Startup内部也创建了一个ContentProvider，并提供了一套用于初始化的标准。然后对于其他第三方库来说，你们就不需要再自己创建ContentProvider了，都按我的这套标准进行实现就行了，我可以保证你们的库在App启动之前都成功进行初始化。
+当App启动的时候会自动执行App Startup库中内置的一个名为 InitializationProvider 的 ContentProvider，该 ContentProvider 在合并后的AndroidManifest.xml文件中查找条目来发现Initializer，然后逐个调用它们的create()方法来进行初始化操作。完成上一阶段之后，加载组件之前会先加载该组件的所有依赖项。因此，可以确保组件的所有依赖项都已完成初始化后才对其进行初始化。
+
+
+
+
+
+## 使用
+
+### 1.添加依赖
+
+想要在库或者app中使用Jetpack Startup组件，需要在Gradle文件中添加一下代码:
+
+```xml
+dependencies {
+ implementation "androidx.startup:startup-runtime:1.0.0"
+}
+```
+
+### 2.定义组件初始化器
+
+想要使用App Startup在应用启动时自动初始化组件，你必须要为每一个要初始化的组件定义一个实现Initializer接口的组件初始化器(initializer)。
+
+Initialize接口是Startup封装的组件接口，用于指定组件的初始化逻辑和初始化顺序。
+
+这个接口里面有两个重要的方法:
+
+- create()：初始化操作
+
+ 包含所有组件初始化所需要的操作，并且返回一个该组件T的实例
+
+- dependencies(): 依赖关系
+
+ 返回该组件initializer所需要依赖的一个包含其他Initializer对象的list集合。可以在该方法中去控制应用启动时initializers的执行顺序。
+
+假设你的应用需要依赖WorkManager，并在启动时进行初始化，需要定义一个WorkManagerInitializer类实现Initializer接口:
+
+```kotlin
+// Initializes WorkManager.
+class WorkManagerInitializer : Initializer {
+ override fun create(context: Context): WorkManager {
+ val configuration = Configuration.Builder().build()
+ WorkManager.initialize(context, configuration)
+ return WorkManager.getInstance(context)
+ }
+ override fun dependencies(): List>> {
+ // No dependencies on other libraries.
+ return emptyList()
+ }
+}
+```
+
+dependencies()方法中返回了一个空的list，因为WorkManager不需要依赖其他任何库。
+
+假设你需要使用另外一个叫做ExampleLogger的库，该库依赖于WorkManager。这种情况下你必须保证应用程序启动后先初始化WorkManager。这里定义一个ExampleLoggerInitializer类实现Initializer接口:
+
+```kotlin
+// Initializes ExampleLogger.
+class ExampleLoggerInitializer : Initializer {
+ override fun create(context: Context): ExampleLogger {
+ // WorkManager.getInstance() is non-null only after
+ // WorkManager is initialized.
+ return ExampleLogger(WorkManager.getInstance(context))
+ }
+
+ override fun dependencies(): List
-
然后会提示添加`ConstraintLayout`支持库。
@@ -95,7 +93,7 @@ implementation 'com.android.support.constraint:constraint-layout:1.1.0'
* layout_constraintVertical_bias
```
- 下面这段代码就是让左边占30%，右边占70%（默认两边各占50%），这样左边就会短一些，如图5所示，此时代码是这样的:
+ 下面这段代码就是让左边占30%，右边占70%（默认两边各占50%），这样左边就会短一些，此时代码是这样的:
```xml