android路由框架

Ⅰ android幾種網路框架的比較

現在 OkHttp 已經一統 android 的江山，但是基於 OkHttp 再次封裝的 框架層出不窮

推薦直接使用 OkHttp 的增強版本 OkHttps , 15秒便可上手，超級好用，這是官方中文文檔地址：okhttps.ejlchina.com

Ⅱ android 開發框架有哪些

主要總結了7個好用的android 開發框架推薦給你：
一、 Afinal

Afinal是一個Android的ioc，orm框架，內置了四大模塊功能：FinalAcitivity,FinalBitmap,FinalDb,FinalHttp。通過finalActivity，我們可以通過註解的方式進行綁定ui和事件。通過finalBitmap，我們可以方便的載入bitmap圖片，而無需考慮oom等問題。通過finalDB模塊，我們一行代碼就可以對android的sqlite資料庫進行增刪改查。通過FinalHttp模塊，我們可以以ajax形式請求http數據。

功能：

一個android的ioc，orm框架，內置了四大模塊功能：FinalAcitivity,FinalBitmap,FinalDb,FinalHttp。通過finalActivity，我們可以通過註解的方式進行綁定ui和事件。通過finalBitmap，我們可以方便的載入bitmap圖片，而無需考慮oom等問題。通過finalDB模塊，我們一行代碼就可以對android的sqlite資料庫進行增刪改查。通過FinalHttp模塊，我們可以以ajax形式請求http數據。

優點：功能比較全面，文檔完善，代碼效率比較高。

缺點：沒有項目demo，框架的時間比較久，代碼冗餘比較多(這也是無可避免的)，文檔比較老跟不上代碼更新進度。

二、 xUtils

xUtils：可以說是Afinal的升級版。

xUtils 包含了很多實用的android工具。

xUtils 支持大文件上傳，更全面的http請求協議支持(10種謂詞)，擁有更加靈活的ORM，更多的事件註解支持且不受混淆影響...

xUitls 最低兼容android 2.2 (api level 8)

三、 ThinkAndroid

ThinkAndroid是一個免費的開源的、簡易的、遵循Apache2開源協議發布的Android開發框架，其開發宗旨是簡單、快速的進行Android應用程序的開發，包含Android
mvc、簡易sqlite orm、ioc模塊、封裝Android
httpclitent的http模塊,具有快速構建文件緩存功能，無需考慮緩存文件的格式，都可以非常輕松的實現緩存，它還基於文件緩存模塊實現了圖片緩存功能，在android中載入的圖片的時候，對oom的問題，和對載入圖片錯位的問題都輕易解決。他還包括了一個手機開發中經常應用的實用工具類，如日誌管理，配置文件管理，android下載器模塊，網路切換檢測等等工具

四、 LoonAndroid

如果你想看ui方面的東西，這里沒有，想要看牛逼的效果這里也沒有。這只是純實現功能的框架，它的目標是節省代碼量，降低耦合，讓代碼層次看起來更清晰。整個框架一部分是網上的，一部分是我改的，為了適應我的編碼習慣，還有一部分像orm完全是網上的組件。在此感謝那些朋友們。
整個框架式的初衷是為了偷懶，之前都是一個功能一個jar，做項目的時候拉進去，這樣對於我來說依然還是比較麻煩。最後就導致我把所有的jar做成了一個工具集合包。
有很多框架都含有這個工具集合里的功能，這些不一定都好用，因為這是根據我個人使用喜歡來實現的，如果你們有自己的想法，可以自己把架包解壓了以後，源碼拉出來改動下。
目前很多框架都用到了註解，除了androidannotations沒有入侵我們應用的代碼以外，其他的基本上都有，要麼是必須繼承框架裡面的activity,要麼是必須在activity的oncreat裡面調用某個方法。
整個框架式不同於androidannotations，Roboguice等ioc框架，這是一個類似spring的實現方式。在整應用的生命周期中找到切入點，然後對activity的生命周期進行攔截，然後插入自己的功能。

五、 KJFrameForAndroid

KJFrameForAndroid 又叫KJLibrary，是一個android的orm 和 ioc
框架。同時封裝了android中的Bitmap與Http操作的框架，使其更加簡單易用;

KJFrameForAndroid的設計思想是通過封裝Android原生SDK中復雜的復雜操作而達到簡化Android應用級開發，最終實現快速而又安全的開發APP。我們提倡用最少的代碼，完成最多的操作，用最高的效率，完成最復雜的功能。

功能：

一個android的orm 和 ioc 框架。同時封裝了android中的Bitmap與Http操作的框架，使其更加簡單易用;
KJFrameForAndroid開發框架的設計思想是通過封裝Android原生SDK中復雜的復雜操作而達到簡化Android應用級開發，最終實現快速而又安全的開發APP。總共分為五大模塊：UILibrary，UtilsLibrary，HttpLibrary，BitmapLibrary，DBLibrary。

六、 dhroid

dhroid 是基於android 平台,
極速開發框架，其核心設計目標是開發迅速、代碼量少、學習簡單、功能強大、輕量級、易擴展.使你更快,更好的開發商業級別應用

功能：

1.Ioc容器: (用過spring的都知道)視圖注入,對象注入,介面注入,解決類依賴關系

2.Eventbus: android平台事件匯流排框架,獨創延時事件,事件管理輕松

3.Dhnet: 網路http請求的解決方案,使用簡單,減少代碼,自帶多種網路訪問緩存策略

4.adapter模塊: 數據綁定輕松,不用寫多餘的adapter,天生網路支持(一行代碼搞定載入,刷新問題)

5.DhDb: android中sqlite的最輕量orm框架(增刪改查輕松搞定)

6.Perference: android自帶Perference 升級版,讓你的Perference更強大,更方便

工具集合 JSONUtil(安全處理json),ViewUtil(數據綁定更快) ThreadWorker(非同步任務工具)...

七、 SmartAndroid

SmartAndroid是一套給
Android開發者使用的應用程序開發框架和工具包。它提供一套豐富的標准庫以及簡單的介面和邏輯結構，其目的是使開發人員更快速地進行項目開發。使用
SmartAndroid可以減少代碼的編寫量，並將你的精力投入到項目的創造性開發上。

功能：

SmartAndroid 擁有全范圍的類庫，可以完成大多數通常需要的APP開發任務，包括：
非同步網路操作相關所有功能、強大的圖片處理操作、輕量級ORM資料庫Sqlite庫、zip操作
、動畫特效、Html等解析採集、事件匯流排EventBus/Otto、Gson(Json)、AQuery、主流所有UI控制項(例如：ActionbarSherlock，SlidingMenu，BottomView，Actionbar，DragListView等10多種UI庫)等。

Ⅲ 請教個關於 Android 路由表的問題

一：使用 route 命令添加

使用route 命令添加的路由，機器重啟或者網卡重啟後路由就失效了，方法：

//添加到主機的路由

# route add –host 192.168.168.110 dev eth0

# route add –host 192.168.168.119 gw 192.168.168.1

//添加到網路的路由

# route add –net IP netmask MASK eth0

# route add –net IP netmask MASK gw IP

# route add –net IP/24 eth1

//添加默認網關

# route add default gw IP

//刪除路由

# route del –host 192.168.168.110 dev eth0

二：在linux下設置永久路由的方法：

1.在/etc/rc.local里添加

方法：

route add -net 192.168.3.0/24 dev eth0

route add -net 192.168.2.0/24 gw 192.168.3.254

2.在/etc/sysconfig/network里添加到末尾

方法：GATEWAY=gw-ip 或者 GATEWAY=gw-dev

3./etc/sysconfig/static-router :

any net x.x.x.x/24 gw y.y.y.y

第三種
使用Linux+Zebra構建軟路由系統Zebra是一種TCP/IP路由軟體，它支持BGP-4、BGP-4+、OSPFv2、OSPFv3、RIPv1、RIPv2和RIPng。它符合GNU的GPL標准，可以運行在Linux和其它Unix變體系統上。Zebra是最先進的路由軟體之一，最新版本可以從GUN
Zebra Web站點上下載。

詳細代碼詳細代碼

Ⅳ 如何構建Android MVVM 應用框架

我們先來看看什麼是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 會把你可能需要的數據帶給你，這使得我們在Vie，具體見 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 做了簡單的封裝，對於每個事件我們用一個ReplyCommand去處理就行了，ReplyCommand 會把可能需要的數據帶給你，這樣我們處理事件的時候也只關心處理數據就行了.
由 圖 1 中ViewModel的模塊中我們可以看出ViewModel類下面一般包含下面5個部分：
Context （上下文）
Model (數據源 java Bean)
Data Field （數據綁定）
Command （命令綁定）
Child ViewModel （子ViewModel）
我們先來看下示例代碼，然後再一一講解5個部分是幹嘛用的：
//context
private 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 ViewModel
public 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
Context是幹嘛用的呢，為什麼每個ViewModel都最好需要持了一個Context的引用呢？ViewModel不處理和UI相關的事也不操作控制項，更不更新UI，那為什麼要有Context呢？原因
Model是什麼呢？其實就是數據源，可以簡單理解是我們用JSON轉過來的Bean。ViewModel要把數據映射到UI中可能需要大量對Model的數據拷貝和操作，拿Model的欄位去生成對應的ObservableField然後綁定到UI（我們不會直接拿Model的數據去做綁定展示），這里是有必要在一個ViewModel保留原始的Model引用，這對於我們是非常有用的，因為可能用戶的某些操作和輸入需要我們去改變數據源，可能我們需要把一個Bean在列表頁點擊後傳給詳情頁，可能我們需要把這個Model當做表單提交到伺服器。這些都需要我們的ViewModel持有相應的Model（數據源）。
Data Field（數據綁定）
Data Field就是需要綁定到控制項上的ObservableField欄位，這是ViewModel的必需品，這個沒有什麼好說。但是這邊有一個建議：
這些欄位是可以稍微做一下分類和包裹的。比如說可能一些欄位是綁定到控制項的一些Style屬性上（如長度、顏色、大小），對於這類針對View Style的的欄位可以聲明一個ViewStyle類包裹起來，這樣整個代碼邏輯會更清晰一些，不然ViewModel裡面可能欄位泛濫，不易管理和閱讀性較差。而對於其他一些欄位，比如說title、imageUrl、name這些屬於數據源類型的欄位，這些欄位也叫數據欄位，是和業務數據和邏輯息息相關的，這些欄位可以放在一塊。
Command（命令綁定）
Command（命令綁定）簡言之就是對事件的處理（下拉刷新、載入更多、點擊、滑動等事件處理）。我們之前處理事件是拿到UI控制項的引用，然後設置Listener，這些Listener其實就是Command。但是考慮到在一個ViewModel寫各種Listener並不美觀，可能實現一個Listener就需要實現多個方法，但是我們可能只想要其中一個有用的方法實現就好了。更重要一點是實現一個Listener可能需要寫一些UI邏輯才能最終獲取我們想要的。簡單舉個例子，比如你想要監聽ListView滑到最底部然後觸發載入更多的事件，這時候就要在ViewModel裡面寫一個OnScrollListener，然後在裡面的onScroll方法中做計算，計算什麼時候ListView滑動底部了。其實ViewModel的工作並不想去處理這些事件，它專注做的應該是業務邏輯和數據處理，如果有一個東西不需要你自己去計算是否滑到底部，而是在滑動底部自動觸發一個Command，同時把當前列表的總共的item數量返回給你，方便你通過 page=itemCount/LIMIT+1去計算出應該請求伺服器哪一頁的數據那該多好啊。MVVM Light Toolkit 幫你實現了這一點：
public final ReplyCommand<Integer> onLoadMoreCommand = new ReplyCommand<>((itemCount) -> {
int page=itemCount/LIMIT+1;
loadData(page.LIMIT)
});

接著在XML布局文件中通過bind:onLoadMoreCommand綁定上去就行了。
<android.support.v7.widget.RecyclerView
android:layout_width="match_parent"
android:layout_height="match_parent"
bind:onLoadMoreCommand="@{viewModel.loadMoreCommand}"/>
x

當然Command並不是必須的，你完全可以依照自己的習慣和喜好在ViewModel寫Listener，不過使用Command可以使ViewModel更簡潔易讀。你也可以自己定義更多的、其他功能的Command，那麼ViewModel的事件處理都是託管ReplyCommand 來處理，這樣的代碼看起來會比較美觀和清晰。Command只是對UI事件的一層隔離UI層的封裝，在事件觸發時把ViewModel層可能需要的數據傳給ViewModel層，對事件的處理做了統一化，是否使用的話，還是看你個人喜好了。
Child ViewModel（子ViewModel）
子ViewModel的概念就是在ViewModel裡面嵌套其他的ViewModel，這種場景還是很常見的。比如說你一個Activity裡面有兩個Fragment，ViewModel是以業務劃分的，兩個Fragment做的業務不一樣，自然是由兩個ViewModel來處理，這時候Activity對應的ViewModel裡面可能包含了兩個Fragment各自的ViewModel，這就是嵌套的子ViewModel。還有另外一種就是對於AdapterView，如ListView RecyclerView、ViewPager等。
//Child ViewModelpublic final
ObservableList<ItemViewModel> itemViewModel = new ObservableArrayList<>();

它們的每個Item其實就對應於一個ViewModel，然後在當前的ViewModel通過ObservableList 持有引用（如上述代碼），這也是很常見的嵌套的子ViewModel。我們其實還建議，如果一個頁面業務非常復雜，不要把所有邏輯都寫在一個ViewModel，可以把頁面做業務劃分，把不同的業務放到不同的ViewModel，然後整合到一個總的ViewModel，這樣做起來可以使我們的代碼業務清晰、簡短意賅，也方便後人的維護。
總的來說，ViewModel和View之前僅僅只有綁定的關系，View層需要的屬性和事件處理都是在XML裡面綁定好了，ViewModel層不會去操作UI，只是根據業務要求處理數據，這些數據自動映射到View層控制項的屬性上。關於ViewModel類中包含哪些模塊和欄位，這個需要開發者自己去衡量，我們建議ViewModel不要引入太多的成員變數，成員變數最好只有上面的提到的5種（context、model……），能不引入其他類型的變數就盡量不要引進來，太多的成員變數對於整個代碼結構破壞很大，後面維護的人要時刻關心成員變數什麼時候被初始化、什麼時候被清掉、什麼時候被賦值或者改變，一個細節不小心可能就出現潛在的Bug。太多不清晰定義的成員變數又沒有注釋的代碼是很難維護的。
另外，我們會把UI控制項的屬性和事件都通過XML（如bind：text=@{...}）綁定。如果一個業務邏輯要彈一個Dialog，但是你又不想在ViewModel裡面做彈窗的事（ViewModel不希望做UI相關的事）或者說改變ActionBar上面的圖標的顏色，改變ActionBar按鈕是否可點擊，這些都不是寫在XML裡面（都是用Java代碼初始化的），如何對這些控制項的屬性做綁定呢？我們先來看下代碼：
public class MainViewModel implements ViewModel {
....
//true的時候彈出Dialog，false的時候關掉dialog
public final ObservableBoolean isShowDialog = new ObservableBoolean();
....
.....
}
// 在View層做一個對isShowDialog改變的監聽
public class MainActivity extends RxBasePmsActivity {

private MainViewModel mainViewModel;

@Override
protected void onCreate(Bundle savedInstanceState) {
.....
mainViewModel.isShowDialog.addOnPropertyChangedCallback(new android.databinding.Observable.OnPropertyChangedCallback() {
@Override
public void onPropertyChanged(android.databinding.Observable sender, int propertyId) {
if (mainViewModel.isShowDialog.get()) {
dialog.show();
} else {
dialog.dismiss();
}
}
});
}
...
}

簡單地說你可以對任意的ObservableField做監聽，然後根據數據的變化做相應UI的改變，業務層ViewModel只要根據業務處理數據就行，以數據來驅動UI。

Ⅳ android開發一般都使用什麼框架

Android開發框架介紹
編輯文檔
學分 +2
開發框架方麵包含基本的應用功能開發、數據存儲、網路訪問這三大塊：
一、應用方面
一般而言一個標準的Android程序由如下4部分組成即Activity、Broadcast Intent Receiver、Service、Content Provider： 1. Activity是最頻繁、最基本的模塊，在Android中，一個Activity就是手機上一屏，相當於一個網頁一樣，所不同的是，每個Activity運行結束了，有個返回值，類似一個函數一樣。Android系統會自動記錄從首頁到其他頁面的所有跳轉記錄並且自動將以前的Activity壓入系統堆棧，用戶可以通過編程的方式刪除歷史堆棧中的Activity Instance。
Activity類中主要是跟界面資源文件關聯起來（res/layout目錄下的xml資源，也可以不含任何界面資源），內部包含控制項的顯示設計、界面交互設計、事件的響應設計以及數據處理設計、導航設計等application設計的方方面面。 2. Broadcast Intent Receiver
Intent提供了各種不同Activity進行跳轉的機制，譬如如果從A activity跳轉到B activity，使用Intent來實現如下： Intent in = new Intent(A.this, B.class); startActivity(in);
BroadcastReceiver提供了各種不同的Android應用程序進行進行進程間通訊的機制，譬如當電話呼叫來臨時，可以通過BroadcastReceiver發布廣播消息。對於用戶而言，BroadcastReceiver是不透明的，用戶無法看到這個事件，BroadcastReceiver通過NotificationManager來通知用戶這些事件發生了，它既可以在資源AndroidManifest.xml中注冊，也可以在代碼中通過Context.registerReceiver()進行注冊，只要是注冊了，當事件來臨的時候，即時程序沒有啟動，系統也在需要的時候會自動啟動此應用程序；另外各應用程序很方便地通過Context.sendBroadcast()將自己的事情廣播給其他應用程序；
3. Service,跟Windows當中的Service完全是一個概念，用戶可以通過startService(Intent service)啟動一個Service，也可通過Context.bindService來綁定一個Service.
4. Content Provider，由於Android應用程序內部的數據都是私有的，Content Provider提供了應用程序之間數據交換的機制，一個程序可以通過實現一個ContentProvider的抽象介面將自己的數據暴露出去，並且隱蔽了具體的數據存儲實現，標準的ContentProvider提供了基本的CRUD（Create,Read,Update,Delete)的介面，並且實現了許可權機制，保護了數據交互的安全性； 一個標準的Android應用程序的工程文件包含如下幾大部分： -> Java源代碼部分(包含Activity)，都在src目錄當中；
-> R.java文件，這個文件是Eclipse自動生成與維護的，開發者不需要修改，提供了Android對的資源全局索引； -> Android Library，這個是應用運行的Android庫；
-> assets目錄，這個目錄裡面主要用與放置多媒體等一些文件；
-> res目錄，放置的是資源文件,跟VC中的資源目錄基本類似，其中的drawable包含的是圖片文件，layout裡麵包含的是布局文件，values目錄裡面主要包含的是字元串(strings.xml)、顏色（colors.xml)以及數組（arrays.xml)資源；
-> AndroidManifest.xml，這個文件異常重要，是整個應用的配置文件，在這個文件中，需要聲明所有用到的Activity、Service、Receiver等。

Ⅵ android app開發中常用到哪些開源框架

在前面的課程中，隨著對Android體系的了解，已經可以進行正常的Android應用開發了。在Android開發中，同其他工程開發一樣，也經常使用一些提高效率的框架，本文我們做一個對比。這些框架，既包括：網路請求框架、也包括圖片載入庫框架、還包括資料庫操作等一些框架，總之，了解和熟悉這些框架，會對自己的開發效率有很大的提升和幫助。

網路請求框架

1、okHttp

在前文的學習中，我們已經了解過okHttp，是一個常用的網路載入庫。

2、Retrofit

介紹

Retrofit是一個很不錯的網路請求庫，該庫是square開源的另外一個庫，之前的okhttp也是該公司開源的。

Retrofit是基於OkHttp封裝的RESTful網路請求框架，使用註解的方式配置請求。優點是速度快，使用註解，callback函數返回結果自動包裝成Java對象。官方自己的介紹說：

A type-safe REST client for Android and Java

該網路框架在github上的地址如下：https://square.github.io/retrofit/

要求

Retrofit支持的http方式方式包括 GET/POST/PUT/DELETE/HEAD/PATCH，Retrofit要求Java的版本是1.8+，Android應用的API版本應該在21+。

依賴

使用Retrofit庫，和其他庫一樣，首先需要設置依賴，依然是在build.gradle文件中設置依賴：

//添加retrofit庫依賴

implementation 『com.squareup.retrofit2:retrofit:2.1.0』

//添加gson轉換器

implementation 『com.squareup.retrofit2:converter-gson:2.1.0』

使用

通過一個例子，我們可以來演示該框架的使用步驟：

1、定義請求介面，即程序中都需要什麼請求操作
public interface HttpServices {

/**

• 獲取頭條新聞

• @param type 新聞類型

• @param key apiKey

• @return

*/

@GET(「toutiao/index」)

Call getNewsList(@Query(「type」) String type, @Query(「key」) String key);

}

2、實例化Retrofit對象，使用的Builder的模式創建，如下代碼所示：
Retrofit retrofit = new Retrofit.Builder()

.baseUrl(Constants.BASE_API)

.addConverterFactory(GsonConverterFactory.create())

.build();

注意，這里設置結構體轉換器，是可以直接把網路請求回來的數據轉換為Java結構體，這里設置的Gson解析器，因此要引入相應的轉換器支持庫。

3、得到介面對象，自己創建的全局的介面對象，並調用相應的介面，得到一個類似於請求Call對象。如下所示：
HttpServices httpServices = retrofit.create(HttpServices.class);

Call newsListCall = httpServices.getNewsList(「top」, Constants.API_KEY);

4、加入到請求隊列中，並設置回調方法：
newsListCall.enqueue(new Callback() {

@Override

public void onResponse(Call call, Response response) {

//網路請求成功的回調方法

List list = Arrays.asList(response.body().result.data);

Log.i(「TAG」, 「請求成功:」 + String.valueOf(list.size()));

NewListAdapter adapter = new NewListAdapter(RetrofitActivity.this);

adapter.setmData(list);

mRecyclerView.setAdapter(adapter);

}

@Override

public void onFailure(Call call, Throwable throwable) {

//網路請求失敗的回調方法

Log.i(「TAG」, 「請求失敗:」 + throwable.getMessage());

}

});

其他界面操作和之前的Android中的內容一致。

3、RxJava

簡單來說，用來處理事件和非同步任務，在很多語言上都有實現，RxJava是Rx在Java上的實現。

原理

RxJava最基本的原理是基於觀察者模式來實現的。通過Obserable和Observer的機制，實現所謂響應式的編程體驗。

特點

RxJava在編程中的實現就是一種鏈式調用，做了哪些操作，誰在前誰在後非常直觀，邏輯清晰，代碼維護起來非常輕松。

RxJava也是一個在github上的庫，githubhttp://www.xingkongmj.com/news/id/62.html地址如下：https://github.com/ReactiveX/RxJava

基於此，還有一個RxAndroid，github地址如下：https://github.com/ReactiveX/RxAndroid

RxJava和RxAndroid的關系

RxAndroid是RxJava的一個針對Android平台的擴展，主要用於 Android 開發。

基本概念

RxJava 有四個基本概念：

Observable：可觀察者，即被觀察者Observer：觀察者subscribe：訂閱事件
這四個概念之間的邏輯關系是：Observable和Observer通過subscribe方法實現訂閱關系，從而Observable可以在需要的時候發出事件來通知Observer。

事件

RxJava 的事件回調方法主要包含以下幾個：

onNext：普通的事件onCompletedhttp://dachang.net/432717.html：事件隊列完結。RxJava 不僅把每個事件單獨處理，還會把它們看做一個隊列。RxJava 規定，當不會再有新的 onNext 發出時，需要觸發 onCompleted 方法作為標志。：事件隊列異常。在事件處理過程中出異常時， 會被觸發，同時隊列自動終止，不再允許再有事件發出。在一個正確運行的事件序列中, onCompleted和 有且只有一個，並且是事件序列中的最後一個。需要注意的是，onCompleted() 和 () 二者也是互斥的，即在隊列中調用了其中一個，就不應該再調用另一個。
資料庫操作框架

在開發時，本地資料庫可以起到緩存數據和存儲業務數據的作用，隨著技術的成熟，不斷推出了有很多關於資料庫的操作框架。比較常見的資料庫操作框架有諸如：GreenDao，OrmLite 和 ActiveAndroid，DBFlow等。

GreenDAO

GreenDAO是一個開源的 Android ORM(「對象/關系映射」)，通過 ORM（稱為「對象/關系映射」），在我們資料庫開發過程中節省了開發時間！

GreenDao的官方文檔地址如下：http://www.xingkongmj.com/news/id/63.html

GreenDao的作用

通過 GreenDao，我們可以更快速的操作資料庫，我們可以使用簡單的面相對象的API來存儲，更新，刪除和查詢 Java 對象。這款資料庫操作框架的特點是：

高性能，在官方的統計數據中，GreenDao在GreenDao，OrmLite 和 ActiveAndroid三個框架中，讀、寫、更新操作效率均表現第一。易於使用的強大 API，涵蓋關系和連接。內存消耗較小。安全：greenDAO 支持 SQLCipherhttp://www.xingkongmj.com/news/id/64.html，以確保用戶的數據安全;
核心概念

GreenDao 的核心類有三個：分別是：

DaoMaster：保存資料庫對象（SQLiteDatabase）並管理特定模式的 DAO 類（而不是對象）。它有靜態方法來創建表或刪除它們。它的內部類 OpenHelper 和DevOpenHelper 是 SQLiteOpenHelper 實現，它們在 SQLite 資料庫中創建模式。DaoSession：管理特定模式的所有可用 DAO 對象，您可以使用其中一個getter方法獲取該對象。DaoSession 還提供了一些通用的持久性方法，如實體的插入，載入，更新，刷新和刪除。XXXDao：數據訪問對象（DAO）持久存在並查詢實體。對於每個實體，greenDAO 生成DAO。它具有比 DaoSession 更多的持久性方法。Entities：可持久化對象。通常, 實體對象代表一個資料庫行使用標准 Java 屬性(如一個POJO 或 JavaBean )。
使用

按照官方的文檔和github上的說明可以實現green的使用。

首先進行的是依賴，對於greenDao，有兩個地方需要設置，分別是項目根目錄中的 build.gradle，還有mole中的build.gradle。
classpath 『org.greenrobot:green-gradle-plugin:3.3.0』 // add plugin

在項目根目錄中的build.gradle目錄中寫這句話的意思是添加greenDao的插件。

在項目mole中的build.gradle中也需要進行配置，有兩個地方需要設置，如下圖所示：

apply plugin: 『org.greenrobot.greenhttp://www.xingkongmj.com/news/id/66.html』 //開頭加入該代碼

dependences{

implementation 『org.greenrobot:green:3.2.0』

}

然後就可以使用了。

bean實體

可以在項目中創建自己業務需要的實體類，並通過註解來設置是實體類，欄位約束等內容。然後點擊Android Studio中的Make mole，即可自動生成XXXDao代碼，以此來方便開發者的操作。生成的XXXDao類，不可修改和編輯，是自動生成的。

ORMLite

ORMLite框架是另外一款Android開發中可以使用的資料庫操作框架。該框架的文檔地址如下：https://ormlite.com/sqlite_java_android_orm.shtml

該框架的文檔准備的不是特別友好，此處不再贅述。

總結，所有的框架原理幾乎都相差不大，只是操作有所差異。

視圖注入框架

在Android項目開發過程中，有太多的頁面需要布局完成，同時在代碼中需要些大量的findviewbyid的操作，來實現控制項的解析。於是就有人想能否輕松一些，解放雙手節省時間，干一些其他有意義的事情，於是ButterKnife就來了。

ButterKnife是一個專注於Android系統的View注入框架,可以減少大量的findViewById以及setOnClickListener代碼，可視化一鍵生成。

該項目在github上的地址如下：http://www.xingkongmj.com/news/id/65.html

這個框架的優勢也非常明顯：

強大的View綁定和Click事件處理功能，簡化代碼，提升開發效率方便的處理Adapter里的ViewHolder綁定問題運行時不會影響APP效率，使用配置方便代碼清晰，可讀性強
使用

首先是設置依賴，在build.gradlehttp://dachang.net/432714.html中進行依賴設置：

implementation 『com.jakewharton:butterknife:10.2.1』

annotationProcessor 『com.jakewharton:butterknife-compiler:10.2.1』

需要注意，該框架要求Java環境1.8版本以上，SDK版本在26以上，因此在使用到的mole中的build.graldle文件中，還必須添加如下代碼配置：

apply plugin: 『com.jakewharton.butterknife』

android{

//…

compileOptions {

sourceCompatibility JavaVersion.VERSION_1_8

targetCompatibility JavaVersion.VERSION_1_8

}

//…

}

另外，還必須在項目根目錄中的build.gradle文件中，添加該框架的插件，如下圖所示：

dependences{

classpath 『com.jakewharton:butterknife-gradle-plugin:10.2.1』

}

然後即可在代碼中進行使用了。

在使用該框架的頁面進行綁定諸如，如下所示代碼:

ButterKnife.bind( this) ;

主要的功能

@BindView（）：控制項id 註解，解放雙手，不用再每個控制項都寫一遍findviewById@BindViews（）:多個控制項id 的註解，括弧內使用花括弧包括多個id即可，中間用，分割開在Fragment中使用，綁定Fragment。@BindString（）：綁定字元串@BindArray：綁定數組@BindBitmap：綁定bitmap資源@OnClick、@OnLongClick：綁定點擊事件和長按事件…還有很多
插件安裝

如果是頁面很復雜，一個一個寫BindView也很費勁，在Android Studio中，可以安裝一個ButterKnife的插件，安裝該插件後，可以在Studio中直接將對應的布局中的所有控制項均給自動生成。

注意，在進行自動生成時，滑鼠要放在布局文件上。

注意事項

ButterKnife框架在使用時，要求的版本比較高，包括Java的版本也有限制。因此，如果計劃在項目中使用，要提前做好預備工作，以防止對已有項目和業務帶來不必要的麻煩，反而影響工作進度。

Ⅶ android 五大應用開發框架是什麼

android應用開發框架是 Application Framework，其系統架構由5部分組成，分別是：Linux Kernel、Android Runtime、Libraries、Application Framework、Applications。

1、Linux Kernel （Linux內核）

Android基於Linux 2.6提供核心系統服務，例如：安全、內存管理、進程管理、網路 堆棧、驅動模型。Linux Kernel也作為硬體和軟體之間的抽象層，它隱藏具體硬體細節而為上層提供統一的服務。

2、Android Runtime （運行庫）

Android包含一個核心庫的集合，提供大部分在Java編程語言核心類庫中可用的功能。每一個Android應用程序是Dalvik虛擬機中的實例，運行在他們自己的進程中。

Dalvik虛擬機設計成，在一個設備可以高效地運行多個虛擬機。Dalvik虛擬機可執行文件格式是.dex，dex格式是專為Dalvik設計的一種壓縮格式，適合內存和處理器速度有限的系統。 大多數虛擬機包括JVM都是基於棧的，而Dalvik虛擬機則是基於寄存器的。

3、Libraries （程序庫）

Android包含一個C/C++庫的集合，供Android系統的各個組件使用。這些功能通過Android的應用程序框架（application framework）暴露給開發者。

4、Application Framework （應用框架層）

通過提供開放的開發平台，Android使開發者能夠編制極其豐富和新穎的應用程序。開發者可以自由地利用設備硬體優勢、訪問位置信息、運行後台服務、設置鬧鍾、向狀態欄添加通知等等，很多很多。 開發者可以完全使用核心應用程序所使用的框架APIs。

應用程序的體系結構旨在簡化組件的重用，任何應用程序都能發布他的功能且任何其他應用程序可以使用這些功能（需要服從框架執行的安全限制）。這一機制允許用戶替換組件。

5、Applications（應用層）

Android裝配一個核心應用程序集合，包括電子郵件客戶端、SMS程序、日歷、地圖、瀏覽器、聯系人和其他設置。所有應用程序都是用Java編程語言寫的。Android本身是一套軟體堆迭(Software Stack)，或稱為「軟體迭層架構」，迭層主要分成三層：操作系統、中間件、應用程序。

(7)android路由框架擴展閱讀

開發人員也可以完全訪問核心應用程序所使用的API框架。該應用程序的架構設計簡化了組件的重用;任何一個應用程序都可以發布它的功能塊並且任何其它的應用程序都可以使用其所發布的功能塊(不過得遵循框架的安全性限制)。同樣，該應用程序重用機制也使用戶可以方便的替換程序組件。

隱藏在每個應用後面的是一系列的服務和系統,其中包括;

豐富而又可擴展的視圖(Views)，可以用來構建應用程序，它包括列表(lists)，網格(grids)，文本框(textBoxes)，按鈕(buttons)，甚至可嵌入的web瀏覽器。

內容提供器(ContentProviders)使得應用程序可以訪問另一個應用程序的數據(如聯系人資料庫)，或者共享它們自己的數據

資源管理器(ResourceManager)提供非代碼資源的訪問，如本地字元串，圖形，和布局文件(layoutfiles)。

通知管理器(NotificationManager)使得應用程序可以在狀態欄中顯示自定義的提示信息。

活動管理器(ActivityManager)用來管理應用程序生命周期並提供常用的導航回退功能。

Ⅷ android有哪些第三方框架

ThinkAndroid是一個免費的開源的、簡易的、遵循Apache2開源協議發布的Android開發框架，其開發宗旨是簡單、快速的進行Android應用程序的開發，包含Android mvc、簡易sqlite orm、ioc模塊、封裝Android httpclitent的http模塊,具有快速構建文件緩存功能，無需考慮緩存文件的格式，都可以非常輕松的實現緩存，它還基於文件緩存模塊實現了圖片緩存功能，在android中載入的圖片的時候，對oom的問題，和對載入圖片錯位的問題都輕易解決。他還包括了一個手機開發中經常應用的實用工具類，如日誌管理，配置文件管理，android下載器模塊，網路切換檢測等等工具。 目前ThinkAndroid主要有以下模塊： MVC模塊：實現視圖與模型的分離。 ioc模塊：android中的ioc模塊，完全註解方式就可以進行UI綁定、res中的資源的讀取、以及對象的初始化。 資料庫模塊：android中的orm框架，使用了線程池對sqlite進行操作。 http模塊：通過httpclient進行封裝http數據請求，支持非同步及同步方式載入。 緩存模塊：通過簡單的配置及設計可以很好的實現緩存，對緩存可以隨意的配置 圖片緩存模塊：imageview載入圖片的時候無需考慮圖片載入過程中出現的oom和android容器快速滑動時候出現的圖片錯位等現象。 配置器模塊：可以對簡易的實現配對配置的操作，目前配置文件可以支持Preference、Properties對配置進行存取。 日誌列印模塊：可以較快的輕易的是實現日誌列印，支持日誌列印的擴展，目前支持對sdcard寫入本地列印、以及控制台列印 下載器模塊:可以簡單的實現多線程下載、後台下載、斷點續傳、對下載進行控制、如開始、暫停、刪除等等。 網路狀態檢測模塊：當網路狀態改變時，對網路狀態進行檢測。

Ⅸ android 怎麼使用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 會把你可能需要的數據帶給你，這使得我們在Vie，具體見 MVVM Light Toolkit 使用指南的 Command 部分 。再強調一遍：ViewModel 不做和UI相關的事。

Ⅹ 使用mina框架寫了一個android客戶端通過路由器連接伺服器連不上是怎麼回事

and pink to near-white, and transparen