Android jetpack总结和实践

背景

在Android开发中常常面临的问题： （1）在应用程序（Activity、Fragment）的生命周期管理困难，尤为是Fragment的跳转带来的生命周期管理问题。 （2）在Activity须要从新建立的时候，界面控制器（View层）中存储的数据丢失，须要从新初始化，影响用户体验。 （3）Android的异步操做（DB，NetWork）时，在界面控制器（View层）被销毁后，界面控制器须要结束和任务的订阅关系，避免内存泄漏和没必要要的信息回调。 （4）Android的后台服务和任务愈发困难。主要是因为Android系统的DOZE省电模式，以及后来对于后台任务和服务的限制。 （5）用户偏好设置和网络请求数据的本地存储问题。

针对以上问题，Google推出Android Jetpack框架来解决以上问题。Jetpack主要分为4个部分（下图）： 基础、架构、行为、界面 。

同时Google也推出 AndroidX 库，AndroidX 是对support library的重大改进。在AndroidX中将全部软件包名都以字符串**androidx.**开头，位于一致的命名空间中。

使用Android Jetpack组件的优点： （1）Lifecycles轻松管理应用程序的生命周期。 （2）LiveData构建可观察的数据对象，以便在基础数据更改时通知视图。 （3）ViewModel存储在应用程序轮换中未销毁的UI相关数据，在界面重建后恢复数据。 （4）Room轻松的实现SQLite数据库。 （5）WorkManager系统自动调度后台任务的执行，优化使用性能。 （6）Navigation导航组件轻松管理Fragment等页面跳转问题。

google推荐的基于Jetpack的Android客户端软件开发架构图： （1）经过定义Repository管理数据来源(Model)。 （2）使用LiveData驱动界面(View)更新。 （3）使用ViewModel代替Presenter管理数据(VM)。 （4）Room（Sqlite）储存本地序列化的数据，Retrofit获取远程数据的数据。

关于该架构的疑问：该模式的是MVP仍是MVVM架构？

与传统的MVP架构相比有如下优势： （1）在MVP架构中，Presenter中持有View层的引用，若是生命周期处理不当，会存在内存泄露的风险。在MVVM架构中View层和VM层经过LiveData通讯，避免了内存泄漏。。 （2）传统MVP架构因为各层之间的通讯是经过接口，因此会致使接口数量惊人，上诉架构经过观察者模式（LiveData）避免了接口问题。

若是在上诉架构中加入Databidning。实现View和Model的双向绑定接能够演变成MVVM架构。可是基于DataBinding的MVVM架构有以下缺点： （1）数据双向绑定，致使View不可重用。 （2）经过DataBinding实现数据绑定，会增长Bug调试难度。 （3）业务的复杂，会带来View页面复杂，model层代码也会增大。

jetpack架构

2.1 Lifecycles

1. 一句话概述： Lifecycles是一个持有组件生命周期状态（Activity、Fragment）信息的类，用来解决生命周期管理问题的组件。Lifecycles源码分析地址
2. 生命周期转化图：

   

3. 实现原理 （1）数据结构： 为何使用该数据结构？ 具备以下优势： 1.SafeIterableMap 的插入操做是时间复杂度O(1）直接经过指针的移动插入数据，并且不须要执行hash算法，效率高。 2.遍历的过程当中删除元素而不触发ConcurrentModifiedException。 3.使用双向链表来存储会比 HashMap （java 8 红黑树）节省内存空间。

   

   （2）类图
4. Lifecycle组件成员Lifecycle被定义成了抽象类，LifecycleOwner、LifecycleObserver被定义成了接口。
5. 组件（Activity、Fragment）实现了LifecycleOwner接口，该只有一个返回Lifecycle对象的方法getLifecyle(): LifecycleRegistry。
6. Lifecycle的内部类State标明状态、Event表示事件
7. ObserverWithState的成员变量GenericLifecycleObserver继承自LifecycleObserver

   

2.2 ViewModel

1. 一句话概述： ViewModel存储和管理 UI 相关数据，保证组件（Activity）从新建立时能够恢复历史数据。 ViewModel源码分析地址
2. 生命周期转化图：

   

3. 实现原理 （1）onRetainNonConfigurationInstance方法。 当发生屏幕切换时，将伴随Destroying被系统调用。经过这个方法能够像onSaveInstanceState()的方法同样保留变化前的Activity数据和状态，最大的不一样在于这个方法能够返回一个包含有状态信息的Object对象，其中甚至能够包含Activity Instance自己。用这个方法保存Activity State后。 （2）经过getLastNonConfigurationInstance()在新的Activity Instance中恢复原有状态。好比: 在恢复窗口时，咱们能够不使用onRestoreInstanceState，而代替的是 getLastNonConfigurationInstance 方法。

2.3 LiveData

1. 一句话概述： LiveData 是保存数据对象的类，经过注册监听器Observer 监听数据的变化。LiveData最大的优点：LiveData 是感知Activity、Fragment等生命周期的组件。LiveData源码分析地址
2. 实现原理 （1）使用LifecycleOwner的observe() 方法将观察者对象附加到LiveData对象，将观察者向LiveData对象订阅，以便通知LiveData中数据的变化。 （2）当Lifecycle 没有处于活动状态（ (STARTED 、RESUMED)），Observer 则不会被通知，即便数据发生了变化，没有处于活动状态的 Observer 也不会被通知。 （3）Lifecycle 被销毁（destroyed）Observer 也自动被删除，无需用户手动清理。 避免内存泄漏：Observer 和 Lifecycle 绑定，能够感知组件生命周期，因此当 Lifecycle 被销毁后，Observer 自动被remove避免内粗泄漏。

2.4 WorkManager

1. 一句话概述： WorkManager 负责用来管理后台任务，它适用于须要保证系统即便应用程序退出也会运行的任务， WorkManager会根据设备API级别和应用程序状态等因素选择适当的方式来运行任务。。[WorkManager源码分析地址](juejin.im/post/5d5e7d…
2. 实现原理 架构图：

   

2.5 Navigation

1. 一句话概述： Navigation管理APP页面跳转。Navigation大部分部分状况下做用于Fragment中，使用Navigation切换Fragment可使代码简洁，直观。Navigation导航组件还支持：Fragment、Activity、导航图和子图、自定义目标等。。Navigation源码分析地址
2. 实现原理 类图：

   

2.6 Paging&Room

1. 一句话概述： Paging主要是用来结合RecyclerView进行使用，是一种分页加载解决方案，这样Paging每次只会加载总数据的一部分。 Room是Google提供的一个ORM库。。Paging&Room组合使用

2. 实现原理 原理图：

   

   

示例

基于Jetpack的架构图总结：

架构图： （1）View层：表示的Activity和Fragment等组件。 （2）ViewModel层：ViewModel存储和View层相关的数据，能够在View层从新绘制时恢复数据，并且负责和View层和仓库层之间的通讯。 （3）仓库层：负责从数据库中获取数据或者从网络中获取数据，并将数据返回给ViewModel层。 （4）数据层：数据层分为网络数据层（Retrofit）和是数据库数据层（GreenDao）。 （5）View层和ViewModel层经过LiveData通讯，避免了接口的内存泄漏问题。 关于仓库层存在必要性？：

官网解析：地址 Repository modules handle data operations. They provide a clean API so that the rest of the app can retrieve this data easily. They know where to get the data from and what API calls to make when data is updated. You can consider repositories to be mediators between different data sources, such as persistent models, web services, and caches.

大体意识：

仓库模块负责处理数据操做，提供了一个干净的API使得获取数据更加容易。仓库层知道从何处获取数据以及更新数据时要调用的API。你能够认为仓库层是做为中介在不经过的数据源之间，好比持久模型，Web服务，缓存等。

总结：遵循关注点分离原则 通过Repository中介层使得ViewModel不须要具体的数据来源，这样就能够根据需求将其交换为其余实现。