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