Android架构实战（一）—— 核心思想

经过对一种更清晰的Android架构的学习，并进行了一定的实战摸索后，也算是对这种Android架构有了一定的了解。由于该架构作者的DEMO比较简单，在实际运用的时候也遇到了许多坑，在自己摸索之后，基本构建出了一套比较满意的架构出来。接下来就会分几部分对这个过程中的经验进行总结，有不足的地方欢迎指出。在看本文之前，建议先阅读一种更清晰的Android架构， 对正题概念有一个了解。

下面进入正题，先对原文进行一下概括和讲解。

一、简介

大型程序的开发思想都一样，“高内聚，低耦合”。然而在实际开发过程，由于模块功能划分的不合理，往往会导致结构错综复杂，依赖关系混乱，开发人员想解耦也无从下手。因此，在开发之前，根据需求对整体的模块进行划分是一个非常有必要的过程。规划过程中，要尽量减少依赖关系，保持模块之间功能的独立性，这样不仅可以大大提高开发效率，维护工作也会变得更加容易。

在原文中，作者给出了这样一个模块分类思想：

• UI：这个很简单，展示层。要注意的是，在UI层中要尽量的避免任何逻辑处理，应该只是负责接收并展示数据这样一个功能。同时，对UI层接收到的事件，应当直接传递给Presenter层进行处理。
• Presenters：MVP架构的中的逻辑处理者。用来做界面层面的逻辑处理，支配UI层面的展示效果。
• Use Cases：Use Cases相当于Presenter和Entity之间的一个桥梁，在RxJava中是一个重要的概念。
• Entities：Entities是数据 处理的终端，不论数据从哪来，到哪去，都应该在Entities中进行实践

在这个设计中，其实作者想强调的是功能分类，单向依赖。不得不说，这样一个设计确实是很优美的。然而在实际开发中，想要真正的做到单向依赖是很难的，特别是UI和presenter之间。例如，一个Button接收到点击事件想要传递给Presenter，则必须持有Presenter的直接引用，并调用其中的方法。因此，我认为在这个架构中，并不需要过分的强调单向依赖，相邻层直接的相互关系是可以接受的（当然，要尽量避免，因为双向依赖比单向依赖更难以维护），但是一定要确保不会产生隔层的依赖关系。这样就可以基本确保整个程序的架构不会产生混乱。

二、Android应用架构

原文给出的架构如下：

原文的想法是希望尽可能对功能模块进行分离。其中Presentation层是采用MVP框架进行展示，Domain层即为Use Cases，进行接口和规则的定义，DataLayer即为数据层。同时原文还指出，每个层之间，应当用自己的类来封装数据，层与层直接通过Mapper来进行数据类的转换。另外，层与层直接的调用，也应当是通过接口来完成的。

如果对于一个多人开发的协作项目来说，这样的分层思想是很好的，因为各个开发人员基本可以进行独立开发，最后再去对接口进行维护即可。但是对于只有1-3个人开发的项目来说，这样一个架构的实用性较低。这是因为过多的层级导致了逻辑链的冗余，即，每开发一个新的功能，对每一个层级中都需要增加相应的类、数据、逻辑等，实现起来会相当的啰嗦。

因此，我在实际开发过程中， 稍微省去了几个必要的步骤：

• 首先，是对层级的处理。在这个三层结构中，在Presentation层设置独立的一个MVP架构会显得相当的冗余，其中的Model功能基本架空。因此，在开发过程，我会将架构还原为一开始提到的4个圈的架构上，使用View-Presenter-UseCase-Model的交互模型。这样一来，开发链就缩短了很多。同时，对于相对独立且复用性较低的功能，每个层级之间也可以适当省去接口的引用方式，直接进行交互，可以省去部分冗余代码。
• 对于数据的包装上，我往往也是直接定义一个全局的数据类进行封装。因为，在开发中为每一个模块去定义一个单独的数据类是很麻烦的一件事，而且还需要为模块与模块之间去实现数据类的转换逻辑。在实际开发中，数据类的结构往往是相同的，因此，完全可以共享，直接传递引用。

注意：以上这些省略操作，仅仅是针对个人或者小型团队开发来说的。对于一个大型的团队和项目，去遵守一整套完整的规则是有必要的。用相对冗余的代码去提高协作性，在开发中是一个很常见的技巧。

三、总结

在这里，我对 一种更清晰的Android架构进行了一个比较概括的介绍，希望大家能够对其基本思想有一个了解。 在这之后，我也会对这之中涉及的一些知识点进行单独的介绍。

当然，这个结构仅仅代表一种开发思路，实际开发过程中遇到的场景往往会比较复杂。因此，理解其设计思想，在开发过程中针对具体问题，按照这个思想去进行解决才是关键。对于一个开发人员来说，通过不断的实践，尝试新的思路，解决遇到的问题，并加以总结，才是提升个人技能的最佳途径。