安居客Android项目架构演进

这里写图片描写叙述

本文已授权微信公众号 AndroidDeveloper 独家公布。

入职安居客三年从project师到 Team Leader，见证了 Android 团队一路走来的发展历程。因此有心将这些记录下来与大家分享。也算是对自己三年来一部分工作的总结。

希望对大家有所帮助。更希望能得到大家宝贵的建议。

三网合并

三年前入职时安居客在业务上刚完毕了三网合并（新房、二手房、好租和商业地产多个平台多个站点合成如今的 anjuke.com。这在公司的历史上称之为三网合并）,因此移动端也将原先的新房、二手房、好租和商业地产多个 App 合并成为了如今的安居客 App。所谓的合并也差点儿相同就是将多个项目的代码复制到了一起组成了新的 Anjuke Project。以下这张图能更加直观的呈现当时的状况：

图片名称

这一时期代码结构混乱、层次不清，各业务技术方案不统一，冗余代码充斥项目的各个角落。甚至连主要的包结构也是胡乱不堪。项目架构更是无从谈起。

大家仅仅只是是不停地往上堆砌代码增加新功能罢了。于是我进入公司的第一件事就是向 Leader 申请梳理了整个项目的结构。

而后随着项目的迭代，我们不断引入了 Retrofit、UniversalImageLoader、OKHttp、ButterKnife 等一系列成熟的开源库，同一时候我们也开发了自己的 UI 组件库 UIComponent、基础工具库 CommonUtils、基于第三方地图封装的 MapSDK、即时聊天模块 ChatLibrary 等等。这之后安居客项目架构大致演变成了由基础组件层、业务组件层和业务层组成的三层架构。

例如以下图：

图片名称

当中业务层是一种非标准的 MVC 架构，Activity 和 Fragment 承担了 View 和 Controller 的职责：

图片名称

前面这样的分层的架构本身是没太大问题的。即使到了如今我们的业务项目也已然是基于这样的分层的架构来构建的，仅仅只是在不断的迭代中我们做了些许调整（分层架构后面在介绍组件化和模块化的时候会具体介绍）。可是随着业务的不断迭代,我们慢慢发现业务层这样的非标准的MVC架构带来了种种影响团队开发效率的问题：

  • Activity 和 Fragment 越来越多的同一时候承担了 Controller 和 View 的职责，导致他们变得及其臃肿且难以维护；
  • 因为 Controller 和 View 的揉合，导致单元測试起来非常困难。
  • 回调嵌套太多。面对负责业务时的代码逻辑不清晰，难以理解且不利于后期维护；
  • 各层次模块之间职责不清晰等等

鉴于三网合并时期我还未增加安居客，所以对这一块的理解难免有偏差，假设有安居客的老同事发现文章中的描写叙述有不正确的地方还望批评指正。

由 RxJava 驱动的 MVP 架构

一种技术架构无法满足全部的业务项目。更不可能有一种架构方案能够一劳永逸。

正如上一节中提到的随着业务的不断迭代。现有架构的缺陷逐渐浮出水面，项目架构必需不断升级迭代才干更好地服务于业务。

MVP 的设计与实现

在研究了 Google 推出的基于 MVP 架构的 Demo 后，我们发现 MVP 架构能解决如今所面临过的非常多问题，于是我们学习并引入到了我们的项目中来，并针对性的做了部分调整。

下图呈现的是安居客 MVP 方案：
这里写图片描写叙述

曾经面提到的三层架构的方案来看是这样的：

图片名称

基于此架构我在 GitHub 上开源了一个项目MinimalistWeather，有兴趣的小伙伴能够去 Clone 下来看看。假设认为对你有帮助就给个 Star 吧。 :)

  • View Layer: 仅仅负责 UI 的绘制呈现，包括 Fragment 和一些自己定义的 UI 组件，View 层须要实现 ViewInterface 接口。

    Activity 在项目中不再负责 View 的职责。仅仅是一个全局的控制者。负责创建 View 和 Presenter 的实例；

  • Model Layer: 负责检索、存储、操作数据。包括来自网络、数据库、磁盘文件和SharedPreferences的数据。
  • Presenter Layer: 作为 View Layer 和 Module Layer 的之间的纽带，它从 Model 层中获取数据，然后调用 View 的接口去控制 View。
  • Contract: 我们參照 Google 的 Demo 增加契约类 Contract 来统一管理 View 和 Presenter 的接口。使得某一功能模块的接口能更加直观的呈现出来。这样做是有利于后期维护的。

另外这套MVP架构还为我们带来了一个额外的优点：我们有了足够明白的开发规范和标准。

仔细到了每一个类应该放到哪个包下，哪个类具体应该负责什么职责等等。这对于我们的 Code Review、接手他人的功能模块等都提供了极大的便利。

前面提到的 MinimalistWeather 就是为了定规范定标准而开发的。

这一时期我们还在项目中引入了 RxJava。非常好的攻克了前面提到的嵌套回调的问题，同一时候能够帮助我们简化复杂业务场景下的代码逻辑（当然 RxJava 的优点远远不止这么一点，对 RxJava 不了解的同学能够去翻翻我之前一系列关于 RxJava 的文章）。我们也将网络库升级到了 Retrofit2 + OKHttp3，它们和 RxJava 之间能更好的配合。

MVP 带来的新问题及解决方式

是不是升级到了 MVP 架构就高枕无忧了呢？非常明显不是这样！MVP 架构也会带来以下新的问题：

  • 因为大量的业务逻辑处理转移到了 Presenter 层，在一些复杂的业务场景中 Presenter 相同会变得臃肿难懂。细心的同学可能注意到了前面的架构图中的 Model 层有个 Data Repository 模块，Data Repository 在这里有两个作用：一是能够将原本由 Presenter 处理的部分逻辑转移到这里来处理，包括数据的校验、部分单纯仅仅与数据相关的逻辑等等，向 Presenter 屏蔽数据处理细节，比方作为 Presenter 就不必关心 Model 层传递过来的数据究竟是来至网络还是来至数据库还是来至本地文件等等；二是我们引入了 RxJava，可是仅仅有网络层中的 Retrofit 能返回 Observable 对象，其它模块都是返回的还是一些非 Observable 的 Java 对象，为了能在整个 Presenter 层中都体验 RxJava 带来的美妙之处，因此能够通过 Data Repository 做一层转换。
  • 如今的 MVP 架构中最重的部分就是 Model Layer 了，这一点从前面的架构图中就能体现。

    因此这就要求我们在 Model 层的设计过程中职责划分要足够清晰。分包更明白，耦合度更低。至于分包大家能够參考 MinimalistWeather 的方案：db 包为数据库模块、http 包为网络模块、preference 包是对 SharedPreferences 的一些封装、repository 包就是前面提到的 Data Repository 模块；

  • 同一时候另一点须要注意，非常多人在使用 RxJava 的过程中往往忘记了对生命周期的管理，这非常easy造成内存泄露。MinimalistWeather 中採用了 CompositeSubscription 来管理。你也能够使用 RxLifecycle 这类开源库来管理生命周期。

组件化与模块化

去年下半年我们 Android 团队内部成立了技术小组，基础组件的开发是技术小组非常重要的一部分工作，所以组件化是我们正在做的事；模块化很多其它的是现有的方案受到来自业务上的挑战以及受到了 Oasis Feng 在 MDCC 上的分享和整个大环境的启示，如今正处于设计规划和 Demo 开发的阶段。

组件化

组件化不是个新概念。通俗的讲组件化就是基于可重用的目的。将一个大的软件系统拆分成一个个独立组件。

组件化的带来的优点不言而喻：

  • 避免反复造轮子，节省开发维护成本；
  • 减少项目复杂性。提升开发效率；
  • 多个团队公用同一个组件，在一定层度上确保了技术方案的统一性。

如今的安居客有是三个业务团队：安居客用户 App、经纪人 App、集客家 App。为了避免各个业务团队反复造轮子，团队中也须要有一定的技术沉淀，因此组件化是必须的。从本篇的第一节大家就能看到组件化的影子，仅仅只是在这之前我们做的并不好。

如今我们须要提供很多其它的、职能单一、性能更优的组件供业务团队使用。依据业务相关性。我们将这些组件分为：基础组件和业务组件。后面在介绍模块化的时候会有进一步的描写叙述。

模块化

自从 Oasis Feng 在去年的 MDCC2016 上分享了模块化的经验后，模块化在 Android 社区越来越多的被提起。

我们自然也不落俗的去做了一些研究和探索。

安居客如今面临非常多问题：比如全量编译时间太长（我这台13款的 MacBook Pro 上打一次包得花十多分钟）；比如新房、二手房、租房等等模块间耦合严重。不利于多团队并行开发測试；另外在17年初公司又一次将租房 App 捡起推广，单独让人来开发维护一个三年前的项目并不划算，所以我们希望能直接从如今的安居客用户端中拆分出租房模块作为一个单独的 App 公布上线。

这样看来模块化似乎是一个不错的选择。

所以我们做模块化的目的大致是这样的：

  • 业务模块间解耦
  • 单个业务模块单独编译打包，加快编译速度
  • 多团队间并行开发、測试
  • 解决好租App须要单独维护的问题。减少研发成本

15年 Trinea 还在安居客的时候开发了一套插件化框架，但受限于当时的团队规模而且插件化对整个项目的改造太大，因此在安居客团队中插件化并未实施下来。而模块化事实上是个非常好的过渡方案，将项目依照模块拆分后各业务模块间解耦的问题不存在了，兴许如有必要。再进行插件化改造仅仅只是是水到渠成的事。

来看看安居客用户 App 的模块化设计图：
这里写图片描写叙述

整个项目分为三层。从下往上各自是：

  • Basic Component Layer: 基础组件层。顾名思义就是一些基础组件，包括了各种开源库以及和业务无关的各种自研工具库；
  • Business Component Layer: 业务组件层，这一层的全部组件都是业务相关的。比如上图中的支付组件 AnjukePay、数据模拟组件 DataSimulator 等等；
  • Business Module Layer: 业务 Module 层，在 Android Studio 中每块业务相应一个单独的 Module。

    比如安居客用户 App 我们就能够拆分成新房 Module、二手房 Module、IM Module 等等。每一个单独的 Business Module 都必须准遵守前面提到的 MVP 架构。

同一时候针对模块化我们也须要定义一些自己的游戏规则:

  • 对于 Business Module Layer。各业务模块之间的通讯跳转採用路由框架 Router 来实现（可能会採用成熟的开源库，也可能会选择反复造轮子）;
  • 对于 Business Component Layer。单一业务组件仅仅能相应某一项具体的业务，对于有个性化需求的对外部提供接口让调用方定制;
  • 合理控制各组件和各业务模块的拆分粒度。太小的公有模块不足以构成单独组件或者模块的，我们先放到相似于 CommonBusiness 的组件中。在后期不断的重构迭代中视情况进行进一步的拆分（这一点的灵感来源于 Trinea 的文章）;
  • 上层的公有的业务或者功能模块能够逐步下放到下层，合理把握好度就好。
  • 各 Layer 间严禁反向依赖，横向依赖关系由各业务 Leader 和技术小组商讨决定。

对于模块化项目，每一个单独的 Business Module 都能够单独编译成 APK。

在开发阶段须要单独打包编译，项目公布的时候又须要它作为项目的一个 Module 来总体编译打包。简单的说就是开发时是 Application，公布时是 Library。因此须要你在 Business Module 的 Gradle 配置文件里增加例如以下代码：

if(isBuildModule.toBoolean()){
    apply plugin: 'com.android.application'
}else{
    apply plugin: 'com.android.library'
}

假设我们须要把租房模块打包成一个单独的租房 App。像以下这样就好：
这里写图片描写叙述

我们能够把 Basic Component Layer 和 Business Component Layer 放在一起看做是 Anjuke SDK，新的业务或者项目仅仅须要依赖 Anjuke SDK 就好（这一点相同是受到了 Trinea 文章的启示）。

甚至我们能够做得更极致一些，开发一套自己的组件管理平台，业务方能够依据自己的需求选择自己须要的组件。定制业务专属的 Anjuke SDK。业务端和 Anjuke SDK 的关系例如以下图所看到的：
这里写图片描写叙述

最后看看安居客模块化的总体设计图：
这里写图片描写叙述

模块化拆分对于安居客这样的比較大型的商业项目而言。因为历史比較久远非常多代码都执行五六年了；各个业务相互交叉耦合严重，所以实施起来还是有非常大难度的。

过程中难免会有预料不到的坑，这就须要我们对各个业务有较深的理解同一时候也要足够的耐心和仔细。

尽管辛苦。可是一旦完毕模块化拆分对整个团队及公司业务上的帮助是非常大的。

以上是我的简单总结以及对模块化的一些思考，不足之处还望大家批评指正。后面模块化的 Demo 完好后我会把它放到 GitHub，并再出一篇文章具体介绍模块化的设计实现细节。

參考资料：

假设你喜欢我的文章。就关注下我的知乎专栏或者在 GitHub 上添个 Star 吧！

posted on 2018-01-28 17:04  yjbjingcha  阅读(456)  评论(0)  编辑  收藏  举报

导航