关于ViewModel

ViewModel是Android原生Jetpack指导框架成员之一,Google在IO大会上发布了一系列的框架组件，目的在于帮助统一应用开发过程中，Android开发者面临框架多样，结构复杂的个人框架。

有空的同学可以继续深入查看Jetpack

1.问题:他是如何能够有一套相对独立的生命周期的呢?

ViewModel生命周期

我们追踪源码查看它的实现和构建过程

在ViewModelProviders中的of方法中，暗藏玄机

of方法 获取HolderFragment

是的，你没有看错，ViewModel 它的一个壳是一个HolderFragment.

我们跟踪HolderFragment可以看到更多的信息关于ViewModel的其他实现

_1.它的构造方法,唯独设置了一个方法setRetainInstance(boolean)

HolderFragment构造方法

我们查看Fragment源码查看这个方法的作用，字面上翻译就是保持实例

setRetainInstance官方文档解释

简单的，也就是说Fragment在一个Activity中，当Activity在配置不断改变 重复走onCreate的时候，它保持不变 不进行create性质的响应

总结:它是一个相对独立的生命体，意味这只要Activity不被销毁，这个Fragment就“活着”，那么这也就概述了ViewModel的生命周期的核心.

2.问题:ViewModel解决了什么?

A1:解决了活动页面在不断的改变过程中数据的问题

怎么理解呢，就是一次活动，开发者不再为数据保存和数据恢复在生命周期上做很多繁重的判断

A2:彻底释放了Activity在部分场景下的职能

怎么理解呢，就是过往中，Activity在MVC和MVP中经常性的被认为是“View”的职能，他掌控了View的显示和手势捕捉，响应。这种多职能在MVC下更是复杂到极点.MVP只能算是剥离逻辑，核心还是把Activity作为View对待。

而ViewModel的出现，我认为是对Activity一次很好的“重定义”,Activity现在更像一个“导航”，它多余的职能被抛弃，或者说分散到其他组件（DataBinding是一个VM实现,在Jetpack组件中你可以把它看作“View”），Activity，Fragment更多的被明确分配职能。极大的剥离了职能分配。保证A、F的简洁高效。

A3:带来的拓展思考，我们通过Google学习到了更多用法。

定义者能更全面的告诉你使用方法和拓展。

3.给我们带来的思考

我们学习到了ViewModel的拓展和实践，我们学习到了哪些。我们该确认哪些应用场景是可以用的

其实应用场景是明白了痛点之后才有所领悟的。对于我的思考来说。

我认为在Android 6.0 动态请求权限的过程是一个ViewModel变种的绝佳应用场景

_1.动态权限请求的痛点：

    分离权限发起和权限接收回调

    权限请求流程控制复杂

    权限分析痛苦

ViewModel教会了我们更巧妙开发权限请求.

既然ViewModel是一个代理Fragment，那么我们权限请求为什么不能是一个代理Fragment呢?

基于这个想法，我们思路打开了。通过代理Fragment帮助我们完成权限请求发起，权限请求接收。修改接收模式。我们能很快的完成权限请求的一系列操作。极大提高动态权限操作的流畅性。

IPermission发起权限请求方式

框架调用起来非常方便。很好的聚合了权限请求的场景，提供了多种回调保证需要的场景。

那么我们看下基本实现思路

1.封装代理的Fragment

IPermissionDelegateFragment构建

2.配置添加需要请求的权限

准备需要请求的权限

3.发起请求

策略不同发起策略不同的请求模式

4.通过策略不同，做不同模式的策略响应

5.不同策略不同的权限结果回调

策略不同，回调的不同

想详细查看源码的同学可以到我的Github上查看:https://github.com/csxiong/IPermission

其实很多思路是站在巨人的肩膀上才能学习到的，RxPermission也是基于这么一个思路进行的封装,再结合RxJava本身对于流程封装很到位。订阅 多订阅源 单一订阅源 多种模式变换支持俱佳 合并模式。衍生出一个优质的框架 。

我吸收他人的分享，学习到了很多。我相信分享终将使我们受益。