一种更清晰的Android架构

入门指南

我们知道,编写高质量的软件很难,也很复杂:急需要满足需求,又要有稳健性,可维护性,可测试性和灵活性,以适应增长和变化。这就是“干净的架构”出现的地方,在开发任何软件应用程序时可能是一个很好地方法。

这个想法很简单:干净的建筑代表了实践,产生的系统是:

  • 独立于框架
  • 可测试
  • 独立的用户界面
  • 独立的数据库
  • 独立的任何外部结构
一种更清晰的Android架构_第1张图片

不要只用4个圆圈(如图中所示),因为它们只是示意图,但是您应该考虑依赖规则:源代码依赖只能指向内部,并且内圈中得任何东西都不能知道任何关于外圈的事情。

以下是一些与熟悉和理解这种方法的相关名词:

  • 实体:这些是应用程序的业务对象
  • 使用案例:这些使用案例协调实体之间的数据流,也被称为交互者
  • 接口适配器:这组适配器将转换来自用例的实体最方便的格式的数据,也被称为交互者
  • 框架和驱动程序:这是所有细节的地方:UI、工具、框架等

有关更好更广泛地解释,请参阅本文

Android框架

我们从一个简单地场景开始:简单地创建一个小城,显示从服务端中检索到的朋友或用户列表,点击其中的任何一个将打开一个新的界面,显示该用户更多的详细信息。

目的是通过保持业务规则对外界不了解任何事情来区分关注点,从而可以在不依赖任何外部元素的情况下进行测试。

为了达到这个目的,我建议是把项目分成三个不同的层次,每个层次都有自己的职责。

值得一提的时,每一层都是哦那个自己的数据模型,这样就可以实现独立性

一种更清晰的Android架构_第2张图片
image

注意:我没有使用其他的外部库(除了解析json数据的gson和测试用到的junit、mockito、robolectric、espresso),这样使例子更清楚。无论如何,添加ORMs存储磁盘数据或任何依赖注入框架或任何你熟悉的库,可以使开发更轻松愉快。

表现层 (Presentation Layer)

表现层在此,表现的是与视图和动画相关的逻辑。这里仅用了一个Model View Presenter(下文简称MVP),但是大家也可以用MVC或MVVM等模式。这里我不再赘述细节,但是需要强调的是,这里的fragment和activity都是View,其内部除了UI逻辑以外没有其他逻辑,这也是所有渲染的东西发生的地方。

本层次的Presenter由多个interactor(用例)组成,Presenter在 android UI 线程以外的新线程里工作,并通过回调将要渲染到View上的数据传递回来。


一种更清晰的Android架构_第3张图片
mvp

如果你需要一个使用MVP和MVVM的Effective Android UI典型案例,可以参考我朋友Pedro Gómez的文章。

领域层 (Domain Layer)

这里的业务规则是指所有在本层发生的逻辑。对于Android项目来说,大家还可以看到所有的interactor(用例)实施。这一层是纯粹的java模块,没有任何的Android依赖性。当涉及到业务对象时,所有的外部组件都使用接口。

一种更清晰的Android架构_第4张图片
domain

数据层 (Data Layer)

应用所需的所有数据都来自这一层中的UserRepository实现(接口在领域层)。这一实现采用了Repository Pattern,主要策略是通过一个工厂根据一定的条件选取不同的数据来源。
比如,通过ID获取一个用户时,如果这个用户在缓存中已经存在,则硬盘缓存数据源会被选中,否则会通过向云端发起请求获取数据,然后存储到硬盘缓存。
这一切背后的原理是由于原始数据对于客户端是透明的,客户端并不关心数据是来源于内存、硬盘还是云端,它需要关心的是数据可以正确地获取到。

![data](http://upload-images.jianshu.io/upload_images/595349-6caa3a650b0f7e7f.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240

注:在代码方面,出于学习目的,我通过文件系统和Android preference实现了一个简单、原始的硬盘缓存。请记住,如果已经存在了能够完成这些工作的库,就不要重复制造轮子。

错误处理

这是一个长期待解决的讨论话题,如果大家能够分享各自的解决方案,那真真是极好的。

我的策略是使用回调,这样的话,如果数据仓库发生了变化,回调有两个方法:onResponse()和onError(). onError方法将异常信息封装到一个ErrorBundle对象中: 这种方法的难点在于这其中会存在一环扣一环的回调链,错误会沿着这条回调链到达展示层。因此会牺牲一点代码的可读性。另外,如果出现错误,我本来可以通过事件总线系统抛出事件,但是这种实现方式类似于使用C语言的goto语法。在我看来,当你订阅多个事件时,如果不能很好的控制,你可能会被弄得晕头转向。

测试

关于测试方面,我根据不同的层来选择不同的方法:

  • 展示层 ( Presentation Layer) : 使用android instrumentation和 espresso进行集成和功能测试
  • 领域层 ( Domain Layer) : 使用JUnit和Mockito进行单元测试;
  • 数据层 ( Data Layer) : 使用Robolectric ( 因为依赖于Android SDK中的类 )进行集成测试和单元测试。

代码展示

我猜你现在在想,扯了那么久的淡,代码究竟在哪里呢? 好吧,这就是你可以找到上述解决方案的github链接。还要提一点,在文件夹结构方面,不同的层是通过以下不同的模块反应的:

  • presentation: 展示层的Android模块
  • domain: 一个没有android依赖的java模块
  • data: 一个数据获取来源的android模块。
  • data-test: 数据层测试,由于使用Robolectric 存在一些限制,所以我得再独立的java模块中使用。

结论

正如 Bob大叔 所说:“Architecture is About Intent, not Frameworks” ,我非常同意这个说法,当然了,有很多不同的方法做不同的事情(不同的实现方法),我很确定,你每天(像我一样)会面临很多挑战,但是遵循这些方法,可以确保你的应用会:

  • 易维护 Easy to maintain
  • 易测试 Easy to tes.
  • 高内聚 Very cohesive.
  • 低耦合 Decoupled.

最后,我强烈推荐你去实践一下,并且分享你的经验。也许你会找到更好的解决方案:我们都知道,不断提升自己是一件件非常好的事。我希望这篇文章对你有所帮助,欢迎拍砖。

参考资料

Source code: https://github.com/android10/Android-CleanArchitecture

  • The clean architecture by Uncle Bob
  • Architecture is about Intent, not Frameworks
  • Model View Presenter
  • Repository Pattern by Martin Fowler
  • Android Design Patterns Presentatio

你可能感兴趣的:(一种更清晰的Android架构)