首页 > 编程学习 > ViewModel 源码设计思路分析

ViewModel 源码设计思路分析

发布时间:2022/11/9 1:49:28

 

前言

转眼一年又过去大半了,在2022年,初定了大多计划,搬家,换公司,很多事情都一托再拖。

这里分享一篇我在公司内部做的分享文章吧,删除了部分对公司内部代码的探讨。

公司中的项目运用到了大量的组件封装。有的是对第三方组件进行二次封装,有的是从零开始设计,如何设计一个可扩展性高,容易使用的组件呢?可以参考参考google开发者是如何设计组件的。

我们以ViewModel组件为例,试图从源码中,窥探作者是如何设计ViewModel组件的。如果是我们,我们会怎么设计ViewModel组件呢?

需求分析

首先,需要明确我们的组件需要什么功能:

1、这个组件专门处理业务的数据逻辑

2、给Activity或者Fragment用的,希望同一个Activity下的fragment可以利用这个VeiwModel交互传递数据。

3、配置发生变化,导致View销毁重建的时候,保存这个ViewModel。数据不丢失。

4、ViewModel虽然不能持有Acitvity、fragment这种上下文,但是允许给一个Application。

5、进程意外杀死重建的时候,需要保存数据

头脑风暴(核心)

整理了需求之后,作者开始了头脑风暴,一起看看作者是如何思考的。

1、用于逻辑处理的类ViewModel。先搞个抽象父类,模板模式封装公共代码,逻辑交给子类。到时候用户继承我们的抽象类就好了。

2、保存这个功能要如何处理?我们希望在Activity或者Fragment中使用。并且到时候,一个Activity,可能有多个ViewModel。作者创建了一个新的类:ViewModelStore。专门用来保存一个界面的多个ViewModel。而VeiwModel负责处理业务逻辑,ViewModel的存储交给ViewModelStore.符合单一职责原则。

3、有了ViewModelStore保存我们的ViewModel了,那配置发生变化的时候,只需要存VeiwModelStore就好了。不是配置发生变化导致的界面销毁,就需要清空ViewModelStore中的ViewModel了。什么时候该保存,什么时候该清空,那就不是ViewModelStore这个类需要关心的事情了。因为ViewModelStore的责任只是用来保存ViewModel的。谁该关心呢?作者认为,谁持有,谁关心~作者创建了一个接口类ViewModelStoreOwner用来声明职责,给个方法,返回一个ViewModelStore,实现了这个接口,就会持有ViewModelStore了。那就由他去操心保存和清空ViewModelStore的功能吧。

可见,职责声明的场景,用接口来表示。

3.1、作者让ComponentActivity实现了接口,并在构造函数中监听生命周期回调。当生命周期走向onDestroy的时候,判断当前是不是因为配置变化导致的销毁Activity,不是的话,就清空ViewModelStore中的数据。

3.2、那具体怎么保存数据呢?当因为配置发生变化的时候,Acitvity的生命周期被安排走向尽头。在ActivityThread中,调用activity的retainNonConfigurationInstances。该方法返回一个NonConfigurationInstances对象(可以认为包装类),把对象用变量lastNonConfigutationInstances保存在ActivityCliendRecord中。在该方法中

NonConfigurationInstances retainNonConfigurationInstances() {
 //该方法是空实现,用于保存子类的对象
 Object activity = onRetainNonConfigurationInstance();

 //...忽略代码 

 NonConfigurationInstances nci = new NonConfigurationInstances();
 nci.activity = activity;

 //...忽略代码
 return nci;
 }

 

所以ComponentActivity实现onRetainNonConfigurationInstance并返回ViewModelStore对象即可。

不过,作者明白,只有一些刁民,喜欢瞎搞事情。

 为了防止这些刁民,作者在ComponentAcitvity中把这个onRetainNonConfigurationInstance方法写了final,防止他们重写了方法,覆盖了我们的代码。这个方法就用来给我们保存数据的.

 但是做人做事都不能赶尽杀绝啊,毕竟大部分的用户都是遵纪守法的好公民,这个方法只保存我们的ViewModelStore,也太局限了。于是,作者就创建了一个空函数,用户实现这个方法,返回他们想要正常保存的数据,到时候,连带帮用户的数据一起存起来不就好了。所以到时候补一个用户实现这个方法,配置发生变化的时候,顺带帮他们一起保存了。既然要存的有2种数据,一种是用户的,另一种是ViewModelStore。那就需要创建一个包装类了,把这俩包装起来。于是ComponentActivity中,就需要创建一个静态内部类了。

这种实现父类给的方法,但是不赶紧杀绝的做法很赞,在我们的项目中,也发现了类似的写法。此处省略一万字。。。。。

当Activity重新创建的时候,再来个方法返回我们之前保存的数据就好了~

在Activtiy的attach函数中,会把之前的配置传回来。

这样子类在就可以通过这个对象获取之前我们存储的ViewModelStore了。

如此一来,保存数据和获取数据的方案都有了~

到目前为止,我们已经有一个专门处理逻辑的类ViewModel,一个专门保存ViewModel的类ViewModelStore,以及利用接口ViewModelStoreOwner去声明相关职责了。保存清空的思路也都有了。

 4、下面就需要考虑如何去创建了

用户是可以自由定义ViewModel的具体的类的,只需要继承我们的ViewModel就好了,并且ViewModel的构造函数中,可能有用户自己的参数。也可能没有参数或者是有一个Application的参数。这种情况下,作者想到了利用工厂模式,为每一个ViewModel提供一个工厂类,如果有构造函数有自定义的参数,那就自己搞个工厂类去创建,没有参数或这有一个Application参数的时候,由我们提供的工厂创建就好了。

工厂类接口很简单:

 作者为没有参数的构造函数和参数只有一个Applicaiton的构造函数,创建一个默认的工厂类NewInstanceFactory和AndridViewModelFactory

 使用反射直接获取具体的类对象。带有Application参数的工厂类也是一样的,只是多了一个参数而已。问题不大:AndroidViewModelFactory

5、创建的方法已经有了。下面就是思考如何获取拿到ViewModel实例对象了。为什么要这么考虑呢?利用工厂模式不是已经可以获取到实例对象了?

因为我们有存储机制,当配置变化的时候,不再是通过factory获取了,而是从ViewModelStore中获取。

先整理一下获取ViewModel需要的相关逻辑:

(1)获取到对应的工厂实例对象

(2)从viewModelStore中获取ViewModel,或者利用工厂去创建一个ViewModel。

(3)创建之后,同时需要保存ViewModel。

这三部就是创建的流程需要涉及的相关逻辑

对于用户而言,他不应该关心如何保存我们的ViewMdel,什么时候从ViewModelStore中获取,什么时候创建,这些都应该是用户无感知的。这遵循迪米特原则:最少知道原则,用户在调用ViewModel组件的时候,不应该知道这个类的内部细节,以及内部调用逻辑。比如说外观者模式,或者中介者模式就符合迪米特原则。外观者,封装了组件内部实现细节,并提供统一的接口或者函数给外部。也降低了使用成本。这种最常见的就是Glide。简单的一行内码,就可以整合了内部千军万马的组件调用逻辑。

作者创建了一个新的类:ViewModelProvider。对外提供一个get函数,利用传入的具体的class,使用对应的工厂创建ViewModel。内部逻辑怎么调用,与用户无关。

这个ViewModelProvider做了什么事情呢?

1、根据不同的情况,拿到对应的工厂类。

2、从缓存中获取ViewModel,拿不到的时候,利用工厂类创建ViewModel。

3、把ViewModel保存到ViewModelStore中。

小结:创建的流程,使用了工厂模式和外观者模式,把创建的流程和业务代码隔离开,并且提供统一的对外访问函数get,降低用户使用成本。

5.1、具体看看这个ViewModelProvider是怎么做的,

ViewModelStore肯定是从外部(View层)带进来了,View层的ComponentActivtiy和Fragment都实现了ViewModelStoreOwner的接口,利用这个接口,就可以拿到了ViewModelStore了。另外还需要根据具体情况获取到默认的Factory。提供默认Factory这个职责,作者又创建一个接口类,HasDefaultViewModelProviderFactory,这个接口也只有一个方法,就是用来返回默认的Factory的。ComponentActivity去负责创建这个默认Factory在合适不过了。毕竟还要获取到application。这个接口类和Owner接口类搭配使用。

可以发现,对于每一个不同的功能职责声明,都有一个独立的接口去负责,并不会因为这些功能都和VeiwModel相关,也都用在一起,而把不同功能的接口整合在一起。就是典型的接口隔离的思想。

到这里,基本的逻辑已经完善了,创建了几个单一职责的类:ViewModel、ViewModelStore,外观者模式类:ViewModelProder、工厂模式涉及的具体的Factory。每一个类都有各自的功能。创建了声明职责的HasDefaultViewModelProviderFactory、ViewModelStoreOwner接口,遵循接口隔离原则。

继续看:

6、ViewModel只能保存因为配置发生变化导致界面重建的数据,如果因为系统资源限制等,导致回来的时候进程重新创建了,我们现有的逻辑是保存数据走onSaveInstanceState的方法。这个只能在View层处理了,这不就是解耦的不够彻底了。于是,就有一个新的类SaveStateHandle

保存这块数据,底层逻辑肯定还是需要调用OnSaveInstanceState,但是ViewModel和Activity是完全解耦的,如何交互呢?

作者想到使用第三者(一个新的类saveStateRegistry)来建立两者的沟通,这就有一些中介者味道了,比如我们非常熟悉的MVC架构,controller就是M和V的中介者。

通过第三者,在onCreate的时候,拿到数据,在onSaveInstanceState的时候,把数据存起来

 

 mSaveStateRegistry这个类和ViewModelStore一样,就是用来做数据存储的,从onCreate中获取数据,把数据用map保存,当需要调用onSaveInstanceState的时候,从外部拿到bundle,把我们的map都存到这个bundle中。

这个mSaveStateRegistry就像是一个model,提供数据的。当然,作者并不直接像上面这样,在onCreate中直接调用mSaveStateRegistry,在调用mSaveStateRegsitry.performStore方法得时候,增加了一些逻辑判断。而逻辑处理的逻辑不应该写在Activity中,更不应该写在数据存储类里面,作者使用了mvc模式,增加一个类作为控制层SaveStateRegistryController,负责处理SaveStateRegistry存储数据时候的额外逻辑。V是Activity,M就是SaveStateRegistry。最终:

 

 下面就是要思考如何把我们的ViewModel和这个SaveStateRegistry建立关系了。作者并没有直接让SaveStateRegistry持有ViewModel。这点和ViewModelStore不同。通过创建了一个接口类SavedStateProvider,这个接口的唯一方法就是返回一个bundle。SaveStateRegistry使用map存储这个接口。而ViewModel间接持有这个接口的实例对象。从而实现了ViewModel和SaveStateRegistry的解耦。

另外,对于ViewModel而言,也需要一个数据类,作者创建了一个新的数据类:SaveStateHandle。目的是通过该类存储我们希望进程意外杀死重建的时候的数据。同样的,SaveStateHandle是对数据的存储操作,该类就持有SaveStateProvider的接口实例对象。作者同样需要做一些额外的操作,比如把SaveStateHandle中的SaveStateProvider对象注册到SaveStateRegistry中,并监听生命周期,保证只注册一次。这些额外的逻辑操作同理交给SaveStatehandleController处理。

所以,ViewModel会持有SaveStateHandle,SaveStateHandle是数据类型,是Model,由控制类SaveStateHandleController提供,逻辑也有它负责。同样是MVC模式。

题外话:ViewModel和Activity的关系很淡泊,ViewModel持有SaveStateHandle对象,SaveStateHandle持有一个SaveStateProvider对象,这个对象被注册到SaveStateRegistry中,SaveStateRegistry不会直接和View层交互,而是通过SaveStateRegistryController。旁系三代以外就可以结婚了。这俩隔离这么远,可以说是妥妥的没啥联系了。

SaveStateHandle怎么和ViewModel建立联系呢?

现在只要在创建ViewModel的时候,把这个SaveStateHandler传给ViewModel即可。

如果是我的话,我会在ViewModel抽象父类中,创建这个成员变量。但作者的思路不同,他对构造函数进行解析,如果构造函数的参数只有SaveStateHandle这个类,或者是SaveStateHandle和Application的类型,在创建的时候,就把这个SaveStateHandle传输传入。这样用户就可以创建一个次构,来获取这个SaveStateHandle了。不过这种做法,有一个问题,如果是用户自定义的Factory,那要就获取不到了。所以在SaveStateHandle的注释中有提到:

 

如果想拿到这货,就需要使用SaveStateViewModelFactory了,不能用自己的。如果用全局变量,感觉就没有构造函数的限制了。

大致依赖关系

 

小彩蛋:

1、在SaveStateHandle中,这里key是直接写死的:

 获取的时候

 

 2、比如ViewModelStore:使用的都是hashmap,而不是ArrayMap。

 思考:是否在某些场景下,HashMap的性能会优于ArrayMap?因为如果HashMap一无是处,为什么没有被打上过期的标识?

 

3、外部访问权限控制

 这段代码源自NewInstanceFactory中,可以发现,专门创建了一个instance用来对外返回sInstance这个对象。而sInstance被声明称内部私有。pubclic修饰不可修改,很早之前google的一些VeiwModel中也遇到过。感觉意义不是很大。

最后

ViewModel组件设计思路差不多就到这了。本次技术分享主要是浅谈一下ViewModel组件的作者可能是如何思考并设计这个组件的。ViewModel的源码细节实际更多一些,可以发现该组件的设计也运用了大量的设计模式和设计思想,当我们自己设计组件的时候,有相似场景的时候。可以参考借鉴一下~。

Copyright © 2010-2022 dgrt.cn 版权所有 |关于我们| 联系方式