背景
在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
- 一句话概述:
Lifecycles是一个持有组件生命周期状态(Activity、Fragment)信息的类,用来解决生命周期管理问题的组件。Lifecycles源码分析地址 - 生命周期转化图:
- 实现原理
(1)数据结构:
为什么使用该数据结构?
具有如下优点:
1.SafeIterableMap 的插入操作是时间复杂度O(1)直接通过指针的移动插入数据,而且不需要执行hash算法,效率高。
2.遍历的过程中删除元素而不触发ConcurrentModifiedException。
3.使用双向链表来存储会比 HashMap (java 8 红黑树)节省内存空间。
(2)类图 - Lifecycle组件成员Lifecycle被定义成了抽象类,LifecycleOwner、LifecycleObserver被定义成了接口。
- 组件(Activity、Fragment)实现了LifecycleOwner接口,该只有一个返回Lifecycle对象的方法getLifecyle(): LifecycleRegistry。
- Lifecycle的内部类State标明状态、Event表示事件
- ObserverWithState的成员变量GenericLifecycleObserver继承自LifecycleObserver
2.2 ViewModel
- 一句话概述:
ViewModel存储和管理 UI 相关数据,保证组件(Activity)重新创建时可以恢复历史数据。
ViewModel源码分析地址 - 生命周期转化图:
- 实现原理
(1)onRetainNonConfigurationInstance方法。 当发生屏幕切换时,将伴随Destroying被系统调用。通过这个方法可以像onSaveInstanceState()的方法一样保留变化前的Activity数据和状态,最大的不同在于这个方法可以返回一个包含有状态信息的Object对象,其中甚至可以包含Activity Instance本身。用这个方法保存Activity State后。
(2)通过getLastNonConfigurationInstance()在新的Activity Instance中恢复原有状态。比如: 在恢复窗口时,我们可以不使用onRestoreInstanceState,而代替的是 getLastNonConfigurationInstance 方法。
2.3 LiveData
- 一句话概述:
LiveData 是保存数据对象的类,通过注册监听器Observer 监听数据的变化。LiveData最大的优势:LiveData 是感知Activity、Fragment等生命周期的组件。LiveData源码分析地址 - 实现原理
(1)使用LifecycleOwner的observe() 方法将观察者对象附加到LiveData对象,将观察者向LiveData对象订阅,以便通知LiveData中数据的变化。
(2)当Lifecycle 没有处于活动状态( (STARTED 、RESUMED)),Observer 则不会被通知,即使数据发生了变化,没有处于活动状态的 Observer 也不会被通知。
(3)Lifecycle 被销毁(destroyed)Observer 也自动被删除,无需用户手动清理。
避免内存泄漏:Observer 和 Lifecycle 绑定,可以感知组件生命周期,所以当 Lifecycle 被销毁后,Observer 自动被remove避免内粗泄漏。
2.4 WorkManager
- 一句话概述:
WorkManager 负责用来管理后台任务,它适用于需要保证系统即使应用程序退出也会运行的任务, WorkManager会根据设备API级别和应用程序状态等因素选择适当的方式来运行任务。。[WorkManager源码分析地址](https://juejin.im/post/5d5e7d0bf265da03dd3d79a3 - 实现原理
架构图:
2.5 Navigation
- 一句话概述:
Navigation管理APP页面跳转。Navigation大部分部分情况下作用于Fragment中,使用Navigation切换Fragment可以使代码简洁,直观。Navigation导航组件还支持:Fragment、Activity、导航图和子图、自定义目标等。。Navigation源码分析地址 - 实现原理
类图:
2.6 Paging&Room
-
一句话概述:
Paging主要是用来结合RecyclerView进行使用,是一种分页加载解决方案,这样Paging每次只会加载总数据的一部分。 Room是Google提供的一个ORM库。。Paging&Room组合使用 -
实现原理
原理图:
示例
基于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不需要具体的数据来源,这样就可以根据需求将其交换为其他实现。
来源:https://blog.csdn.net/u011060103/article/details/100125769