《Android程序设计Android程序设计》pdf下载在线阅读，求百度网盘云资源

《Android程序设计》（Zigurd Mednieks）电子书网盘下载免费在线阅读

链接：> 提取码：7bx5

书名：Android程序设计

作者：Zigurd Mednieks

译者：祝洪凯

出版社：机械工业出版社华章公司

出版年份：2013-3-1

页数：456

内容简介：

如何才能构建设计良好的Android应用？通过本书提供的权威指南，深入探索Android核心模块及其API，了解如何创建可以运行在一系列Android设备上的出色的应用软件。本书将带你探索行之有效的应用设计和实施方式，包括一些应用框架，你可以把这些框架作为自己项目的起始点。

深入传感器、本地开发、3D图形和许多其他主题，并发现如何在选择的平台上构建应用程序。如果你要进阶到高级程序员，你将学会如何创建良好的Android应用程序。

作者简介：

Zigurd Mednieks是领先的OEM、企业和创建基于Android系统的创业投资顾问。

Laird Dornin是一家大型无线运营商的高级工程师，在Java、Android、J2ME、SavaJe和WebKit方面有丰富的经验。

GBlake Meike是一位经验丰富的开发人员，为移动和服务端平台构建Java应用有丰富的经验。

Masumi Nakamura是Where Inc的Big Data和Recommendations组的首席架构师。

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

开发一个程序，android系统框架是层层相扣，不能分开的。应用程序层：这个层主要指的就是用java语言编写的运行在虚拟机上的程序，Google在最开始时就在android系统中捆绑了一些核心的应用（核心应用的编写必须使用应用层序框架层的API框架

2：android开发框架有四个层，从高层到低层分别是应用程序层、应用程序框架层

android应用开发框架是ApplicationFramework其系统架构由5部分组成，分别是：LinuxKernel、AndroidRuntime、Libraries、ApplicationFramework、。

android应用开发框架是ApplicationFramework其系统架构由5部分组成，分别是：LinuxKernel、AndroidRuntime、Libraries、ApplicationFramework、。第二部分将详细介绍这5个部分。下面自底向上分析各层。

Android架构

1、LinuxKernel

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

2、AndroidRuntime

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

3、Libraries

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

4、ApplicationFramework

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

5、

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

开源框架推荐：

网络

[ok>

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(Athis, Bclass); startActivity(in);

BroadcastReceiver提供了各种不同的Android应用程序进行进行进程间通讯的机制，譬如当电话呼叫来临时，可以通过BroadcastReceiver发布广播消息。对于用户而言，BroadcastReceiver是不透明的，用户无法看到这个事件，BroadcastReceiver通过NotificationManager来通知用户这些事件发生了，它既可以在资源AndroidManifestxml中注册，也可以在代码中通过ContextregisterReceiver()进行注册，只要是注册了，当事件来临的时候，即时程序没有启动，系统也在需要的时候会自动启动此应用程序；另外各应用程序很方便地通过ContextsendBroadcast()将自己的事情广播给其他应用程序；

3 Service,跟Windows当中的Service完全是一个概念，用户可以通过startService(Intent service)启动一个Service，也可通过ContextbindService来绑定一个Service

4 Content Provider，由于Android应用程序内部的数据都是私有的，Content Provider提供了应用程序之间数据交换的机制，一个程序可以通过实现一个ContentProvider的抽象接口将自己的数据暴露出去，并且隐蔽了具体的数据存储实现，标准的ContentProvider提供了基本的CRUD（Create,Read,Update,Delete)的接口，并且实现了权限机制，保护了数据交互的安全性； 一个标准的Android应用程序的工程文件包含如下几大部分： -> Java源代码部分(包含Activity)，都在src目录当中；

-> Rjava文件，这个文件是Eclipse自动生成与维护的，开发者不需要修改，提供了Android对的资源全局索引； -> Android Library，这个是应用运行的Android库；

-> assets目录，这个目录里面主要用与放置多媒体等一些文件；

-> res目录，放置的是资源文件,跟VC中的资源目录基本类似，其中的drawable包含的是文件，layout里面包含的是布局文件，values目录里面主要包含的是字符串(stringsxml)、颜色（colorsxml)以及数组（arraysxml)资源；

-> AndroidManifestxml，这个文件异常重要，是整个应用的配置文件，在这个文件中，需要声明所有用到的Activity、Service、Receiver等。

我们先来看看什么是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 NewsServiceNews news;

private TopNewsServiceNews 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(pageLIMIT)

});

接着在XML布局文件中通过bind:onLoadMoreCommand绑定上去就行了。

<androidsupportv7widgetRecyclerView

android:layout_width="match_parent"

android:layout_height="match_parent"

bind:onLoadMoreCommand="@{viewModelloadMoreCommand}"/>

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=@{}）绑定。如果一个业务逻辑要d一个Dialog，但是你又不想在ViewModel里面做d窗的事（ViewModel不希望做UI相关的事）或者说改变ActionBar上面的图标的颜色，改变ActionBar按钮是否可点击，这些都不是写在XML里面（都是用Java代码初始化的），如何对这些控件的属性做绑定呢？我们先来看下代码：

public class MainViewModel implements ViewModel {

//true的时候d出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) {

mainViewModelisShowDialogaddOnPropertyChangedCallback(new androiddatabindingObservableOnPropertyChangedCallback() {

@Override

public void onPropertyChanged(androiddatabindingObservable sender, int propertyId) {

if (mainViewModelisShowDialogget()) {

dialogshow();

} else {

dialogdismiss();

}

}

});

}

}

简单地说你可以对任意的ObservableField做监听，然后根据数据的变化做相应UI的改变，业务层ViewModel只要根据业务处理数据就行，以数据来驱动UI。

以上就是关于《Android程序设计Android程序设计》pdf下载在线阅读，求百度网盘云资源全部的内容，包括:《Android程序设计Android程序设计》pdf下载在线阅读，求百度网盘云资源、一般的android开发都用到了系统架构哪些层_android系统架构由哪些组成、安卓app开发框架有哪些等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！