android应用程序结构_Android应用程序的生产级体系结构[第1部分]

android应用程序结构

语境

我认为是时候写一系列有关如何设计适当的可伸缩体系结构的文章了，您可以将其应用于任何中型项目 。 本系列文章是我从为不同公司从事不同项目所学到的所有知识的总和。 出于明显的原因，我无法透露任何信息，但是我可以告诉您，我已经在社交网络应用程序，游轮应用程序，飞机应用程序，电子商务应用程序，无线电流应用程序和银行应用程序的项目中工作。 在所有这些不同的项目上工作都教会了我在做大型项目时需要谨记的要做和不做的事情。 有些事情与技术本身有关 ，有些事情与您选择应用的体系结构将如何影响您的工程团队有关 。

在你开始前

本文假定您处于半高级或高级级别 。 这意味着您可以轻松使用与Android开发相关的最著名技术，例如Dagger，Kotlin，RxJava，与Google相关的库（FCM，Remote Config，Crashlytics），以及显然是Android SDK。

我将开始讨论技术堆栈设置 ，然后显示我为本文创建的示例应用程序 ，然后在下一篇文章中，我将遍历体系结构的每个层 。

技术堆栈设置

从前一段时间以来，我一直从MVP永久迁移到MVVM，因为MVVM通过Android的LiveData和ViewModels成为第一个受官方支持的 Android体系结构。 而且，由于本文旨在针对大规模体系结构，因此它将成为具有功能模块 ， 核心模块和基本模块的多模块体系结构。

我将在这里使用的技术是： 使用Dagger进行依赖注入，使用OkHttp / Retrofit作为我的网络层，使用RxJava将网络层包装到存储库中。

示例应用

我已经创建了一个 示例应用程序作为该体系结构工作原理的一个示例（无双关）。 此示例应用程序显示了不同的现实场景，其中我们必须使用缓存，执行搜索，混合不同的端点等。

每个功能模块都显示不同的用例和不同的场景。 我经常看到，当您在线查找示例时，只会看到最直接，最简单，最不现实的情况¹。 例如，仅从后端获取某些内容并将其显示在UI上。 以我的个人经验，这不是现实世界的发展方式。 在现实世界中，您将不得不在公司内部使用不同的资源来回移动，并且由于不同的约束，您可能不得不使用一些不错的API端点²，或者可能必须使用不同的端点向用户显示全部信息。

RxJava示例1

“ RxJava示例＃1”显示了我们如何有条件地将两个API调用压缩在一起。

在此示例中，我们使用两个不同的端点来获取“最近查看的新闻”和常规的分页新闻。 如果我们执行“从上到下刷新”或从头开始打开“活动”，则将同时获取最近查看的新闻和分页新闻的第一页。 如果我们继续向下滚动直到到达下一页，我们将仅调用API来获取第二页。

此示例还处理错误情况，例如在没有Internet连接的情况下进行“推入刷新”。

RxJava示例＃2

“ RxJava示例2”显示了如何通过RxJava压缩来自不同端点的响应。

在此示例中，我们压缩了来自两个不同端点的响应，一个端点提供用户的“业务技能信息”，另一个端点提供用户的“个人信息”。 我们通过RxJava将这些请求压缩在一起，并使用包装对象来携带响应。 此外，我们为每个端点处理不同的错误情况，并相应地更新UI。

本示例支持“按需刷新”行为，不处理任何Internet连接状态。

缓存示例

“缓存示例”显示了我们如何使用缓存存储库和网络存储库向用户显示数据，动态更新数据，而无需使用任何EventBus技术，而是依靠Room的Flowable将这些更新导入UI。

在此示例中，我们从ApiAry上的模拟终结点主机获取配方列表，将这些配方存储在缓存中，并允许用户为配方添加书签。 当我们为食谱添加书签时，我们可以立即看到更改反映在食谱列表中，这要归功于Room's Flowables。

此示例还支持“从上到下”行为，并处理不同的错误状态，例如尝试在没有Internet连接的情况下获取配方列表。

LiveData示例

“ LiveData示例”显示了如何依靠LiveData来实现复杂的搜索。

在此示例中，我们可以使用Imgur API搜索图像帖子，通过此API，我们可以使用查询字符串作为搜索词进行搜索，并且我们有一些过滤选项。 我们可以选择是否要获取最新帖子（顶部）或是否要获取最流行的帖子（病毒式）。 如果我们选择按热门帖子过滤，我们还可以指定日期窗口，从day ， week或month中获取热门帖子。

本示例支持处理“上拉至刷新”手势和分页。 此外，我们会处理不同的错误状态，例如尝试在没有互联网连接的情况下搜索某些内容（如果看到内容，则会显示Snackbar；如果从头开始打开“活动”，则会显示完整的错误状态）。

所有这些都是通过LiveData完成的。

笔记

[1]通过不现实的场景，我的意思是当您浏览文章时，它们将向您展示如何获取数据，如何将其保存在缓存中以及如何在RecyclerView上显示它们。 一切都很好。 但是，如果获取500（内部错误）会发生什么？ 如果获取304（未修改）会怎样？ 您是否浪费时间并将重复的响应存储在缓存中？ 如果没有互联网连接会怎样？ 大多数文章实际上都忽略了所有这些极有可能在现实世界中发生的极端情况。

[2]有些人可能会争辩说，如果要做到这一点，您应该继续前进，并满足于您所想要的一切。 但这不是公司的运作方式。 公司需要交付产品。 后端和前端开发人员有最后期限，并且试图修复终结点，以便使其对移动设备更加友好，这可能会花费一些时间，而后端资源却没有时间。

翻译自: https://hackernoon.com/a-production-level-architecture-for-android-apps-part-1-5j2z3a11

android应用程序结构