android路由架构

❶ android组件化为什么使用路由

因为组件化开发，模块是作为library模块，互相之间无法找到路径，导致无法跳转，所谓路由，就是一个当行系统，可以确保各个library模块之间也可以相互跳转

❷ 一般的android开发都用到了系统架构哪些层

1：android分为四个层，从高层到低层分别是应用程序层、应用程序框架层

开发一个程序，android系统框架是层层相扣，不能分开的。 应用程序层： 这个层主要指的就是用java语言编写的运行在虚拟机上的程序，Google在最开始时就 在android系统中捆绑了一些核心的应用（核心应用的编写必须使用应用层序框架层的API框架.
2：android 开发框架有四个层，从高层到低层分别是应用程序层、应用程序框架层
android应用开发框架是 Application Framework. 其系统架构由5部分组成，分别是：linux Kernel、Android Runtime、Libraries、Application Framework、Applications。

❸ 什么是android系统，android的发展以及android的平台架构和特性

Android平台采用了整合的策略思想，包括底层Linux操作系统、中间层的中间件和上层的Java应用程序。下面我把Android的特性及其架构体系结构总结一下。

一、Android的平台特性

Android平台有如下特性：

1. 应用程序框架支持组件的重用与替换。

这样我们可以把系统中不喜欢的应用程序删除，安装我们喜欢的应用程序。

2. Dalvik虚拟机专门为移动设备进行了优化。

Android应用程序将由Java编写、编译的类文件通过DX工具转换成一种后缀名为.dex的文件来执行。Dalvik虚拟机是基于寄存器的，相对于Java虚拟机速度要快很多。

3. 内部集成浏览器基于开源的WebKit引擎。

有了内置的浏览器，这将意味着WAP应用的时代即将结束，真正的移动互联网时代已经来临，手机就是一台“小电脑”，可以在网上随意遨游。

4. 优化的图形库包括2D和3D图形库，3D图形库基于OpenGL ES 1.0。

强大的图形库给游戏开发带来福音。在3G最为重要的的应用莫过于手机上网和手机游戏。

5. SQLite用作结构化的数据存储。

6. 多媒体支持包括常见的音频、视频和静态印象文件格式

如MPEG4、H.264、MP3、AAC、AMR、JGP、PNG、GIF。

7. GSM电话（依赖于硬件）。

8. 蓝牙（Bluetooth）、EDGE、3G、WiFi（依赖于硬件）。

9. 照相机、GPS、指南针和加速度计（依赖于硬件）。

10. 丰富的开发环境包括设备模拟器、调试工具、内存及性能分析图表和Eclipse集成的开发环境插件。

Google提供了Android开发包SDK，其中包含了大量的类库和开发工具，并且针对Eclipse的可视化开发插件ADT。

二、Android平台架构

从上图我们可以看出，Android操作系统的体系结构可分为4层，由上到下依次是应用程序、应用程序框架、核心类库和Linux内核，其中第三层还包括Android运行时的环境。下面分别来讲解各个部分。

1. 程序应用

Android
连同一个核心应用程序包一起发布，该应用程序包包括E-mail客户端、SMS短消息程序、日历、地图、浏览器、联系人管理程序等。所有的应用程序都是用Java编写的。

2. 应用程序框架

开发者完全可以访问核心应用程序所使用的API框架。该应用程序框架架构用来简化组件软件的重用，任何一个应用程序都可以发布它的功能块并且任何其他的应用程序都可以使用其所发布的功能块（不过得遵循框架的安全性限制）。该应用程序重用机制使得组件可以被用户替换。

以下所有的应用程序都由一系列的服务和系统组成，包括：

1）一个可扩展的视图（Views）可以用来创建应用程序，包括列表（lists）、网络（grids）、文本框（text
boxes）、按钮（buttons），甚至是一个可嵌入的Web浏览器。

2）内容管理器（Content Providers）使得应用程序可以访问另一个应用程序的数据（如联系人数据库），或者共享它们自己的数据。

3）一个资源管理器（Resource Manager）提供非代码资源的访问，如本地字符串、图形和分层文件（layout files）。

4）一个通知管理器（Notification Manager）使得应用程序可以在状态栏中显示客户通知信息。

5）一个活动类管理器（Activity Manager）用来管理应用程序生命周期并提供常用的导航回退功能。

3. Android程序库

Android包括一个被Android系统中各种不同组件所使用的C/C++集库。该库通过Android应用程序框架为开发者提供服务。

以下是一些主要的核心库：

1）系统C库：一个从BSD继承来的标准C系统函数库（libc），专门为基于Embedded Linux的设备定制。

2）媒体库：基于PacketVideo
OpenCORE；该库支持录放，并且可以录制许多流行的音频视频格式，还有静态映像文件包括MPEG4、H.264、MP3、AAC、JPG、PNG。

3）Surface Manager：对显示子系统的管理，并且为多个应用程序提供2D和3D图层的无缝融合。

4）LibWebCore：一个最新的Web浏览器引擎，用来支持Android浏览器和一个可嵌入的Web视图。

5）SGL：一个内置的2D图形引擎。

6）3D libraries：基于OpenGL ES 1.0 APIs实现；该库可以使用硬件3D加速(如果可用）或者使用高度优化的3D软加速。

7）FreeType：位图（bitmap）和向量（vector）字体显示。

8）SQLite：一个对于所以应用程序可用、功能强劲的轻型关系型数据库引擎。

4. Android运行库

Android包括了一个核心库，该核心库提供了Java编程语言核心库的大多数功能。

每一个Android应用程序都在它自己的进程中运行，都拥有一个独立的Dalvik虚拟机实例。Dalvik是针对同时高效地运行多个VMs实现的。Dalvik虚拟机执行.dex的Dalvik可执行文件，该格式文件针对最小内存使用做了优化。该虚拟机是基于寄存器的，所有的类都是经由Java汇编器编译，然后通过SDK中的DX工具转化成.dex格式由虚拟机执行。

Dalvik虚拟机依赖于Linux的一些功能，比如线程机制和底层内存管理机制。

5. Linux内核

Android的核心系统服务依赖于Linux内核，如安全性、内存管理、进程管理、网络协议栈和驱动模型。Linux内核也同时作为硬件和软件栈之间的硬件抽象层。

❹ android系统 主要有哪几部分

android系统分为四部分，从高到低分别是：

1、Android应用层

2、Android应用框架层

3、Android系统运行层

4、Linux内核层

Android系统构架主要应用于ARM平台，但不仅限于ARM，通过编译控制，在X86、MAC等体系结构的机器上同样可以运行。

(4)android路由架构扩展阅读：

Android运行库

Android包括了一个核心库，该核心库提供了JAVA编程语言核心库的大多数功能。

每一个Android都拥有一个独立的Dalvik虚拟机实例。Dalvik被设计成一个设备可以同时高效地运行多个虚拟系统。Dalvik虚拟机执行(.dex)的Dalvik可执行文件，该格式文件针对小内存使用做了优化。

同时虚拟机是基于寄存器的，所有的类都经由JAVA编译器编译，然后通过SDK中的“dx”工具转化成.dex格式由虚拟机执行。

❺ android常用框架有哪些

android应用开发框架是 Application Framework. 其系统架构由5部分组成，分别是：Linux Kernel、Android Runtime、Libraries、Application Framework、Applications。第二部分将详细介绍这5个部分。下面自底向上分析各层。

Android架构

1、Linux Kernel

Android基于Linux 2.6提供核心系统服务，例如：安全、内存管理、进程管理、网络堆栈、驱动模型。Linux Kernel也作为硬件和软件之间的抽象层，它隐藏具体硬件细节而为上层提供统一的服务。 如果你学过计算机网络知道OSI/RM，就会知道分层的好处就是使用下层提供的服务而为上层提供统一的服务，屏蔽本层及以下层的差异，当本层及以下层发生了变化不会影响到上层。也就是说各层各尽其职，各层提供固定的SAP（Service Access Point），专业点可以说是高内聚、低耦合。 如果你只是做应用开发，就不需要深入了解Linux Kernel层。

2、Android Runtime

Android包含一个核心库的集合，提供大部分在Java编程语言核心类库中可用的功能。每一个Android应用程序是Dalvik虚拟机中的实例，运行在他们自己的进程中。Dalvik虚拟机设计成，在一个设备可以高效地运行多个虚拟机。Dalvik虚拟机可执行文件格式是.dex，dex格式是专为Dalvik设计的一种压缩格式，适合内存和处理器速度有限的系统。 大多数虚拟机包括JVM都是基于栈的，而Dalvik虚拟机则是基于寄存器的。两种架构各有优劣，一般而言，基于栈的机器需要更多指令，而基于寄存器的机器指令更大。dx 是一套工具，可以将 Java .class 转换成 .dex 格式。一个dex文件通常会有多个.class。由于dex有时必须进行最佳化，会使文件大小增加1-4倍，以ODEX结尾。 Dalvik虚拟机依赖于Linux 内核提供基本功能，如线程和底层内存管理。

3、Libraries

Android包含一个C/C++库的集合，供Android系统的各个组件使用。这些功能通过Android的应用程序框架（application framework）暴露给开发者。下面列出一些核心库： 系统C库--标准C系统库（libc）的BSD衍生，调整为基于嵌入式Linux设备 媒体库--基于PacketVideo的OpenCORE。这些库支持播放和录制许多流行的音频和视频格式，以及静态图像文件，包括MPEG4、 H.264、 MP3、 AAC、 AMR、JPG、 PNG 界面管理--管理访问显示子系统和无缝组合多个应用程序的二维和三维图形层 LibWebCore--新式的Web浏览器引擎,驱动Android 浏览器和内嵌的web视图 SGL--基本的2D图形引擎 3D库--基于OpenGL ES 1.0 APIs的实现。库使用硬件3D加速或包含高度优化的3D软件光栅 FreeType --位图和矢量字体渲染 SQLite --所有应用程序都可以使用的强大而轻量级的关系数据库引擎

4、Application Framework

通过提供开放的开发平台，Android使开发者能够编制极其丰富和新颖的应用程序。开发者可以自由地利用设备硬件优势、访问位置信息、运行后台服务、设置闹钟、向状态栏添加通知等等，很多很多。 开发者可以完全使用核心应用程序所使用的框架APIs。应用程序的体系结构旨在简化组件的重用 ，任何应用程序都能发布他的功能且任何其他应用程序可以使用这些功能（需要服从框架执行的安全限制）。这一机制允许用户替换组件。 所有的应用程序其实是一组服务和系统，包括： 视图（View）--丰富的、可扩展的视图集合，可用于构建一个应用程序。包括包括列表、网格、文本框、按钮，甚至是内嵌的网页浏览器 内容提供者（Content Providers）--使应用程序能访问其他应用程序（如通讯录）的数据，或共享自己的数据 资源管理器（Resource Manager）--提供访问非代码资源，如本地化字符串、图形和布局文件 通知管理器（Notification Manager）--使所有的应用程序能够在状态栏显示自定义警告 活动管理器（Activity Manager）--管理应用程序生命周期,提供通用的导航回退功能

5、Applications

Android装配一个核心应用程序集合，包括电子邮件客户端、SMS程序、日历、地图、浏览器、联系人和其他设置。所有应用程序都是用Java编程语言写的。更加丰富的应用程序有待我们去开发！ 从上面我们知道Android的架构是分层的，非常清晰，分工很明确。Android本身是一套软件堆迭(Software Stack)，或称为“软件迭层架构”，迭层主要分成三层：操作系统、中间件、应用程序。从上面我们也看到了开源的力量，一个个熟悉的开源软件在这里贡献了自己的一份力量。

❻ 智能路由使用android系统相比openwrt有什么优势

1）重用性好，通过Android Dalvik虚拟机将开发环境和应用与芯片方案解耦，一套APP和开发环境可用于不同的硬件，提高应用的重用性，避免重复开发。
2）安全性增强，Android继承了Linux内核的安全机制实现系统安全，并针对应用安装提供沙盒、权限、应用签名等机制，进一步实现permission机制下的应用间数据安全。
3）生态环境健康，Android系统是全球市场占有率最高的智能平台，有大量的第三方资源可以合作和使用，利于快速开发新特性。

❼ 安卓架构中最底层是哪个

Android系统构架是安卓系统的体系结构，android的系统架构和其操作系统一样，采用了分层的架构，共分为四层，从高到低分别是Android应用层，Android应用框架层，Android系统运行库层和Linux内核层。
Android系统构架主要应用于ARM平台，但不仅限于ARM，通过编译控制，在X86、MAC等体系结构的机器上同样可以运行。
中文名
安卓系统构架
外文名
Android systematic framework
Android系统架构分为四层架构，从高到低分别是应用层，应用框架层，系统运行层和Linux内核层。
Android系统体系结构
1.应用层
Android会同一系列核心应用程序包一起发布，该应用程序包包括email客户端，SMS短消息程序，日历，地图，浏览器，联系人管理程序等。它们一般都是使用Java进行编写。
2.应用框架层
开发人员也可以完全访问核心应用程序所使用的API框架。该应用程序的架构设计简化了组件的重用;任何一个应用程序都可以发布它的功能块并且任何其它的应用程序都可以使用其所发布的功能块(不过得遵循框架的安全性限制)。同样，该应用程序重用机制也使用户可以方便的替换程序组件。

❽ Android的系统架构包括哪些部分

Android一词的本义指“机器人”，最初的Android主要支持手机，后来经过开发改良，逐渐扩展到平板电脑及其他一些领域上，是首个为移动终端打造的真正的开放和完整的移动软件。

Android的系统架构和其操作系统一样，采用了分层的架构。Android分为四个层，从高层到低层分别是应用程序层、应用程序框架层、系统运行库层和Linux内核层。

一、应用程序
Android会同一系列核心应用程序包一起发布，该应用程序包包括客户端，SMS短消息程序，日历，地图，浏览器，联系人管理程序等。所有的应用程序都是使用JAVA语言编写的。

二、应用程序框架
开发人员也可以完全访问核心应用程序所使用的API框架。该应用程序的架构设计简化了组件的重用;任何一个应用程序都可以发布它的功能块并且任何其它的应用程序都可以使用其所发布的功能块（不过得遵循框架的安全性）。同样，该应用程序重用机制也使用户可以方便的替换程序组件。

三、系统运行库
Android 包含一些C/C++库，这些库能被Android系统中不同的组件使用。它们通过 Android 应用程序框架为开发者提供服务。

四、Linux内核层
Android内核是基于Linux 内核的修改的内核版本，它提供了用于支持Android平台的设备驱动。

❾ Android 6.0 策略路由

实现648 Android 6.0端与410 Linux端通过Switch通信

1. 虚拟网卡配置

648中延用638中方法在有线网络接口eth0上创建虚拟网卡eth0.1并设置ip 10.66.1.3用以与410地址10.66.1.2通信。

配置结果可通过命令“ifconfig”查看：

并且配置完成后，系统路由表中会自动多出一条路由：

2. Android M 多网络共存

经过步骤一的配置之后在638 Android 4.4系统上即可与410建立通信；但在648 Android 6.0上是不通的。此问题查询了很长时间终于有了解决方案，且听我细细道来。

Android4.4只使用了一张路由表，使用busybox route就可以完成路由表的设置，从Android5.0之后，考虑要对多网络的支持，采用了多路由表。Android 5.0(LOLLIPOP)以上，在同一时间下，Android系统可以允许多网络类型连接，而且并不是简单的网络共存，而是每个网络有一套自己的dns，网关，路由表。比如eth0，wlan0分别有自己独立的一套。应用层在建立socket连接的时候，可以自由选择使用那套网络；在这样子的前提下，你就可以选择究竟采用那种网络来完成你的请求。这里还涉及到另一个新的概念不同网络的标识netid，应用层可通过绑定指定的netid来设置该应用走指定的网络，但此处暂不赘述有兴趣可自己了解。在Android 5.0(LOLLIPOP)之前，在同一时间下，Android系统只能允许一种网络类型连接。之后在多网络的情况下，系统是如何选择的呢？这就需要引入一个关键名词“策略路由”。

策略路由在linux中已经存在很久，但是Android5.0开始才真正将其作用发挥出来。策略路由区别于一般的路由就在于，一般的路由是以目的地址作为识别与区分的标识，例如下面这个路由表，它表示所有目的地址为192.168.7.0/24的数据包都直接从eth0发出

当面对比较复杂的情况时，这种基于目的地址的路由，就很受局限。例如：有两个网卡eth0, eth1，希望所有http上网数据从eth0出去，FTP数据从eth1出去。这种情况就必须要策略路由才能处理。

策略路由的基本命令：

648上策略路由信息：

各部分解释

整行的意思就是，如果一个数据包符合规则（源地址、目的地址、协议、端口、数据包大小、内容等），则使用指定路由表。

系统最多支持255个路由表：

在默认情况下进行路由时，首先会根据规则0在本地路由表里寻找路由，如果目的地址是本网络，或是广播地址的话，在这里就可以找到合适的路由；从这个路由规则中可以看到， 路由表 local优先，然后是netid 对应 0x10064 的走 eth0 路由表，对应 0x10066 走 eth0 路由表。而通常情况下访问网络时没有设置 netid，默认就使用 22000: from all fwmark 0x0/0xffff lookup eth0 这个，即 eth0 路由表。

有了策略路由，就可以保证当多网卡存在是，每个网卡有自己的路由表，为多网卡共存提供路由基础。上层应用，可以选择要经过的路由。

此处没有走eth0.1到10.66.1.2的路由策略，需添加：

3. Linux 路由与策略路由

Linux是在内核2.1开始采用策略性路由机制的。策略性路由机制与传统的路由算法相比主要是引入了上面的多路由表以及规则的概念。

要配置一个策略路由有2步：

1、在自定义路由表中添加要走的路由 ip route add xxx table table_num

2、增加策略，使得符合该策略的流量走第一步所定义的路由表 ip rule add 策略 【table tablenum 或 动作】。

传统的linux路由是由一张路由表去保存网络链路上的路由信息的。新的linux策略路由的理念是使用多张路由表去保存路由信息。何为策略路由呢，就是为不用的数据包制定不同的路由策略，即在IP路选时走不同的路由。

在策略路由机制中，可以支持多张路由表，最多可支持255张表。其中4张是内置路由表，如下：

策略路由的作用

1 基于源地址选路（ Source-Sensitive Routing）

2 根据服务级别选路（ Quality of Service）

3 节省费用的应用

4 负载平衡（Load Sharing）

❿ 如何构建Android MVVM 应用框架

概述
说到Android MVVM，相信大家都会想到Google 2015年推出的DataBinding框架。然而两者的概念是不一样的，不能混为一谈。MVVM是一种架构模式，而DataBinding是一个实现数据和UI绑定的框架，是构建MVVM模式的一个工具。
之前看过很多关于Android MVVM的博客，但大多数提到的都是DataBinding的基本用法，很少有文章仔细讲解在Android中是如何通过DataBinding去构建MVVM的应用框架的。View、ViewModel、Model每一层的职责如何?它们之间联系怎样、分工如何、代码应该如何设计?这是我写这篇文章的初衷。
接下来，我们先来看看什么是MVVM，然后再一步一步来设计整个MVVM框架。
MVC、MVP、MVVM
首先，我们先大致了解下Android开发中常见的模式。
MVC
View：XML布局文件。
Model：实体模型(数据的获取、存储、数据状态变化)。
Controllor：对应于Activity，处理数据、业务和UI。
从上面这个结构来看，Android本身的设计还是符合MVC架构的，但是Android中纯粹作为View的XML视图功能太弱，我们大量处理View的逻辑只能写在Activity中，这样Activity就充当了View和Controller两个角色，直接导致Activity中的代码大爆炸。相信大多数Android开发者都遇到过一个Acitivty数以千行的代码情况吧!所以，更贴切的说法是，这个MVC结构最终其实只是一个Model-View(Activity:View&Controller)的结构。
MVP
View: 对应于Activity和XML，负责View的绘制以及与用户的交互。
Model: 依然是实体模型。
Presenter: 负责完成View与Model间的交互和业务逻辑。
前面我们说，Activity充当了View和Controller两个角色，MVP就能很好地解决这个问题，其核心理念是通过一个抽象的View接口(不是真正的View层)将Presenter与真正的View层进行解耦。Persenter持有该View接口，对该接口进行操作，而不是直接操作View层。这样就可以把视图操作和业务逻辑解耦，从而让Activity成为真正的View层。
但MVP也存在一些弊端：
Presenter(以下简称P)层与View(以下简称V)层是通过接口进行交互的，接口粒度不好控制。粒度太小，就会存在大量接口的情况，使代码太过碎版化;粒度太大，解耦效果不好。同时对于UI的输入和数据的变化，需要手动调用V层或者P层相关的接口，相对来说缺乏自动性、监听性。如果数据的变化能自动响应到UI、UI的输入能自动更新到数据，那该多好!
MVP是以UI为驱动的模型，更新UI都需要保证能获取到控件的引用，同时更新UI的时候要考虑当前是否是UI线程，也要考虑Activity的生命周期(是否已经销毁等)。
MVP是以UI和事件为驱动的传统模型，数据都是被动地通过UI控件做展示，但是由于数据的时变性，我们更希望数据能转被动为主动，希望数据能更有活性，由数据来驱动UI。
V层与P层还是有一定的耦合度。一旦V层某个UI元素更改，那么对应的接口就必须得改，数据如何映射到UI上、事件监听接口这些都需要转变，牵一发而动全身。如果这一层也能解耦就更好了。
复杂的业务同时也可能会导致P层太大，代码臃肿的问题依然不能解决。
MVVM
View: 对应于Activity和XML，负责View的绘制以及与用户交互。
Model: 实体模型。
ViewModel: 负责完成View与Model间的交互，负责业务逻辑。
MVVM的目标和思想与MVP类似，利用数据绑定(Data Binding)、依赖属性(Dependency Property)、命令(Command)、路由事件(Routed Event)等新特性，打造了一个更加灵活高效的架构。
数据驱动
在常规的开发模式中，数据变化需要更新UI的时候，需要先获取UI控件的引用，然后再更新UI。获取用户的输入和操作也需要通过UI控件的引用。在MVVM中，这些都是通过数据驱动来自动完成的，数据变化后会自动更新UI，UI的改变也能自动反馈到数据层，数据成为主导因素。这样MVVM层在业务逻辑处理中只要关心数据，不需要直接和UI打交道，在业务处理过程中简单方便很多。
低耦合度
MVVM模式中，数据是独立于UI的。
数据和业务逻辑处于一个独立的ViewModel中，ViewModel只需要关注数据和业务逻辑，不需要和UI或者控件打交道。UI想怎么处理数据都由UI自己决定，ViewModel不涉及任何和UI相关的事，也不持有UI控件的引用。即便是控件改变了(比如：TextView换成EditText)，ViewModel也几乎不需要更改任何代码。它非常完美的解耦了View层和ViewModel，解决了上面我们所说的MVP的痛点。
更新UI
在MVVM中，数据发生变化后，我们在工作线程直接修改(在数据是线程安全的情况下)ViewModel的数据即可，不用再考虑要切到主线程更新UI了，这些事情相关框架都帮我们做了。
团队协作
MVVM的分工是非常明显的，由于View和ViewModel之间是松散耦合的：一个是处理业务和数据、一个是专门的UI处理。所以，完全由两个人分工来做，一个做UI(XML和Activity)一个写ViewModel，效率更高。
可复用性
一个ViewModel可以复用到多个View中。同样的一份数据，可以提供给不同的UI去做展示。对于版本迭代中频繁的UI改动，更新或新增一套View即可。如果想在UI上做A/B Testing，那MVVM是你不二选择。
单元测试
有些同学一看到单元测试，可能脑袋都大。是啊，写成一团浆糊的代码怎么可能做单元测试?如果你们以代码太烂无法写单元测试而逃避，那可真是不好的消息了。这时候，你需要MVVM来拯救。
我们前面说过了，ViewModel层做的事是数据处理和业务逻辑，View层中关注的是UI，两者完全没有依赖。不管是UI的单元测试还是业务逻辑的单元测试，都是低耦合的。在MVVM中数据是直接绑定到UI控件上的(部分数据是可以直接反映出UI上的内容)，那么我们就可以直接通过修改绑定的数据源来间接做一些Android UI上的测试。
通过上面的简述以及模式的对比，我们可以发现MVVM的优势还是非常明显的。虽然目前Android开发中可能真正在使用MVVM的很少，但是值得我们去做一些探讨和调研。
如何构建MVVM应用框架
如何分工
构建MVVM框架首先要具体了解各个模块的分工。接下来我们来讲解View、ViewModel、Model它们各自的职责所在。
View
View层做的就是和UI相关的工作，我们只在XML、Activity和Fragment写View层的代码，View层不做和业务相关的事，也就是我们在Activity不写业务逻辑和业务数据相关的代码，更新UI通过数据绑定实现，尽量在ViewModel里面做(更新绑定的数据源即可)，Activity要做的事就是初始化一些控件(如控件的颜色，添加RecyclerView的分割线)，View层可以提供更新UI的接口(但是我们更倾向所有的UI元素都是通过数据来驱动更改UI)，View层可以处理事件(但是我们更希望UI事件通过Command来绑定)。简单地说：View层不做任何业务逻辑、不涉及操作数据、不处理数据，UI和数据严格的分开。
ViewModel
ViewModel层做的事情刚好和View层相反，ViewModel只做和业务逻辑和业务数据相关的事，不做任何和UI相关的事情，ViewModel 层不会持有任何控件的引用，更不会在ViewModel中通过UI控件的引用去做更新UI的事情。ViewModel就是专注于业务的逻辑处理，做的事情也都只是对数据的操作(这些数据绑定在相应的控件上会自动去更改UI)。同时DataBinding框架已经支持双向绑定，让我们可以通过双向绑定获取View层反馈给ViewModel层的数据，并对这些数据上进行操作。关于对UI控件事件的处理，我们也希望能把这些事件处理绑定到控件上，并把这些事件的处理统一化，为此我们通过BindingAdapter对一些常用的事件做了封装，把一个个事件封装成一个个Command，对于每个事件我们用一个ReplyCommand去处理就行了，ReplyCommand会把你可能需要的数据带给你，这使得我们在ViewModel层处理事件的时候只需要关心处理数据就行了，具体见MVVM Light Toolkit 使用指南的 Command 部分。再强调一遍：ViewModel 不做和UI相关的事。
Model
Model层最大的特点是被赋予了数据获取的职责，与我们平常Model层只定义实体对象的行为截然不同。实例中，数据的获取、存储、数据状态变化都是Model层的任务。Model包括实体模型(Bean)、Retrofit的Service ，获取网络数据接口，本地存储(增删改查)接口，数据变化监听等。Model提供数据获取接口供ViewModel调用，经数据转换和操作并最终映射绑定到View层某个UI元素的属性上。
如何协作
关于协作，我们先来看下面的一张图：

上图反映了MVVM框架中各个模块的联系和数据流的走向，我们从每个模块一一拆分来看。那么我们重点就是下面的三个协作。
ViewModel与View的协作。
ViewModel与Model的协作。
ViewModel与ViewModel的协作。
ViewModel与View的协作

图2中ViewModel和View是通过绑定的方式连接在一起的，绑定分成两种：一种是数据绑定，一种是命令绑定。数据的绑定DataBinding已经提供好了，简单地定义一些ObservableField就能把数据和控件绑定在一起了(如TextView的text属性)，但是DataBinding框架提供的不够全面，比如说如何让一个URL绑定到一个ImageView，让这个ImageView能自动去加载url指定的图片，如何把数据源和布局模板绑定到一个ListView，让ListView可以不需要去写Adapter和ViewHolder相关的东西?这些就需要我们做一些工作和简单的封装。MVVM Light Toolkit 已经帮我们做了一部分的工作，详情可以查看MVVM Light Toolkit 使用指南。关于事件绑定也是一样，MVVM Light Toolkit 做了简单的封装，对于每个事件我们用一个ReplyCommand去处理就行了，ReplyCommand会把可能需要的数据带给你，这样我们处理事件的时候也只关心处理数据就行了。
由图1中ViewModel的模块中我们可以看出ViewModel类下面一般包含下面5个部分：
Context (上下文)
Model (数据源 Java Bean)
Data Field (数据绑定)
Command (命令绑定)
Child ViewModel (子ViewModel)
我们先来看下示例代码，然后再一一讲解5个部分是干嘛用的：
//contextprivate Activity context;//model（数据源 Java Bean）private NewsService.News news;private TopNewsService.News topNews;//数据绑定，绑定到UI的字段（data field）public final ObservableField<String> imageUrl = new ObservableField<>();public final ObservableField<String> html = new ObservableField<>();public final ObservableField<String> title = new ObservableField<>();// 一个变量包含了所有关于View Style 相关的字段public final ViewStyle viewStyle = new ViewStyle();//命令绑定（command）public final ReplyCommand onRefreshCommand = new ReplyCommand<>(() -> {

})public final ReplyCommand<Integer> onLoadMoreCommand = new ReplyCommand<>((itemCount) -> {

});//Child ViewModelpublic final ObservableList<NewItemViewModel> itemViewModel = new ObservableArrayList<>();/** * ViewStyle 关于控件的一些属性和业务数据无关的Style 可以做一个包裹，这样代码比较美观，
ViewModel 页面也不会有太多太杂的字段。 **/public static class ViewStyle {
public final ObservableBoolean isRefreshing = new ObservableBoolean(true);
public final ObservableBoolean progressRefreshing = new ObservableBoolean(true);
}
Context