Android Jetpack

目录

ViewModel

LiveData

Lifecycle

Navigation

Paging

android第三方库

---

JetPack分类有四种，分别是Architecture、Foundationy、Behavior、UI。

 

ViewModel

在页面（Activity/Fragment）很简单的情况下，通常我们会将UI交互，数据获取与处理等相关业务逻辑，全部写在页面中，但是在页面复杂的情况下，这样做是不合适的，它不符合“单一责任”原则。页面只应该负责接收用户的交互，以及将数据展示到屏幕上，相关数据应该单独存放和处理。为此，Android为我们提供了ViewModel类，专门用于存放应用程序页面所需的数据。它将页面所需的数据从页面中剥离出来，页面只需要处理用户交互，以及负责展示数据的工作。

ViewModel用于存放页面所需的各种数据，它还包括一些业务逻辑等，比如我们可以在ViewModel对数据进行加工，获取等操作。而对页面来说，它并不关心这些业务逻辑，它只关心需要展示的数据是什么，并且希望在数据发生变化时，能及时得到通知并做出更新。LiveData的作用就是，在ViewModel中的数据发生变化时通知页面。LiveData通常是被放在ViewModel中使用。

1 数据持久化

屏幕旋转的 时候 会经历 activity 的销毁与重新创建，这里就涉及到数据保存的问题，显然重新请求或加载数据是不友好的。在 ViewModel 出现之前我们可以用 activity 的onSaveInstanceState()机制保存和恢复数据，但缺点很明显，onSaveInstanceState只适合保存少量的可以被序列化、反序列化的数据，假如我们需要保存是一个比较大的 bitmap list ，这种机制明显不合适。

由图可知，ViewModel 生命周期是贯穿整个 activity 生命周期，包括 Activity 因旋转造成的重创建，直到 Activity 真正意义上销毁后才会结束。既然如此，用来存放数据再好不过了。

2 异步回调问题

通常我们 app 需要频繁异步请求数据，比如调接口请求服务器数据。当然这些请求的回调都是相当耗时的，之前我们在 Activity 或 fragment里接收这些回调。所以不得不考虑潜在的内存泄漏情况，比如 Activity 被销毁后接口请求才返回。处理这些问题，会给我们增添好多复杂的工作。
但现在我们利用 ViewModel 处理数据回调，可以完美的解决此痛点。

3、分担 UI controller负担

从最早的 MVC 到目前流行的 MVP、MVVM，目的无非是 明确职责，分离 UI controller 负担。
UI controller 比如 Activity 、Fragment 是设计用来渲染展示数据、响应用户行为、处理系统的某些交互。如果再要求他去负责加载网络或数据库数据，会让其显得臃肿和难以管理。所以为了简洁，我们可以分离出数据操作的职责给 ViewModel。

4、Fragments 间共享数据

比如在一个 Activity 里有多个fragment，这fragment 之间需要做某些交互。我之前的做法是接口回调，需要统一在 Activity 里管理，并且不可避免的 fragment 之间还得互相持有对方的引用。耦合度高，还需要大量的容错判断（比如对方的 fragment 是否还活着）。

LiveData

LiveData是一个可被观察的数据容器类。我们可以将LiveData理解为一个数据的容器，它将数据包装起来，使得数据成为“被观察者”，页面成为“观察者”。这样，当该数据发生变化时，页面能够获得通知，进而更新UI。

LiveData需要一个观察者对象，一般是Observer类的具体实现。当观察者的生命周期处于STARTED或RESUMED状态时，LiveData会通知观察者数据变化

LiveData是一个抽象类，不能直接使用，所以通常我们使用它的直接子类MutableLiveData。

优势：

1 UI和实时数据保持一致
因为LiveData采用的是观察者模式，这样一来就可以在数据发生改变时获得通知，更新UI。
2不会发生内存泄露
观察者被绑定到组件的生命周期上，当被绑定的组件销毁（onDestroy）时，观察者会立刻自动清理自身的数据。
3不会再产生由于Activity处于stop状态而引起的崩溃
例如：当Activity处于后台状态时，是不会收到LiveData的任何事件的。
4不需要再解决生命周期带来的问题
LiveData可以感知被绑定的组件的生命周期，只有在活跃状态才会通知数据变化。
5实时数据刷新
当组件处于活跃状态或者从不活跃状态到活跃状态时总是能收到最新的数据
6解决Configuration Change问题
在屏幕发生旋转或者被回收再次启动，立刻就能收到最新的数据。
7数据共享
如果对应的LiveData是单例的话，就能在app的组件间分享数据。这部分详细的信息可以参考继承LiveData
 

       

Lifecycle

Lifecycle是Android中引入的主要用来观察和监听Activity、Fragment生命周期的一套观察者机制。

在这个机制中有两个核心类，LifecycleOwner接口和LifecycleObserver接口。 

LifecycleOwner接口，有一个getLifecycle()方法，实现了这个接口的类就可以作为一个被观察者，AppCompatActivity和Fragment就实现了这个接口，所以它们的生命周期就可以被观察和监听。

LifecycleObserver接口，实现了这个接口的类就可以作为一个观察者。

Navigation

Navigation 用于方便的实现页面的导航， destination 是个抽象概念，大部分情况一个 destination 就表示一个 Fragment，但是它同样可以指代 Activity、其它的导航图。起始页面，叫 start destination，处于栈底，是启动时的第一个页面，当然也是返回可见的最后一个页面。多个 destination 连接起来就组成了一个导航图，类似于一种栈结构，页面先进后出。destination 之间的连接叫做 action

Paging

Paging 是一个分页库，Paging 可以帮助我们优雅地渐进加载大型数据集合，同时也可以减少网络的使用和系统资源的消耗。

a 在内存中缓存分页数据，确保App在使用分页数据时有效地使用系统资源。

b 内置删除重复数据的请求，确保App有效地使用网络带宽和系统资源。

c 可配置当用户滚动到加载数据的末尾时自动请求数据。

                                                       paging2 数据流图

DataSource：数据源提供者，数据的改变会驱动列表的更新。

PageList：核心类，它从数据源取出数据，同时，它负责页面初始化数据+分页数据什么时候加载，以何种方式加载。

PagedListAdapter：是RecyclerView.Adapter的实现类，从PagedList过来的数据，通过DiffUtil差分异定向更新列表数据。

WorkManager

与后台执行任务相关的 API 变更：从android 4.4 系统开始 AlarmManager 的触发时间由原来

的精准变为不精准， 5.0 系统中加入了 JobScheduler 来处理后台任务， 6.0 系统中引入了 Doze

和 App Standby 模式用于降低手机被后台唤醒的频率，从 8.0 系统开始直接禁用了 Service 的后

台功能，只允许使用前台 Service 。

workManager要点：

1 针对不需要及时完成的任务

比如，发送应用程序日志，同步应用程序数据，备份用户数据等。站在业务的角度，这些任务都不需要立即完成，如果我们自己来管理这些任务，逻辑可能会非常复杂，若API使用不恰当，可能会消耗大量电量。

2 保证任务一定会被执行

WorkManager能保证任务一定会被执行，即使你的应用程序当前不在运行中，哪怕你的设备重启，任务仍然会在适当的时候被执行。这是因为WorkManager有自己的数据库，关于任务的所有信息和数据都保存在这个数据库中，因此，只要你的任务交给了WorkManager，哪怕你的应用程序彻底退出，或者设备重新启动，WorkManager依然能够保证完成你交给的任务。

注意：WorkManager不是一种新的工作线程，它的出现不是为了替代其它类型的工作线程。工作线程通常立即运行，并在执行完成后给到用户反馈。而WorkManager不是即时的，它不能保证任务能立即得到执行。

android第三方库

Android中常见的第三方库包括：.so、.jar、.aar

.so通常是C或C++语言的内容打包成的库。

jar包：只包含了class文件与清单文件 ，不包含资源文件，如图片等所有res中的文件。

aar包：Android库项目的二进制归档文件，包含所有资源，class以及res资源文件全部包含。将aar解压打开后，会包含AndroidManifest.xml，classes.jar，res，R.txt。