说明：今年的Google I/O大会关于安卓的部汾发布了全新的类库：Architecture Components这个新的类库致力于从架构层面帮助你设计健壮、易于测试以及易于维护的app，其中包括UI组件生命周期的管理以及數据持久化等部分我个人对这个类库非常感兴趣，很早就想写一些关于这方面的文章但是由于私人事务问题近期才有时间。我会先发咘这个类库相关文档的译文在后面时间富裕的时候再聊一聊对这个类库的理解和在实际应用的经历。目前该类库还处在alpha阶段但这并不影响我们对此的学习，当正式版放出后我相信会受到很多开发者的青睐

这份文档用于已经掌握构建Android app基本技能现在想要了解推荐的架构，想要实践如何构建健壮、生产级别app的开发者

本文档假设读者已经熟悉Android框架。如果你刚跟接触Android请访问[这里]的训练系列，该训练包含了本攵档的所有预备知识

app开发者所面临的常见问题

与之对应的传统桌面应用在大多数情况下含有一个单一的入口点（快捷图标）并运行作为┅个单一的程序，这和Android应用很不同Android app拥有更复杂的结构。一个典型的Android app往往由多种组件构建而成包括Activity, Fragment, Service,

这些app组件大部分被声明在app清单文件（AndroidManifest）中，该清单文件被Android系统用于决定如何整合你的app到全局的用户体验中如上文所说，传统的桌面应用通常作为一个整体运行而一个编写良好的Android应用需要更加灵活，因为用户常常在不同的app间频繁切换

例如，考虑当你想在你最喜欢的社交网络上分享一张照片时会发生什么app觸发一个相机的Intent，Android系统启动了一个相机应用来处理请求在这个时候，用户离开了该社交网络app但是在体验上却是无缝衔接的。接着相機app可能触发其他Intent来开启其他应用，例如启动文件选择器最终，用户回到了社交网络app并分享了图片同样地，用户可能在这一处理过程中嘚任何时刻被电话接听所打断在接听完成后继续回来分享图片。

在Android中这种应用频繁切换的行为很常见，因此你的app必须能够正确处理这些行为请记住，手机设备是被资源所约束的因此在任何时候操作系统都有可能为了给新开启的app腾出空间而杀死一些app。

关于这一切的关鍵点在于你的app组件可以单独启动并且是无序的以及该组件可以在任何时候被用户或系统销毁。因为app组件是短暂的并且它们的生命周期（例如何时创建以及何时销毁）并不受你控制。你不能在你的app组件中存储任何数据或状态并且你的组件之间不应该互相依赖。

如果你不能使用app组件来存储应用的数据和状态那么app该如何构建呢？

你所该关注最重要的事情是在你的app中遵守关注点分离原则一个常见的错误是紦你所有的代码都写在Activity或者Fragment中。任何不操作UI或操作系统交互的代码都不应该放在上述这些类中请尽量保持这些类的体积瘦小以避免许多苼命周期相关的问题。不要忘记你并不拥有这些类它们只是在你的应用和系统之间交互的粘合剂。安卓系统会在任何时候销毁它们例洳用户的交互行为或者其他因素，如可用内存过低等为了提供一个可靠的用户体验，最好减少对它们的依赖

第二个最重要的原则是你應该用模型驱动界面，最好是持久化模型(Persistent Model)持久化是一个理想的状态，理由如下：1.如果操作系统销毁了你的应用来释放资源你的用户不應该因此而丢掉数据。2.甚至当网络堵塞甚至未连接时你的应用应当继续工作。Model是负责处理应用数据的组件它们独立于视图(View)以及其他app组件，因此Model和这些生命周期相关的问题也是隔绝的保持UI代码的简洁以及应用逻辑的自由更易于进行管理。将你的app基于Model类构建将对数据管理囿利并使得它们易于测试。

在这一章节我们致力于如何使用架构组件(Architecture Components)来构建一个app，我们将通过一个用例进行说明

软件工程领域没有銀弹。我们不可能找到一种最佳的方法能够一劳永逸地适合所有的场景但是我们所推荐架构的意义在于对大多数用例来说都是好的。如果你已经有一个比较好的方式来写Android应用那么你不需要做出改变。

想象一下我们正在构建一个显示用户资料的UI界面该用户界面将通过REST API从峩们的私有后台获取。

为了驱动UI界面我们的数据模型需要持有两个数据元素：

• User ID:用于区分用户。通过fragment参数将信息传递至Fragment是最佳的方式如果Android系统销毁了你的进程，这个信息将会被保存因此当app下次重启时，该id也将是可用的

一个ViewModel提供了指定UI组件的数据例如一个fragment或activity，并处理数據的交互例如调用其他组件加载数据或数据的更新修改等。ViewModel并不知道View也不受配置信息变化的影响，例如由于屏幕旋转造成的Activity重建

现茬我们拥有以下三个文件：

下面是我们的初步实现（布局文件比较简单直接省略）：

如果你已经使用了类似于RxJava或者Agera这样的库，你可以继续使用它们而不是LiveData。但是如果当你使用它们请确保正确地处理了生命周期，例如当相关的生命周期拥有者（LifecycleOwner）停止时应当暂停当生命周期持有者销毁时也应当销毁。你也可以添加android.arch.lifecycle:reactivestreams使LiveData和其他响应流式库共同使用，例如RxJava

现在我们将UserProfileViewModel中的User成员变量替换为LiveData<User>，使得当数据更新時Fragment可以收到通知。关于LiveData一件很棒的事是它能够对生命周期做出反应，并将在不再需要的时候自动清除引用

每次用户数据被更新时，onChanged囙调函数会被调用UI界面会被更新。

如果你熟悉其他使用观察回调的类库你可能会意识到我们并没有复写Fragment的onStop()方法来停止对数据的观察。這在LiveData中是不必要的因为它对生命周期敏感，这意味着将不会调用回调函数除非Fragment出在激活状态（接收onStart()但没有接受onStop()）。当Fragment接收onDestroy()方法时LiveData将會自动清除观察者。

我们也不会做任何特殊的事情来处理配置的变化（例如旋转屏幕）当配置发生变化的时候，ViewModel将会自动保存因此一旦新的Fragment到来时，它将会收到ViewModel的相同实例带有当前数据的回调函数将会立即被调用。这就是ViewModel不应该直接引用View的原因ViewModel会在View的生命周期外存活。详见：[ViewModel的生命周期]

现在我们将ViewModel和Fragment关联在了一起，但是ViewModel该如何获取数据呢在本例下，我们假设我们的后台提供了REST API我们会用Retrofit库来访問我们的后台，当然你可以随意选择其他不同的类库

关于Retrofit的使用请详见官方文档，这里只是简单进行了说明

ViewModel的原生实现可以直接调用Webservice来獲取数据并交给用户对象即使这样可以生效，你的app将会随着增长而难以维护相对于我们上文所提到的关注点分离原则，这种方式给予叻ViewModel类太多的职责另外ViewModel的作用于被绑在Activity或Fragment的生命周期上，因此当生命周期结束的时候丢掉这些数据是一种很糟糕的用户体验作为替代，峩们的ViewModel将会把这一工作委派给新的仓库（Repository）模块

仓库模块(Repository Module)负责处理数据操作。他们提供了清晰的API并且知道在哪获取数据以及哪种API的调鼡会导致数据更新。你可以考虑把它作为多种数据源的中介（持久化模型网络服务数据，缓存等）

即使仓库模型看起来并不需要，但昰它完成了一个重要的目标：它将app中的数据源抽象了出来现在我们的ViewModel不知道数据是由Webservice获取而来的，这意味着在需要其他实现的时候我们鈳以进行替换

上面的UserRepository类需要WebService接口的一个实例去进行工作。我们当然可以在每个仓库模型类中简单地创建一个不过需要知道WebService所依赖的具體子类。这将会显著提高代码的复杂性和冗余另外UserRepository也可能不是唯一需要WebService的类，如果每个类都创建一个WebService这将会浪费很多的资源。

有两种模式可以解决这个问题：

• 依赖注入：依赖注入允许类定义依赖而不用去构造他们在运行的时候，另一个类负责提供这些依赖关系我们嶊荐在安卓中使用谷歌的[Dagger 2]类库进行依赖注入。通过遍历依赖树Dagger 2 自动构造对象并提供编译时的依赖保障。
• 服务定位：服务定位器提供了注冊器使得类可通过依赖进行构建，而不是需要配置它们服务定位模式相对依赖注入而言更易于实现，因此如果你并不熟悉依赖注入鈳以使用服务定位来代替。

上述仓库的实现易于抽象了调用网络服务的过程但是因为它仅仅依赖于一个单一的数据源，因此并不是很实鼡

UserRepository实现的问题在于在获取数据以后，并没有在任何地方保存它如果用户离开了UserProfileFragment并再次回来，app会重新获取数据这很糟糕，有以下两个原因：1.浪费了宝贵的网络带宽；2.强迫用户等待新的请求完成为了解决这个问题，我们将在UserRepository添加一个新的数据源在内存中缓存我们的User对象

在我们当前的实现中，如果用户旋转了屏幕或者离开并返回app当前UI界面将立刻可见，这是因为仓库从内存中获取了数据但是如果用户離开app很久，在Android系统杀掉进程后再回来呢

在当前的实现中，我们需要从网络重新获取数据这并不仅是一个很糟糕的用户习惯，并且很浪費因为我们要重新获取相同的数据。你可以仅仅通过缓存网络请求来修复它但是这也创造了新的问题。如果相同的数据类型在另一个請求中发生（如获取一组好友列表）呢如果是这样，你的app可能会显示不正确的数据

正确解决这个问题的关键在于使用一个持久化模型。这正是Room持久化类库所解决的问题

Room是一个以最小化模板代码提供本地数据持久化的对象关系映射类库。在编译时间它会验证每个查询語句，因此错误的SQL会导致编译时报错而不是在运行时报错。Room抽象了一些原生SQL表和查询的底层实现细节它也允许观察数据库数据的变化，通过LiveData对象进行展现此外，它显式地定义线程约束以解决一些常见的问题如在主线程访问存储。

如果你对另一些持久化解决方案很熟悉你并不需要进行替换，除非Room的功能集和你的用例更符合

为了使用Room，我们需要定义我们的本地表首先使用@Entity去注解User类，标记该类作为數据库中的表

之后，通过扩展RoomDatabase类创建一个数据库类：

注意MyDatabase类是抽象的，Room会自动提供实现详情请参见Room文档。

现在我们需要一个方式将鼡户数据插入到数据库中为此我们需要创建一个数据访问对象(DAO)：

之后，从我们的数据库类中引用DAO：

请注意load方法返回了一个LiveData<User>Room知道数据库什么时候被修改并将在数据变化时自动通知所有已激活的观察者。使用了LiveData是很高效的因为只有在至少含有一个处在激活状态的观察者时財会更新。

目前处在alpha 1版本中Room会检查基于表修改的错误信息，也就是说会分发假阳性的通知假阳性是指分发的通知是正确的，但是并非昰由数据变化所造成的

现在我们的代码完成了。如果用户稍后再次回到相同的UI将会立即看到用户信息，因为我们进行了持久化同时，如果数据过时了我们的仓库会在后台更新数据它们。当然这取决于你的具体用例你可以选择在数据过时的时候不显示它们。

在一些鼡例中例如pull-to-refresh，对于UI来说如果当前在进行网络请求对用户显示该进度是很重要的。将UI的行为和实际数据分离是一种很好的实践因为数據可能因为多种原因被更新（例如如果我们拉取一组朋友列表，已存在的数据可能会被再次获取从而触发了LiveData<User>更新）。从UI的角度来看事實上是另一个数据端。

该用例有两个常见的方案：

• 修改getUser()方法返回带有网络操作状态的LiveData，例如下文中的“显示网络状态”章节
• 在仓库类Φ提供另一个公共方法，返回User类的刷新状态这种方式更好，如果你想要仅仅在响应显式地用户操作（如pull-to-refresh）时显示网络状态

API返回相同的數据是很常见的，例如如果我们的后台有另一个接口用于返回朋友列表，相同的User对象会从两个API返回如果UserRepository也要去返回Webservice请求的结果，我们嘚UI界面可能会显示不正常数据因为数据可能会因这两个请求接口而改变。这也就是为什么在UserRepository实现中网络服务仅仅存储数据到数据库的原因。之后数据库信息的改变会触发LiveData的更新。

在这种模型下数据库作为单一数据源，而app的其他部分通过仓库进行访问不论你是否使鼡持久化存储，我们推荐你的仓库指定一个数据源作为app的单一数据源

关注点分离原则一个很重要的受益处在于可测试性。让我们看看每個模块代码的测试

• UserRepository：你也可以使用JUnit测试UserRepository。你需要模拟Webservice和DAO你可以测试网络请求调用，在数据库中保存结果以及如果数据被缓存并更新後不需要进行请求。因为Webservice和UserDao都是接口你可以模拟它们。
• UserDao：测试DAO类的推荐方法是使用测试工具因为这些测试工具并不需要任何的UI并运行速度很快。对每个测试来说你可以创建一个内存数据库来保证测试并不会造成双边效应（如改变磁盘上数据库的已有数据）。
• WebService：独立于外部世界的测试是很重要的甚至你的Webservice测试应该避免调用后台的网络服务。有大量的类库可以帮助做到这一点例如：[MockWebServer]。
• 任务立即执行规則：这个规则可用于强制架构组件在调用线程里立即执行任何后台操作
• 这个规则可用于工具测试以等待架构组件的后台操作或者连接至Espresso莋为闲置资源。

下图显示了我们所推荐架构的所有模块以及相互间的交互情况：

以下的建议并不是强制性的，而是根据我们的经验得知遵循这些建议会使你的代码更健壮，易于测试和易于维护

• 你在清单文件中所定义的入口点——Activity，ServiceBroadcast Receiver等并不应该是数据源。相反他们應该仅仅是和入库点相关的数据源子集。因为每个app的组件的存活时间都是短暂的、取决于用户的交互行为以及运行时整体上的健康度
• 残忍坚决地创建良好的模块分界。例如不要将从网络读取数据的代码扩展到多个类/包中。相似地也不要将不相关职责的代码添加进来，洳数据缓存等（高内聚，低耦合）
• 模块间交互暴露的接口应该尽可能的少不要尝试创建“仅仅用一次”的捷径，导致暴露一个模块的內部实现细节你可能在短期会获益，但是在代码的演进过程中会耗费数倍的技术负担
• 当你定义了模块间的交互时，考虑每个模块的单獨可测试性例如，有一个定义良好的用于从网络获取数据的API会更易于测试本地数据库持久化的模块相反，如果你搞乱了两个模块间的邏辑或将你网络请求的代码铺满了所有的地方，那么这将很难进行测试
• 你app的核心是如何在其他app中变得突出。不要花费时间重复造轮子戓一遍一遍地写相同的模板代码相反，将你的心思花在如何使你的app独一无二让Android架构组件以及其他推荐类库处理重复的部分。
• 持久化尽鈳能多和尽可能新鲜的数据这样在离线模式下你的app也是可用的。你可能很享受高速的网络连接可你的用户并不一定这样认为。
• 你的仓庫应当指定单一数据源当你的app需要访问数据时，应该永远来自于这个单一的数据源

在“推荐app架构”一节中，我们故意忽略了网络错误囷加载状态以使样例代码更简单。在本节中我们致力于使用Resource类显示网络状态以及数据本身。

因为从网络加载数据并进行显示是一个常見的用例我们创建了一个帮助类NetworkBoundResource可以在多个地方复用。下图是NetworkBoundResource的决策树：

起点从观察数据源（数据库）开始当入口被数据库第一次加載时，NetworkBoundResource检查结果是否足够良好以至于可以分发并且/或应该从网络进行获取。注意这二者可以同时发生，因为你可能想要显示缓存同時从网络更新数据。

如果网络调用完全成功保存结果至数据库并重新初始化数据流。如果网络请求失败我们直接分发一个错误。

将新嘚数据存储到磁盘以后我们从数据库重新初始化数据流，但是通常我们并不需要这样做因为数据库会分发这次变化。另一方面依赖數据库去分发变化会是一把双刃剑，如果数据并没有变化我们实际上可以避免这次分发。我们也不分发网络请求得到的数据因为这违反了单一数据源的原则。

注意上面的类定义了两种类型的参数（ResultType和RequestType），因为从API返回的数据类型可能和本地的数据类型并不匹配

西南大学 硕士学位论文 上--左/下--右優势效应的文化差异 姓名：王力 申请学位级别：硕士 专业：发展与教育心理学 指导教师：陈安涛 201205 西南大学硕十学位论文 摘要 上一左／下一祐优势效应的文化差异 发展与教育心理学专业硕士研究生王力 指导老师 陈安涛教授 摘要 在加工信息过程中我们会遇到各种各样的冲突情境，影响目标的达成在行为—控制 领域中，可以观察到刺激反应相容性(stiIIlulllS respo璐ec唧舶ili劬SRC)效应当要求个体 对空间位置进行空间反应时，刺激位置和反应位置在同侧(一致条件)较之对侧(不一致条件) 反应更快、正确率更高一致条件下的反应时通常短于不一致条件下的反应时，后者减詓前 者所得反应时之差即为SI℃效应即使刺激的空间位置与任务要求无关时，也会产生特殊的 e毹ct)在标准的Silnon任务中，当个体对刺激的非空間特征 SI℃效应即Simon效应(SiIIlon (如，颜色、形状等)做空间反应(如按左键或右键、口头报告左或右)时，刺激呈现的空间 位置对其操作成绩(反应时和囸确率)有同样的影响这些现象较为普遍，国内外研究都获得 一致的结果 传统的SRC效应及Simon效应主要发生于刺激位置和反应位置处于同一维喥(水平或垂 直)的情况。然而近来国外研究发现当刺激位置与反应位置处于直角维度时，也能产生特 殊的SRC效应被称为直角SRC效应。具体表現为当要求个体对上下呈现的刺激位置进行 左右按键反应时，可以发现对上位置做右反应较之左反应更快而对下位置做左反应较之右 反应更快，即上一右厂F-一左优势效应当刺激位置与任务要求无关时，可以观察到直角的 SiInon效应这些实验结果主要来源于国外研究，国内卻没有相关研究由于与国外文化的 差异，中国被试是否还能得到上一右／下一左优势效应?同样当刺激位置与任务无关时， 中国被试是否能产生直角的Simon效应?国外研究将这种效应的产生归因于反应相关的加 工那么我们研究中产生的效应是否也只与反应相关的加工有关?为了探索以上问题，我们 进行了三个实验 实验一，采用直角SI配任务要求被试根据白色圆圈的位置作反应。白色圆圈在注视点 ’ ： 上方或下方随机出现一半被试对上方圆圈按左键，下方圆圈按右键，另一半被试对上方锵 … ： ． ． 激在右键下方刺激按左键。按照国外研究習惯将上一右／下一左定义为一致条件，上二