安卓架构组件-App架构指导

Posted 2021-04-28 编程技术圈

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

  总结

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

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

“

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

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

这些app组件大部分被声明在app清单文件（AndroidManifest）中，该清单文件被Android系统用于决定如何整合你的app到全局的用户体验中。如上文所说，传统的桌面应用通常作为一个整体运行，而一个编写良好的Android应用需要更加灵活，因为用户常常在不同的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类构建将对数据管理有利，并使得它们易于测试。

  三、推荐App架构

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

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

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

构建用户界面

UI界面将会由一个叫做UserProfileFragment.java的Fragment和对应的布局文件user_profile_layout.xml组成。

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

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

• User Object:一个含有用户数据的POJO类

我们将会创建一个基于ViewModel类的UserProfileViewModel来保存信息。

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

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

• user_profile.xml: 定义了屏幕的UI布局

• UserProfileViewModel.java:准备用于UI的数据类

• UserProfileFragment.java: UI控制器，在ViewModel中显示数据以及响应用户交互

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

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

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

现在我们修改UserProfileFragment，观察数据变化并更新UI。

每次用户数据被更新时，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接口Webservice：

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

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

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

下方的UserRepository类将会使用WebService来获取数据项：

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

管理组件间的依赖

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

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

• 依赖注入：依赖注入允许类定义依赖而不用去构造他们。在运行的时候，另一个类负责提供这些依赖关系。我们推荐在安卓中使用谷歌的[Dagger 2]类库进行依赖注入。通过遍历依赖树，Dagger 2 自动构造对象并提供编译时的依赖保障。

• 服务定位：服务定位器提供了注册器，使得类可通过依赖进行构建，而不是需要配置它们。服务定位模式相对依赖注入而言更易于实现，因此如果你并不熟悉依赖注入，可以使用服务定位来代替。

连接ViewModel和仓库

现在我们修改我们的UserProfileViewModel以使用仓库：

缓存数据

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

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会检查基于表修改的错误信息，也就是说会分发假阳性的通知。假阳性是指分发的通知是正确的，但是并非是由数据变化所造成的。

现在我们修改UserRepository类，将Room数据源包含在内。

请注意，即使我们在UserRepository中改变了数据源，我们仍然不需要改变UserProfileViewModel或者UserProfileFragment。这种灵活性是由抽象所提供的。这对于测试来说也是很棒的，因为你可以在测试UserProfileViewModel的时候提供一个假的UserRepository。

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

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

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

• 修改getUser()方法，返回带有网络操作状态的LiveData，例如下文中的“显示网络状态”章节。

• 在仓库类中提供另一个公共方法，返回User类的刷新状态。这种方式更好，如果你想要仅仅在响应显式地用户操作（如pull-to-refresh）时显示网络状态。

真正单一数据源

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

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

测试

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

• UI&交互：这是唯一需要[Android UI Instrumentation test]的时刻。测试UI的最佳方式是创建一个[Espresso]特使。你可以创建Fragment并提供一个虚拟的ViewModel。因为Fragment仅仅和ViewModel对话，模拟ViewModel对于测试来说就已经足够了。

• ViewModel：ViewModel可以使用[JUnit测试]。你仅仅需要模拟UserRepository。

• UserRepository：你也可以使用JUnit测试UserRepository。你需要模拟Webservice和DAO。你可以测试网络请求调用，在数据库中保存结果，以及如果数据被缓存并更新后不需要进行请求。因为Webservice和UserDao都是接口，你可以模拟它们。

• UserDao：测试DAO类的推荐方法是使用测试工具。因为这些测试工具并不需要任何的UI并运行速度很快。对每个测试来说，你可以创建一个内存数据库来保证测试并不会造成双边效应（如改变磁盘上数据库的已有数据）。

• WebService：独立于外部世界的测试是很重要的，甚至你的Webservice测试应该避免调用后台的网络服务。有大量的类库可以帮助做到这一点，例如：[MockWebServer]。

• 测试构件：架构组件提供一个Maven构件来控制后台线程。在android.arch.core:core-testing中，有两个JUnit规则：

• 任务立即执行规则：这个规则可用于强制架构组件在调用线程里立即执行任何后台操作

• 这个规则可用于工具测试，以等待架构组件的后台操作或者连接至Espresso作为闲置资源。

最终架构

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

image

指导原则

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

• 你在清单文件中所定义的入口点——Activity，Service，Broadcast Receiver等并不应该是数据源。相反，他们应该仅仅是和入库点相关的数据源子集。因为每个app的组件的存活时间都是短暂的、取决于用户的交互行为以及运行时整体上的健康度。

• 残忍坚决地创建良好的模块分界。例如，不要将从网络读取数据的代码扩展到多个类/包中。相似地，也不要将不相关职责的代码添加进来，如数据缓存等。（高内聚，低耦合）

• 模块间交互暴露的接口应该尽可能的少。不要尝试创建“仅仅用一次”的捷径，导致暴露一个模块的内部实现细节。你可能在短期会获益，但是在代码的演进过程中会耗费数倍的技术负担。

• 当你定义了模块间的交互时，考虑每个模块的单独可测试性。例如，有一个定义良好的用于从网络获取数据的API会更易于测试本地数据库持久化的模块。相反，如果你搞乱了两个模块间的逻辑，或将你网络请求的代码铺满了所有的地方，那么这将很难进行测试。

• 你app的核心是如何在其他app中变得突出。不要花费时间重复造轮子或一遍一遍地写相同的模板代码。相反，将你的心思花在如何使你的app独一无二，让Android架构组件以及其他推荐类库处理重复的部分。

• 持久化尽可能多和尽可能新鲜的数据，这样在离线模式下你的app也是可用的。你可能很享受高速的网络连接，可你的用户并不一定这样认为。

• 你的仓库应当指定单一数据源。当你的app需要访问数据时，应该永远来自于这个单一的数据源。

附加：显示网络状态

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

下面是样例的实现：

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

image

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

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

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

以下是NetworkBoundResource所提供的API：

链接：http://chuckiefan.com/2017/06/07/%E7%BF%BB%E8%AF%91-%E5%AE%89%E5%8D%93%E6%9E%B6%E6%9E%84%E7%BB%84%E4%BB%B6(1)-App%E6%9E%B6%E6%9E%84%E6%8C%87%E5%AF%BC.html

本文来自Chuckiefan投稿

每日英文

One day you'll understand that it's harder to be kind than clever. cleverness is a gift, yet kindness is a choice.  

有一天你会明白，善良比聪明更难。聪明是一种天赋，而善良是一种选择。

乐乐有话说

有些压力总是得自己扛过去，说出来就成了充满负能量的抱怨。寻求安慰也无济于事，还徒增了别人的烦恼。而当你独自走过艰难险阻，一定会感激当初一声不吭咬牙坚持着的自己。

   
     
     
   

    
      
      
    
 
     
      
        
        
      

       
         
         
       
 
        
 
         
 
          
 
          
 
          
 
          
 
          
 
          
 
          
 
          
 
         
 
         
 
          
如德芙般丝滑的ViewPager轮播
 
          
 
         
 
        
 
       
      
        
        
      
 
    
   
     
     
   

   
     
     
   

    
      
      
    
 
     

看完本文有收获？请转发分享给更多人
关注「杨守乐」，提升编程技能
 
    
   
     
     
   

优秀人才不缺工作机会，只缺适合自己的好机会。但是他们往往没有精力从海量机会中找到最适合的那个。100offer 会对平台上的人才和企业进行严格筛选，让「最好的人才」和「最好的公司」相遇。

扫描下方二维码，注册 100offer，谈谈你对下一份工作的期待。一周内，收到 5-10 个满足你要求的好机会！