图文详解Android架构设计原则教程

     架构是什么？架构又名软件架构，是有关软件整体结构与组件的抽象描述，是用于指导大型软件系统各个方面的设计。架构描述语言(ADL)用于描述软件的体系架构。现在已有多种架构描述语言，如Wright(由卡内基梅隆大学开发)，Acme(由卡内基梅隆大学开发)，C2(由UCI开发)，Darwin(由伦敦帝国学院开发)。ADL的基本构成包括组件、连接器和配置。　

    那么安卓软件架构是软件设计必须能够帮助开发者发展和扩充解决方案，保持代码清晰健壮，并且可扩展，易于维护，而不必每件事都重写代码。面对软件存在的问题，也必须遵守SOLID原则，不要过度工程化，尽可能降低框架中模块的依赖性。

　　经过一段时间的信息的反馈以及资料的搜集，我认为构建现代移动应用(Android)的好方法是在这里，那么下面讲讲我们Android架构设计原则。

　　架构演变

　　演变意味着一个循序渐进的过程，由某些状态改变到另一种不同的状态，且新状态通常更好或更复杂。

　　依此一说，软件是随着时间发展和改变的，更多的是在架构上的发展和改变。而实际上，一款好的软件设计必须能够帮助我们发展和扩充解决方案，也必须保持其健壮性，而不必每件事都需要重写代码。

　　那么在这篇文章中，我们详细讲解我个人认为之重中之重的要点，为了保持基本代码条理清晰，要记住下面这张图片，我们开始吧!

　　响应式方法：Rxjava

　　关于这方面的文章有很多，还有做方面事和精英的人都有很多，所以我不打算在这里讨论RxJava的好处(我假设您已经对它有所体验了)。但是，我将指出在Android应用程序开发方面的有趣之处，以及如何帮助我形成第一个清晰的架构的方法。

　　首先，我需要选择一种响应式的模式通过转换usecase(在这个清晰的架构命名规则中，其被称为interactor)返回Observables，表示所有底层都遵循这一链条，也返回Observables 。

　　如你所见，所有用例继承这个抽象类，并实现抽象方法buildUseCaseObservable()。该方法将建立一个Observables，它承担了繁重的工作，并且还要返回所需的数据。

　　需要强调是，在execute()方法中，因为要确保Observables 是在独立线程执行，所以要尽可能减轻阻止android主线程的程度。而其结果就是会通过android主线程调度程序将主线程压入线程队列的尾部(push back)。

　　到目前为止，我们的Observables启动并且运行了。但也必须要观察它所发出的数据序列。要做到这一点，我需要改进presenters(MVP模式表现层的一部分)，把它变成了观察者(Subscribers)，它通过用例对发出的项目做出“react”，以便更新用户界面。

　　观察者是这样的：

　　每个观察者都是每个presenter的内部类，并实现了一个Defaultsubscriber接口，创建了基本的默认错误处理。

　　将所有的片段放在一起后，通过下面的图，你可以获得完整的概念：

　　下面让我们列举一些摆脱基于RxJava方法的好处：

　　在观察者(Subscribers)与被观察者(Observables)之间去耦合：更加易于维护和测试。

　　简化异步任务：如果要求多个异步执行时，如果需要一个以上异步执行的级别，Java的thread和future的操作和同步比较复杂，因此通过使用调度程序，我们可以很方便地(不需要额外工作)在后台与主线程之间跳转，特别是当我们需要更新UI时。还可以避免“回调的坑”—— 它使我们代码可读性差，且难以跟进。

　　数据转换/组成：在不影响客户端情况下，我们能够整合多个Observables，使解决方案更灵活。

　　错误处理：在任何Observables内发生错误时，就向消费者发出信号。

　　从我的角度看有一点不足，甚至要为此需要付出代价，那些还不熟悉概念的开发人员还是要遵循学习曲线。但你从中得到了极有价值的东西。为了成功而reactive起来吧!

　　依赖注入：Dagger 2

　　关于依赖注入，在这就不一一介绍了，有兴趣可以查找我们网站上的相关内容学习或者到网上搜索学习，那么我们接着说下面的内容了。

　　值得一提的是，通过实现一个像Dagger 2那样的依赖注入框架我们能够获得：

　　组件重用，因为依赖的对象可以在外部注入和配置。

　　当注入对象作为协作者(collaborators)时，由于对象的实例存在于在一个隔离和解耦地方，这样在我们的代码库中，就不需要做很多的改变，就可以改变任何对象的实现。

　　依赖可以注入到一个组件：这些将这些模拟实现的依赖对象注入成为可能，这使得测试更容易。

　　Lambda表达式：Retrolambda

　　没有人会抱怨在代码中使用Java 8的lambada表达式，甚至在简化并摆脱了很多样板代码以后，使用得更多，如你看到这段代码：

　　然而，我百感交集，为什么呢?我们曾在@SoundCloud讨论Retrolambada，主要是是否使用它，结果是：

　　1. 赞成的理由：

　　1）Lambda表达式和方法引用

　　2）“try-with-resources”语句

　　3）使用karma做开发

　　2. 反对的理由：

　　1）Java 8 API的意外使用

　　2）十分令人反感的第三方库

　　3）要与Android一起使用的第三方插件Gradle

　　最后，我们认定它不能为我们解决任何问题：你的代码看起来很好且具有可读性，但这不是我们与之共存的东西，由于现在所有功能最强大的IDE都包含代码折叠式选项，这就涵盖这一需求了，至少是一个可接受的方式。

　　说实在的，我们尽管在其他业余时间可能会使用到它，但在这里使用它的主要原因是尝试和体验Android中Lambda表达式。是否使用它由你自己决定。但在这里我只是展示我的视野。

　　测试方法

　　在测试方面，与示例的第一个版本相关的部分变化不大：

　　表现层：用Espresso 2和Android Instrumentation测试框架测试UI。

　　领域层：JUnit + Mockito —— 它是Java的标准模块。

　　数据层：将测试组合换成了Robolectric 3 + JUnit + Mockito。这一层的测试曾经存在于单独的Android模块。由于当时(当前示例程序的第一个版本)没有内置单元测试的支持，也没有建立像robolectric那样的框架，该框架比较复杂，需要一群黑客的帮忙才能让其正常工作。

　　幸运的是，这都是过去的一部分，而现在所有都是即刻可用，这样我可以把它们重新放到数据模块内，专门为其默认的测试路径：src/test/java。

　　包的组织

　　个人认为一个好的架构关键因素之一是代码/包的组织：程序员浏览源代码遇到的第一件事情就是包结构。一切从它流出，一切依赖于它。

　　我们也能够辨别出将应用程序封装进入包(package)的2个路径：

　　按层分包：每一个包(package)中包含的项通常不是彼此密切相关的。这样包的内聚性低、模块化程度低，包之间偶合度高。因此，编辑某个特性要编辑来自不同包的文件。另外，单次操作几乎不可能删除掉某个功能特性。

　　按特性分包：用包来体现特性集。把所有相关某一特性(且仅特性相关)的项放入一个包中。这样包的内聚性高，模块化程度高，包之间偶合度低。紧密相关的项放在一起。它们没有分散到整个应用程序中。

　　我的建议是去掉按特性分包，会带来的好处有以下主要几点：

　　1.模块化程度更高

　　2.代码导航更容易

　　3.功能特性的作用域范围最小化了

　　倘若与功能特性团队一起工作(比如我们在@SoundCloud的所作所为)，也会是非常有趣的事情。代码的所有权会更容易组织，也更容易被模块化。在许多开发人员共用一个代码库的成长型组织当中，这也是一种成功的体现。

　　正如你所见的，我的方法看起来就像按层分包：这里我可能会犯错(例如，在“users”下组织一切)，但在这种情况下我会原谅自己，因为这是个以学习为目的的例子，而且我想显示的是清晰架构方法的主要概念。领会其意，切勿盲目模仿:-)。

　　还需要做的事：组织构建逻辑

　　都知道建房时是需要从地基开始，一切都要打好基础，而软件开发也是这样，其实我想要表达的是，从我的角度来看，构建系统(及其组织)是软件架构的重要部分。

　　在Android平台上，我们采用Gradle，它其实是一种与平台无关的构建系统，功能非常强大。这里的想法是通过一些提示和技巧，让你组织构建应用程序时能够得到简化。

　　在单独的gradle构建文件中按功能对内容进行分组

　　因此，你可以用“apply from: ‘buildsystem/ci.gradle’”插入到任何Gradle建立的文件中进行配置。不要把所有都放置在一个build.gradle文件中，否则就是去创建一个怪物，这是教训。

　　创建依赖关系图

　　如果想在项目的不同模块间重用相同的组件版本，这很好;否则就要在不同的模块间使用不同的版本的组件依赖。另外一点，你是在同一个地方控制依赖关系，像组件版本发生冲突这样的事情一眼就能看出来。

　　结语

　　到这，安卓架构的内容基本介绍完了，重要的是好的软件架构会帮助代码保持清晰和健壮，还可以保持代码的可扩展性，易于维护。

　　现在我想指出一些事情。面对软件存在的问题，要报以本应当解决的态度：

　　1.遵守SOLID原则

　　2.不要过度思考(不过度工程化)

　　3.务实

　　4.尽可能降低(Android)框架中模块的依赖性

     小结里一下上文，现在整理一下整篇文章的内容，上文主要是介绍了安卓架构的原则，首先是从架构演变说起，到RxJava的响应方式方法，粗略带过Dagger 2和Lambda表达式——Retrolambda，最后详细讲解了测试的方法和包的组织，基本内容就这么多，详细的内容看回原文，或者在本站查找相关内容观看。