Android Component Framework为我们解决了一些繁琐的问题，并勾勒出Android App开发的合理框架。也可以说是一种官方推荐的标准范式，使用这种范式编码，我们可以构建出可展性更强，逻辑更为清晰的App。因而在使用该种范式之前，我们有必要弄清楚该框架的设计思路。同时我们也应该高度重视框架给出的开发理念。的确，是一些基本的，核心的理念指导或者误导着我们的编码
1.ViewModel的设计意图是什么？
在官方给出的指导中，Actvity是作为一个自我封闭的系统组件而存在的，组件通信通过Intent，组件之间应该解耦合，最重要的是组件之间的跳转都是通过系统服务处理的。严格意义上说，组件之间是并不直接沟通的。这就会使得，组件之间的数据也应该是自我封闭的。举一个很简单的用例，ListActivity呈现一个日程列表，点击条目跳转到DetailActivity，在此可以编辑保存。就一般的做法，我们会把所选的条目信息放入Intent,传入DetailActivity，这也是标准做法。通过这种方式传递数据，就表明数据在两个Activity之间是独立的。即使在DetailActivity重新编辑了条目，数据的改变也不会如实反映到ListActivity上去。原因何在？就是数据独立导致的。
Android官方文档在讲解Activity时，着重强调了生命周期，以及对每个状态执行何种操作给出了指导。但是并没有避免程序员将大部分代码逻辑放在Activity中。在最新的Android Component Frame的指导文档中，Android Team强调了非常重要的观点--Activity只是系统与App沟通的窗口，系统随时可以销毁掉Activity，因而将代码逻辑放到Activity中是不可取的。也可以说Activity并不拥有数据，它只是负责接受数据变化，并通知UI跟新。
说到这里也应该引出这篇文章的主角ViewModel了。ViewModel处理业务逻辑，并在屏幕旋转，Activity被销毁重建的时候，依然存在。
2.ViewModel源码解析
ViewModel组件的源码相当简单，它的目的就是建立一个UI和数据的隔离带。ViewModel为Activity或Fragment提供数据访问接口，同时将UI层的指令传递给数据层。简单点说，ViewModel组件的源码就是围绕如何获取一个ViewModel来写的。ViewModelProviders.of获取ViwModelProvider，ViewModelProvider.get获取ViewModel。其中ViewModel的构造方式可以由ViewModelProviders.of的Factory参数自行定义。support包中的AppCompatActivity已经整合了LifeCycle和ViewModel组件。