WorkManager

The WorkManager API makes it easy to specify deferrable, asynchronous tasks and when they should run. These APIs let you create a task and hand it off to WorkManager to run immediately or at an appropriate time.

在早期，为了做一些延迟定时的任务，做了个基于闹钟的定时任务队列SchedulerQueue。现在谷歌官方帮我们把一切都封装好了。后续你不用再自己造轮子了.像这样的轮子在后台等都有很完全的库了，只是安卓系统支持不太好，搞到现在才出一个吧。

整体原理如下

使用流程如下：

VidwModel

前面在使用LiveData时候，我们已经看到了ViewModel，不过没有去深入的说，因为那篇文章是说LiveData的，这次我们说会ViewModle去。
它主要是以关联生命周期的方式来存储和管理UI相关的数据的类，即使configuration发生改变，数据仍然可以存在不会销毁
前面我们看到我们的LiveData是写在viewModle里面的变量啊。

jetPack在引入ViewModel时有以下几点：

1. 数据管理：
   Activity或Fragment这类应用组件都有自己的生命周期，他们的生命周期都是被Framework所管理。Framework可能会根据用户的一些操作以及设备的状态对Activity或Fragment进行销毁和重建。作为开发者，这些行为我们是无法干预的。伴随着Activity或Fragment的销毁和重建，它们当中的数据也会随着一起销毁和重建。对于一些简单的数据，Activity可以使用onSaveInstanceState()方法，并从onCreate的bundle中重新获取，但这一方法仅仅适合一些简单的UI状态，对于列表型这种庞大的数据类型并不适合

2. 异步与生命周期问题：
   Activity或Fragment经常会做一些异步的耗时操作，随之就需要管理这些异步操作得到的数据，并在destroyed的时候清理它们，从而避免内存溢出这类问题的发生。但是这样的处理会随着项目扩大而变得十分复杂

3. 分忧：
   Activity或Fragment本身需要处理很多用户的输入事件并和操作系统打交道，当它们还要花时间管理那些数据资源时，它们所在的类就会变得异常庞大，造就出所谓的god activities和god fragments，这样很尴尬

正因为这样，所以类似MVP结构的重要一环一样，这个也会有很长的生命周期，便于我们对数据做统一管理

LiveData

LiveData是一个可以感知Activity、Fragment生命周期的数据容器。
当LiveData所持有的数据发生改变时，它会通知相应的观察者进行数据更新。
由于Activity、Fragment都已实现LifecycleOwner接口，

所以持有LifecycleOwner引用的LiveData在LifecycleOwner的生命周期处于started或resumed时可以作出相应更新，
而在LifecycleOwner处于被销毁时停止更新。

目前在项目使用了这个是改造了 网络请求，数据回包的问题。

发送网络请求，然后用观察者来处理对应数据，省去自己在对回包时候的生命周期判断的恶心判断逻辑。

从官方文档来看，LiveData的使用有以下几大好处

1. 保证UI状态和数据的统一：
   LiveData采用了观察者设计模式。当生命周期状态改变时，LiveData会通知Observer对象。每次应用程序数据更改时，都会通知观察者对象，从而更新UI。
2. 减少内存泄漏：
   LiveData能够感知到组件的生命周期，观察者绑定到生命周期对象，并在其相关生命周期被破坏后自行清理。
3. 当Activity停止时不会引起崩溃：
   这是因为组件处于非激活状态时，不会收到LiveData中数据变化的通知
4. 不需要额外的手动处理来响应生命周期的变化：
   这一点同样是因为LiveData能够感知组件的生命周期，所以就完全不需要在代码中告诉LiveData组件的生命周期状态。
5. 组件和数据相关的内容能实时更新：
   组件在前台的时候能够实时收到数据改变的通知，这是可以理解的。当组件从后台到前台来时，LiveData能够将最新的数据通知组件，这两点就保证了组件中和数据相关的内容能够实时更新。
6. 资源共享：
   通过继承LiveData类，然后将该类定义成单例模式，在该类封装监听一些系统属性变化，然后通知LiveData的观察者。

我们经常有这样的场景：

feed流-详情页这样的例子是最实在的，经常会跳去某个item的详情页，然后在里面做些处理，回到feed流页面，要保持数据的一致

安卓提供了新的JetPack工具包，把原本我们早期开发安卓所遇到的一些基础问题，重新做了封装，便于我们使用。

这些组件可帮助我们摆脱编写样板代码的工作并简化复杂任务，以便您可以专注于您关心的代码。

这次的源码探索系列，就针对这块来做新的探索，虽然Flutter已经逐渐的成熟，大有逐渐替代之势，不过还是继续看下这块的源码，对其思路做了解，以方便以后的框架设计，提供新的思路来做。

系列文章基本按照这个列表的内容来做，对于基础包就不做过度描述，Appcompat最近运用于做一些转场动画，不过这个只针对5.0的贡献元素等的一次封装，没太大意义，就不管了，KTX是对kotlin的扩展使用，也不深入去说，Multidex这个都知道，只是挪过来放一起，就不去看了。

所以这次的探索系列文章，主要针对架构这一列.先做记录，然后对UI，行为这块做些记录。像TV,Wear OS 这些选择看了即可，需要时候再看。
同时作为踩过dataBind的问题的人，现在对他是完全的嫌弃的，他带来太多的问题了。

现在就开始从Lifecycles开始写起.点击more查看更多哦！

做过web的同学应该也知道，我们React的组件是有生命周期的，

这个Flutter的widget也是有生命周期的