本文已受权微信公众号 AndroidDeveloper 独家发布。java
入职安居客三年从工程师到 Team Leader,见证了 Android 团队一路走来的发展历程。所以有心将这些记录下来与你们分享,也算是对本身三年来一部分工做的总结。但愿对你们有所帮助,更但愿能获得你们宝贵的建议。android
三年前入职时安居客在业务上刚完成了三网合并(新房、二手房、好租和商业地产多个平台多个网站合成如今的 anjuke.com,这在公司的历史上称之为三网合并),所以移动端也将原先的新房、二手房、好租和商业地产多个 App 合并成为了如今的安居客 App。所谓的合并也差很少就是将多个项目的代码拷贝到了一块儿组成了新的 Anjuke Project。下面这张图能更加直观的呈现当时的情况:git
这一时期代码结构混乱、层次不清,各业务技术方案不统一,冗余代码充斥项目的各个角落;甚至连基本的包结构也是胡乱不堪,项目架构更是无从谈起。你们只不过是不停地往上堆砌代码添加新功能罢了。因而我进入公司的第一件事就是向 Leader 申请梳理了整个项目的结构。github
然后随着项目的迭代,咱们不断引入了 Retrofit、UniversalImageLoader、OKHttp、ButterKnife 等一系列成熟的开源库,同时咱们也开发了本身的 UI 组件库 UIComponent、基础工具库 CommonUtils、基于第三方地图封装的 MapSDK、即时聊天模块 ChatLibrary 等等。这以后安居客项目架构大体演变成了由基础组件层、业务组件层和业务层组成的三层架构。以下图:web
其中业务层是一种非标准的 MVC 架构,Activity 和 Fragment 承担了 View 和 Controller 的职责:数据库
前面这种分层的架构自己是没太大问题的,即便到了如今咱们的业务项目也已然是基于这种分层的架构来构建的,只不过在不断的迭代中咱们作了些许调整(分层架构后面在介绍组件化和模块化的时候会详细介绍)。可是随着业务的不断迭代,咱们慢慢发现业务层这种非标准的MVC架构带来了种种影响团队开发效率的问题:bash
鉴于三网合并时期我还未加入安居客,因此对这一块的理解不免有误差,若是有安居客的老同事发现文章中的描述有不对的地方还望批评指正。微信
一种技术架构没法知足全部的业务项目,更不可能有一种架构方案可以一劳永逸。正如上一节中提到的随着业务的不断迭代,现有架构的缺陷逐渐浮出水面,项目架构必需不断升级迭代才能更好地服务于业务。网络
在研究了 Google 推出的基于 MVP 架构的 Demo 后,咱们发现 MVP 架构能解决如今所面临过的不少问题,因而咱们学习并引入到了咱们的项目中来,并针对性的作了部分调整。下图呈现的是安居客 MVP 方案:
架构
之前面提到的三层架构的方案来看是这样的:
基于此架构我在 GitHub 上开源了一个项目MinimalistWeather,有兴趣的小伙伴能够去 Clone 下来看看,若是以为对你有帮助就给个 Star 吧。 :)
另外这套MVP架构还为咱们带来了一个额外的好处:咱们有了足够明确的开发规范和标准。细致到了每个类应该放到哪一个包下,哪一个类具体应该负责什么职责等等。这对于咱们的 Code Review、接手他人的功能模块等都提供了极大的便利。前面提到的 MinimalistWeather 就是为了定规范定标准而开发的。
这一时期咱们还在项目中引入了 RxJava,很好的解决了前面提到的嵌套回调的问题,同时可以帮助咱们简化复杂业务场景下的代码逻辑(固然 RxJava 的好处远远不止这么一点,对 RxJava 不了解的同窗能够去翻翻我以前一系列关于 RxJava 的文章)。咱们也将网络库升级到了 Retrofit2 + OKHttp3,它们和 RxJava 之间能更好的配合。
是否是升级到了 MVP 架构就高枕无忧了呢?很明显不是这样!MVP 架构也会带来如下新的问题:
去年下半年咱们 Android 团队内部成立了技术小组,基础组件的开发是技术小组很重要的一部分工做,因此组件化是咱们正在作的事;模块化更多的是现有的方案受到来自业务上的挑战以及受到了 Oasis Feng 在 MDCC 上的分享和整个大环境的启发,如今正处于设计规划和 Demo 开发的阶段。
组件化不是个新概念,通俗的讲组件化就是基于可重用的目的,将一个大的软件系统拆分红一个个独立组件。
组件化的带来的好处不言而喻:
如今的安居客有是三个业务团队:安居客用户 App、经纪人 App、集客家 App。为了不各个业务团队重复造轮子,团队中也须要有必定的技术沉淀,所以组件化是必须的。从本篇的第一节你们就能看到组件化的影子,只不过在这以前咱们作的并很差。如今咱们须要提供更多的、职能单1、性能更优的组件供业务团队使用。根据业务相关性,咱们将这些组件分为:基础组件和业务组件。后面在介绍模块化的时候会有进一步的描述。
自从 Oasis Feng 在去年的 MDCC2016 上分享了模块化的经验后,模块化在 Android 社区愈来愈多的被提起。咱们天然也不落俗的去作了一些研究和探索。安居客如今面临不少问题:例如全量编译时间太长(我这台13款的 MacBook Pro 上打一次包得花十多分钟);例如新房、二手房、租房等等模块间耦合严重,不利于多团队并行开发测试;另外在17年初公司从新将租房 App 捡起推广,单独让人来开发维护一个三年前的项目并不划算,因此咱们但愿能直接从如今的安居客用户端中拆分出租房模块做为一个单独的 App 发布上线。这样看来模块化彷佛是一个不错的选择。
因此咱们作模块化的目的大体是这样的:
15年 Trinea 还在安居客的时候开发了一套插件化框架,但受限于当时的团队规模而且插件化对整个项目的改造太大,所以在安居客团队中插件化并未实施下来。而模块化实际上是个很好的过渡方案,将项目按照模块拆分后各业务模块间解耦的问题不存在了,后续若有必要,再进行插件化改造只不过是水到渠成的事。
来看看安居客用户 App 的模块化设计图:
整个项目分为三层,从下往上分别是:
同时针对模块化咱们也须要定义一些本身的游戏规则:
对于模块化项目,每一个单独的 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 吧!