Android应用程序架构

Android Application Architecture

我们从标准活动和AsyncTasks到由RxJava支持的基于MVP的现代架构的旅程。

Android开发生态系统变得非常快。每周都会创建新工具，更新Lib，写博客文章和发言。如果你去度假一个月，当你回来的时候会有一个新版本的支持库和/或Play服务。

我已经使用ribot团队制作Android应用程序三年多了。在此期间，我们用于构建Android应用程序的架构和技术不断发展。本文将通过解释我们的学习，错误和这些架构变化背后的推理，带您走过这段旅程。
旧时代
回到2012年，我们的代码库用于遵循基本结构。我们没有使用任何网络库，AsyncTasks仍然是我们的朋友。下图显示了大致的架构。

初始架构

代码分为两层：负责从REST API和持久性数据存储检索/保存数据的数据层;和视图层，其职责是在UI上处理和显示数据。
APIProvider提供了使活动和片段能够轻松地与REST API交互的方法。这些方法使用URLConnection和AsyncTasks在单独的线程中执行网络调用，并通过回调将结果返回到活动。
以类似的方式，CacheProvider包含从SharedPreferences或SQLite数据库检索和存储数据的方法。它还使用回调将结果传递回活动。

问题

这种方法的主要问题是View层有太多的责任。想象一个简单的常见场景，其中应用程序必须加载博客帖子列表，将它们缓存在SQLite数据库中，并最终显示在ListView上。活动必须做到以下几点：
在APIProvider中调用loadPosts（回调）方法
等待APIProvider成功回调，然后在CacheProvider中调用savePosts（callback）。
等待CacheProvider成功回调，然后在ListView上显示帖子。
单独处理来自APIProvider和CacheProvider的两个潜在错误回调。
这是一个非常简单的例子。在实际情况下，REST API可能不会返回视图需要的数据。因此，活动必须以某种方式在显示数据之前转换或过滤数据。另一个常见的情况是loadPosts（）方法接收需要从其他地方获取的参数，例如Play Services SDK提供的电子邮件地址。很可能SDK将使用回调异步返回电子邮件，这意味着我们现在有三个层次的嵌套回调。如果我们继续增加复杂性，这种方法将导致所谓的回调地狱。
综上所述：
活动和碎片变得非常大，难以维护
太多的嵌套回调意味着代码是丑陋的，很难理解这么痛苦地做出更改或添加新的功能。
单元测试变得具有挑战性，如果不是不可能的，因为很多逻辑生活在活动或片段内，是艰苦的单元测试。

一个由RxJava驱动的新架构

我们按照以前的方法约两年。在此期间，我们做了几个改进，轻微缓解了上述问题。例如，我们添加了几个帮助类来减少活动和片段中的代码，我们开始在APIProvider中使用Volley。尽管有这些变化，我们的应用程序代码还不是测试友好的，回调地狱问题仍然发生得太频繁。
直到2014年，我们才开始阅读关于RxJava。在一些示例项目上尝试之后，我们意识到这最终可以是嵌套回调问题的解决方案。如果你不熟悉反应式编程，你可以阅读这个介绍。简而言之，RxJava允许您通过异步流管理数据，并为您提供了许多运算符，您可以应用于流，以便变换，过滤或组合数据。
考虑到我们在过去几年中经历的痛苦，我们开始考虑一个新应用程序的架构如何看起来。所以我们想出了这个。




RxJava驱动架构
与第一种方法类似，该架构可以分为数据层和视图层。数据层包含DataManager和一组帮助程序。视图层由Android框架组件（如Fragments，Activities，ViewGroups等）构成。
辅助类（图中第三列）具有非常具体的职责，并以简明的方式实现它们。例如，大多数项目都有帮助访问REST API，从数据库读取数据或与第三方SDK交互。不同的应用程序将有不同数量的助手，但最常见的是：
PreferencesHelper：在SharedPreferences中读取和保存数据。
DatabaseHelper：处理访问SQLite数据库。
改进服务：执行对REST API的调用。我们开始使用Retrofit而不是Volley，因为它为RxJava提供了支持。它也更好使用。
辅助类中的大多数公共方法将返回RxJava Observable。
DataManager是架构的大脑。它广泛地使用RxJava运算符组合，过滤和转换从辅助类检索的数据。 DataManager的目的是通过提供准备显示的数据来减少Activity和Fragments必须做的工作量，并且通常不需要任何转换。
下面的代码显示了DataManager方法的外观。此示例方法的工作原理如下：
调用Retrofit服务以从REST API加载博客文章列表
使用DatabaseHelper将帖子保存在本地数据库中以进行缓存。
过滤今天写的博客文章，因为那些是唯一的视图层想要显示的。

public Observable<Post> loadTodayPosts() {
        return mRetrofitService.loadPosts()
                .concatMap(new Func1<List<Post>, Observable<Post>>() {
                    @Override
                    public Observable<Post> call(List<Post> apiPosts) {
                        return mDatabaseHelper.savePosts(apiPosts);
                    }
                })
                .filter(new Func1<Post, Boolean>() {
                    @Override
                    public Boolean call(Post post) {
                        return isToday(post.date);
                    }
                });
}

https://gist.github.com/ivacf/b84654c3c5984c84401e/raw/134c4ccf4ffddef58ab8a5caa45d3ad30168e8af/DataManager.java

视图层中的组件（如Activities或Fragments）将简单地调用此方法并订阅返回的Observable。一旦订阅完成，Observable发出的不同的帖子可以直接添加到适配器，以便显示在RecyclerView或类似的。
这种架构的最后一个元素是事件总线。事件总线允许我们广播在数据层中发生的事件，以便视图层中的多个组件可以订阅这些事件。例如，DataManager中的signOut（）方法可以在Observable完成时发布事件，以便订阅此事件的多个活动可以更改其UI以显示签出状态。

为什么这种方法更好？

RxJava Observables和运算符删除了嵌套回调的需要。
DataManager接管以前是视图图层的一部分的职责。因此，它使Activities和Fragments更轻量级。
将活动和片段中的代码移动到DataManager和助手意味着编写单元测试变得更容易。
清楚地分离职责，使DataManager成为与数据层交互的唯一点，使得这种架构对测试友好。辅助类或DataManager可以轻松地嘲笑。

我们还有什么问题？

对于大型和非常复杂的项目，DataManager可能变得过于。肿和难以维护。
虽然视图层组件（如活动和片段）变得更轻量级，但它们仍然需要处理大量关于管理RxJava订阅，分析错误等的逻辑。

在过去一年中，几个架构模式，如MVP或MVVM已经在Android社区中越来越受欢迎。在对示例项目和文章探索这些模式之后，我们发现MVP可以为我们现有的方法带来非常有价值的改进。因为我们当前的架构分为两层（视图和数据），增加MVP感觉自然。我们只需要添加一个新的演示者层，并将代码的一部分从视图移动到演示者。

基于MVP的架构

数据层保持原样，但它现在称为模型，以更加一致的模式的名称。
演示者负责从模型加载数据，并在结果准备好时调用视图中的正确方法。他们订阅由数据管理器返回的Observables。因此，他们必须处理像调度程序和订阅。此外，如果需要，他们可以分析错误代码或对数据流应用额外的操作。例如，如果我们需要过滤一些数据，并且这个相同的过滤器不可能在其他任何地方重复使用，那么在演示者而不是数据管理器中实现它可能更有意义。
下面你可以看到一个公共方法在演示者看起来像。此代码订阅了我们在上一节中定义的dataManager.loadTodayPosts（）方法返回的Observable。



public void loadTodayPosts() {
    mMvpView.showProgressIndicator(true);
    mSubscription = mDataManager.loadTodayPosts().toList()
            .observeOn(AndroidSchedulers.mainThread())
            .subscribeOn(Schedulers.io())
            .subscribe(new Subscriber<List<Post>>() {
                @Override
                public void onCompleted() {
                    mMvpView.showProgressIndicator(false);
                }


                @Override
                public void onError(Throwable e) {
                    mMvpView.showProgressIndicator(false);
                    mMvpView.showError();
                }


                @Override
                public void onNext(List<Post> postsList) {
                    mMvpView.showPosts(postsList);
                }
            });
    }


mMvpView是此演示者正在协助的视图组件。通常MVP视图是一个Activity，Fragment或ViewGroup的实例。
与以前的架构一样，视图层包含标准框架组件，如ViewGroups，Fragments或Activities。主要的区别是这些组件不直接订阅Observable。它们实现了一个MvpView接口，并提供了简单的方法列表，如showError（）或showProgressIndicator（）。视图组件还负责处理诸如点击事件的用户交互，并且通过调用演示者中的正确方法来相应地操作。例如，如果我们有一个加载帖子列表的按钮，我们的Activity将从onClick侦听器调用presenter.loadTodayPosts（）。
如果你想看到这个基于MVP架构的一个完整的工作示例，你可以在GitHub上查看我们的Android Boilerplate项目。您还可以在ribot的架构指南中阅读更多内容。

为什么这种方法更好？

活动和片段变得非常轻量级。他们唯一的职责是设置/更新UI并处理用户事件。因此，它们变得更容易维护。
我们现在可以通过模拟视图层轻松地为演示者编写单元测试。之前，这段代码是视图层的一部分，所以我们不能单元测试它。整个架构变得非常测试友好。
如果数据管理器变得。肿，我们可以通过将一些代码移动到演示者来缓解这个问题。
我们还有什么问题？
当代码库变得非常大和复杂时，拥有单个数据管理器仍然是一个问题。我们还没有达到这是一个真正的问题，但我们知道，它可能发生。
重要的是要提到这不是完美的建筑。事实上，认为有一个独特和完美的，将永远解决你的所有问题是天真的。 Android生态系统将保持快速发展，我们必须通过探索，阅读和实验，以便我们可以找到更好的方式来继续构建优秀的Android应用程序。
我希望你喜欢这篇文章，你发现它有用。如果是这样，不要忘记点击推荐按钮。此外，我很乐意听到你对我们最新方法的想法。

public Observable<Post> loadTodayPosts() {
	return mRetrofitService.loadPosts()
	.concatMap(new Func1<List<Post>, Observable<Post>>() {
	@Override
	public Observable<Post> call(List<Post> apiPosts) {
	return mDatabaseHelper.savePosts(apiPosts);
	}
	})
	.filter(new Func1<Post, Boolean>() {
	@Override
	public Boolean call(Post post) {
	return isToday(post.date);
	}
	});
	}

public Observable<Post> loadTodayPosts() {
        return mRetrofitService.loadPosts()
                .concatMap(new Func1<List<Post>, Observable<Post>>() {
                    @Override
                    public Observable<Post> call(List<Post> apiPosts) {
                        return mDatabaseHelper.savePosts(apiPosts);
                    }
                })
                .filter(new Func1<Post, Boolean>() {
                    @Override
                    public Boolean call(Post post) {
                        return isToday(post.date);
                    }
                });
}