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