原文链接：https://fernandocejas.com/2014/09/03/architecting-android-the-clean-way/

 

过去的几个月中，在Tuenti上与同行例如@pedro_g_s和@flipper83进行了一些讨论。我决定去写一篇关于Android APP架构的文章。

 

写这个文章的目的是为了向你们展示一些我自己的方法，这些方法已经存在我的脑中好几个月了，主要来自于我自己的学习和研究。

 

我们都知道编写高质量的软件是很难的而且很复杂：这不仅仅是满足需求，而应该是健壮的，易维护的，可测试的和可扩展的。所以提出的“简单的架构”理念是一种好的开发任何软件应用的方法。

 

想法很简单：“简洁架构”代表一组实践方式它的系统包含以下内容：

并不是必须而且只能用4个圈表示(如图上所示），但是这里有一条从属规则必须知道。这个从属规则是：代码的依赖只能是指向内部的，而且只有内圈能知道外圈的内容。也就是外部的圈是无法知道内部圈的内容的。

 

以下是一些能让我们更好的熟悉和理解这个方法的一些名词解释：

 

为了更好的解释，请参考这篇文章和视频。

 

我会通过一个简单的例子来解释这个方案；创建一个简单的APP，这个APP实现的功能是：通过后台云来获取朋友或者用户的列表，当用户点击列表中的一项就会显示一个详细的页面。

 

目的是为了独立业务单元，业务单元对于外围是未知的，然而这个业务单元能够进行独立测试。

 

我提议将工程分成3层来实现，每层都有自己的目的并与其它层独立。

 

因为每层都有自己的数据模型所以才能实现独立（你可以看到在代码中有一个数据映射表被用来进行完成数据的传送,这个是不想通过整个应用使用公用一套模型的代价）

 

以下是原理图：

注释：我没有使用外部的类库（除了使用gson去解析json数据和junit，mockito,robolectic和espresso 用来测试）。这样做的目的就是为了例子更简洁。另外不要讨厌去添加ORMs去存储硬盘数据或者其他相关的注入框架或者其他的工具或者你熟悉的库。（记住不要重复的制造车轮）

 

 

呈现者在这层中由inteactors组成，他们在主UI线程之外的线程上工作，然后通过回调函数来传回数据并更新UI。

 

如果你想要一个更好的关于MVP和MVVM在Android UI的影响，可以看这篇文章。

 

业务规则在这里，所有的逻辑关系也在这里。查看Android 工程，你会发现所有的Interactors的实现在这里。

这一层由无Android无关的纯Java代码构成。所有外部组件使用接口来对业务块进行联系。

 

应用中所有的数据都来自这一层，他们通过UserRepository（这个接口在domain层）的实现，使用Repository Pattern的一种策略，通过工厂模式，获取各种不同的数据源取决于*条件。

 

在实例中，当我们通过Id来获取用户实例的时候，首先会选择磁盘缓存，如果不存在的话会通过网络获取数据然后保存在本地磁盘中。

 

这种机制的前提条件是数据源对于客户端来说是透明的，它不必关系数据是来自内存，磁盘或者是云数据库。只要相信可以获得到数据即可。

注释：在实例中，因为只是为了学习，我通过一个文件系统和android preferences来实现简单和原始的磁盘缓存。再次铭记不要重复造车轮。

 

这个是我们应该总是优先讨论，如果分享你的解决方案会更好。

 

我的策略是使用回调函数，如果一些错误发生在数据库，那么回调会有两个方法onResponse()和onError().第二个方法是会将异常封装在一个叫"ErorBundle"的类中：这个方法会带来一些困难因为存在一个链式的回调，一个接一个的知道错误到了presentation层，但是如果代码写的易读会将这种困难度减低。

另一方面，我会实现一个evetn bus 系统来处理错误事件，这个系统叫GOTO . 在我看来，有时如果订阅太多的事件，但是又没有控制紧密会导致一些事件丢失。

 

对于测试工作，我选了几种对应不同层的解决方案。

 

代码在github上https://github.com/pedrovgs/EffectiveAndroidUI/,对于代码文件夹结构需要说明的是不同的层使用不同的模块。

 

正如Uncle bob 所说“Architecture is about Intent,not Frameworks".我们在工作中总是会遇到各种挑战，但是如果使用这些技术，对于应用可以做到以下：

作为总结我强烈建议你去试试然后分享你的结果和经验。我们相信持续的改进一直是一种好的事情。

 

我希望你能通过本文获得有用的信息。