Android Jetpack 从使用到源码深耕数据库注解Room 从实践到原理
Posted itbird01
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Android Jetpack 从使用到源码深耕数据库注解Room 从实践到原理相关的知识,希望对你有一定的参考价值。
android 开发中,常见的数据存储的方式,有SharePreference、网络、Sqlite、MMKV、文件、 ContentProvider,其中,SharePreference、MMKV从简单的使用入手,到使用上的经验总结,最终我们借助于源码的深入阅读学习,对其原理也进行了深入的总结。但是,大家也发现了,数据库Sqlite有很多成熟的三方封装框架,例如我们最常用的GreenDao,一直想着对其进行一下源码的深入探索、总结,但是由于各种原因,未付诸于实行。
今年计划对Jetpack系列组件,从使用入手、到经验总结、到源码原理解读进行一遍系统总结,其中正好有一个数据库的封装组件Room。本文,我们开始从简单的使用入手,开始源码原理的深入解读,希望大家有所收获。
其实说到Room,在前面Jetpack WorkManager组件的探索时,我们已经涉及到,当时研究WorkManager源码时,我们发现,它将我们提交的任务,使用Room存储到了数据库,这也正是为什么WorkManager可以做到,在APP被杀死、系统重启之后,我们提交的任务依然可以被执行的原因。
1.背景
全篇开始之前,先面对一个问题,为什么要使用Room?
需求:我们这里不妨以一个简单的例子,来说明一下。我们有一个实体User类,实体有三个字段,id、firstname、lastname,我们现在使用sqlite实现user数据的增、删、改、查。
5. Jetpack源码解析---ViewModel基本使用及源码解析
截止到目前为止,JetpackNote源码分析的文章已经有四篇文章了,这一系列的文章我的初衷是想仔细研究一下Jetpack,最终使用Jetpack组件写一个Demo,上一篇已经分析了
LiveData
,本篇文章将分析ViewModel.
1.背景
Jetpack源码解析系列文章:
1. Jetpack源码解析—看完你就知道Navigation是什么了?
2. Jetpack源码解析—Navigation为什么切换Fragment会重绘?
3. Jetpack源码解析—用Lifecycles管理生命周期
4. Jetpack源码解析—LiveData的使用及工作原理
上篇我们对LiveData
进行了分析,已清楚了它的主要作用,我们再来温习一下:
LiveData是一个可以感知Activity、Fragment生命周期的数据容器。其本身是基于观察者模式设计的,当
LiveData
所持有的数据发生改变时,它会通知对应的界面所持有该数据的UI进行更新,并且LiveData
中持有Lifecycle
的引用,所以只会在LifecycleOwner
处于Active
的状态下通知数据改变,果数据改变发生在非 active 状态,数据会变化,但是不发送通知,等owner
回到 active 的状态下,再发送通知.而
LiveData
配合今天所讲的ViewModel
使用起来真的是非常方便,接下来我们开始分析:
2.简介
2.1 是什么?
简单来说:ViewModel
是以关联生命周期的方式来存储和管理UI相关数据的类,即使configuration
发生改变(例如屏幕旋转),数据仍然可以存在不会销毁.
举个例子来说:我们在开发中经常会遇到这种场景,当我们的Activity和Fragment被销毁重建之后,它们中的数据将会丢失,而我们一般的解决方案就是通过onSaveInstanceState()
中保存数据,然后在onCreate()
中恢复过来,但是当这些数据较大时或者数据可能又需要重新请求接口,这时候ViewModel就派上用场了,也就是说当我们把数据保存在ViewModel中,不管Activity和Fragment被销毁了还是屏幕旋转导致configuration发生了变化,保存在其中的数据依然存在。
不仅如此,ViewModel还可以帮助我们轻易的实现Fragment及Activity之间的数据共享和通信,下面会详细介绍。
2.2 ViewModel生命周期
先来看一下官方给出的图:
图中展示了当一个Activity经过屏幕旋转后的生命周期状态改变,右侧则是ViewModel的生命周期状态。我们可以看到ViewModel的生命周期并不会跟随着Activity的生命周期变化而变化,虽然ViewModel是由该Activity创建的。我们会在源码分析部分再去看ViewModel的生命周期具体是怎样的。下面我们看下ViewModel该怎样使用?
3. 基本使用
3.1 数据存储
我们参考官方Demo实现一个计时器的功能,并且演示当屏幕发生旋转时,计时器会不会重新启动:
DemoViewModel
class DemoViewModel : ViewModel()
var time: Long? = null
var seekbarValue = MutableLiveData<Int>()
ViewModelFragment
class ViewModelFragment : Fragment()
override fun onCreateView(
inflater: LayoutInflater, container: ViewGroup?,
savedInstanceState: Bundle?
): View?
return inflater.inflate(R.layout.fragment_view_model, container, false)
override fun onActivityCreated(savedInstanceState: Bundle?)
super.onActivityCreated(savedInstanceState)
val vm = ViewModelProviders.of(this).get(DemoViewModel::class.java)
if (vm.time == null)
vm.time = SystemClock.elapsedRealtime()
chronometer.base = vm.time!!
chronometer.start()
btn_fragment_share.setOnClickListener
findNavController().navigate(R.id.viewModelShareActivity)
代码很简单,只是在ViewModel中存储了一个time
值,在fragment中启动计时器,当我们旋转屏幕的时候你会发现,计时器的值并没有变化,仍然按照旋转之前的数值进行计数。
3.2 Fragment数据共享
在ViewModelShareActivity中展示了ViewModel中的数据进行Fragment数据共享的功能。
在之前的DemoViewModel中我们存储了seekbar
的值,然后我们看Fragment中是怎么实现的?
class DataShareFragment : Fragment()
private lateinit var mViewModel: DemoViewModel
override fun onCreateView(
inflater: LayoutInflater, container: ViewGroup?,
savedInstanceState: Bundle?
): View?
mViewModel = ViewModelProviders.of(activity!!).get(DemoViewModel::class.java)
return inflater.inflate(R.layout.fragment_data_share, container, false)
override fun onActivityCreated(savedInstanceState: Bundle?)
super.onActivityCreated(savedInstanceState)
subscribeSeekBar()
private fun subscribeSeekBar()
// 监听SeekBar改变ViewModel的中的值
seekBar.setOnSeekBarChangeListener(object : SeekBar.OnSeekBarChangeListener
override fun onProgressChanged(seekBar: SeekBar, progress: Int, fromUser: Boolean)
if (fromUser)
mViewModel.seekbarValue.value = progress
override fun onStartTrackingTouch(seekBar: SeekBar)
override fun onStopTrackingTouch(seekBar: SeekBar)
)
// 当ViewModel中的值发生变化时,更新SeekBar
activity?.let
mViewModel.seekbarValue.observe(it, Observer<Int> value ->
if (value != null)
seekBar.progress = value
)
看代码其实挺简单的,只做了两个操作:
- 监听SeekBar改变ViewModel的中的值
- 当ViewModel中的值发生变化时,更新SeekBar
同样,当旋转屏幕之后,SeekBar的值也不会改变。到这里ViewModel的基本使用方式我们已经了解了,接下来我们来分析一下它具体是怎么实现的?
没错,又到了源码分析的部分了,相信很多童鞋也都比较不喜欢源码的部分,包括我也是,之前很不愿意去看源码,但是当你尝试看了一些源码之后,你会发现很有意思的,因为有些东西你是有必要去分析源码实现的,这是作为一个开发者必备的基本的素质,而且当你使用一个组件的时候,一步一步的跟着代码走,慢慢的分析了整个的组件设计方式,最后站在开发这个组件的角度,去看他的设计思想和一些模式的时候,对自己本身也是一个很大的提高,所以我真的建议有兴趣的可以跟着自己的思路一步一步的看下源码。好了废话不多说。
4. 源码分析
ViewModelProviders
在使用VM的时候一般都通过val vm = ViewModelProviders.of(this).get(DemoViewModel::class.java)
去创建,具体来看一下of方法:
@NonNull
@MainThread
public static ViewModelProvider of(@NonNull Fragment fragment, @Nullable Factory factory)
Application application = checkApplication(checkActivity(fragment));
if (factory == null)
factory = ViewModelProvider.AndroidViewModelFactory.getInstance(application);
return new ViewModelProvider(fragment.getViewModelStore(), factory);
of方法通过ViewModelProvider中的一个单例AndroidViewModelFactory创建了Factory帮助我们去创建VM,并且返回了一个ViewModelProvider。大家注意一下第一个参数fragment.getViewModelStore()
,这个ViewModelStore是什么呢?接着看
public class ViewModelStore
private final HashMap<String, ViewModel> mMap = new HashMap<>();
//存储VM
final void put(String key, ViewModel viewModel)
ViewModel oldViewModel = mMap.put(key, viewModel);
if (oldViewModel != null)
oldViewModel.onCleared();
final ViewModel get(String key)
return mMap.get(key);
Set<String> keys()
return new HashSet<>(mMap.keySet());
/**
* Clears internal storage and notifies ViewModels that they are no longer used.
*/
public final void clear()
for (ViewModel vm : mMap.values())
vm.clear();
mMap.clear();
其实就是一个存储VM的容器,里面通过HashMap进行存和取。
下面我们看创建VM时的get()
方法
@NonNull
@MainThread
public <T extends ViewModel> T get(@NonNull String key, @NonNull Class<T> modelClass)
//在ViewModelStore中拿到VM实例
ViewModel viewModel = mViewModelStore.get(key);
if (modelClass.isInstance(viewModel))
//noinspection unchecked
return (T) viewModel;
else
//noinspection StatementWithEmptyBody
if (viewModel != null)
// TODO: log a warning.
//工厂创建VM,并保存VM
if (mFactory instanceof KeyedFactory)
viewModel = ((KeyedFactory) (mFactory)).create(key, modelClass);
else
viewModel = (mFactory).create(modelClass);
mViewModelStore.put(key, viewModel);
//noinspection unchecked
return (T) viewModel;
get()
方法就是获取VM实例的过程,如果VM不存在,则通过工厂去创建实例。具体工厂创建实现:
public static class AndroidViewModelFactory extends ViewModelProvider.NewInstanceFactory
private static AndroidViewModelFactory sInstance;
/**
* Retrieve a singleton instance of AndroidViewModelFactory.
*
* @param application an application to pass in @link AndroidViewModel
* @return A valid @link AndroidViewModelFactory
*/
@NonNull
public static AndroidViewModelFactory getInstance(@NonNull Application application)
if (sInstance == null)
sInstance = new AndroidViewModelFactory(application);
return sInstance;
private Application mApplication;
/**
* Creates a @code AndroidViewModelFactory
*
* @param application an application to pass in @link AndroidViewModel
*/
public AndroidViewModelFactory(@NonNull Application application)
mApplication = application;
@NonNull
@Override
public <T extends ViewModel> T create(@NonNull Class<T> modelClass)
if (AndroidViewModel.class.isAssignableFrom(modelClass))
//noinspection TryWithIdenticalCatches
try
return modelClass.getConstructor(Application.class).newInstance(mApplication);
.......
return super.create(modelClass);
这个工厂就很简单了,就是通过反射来创建VM实例。
到这里VM的创建过程就差不多了,而我们发现他并没有和生命周期有什么相关的东西,或者说VM是怎样保证的的数据不被销毁的呢?看了网上的一些文章,很多都说在of
方法的时候传入了Fragment,并且通过HolderFragment持有ViewModelStore对象等等……比如:
但是在我这里发现跟他们的都不一样,我搜了一下ViewModelStores,发现它已经‘退役’了。
并且它的注释也告诉了我们它的继承者:
也就是我们在of()
方法中的:
也就是说谷歌已经将ViewModelStore集成到了Fragment中,一起去看一下吧:
Fragment.java
@NonNull
@Override
public ViewModelStore getViewModelStore()
if (mFragmentManager == null)
throw new IllegalStateException("Can't access ViewModels from detached fragment");
return mFragmentManager.getViewModelStore(this);
FragmentManagerImpl.java
private FragmentManagerViewModel mNonConfig;
......
@NonNull
ViewModelStore getViewModelStore(@NonNull Fragment f)
return mNonConfig.getViewModelStore(f);
我们可以看到代码到了我们熟悉的FragmentManagerImpl,它的里面持有了一个FragmentManagerViewModel实例,进去看看这个是个什么东西:
FragmentManagerViewModel.java
class FragmentManagerViewModel extends ViewModel
//创建FragmentVM的工厂
private static final ViewModelProvider.Factory FACTORY = new ViewModelProvider.Factory()
@NonNull
@Override
@SuppressWarnings("unchecked")
public <T extends ViewModel> T create(@NonNull Class<T> modelClass)
FragmentManagerViewModel viewModel = new FragmentManagerViewModel(true);
return (T) viewModel;
;
//从viewModelProvider中获取FragmentVM实例
@NonNull
static FragmentManagerViewModel getInstance(ViewModelStore viewModelStore)
ViewModelProvider viewModelProvider = new ViewModelProvider(viewModelStore,
FACTORY);
return viewModelProvider.get(FragmentManagerViewModel.class);
//非中断的Fragment集合
private final HashSet<Fragment> mRetainedFragments = new HashSet<>();
private final HashMap<String, FragmentManagerViewModel> mChildNonConfigs = new HashMap<>();
private final HashMap<String, ViewModelStore> mViewModelStores = new HashMap<>();
private final boolean mStateAutomaticallySaved;
// Only used when mStateAutomaticallySaved is true
private boolean mHasBeenCleared = false;
// Only used when mStateAutomaticallySaved is false
private boolean mHasSavedSnapshot = false;
FragmentManagerViewModel(boolean stateAutomaticallySaved)
mStateAutomaticallySaved = stateAutomaticallySaved;
//添加非中断Fragment
boolean addRetainedFragment(@NonNull Fragment fragment)
return mRetainedFragments.add(fragment);
@NonNull
Collection<Fragment> getRetainedFragments()
return mRetainedFragments;
//是否改销毁
boolean shouldDestroy(@NonNull Fragment fragment)
if (!mRetainedFragments.contains(fragment))
// Always destroy non-retained Fragments
return true;
if (mStateAutomaticallySaved)
// If we automatically save our state, then only
// destroy a retained Fragment when we've been cleared
return mHasBeenCleared;
else
// Else, only destroy retained Fragments if they've
// been reaped before the state has been saved
return !mHasSavedSnapshot;
boolean removeRetainedFragment(@NonNull Fragment fragment)
return mRetainedFragments.remove(fragment);
//获取VMStore
@NonNull
ViewModelStore getViewModelStore(@NonNull Fragment f)
ViewModelStore viewModelStore = mViewModelStores.get(f.mWho);
if (viewModelStore == null)
viewModelStore = new ViewModelStore();
mViewModelStores.put(f.mWho, viewModelStore);
return viewModelStore;
//销毁并清空VM
void clearNonConfigState(@NonNull Fragment f)
if (FragmentManagerImpl.DEBUG)
Log.d(FragmentManagerImpl.TAG, "Clearing non-config state for " + f);
// Clear and remove the Fragment's child non config state
FragmentManagerViewModel childNonConfig = mChildNonConfigs.get(f.mWho);
if (childNonConfig != null)
childNonConfig.onCleared();
mChildNonConfigs.remove(f.mWho);
// Clear and remove the Fragment's ViewModelStore
ViewModelStore viewModelStore = mViewModelStores.get(f.mWho);
if (viewModelStore != null)
viewModelStore.clear();
mViewModelStores.remove(f.mWho);
看代码我们发现它继承了VM,并且里面保存了VMStore,也就是说保存了VM,同时清空的操作也在这里面:clearNonConfigState()
ViewModelStore.java
/**
* Clears internal storage and notifies ViewModels that they are no longer used.
*/
public final void clear()
for (ViewModel vm : mMap.values())
vm.clear();
mMap.clear();
那么到底是什么时候来清空VM的呢?也就是说clear()
是什么时候调用的呢?查看源码我们发现有两处:
- 也就是上面提到的FragmentViewModel.java里面的
clearNonConfigState()
方法,而这个方法只在一个地方被调用了:
if (DEBUG) Log.v(TAG, "movefrom CREATED: " + f);
boolean beingRemoved = f.mRemoving && !f.isInBackStack();
if (beingRemoved || mNonConfig.shouldDestroy(f))
boolean shouldClear;
if (mHost instanceof ViewModelStoreOwner)
shouldClear = mNonConfig.isCleared();
else if (mHost.getContext() instanceof Activity)
Activity activity = (Activity) mHost.getContext();
shouldClear = !activity.isChangingConfigurations();
else
shouldClear = true;
//Fragment正在被移除或者应该清空的状态下
if (beingRemoved || shouldClear)
mNonConfig.clearNonConfigState(f);
f.performDestroy();
dispatchOnFragmentDestroyed(f, false);
else
f.mState = Fragment.INITIALIZING;
这个方法是在FragmentManagerImpl.java中的
moveToState
方法里面的,这个方法是跟随着Fragment的生命周期的,当这个方法被调用时,判断两个状态beingRemoved
和shoudClear
然后调用clear()
方法。关于moveToState()
可以查看这篇文章:Fragment之底层关键操作函数moveToState
- 第二个调用的地方就是ComponentActivity.
以上是关于Android Jetpack 从使用到源码深耕数据库注解Room 从实践到原理的主要内容,如果未能解决你的问题,请参考以下文章
Android Jetpack 从使用到源码深耕调度任务组件WorkManager 从实践到原理
Android Jetpack 从使用到源码深耕数据库注解Room 从实践到原理
Android Jetpack 组建介绍——Lifecycler