android官网中文 Google I/O 2017:官方推出Android应用开发架构指南,附Demo和官方文档

相关阅读:

吊起来炸天！74 APP完整源代码！

简评:虽然Android架构的选择一直是免费的，但MVP、MVC、MVVM都有自己的粉丝。不过谷歌最近发布了一个关于应用架构的实用指南，给出了相当详细的步骤和一些指导建议。希望大家可以看看，研究一下，搭建一个更好更好用的APP，为安卓生态的改善做点贡献。: )

最近，政府发布了一份关于应用程序架构的最佳实践指南。下面给大家简单介绍一下:

首先，Android开发者必须知道，Android中有四个组件，它们有自己的生命周期，在某种程度上不受你的控制。Android操作系统随时都可能根据用户的行为或资源短缺情况回收这些组件。

这就引出了第一条规则:“不要在应用组件中保存任何应用数据或状态，组件之间不应该相互依赖”。

最常见的错误是在Activity或Fragment中编写与UI和交互无关的代码。尽可能减少对它们的依赖，可以避免大量生命周期带来的问题，提供更好的用户体验。

第二条规则:“通过模型驱动应用UI，并尽可能地持久化”。

这有两个主要原因:

如果系统回收您的应用程序资源或任何其他意外情况，它不会导致用户丢失数据。

模型应该是负责处理应用程序数据的组件。独立于视图和应用程序组件，它使视图代码保持简单，并使您的应用程序逻辑更容易管理。另外，把应用数据放在模型类里更有利于测试。

官方推荐的应用架构

在这里，正式的演示是通过使用最新的架构组件来构建应用程序。

假设你正在计划开发一个显示用户个人信息的界面，用户数据是通过REST API从后端获取的。

首先，我们需要创建三个文件:

User_profile.xml:定义接口。

UserProfileViewModel.java:数据类别。

UserProfileFragment.java:在ViewModel中显示数据，响应用户交互。

为了简单起见，这里省略了布局文件。

公共类UserProfileViewModel扩展了视图模型{私有字符串userId私人用户；

公共类UserProfileFragment扩展LifecycleFragment { private static final String UID _ KEY = " UID "；私有用户配置视图模型视图模型；@覆盖

注意ViewModel和LifecycleFragment都是Android新推出的，可以参考官方指令进行集成。

现在我们已经完成了这三个模块，如何将它们连接起来呢？也就是说，当设置了ViewModel中的用户字段时，我们需要一种通知UI的方式。这就是直播数据的来源。

LiveData是一个可观察的数据持有者(使用观察者模式)。它可以允许应用程序组件(如活动、片段)观察它，而不会在它们之间创建强依赖关系。LiveData还可以自动响应每个组件的声明周期事件，防止内存泄漏，这样应用程序就不会消耗更多的内存。

注意:LiveData与RxJava或Agera的主要区别在于，LiveData自动帮助处理生命周期事件，避免内存泄漏。

现在，让我们修改用户配置视图模型:

公共类UserProfileViewModel扩展了视图模型{

然后在用户配置文件中观察它并更新我们的用户界面:

@ override public void onActivityCreated(@ Nullable Bundle savedInstanceState){ super . onActivityCreated(savedInstanceState)；viewModel.getUser()。观察(这一点，用户->;{ //更新UI

检索数据

现在已经联系了ViewModel和Fragment，但是ViewModel怎么获取数据呢？

在这个例子中，我们假设后端提供REST API，所以我们选择refught来访问我们的后端。

首先，定义一个网络服务:

公共界面Webservice { /**

不要直接通过视图模型获取数据，这里我们将把工作转移到一个新的存储库模块。

存储库模块负责数据处理，并为应用程序的其他部分提供干净可靠的API。您可以将其视为不同数据源(Web、缓存或数据库)和应用程序之间的中间层。

公共类user repository { private Webservice web service；// ...

管理组件之间的依赖关系

根据上面的代码，我们可以看到用户仓库中有一个网络服务的实例，所以不要直接在用户仓库中创建新的网络服务。这很容易导致代码的重复和复杂化。例如，用户仓库可能不是唯一使用网络服务的类。如果为每个使用的类创建一个新的网络服务，这将导致资源的浪费。

在这里，我们推荐Dagger 2来管理这些依赖关系。

现在，让我们将视图模型与存储库连接起来:

公共类UserProfileViewModel扩展了视图模型{私有LiveData & lt用户>。用户；私有用户存储库用户报告；@Inject // UserRepository参数由Dagger 2提供

缓存数据

在实际项目中，存储库通常不只有一个数据源。因此，我们在此添加缓存:

@Singleton //通知Dagger这个类应该构造为一个公共类user repository { private Webservice web service；//内存缓存中简单，为简洁起见省略了细节

持续数据

现在，当用户旋转屏幕或暂时离开应用程序并返回时，数据是直接可见的，因为它是直接从缓存中获得的。但是如果用户长时间关闭应用，Android完全扼杀了进程呢？

在我们当前的实现中，我们将再次从网络获取数据。这不是一个好的用户体验。这时候就需要数据持久化了。继续引入新的组件室。

Room可以帮助我们方便地实现本地数据持久化，抽象出很多常见的数据库操作，并在编译时验证每个查询，这样受损的SQL查询只会导致编译时错误，而不会导致运行时崩溃。它还可以与上述的LiveData完美配合，帮助开发者处理很多线程问题。

现在，让我们看看如何使用房间。: )

首先，将@Entity添加到User类中，并将User声明为数据库中的一个表。

@实体类用户{

然后创建一个数据库类并继承RoomDatabase:

@数据库(实体= {User.class}，版本= 1)

注意我的数据库是一个抽象类，Room会自动添加实现。

现在我们需要一种将用户数据插入数据库的方法:

@Daopublic接口User Dao { @ Insert(OnConflict = REPLACE)void save(用户用户)；@查询(" SELECT * FROM user WHERE id =:userId ")live data & lt；用户>。加载(字符串用户标识)；

然后将DAO添加到数据库类中:

@数据库(实体= {User.class}，版本= 1)

请注意，上面的加载方法返回livedata

现在继续修改用户存储库:

@Singletonpublic类user repository { private final WeB service web service；私有最终用户道用户道；私人最终遗嘱执行人；@注入

可以看出，即使我们在UserRepository中更改了数据源，也完全不需要修改ViewModel和Fragment，这就是抽象的优势。同时也非常适合测试。在测试用户概要视图模型时，我们可以为测试提供用户存储库。

以下内容在原文中作为附录，但个人认为也很重要，所以擅自上移介绍给大家。: )

在上面的例子中，您可能会发现我们没有处理网络错误和加载状态。但在实际开发中非常重要。在这里，我们实现了一个工具类，根据不同的网络条件选择不同的数据源。

首先，实现一个资源类:

//用statuspublic类Resource & lt描述数据的泛型类。T>。{ @非空公共最终状态状态；@可空公共最终T数据；@可空的公共最终字符串消息；私有资源(@非空状态状态，@可空测试数据，@可空字符串消息){ this.status = statusthis.data = datathis.message = message

因为从网络加载数据类似于从磁盘加载数据，所以创建了一个新的NetworkBoundResource类来促进多次重用。以下是网络边界资源的决策树:

API设计:

//结果类型:资源数据的类型//请求类型:应用编程接口响应抽象类网络边界资源的类型& lt结果类型，请求类型>；{ //调用以将API响应的结果保存到数据库中

请注意，ApiResponse用作网络请求，而ApiResponse是Retrofit2的简单包装器。调用，用于将其响应转换为LiveData。

以下是具体实现:

公共抽象类NetworkBoundResource & lt结果类型，请求类型>；{

现在，我们可以根据不同的情况使用网络边界资源来获取数据:

类别UserRepository {

至此，我们的代码全部完成。最终的架构如下所示:

最后，给出了一些指导原则

虽然以下原则不是强制性的，但是根据我们的经验遵循它们可以使您的代码更加健壮、可测试和可维护。

您在清单中定义的所有组件-活动、服务、广播接收器...不是数据源。因为每个组件的生命周期都挺短的，而且要看当前用户和设备的交互以及系统的运行状态。简单地说，这些组件不应该用作应用程序的数据源。

在你应用的模块之间建立清晰的责任界限。例如，不要将与数据缓存无关的代码放在同一个类中。

每个模块尽可能少地公开内部实现。从以往的经验来看，千万不要为了一时的方便而直接暴露大量的内部实现。这会让你以后背负沉重的技术债务(新技术很难替代)。

在定义模块之间的交互时，请考虑如何尽可能隔离每个模块，并通过设计良好的API进行交互。

你的应用程序的核心应该是让它脱颖而出的东西。不要浪费时间构建轮子或一遍又一遍地编写相同的模板代码。相反，您应该集中精力使您的应用程序变得独特，并将一些重复的工作交给Android架构组件或这里介绍的其他优秀的库。

尽可能保留数据，以便您的应用程序在脱机模式下仍然可用。虽然你可能喜欢快速的网络，但你的用户可能不喜欢。

本文不再贴出相关代码。请查看官方文件，了解每个图书馆的具体用途

附上正式的演示项目: