干货 | 从智行 Android 项目看组件化架构实践

作者简介

陈杰，智行火车票高级开发工程师，目前主要负责智行火车票 Android 客户端的架构和公共基础业务开发，热衷于 Android 技术的研究和开源分享。

一、前言

智行火车票早期以火车票业务起步，随着整体的业务发展和扩张，先后增加了汽车票、机票和酒店模块，逐渐打造成了一个提供出行、旅行和住宿一站式预订服务的 OTA 平台。

在业务扩张过程中，之前 Android 项目单一工程的架构模式慢慢暴露出一些问题，例如业务间耦合较多，整体项目编译耗时等，渐渐无法满足业务开发需求。

为了解决面临的问题，综合主流的 Android 项目架构方案，团队选择了组件化架构方案对项目进行了调整和实践，抽离出基础组件库、独立的业务模块，实现了各独立业务的拆分和独立运行，可以单独进行需求开发，发版时再合并到一起编译打包和发布。

在组件化架构实践过程中，团队解决了组件化调整中遇到的一些难题，对组件化技术在 Android 项目中的应用有一定的参考价值和实践经验。同时根据业务需求，还实现同一个项目进行多个应用差异化适配打包的功能，便于开发和维护团队旗下的其他应用。

二、概述

本文主要根据智行 Android 团队在组件化架构调整中的实践过程以及最终的实践成果，从以下几个方面来进行阐述：

• 为什么要进行组件化架构调整

• 组件化结构调整的实施步骤

• 组件化调整过程中遇到的难题以及解决方案

• 组件化架构调整的成果

2.1 组件化调整的原因和目标

如前面提到的，在调整之前，项目是单一工程的架构模式，这也是常见的 Android 项目架构模式，但是一旦项目整体业务增多，扩张出相对较为独立的业务模块，这种架构就会带来一些问题，例如：

• 业务间代码层面耦合太重，业务之间隔离不明确：由于各业务间代码存在较多的耦合，经常出现某个业务线功能开发迭代影响其他业务线，出现代码冲突，影响其他业务功能。

• 项目整体源码较多，编译耗时久：各业务开发人员主要开发各自业务线需求，但是需要编译整个项目，耗时较多，影响开发效率。

• 多应用差异化适配方案不完善：在业务扩张过程中，还衍生出一些独立应用，例如智行旗下的订票助手、智行机票等应用，实际是使用同一个项目打包，更改一些主题配色和首页入口，进行差异化的编译打包。之前使用的多应用打包方案存在一些的问题，逐渐无法满足实际需求。

参考技术社区的 Android 架构方案，以及结合项目实际情况和业务场景，我们选择了组件化方案来进行架构的调整。

Android 项目组件化，最早是冯森林老师在 2016 年 MDCC 大会上的《回归初心，从容器化到组件化》演讲中提出来的，当时该方案刚提出，实际应用到项目中的还是比较少得，毕竟一般的公司项目业务不是很复杂，项目结构也是较为单一，没有使用组件化的必要。

但对于此时的智行 Android 项目而言，正是组件化架构最适合实践的项目，多个业务线，项目整体比较庞大，业务间不必要的耦合过多，因此组件化架构的调整方案也就应运而生。

在进行调整之前，团队也定下了调整预期的目标：

1）业务解耦，使得各业务模块可以独立运行，同时可以组合编译打包

2）拆分基础组件，抽离出基础组件 Library

3）各业务间通信和业务交叉调用的实现

4）实现多应用差异化适配打包

以上大的目标点主要是来解决之前遇到的问题，也是项目架构调整的首要目的。

2.2 组件化架构调整的整体规划

2.2.1 基础组件的拆分

智行 Android 项目的基础组件主要分为业务基础组件和功能基础组件，其中业务基础组件包含登录组件、自定义 View 组件、项目网络层组件等，这些和业务有关联，提供给各业务模块的基础组件，根据具体情况拆分成 aar 或者 library，像登录，基础网络层这样较为稳定的组件，一般直接打包成 aar，减少编译耗时。而像自定义 View 组件，由于随着版本迭代会有较多变化，就直接以源码形式抽离成 Library。

基础组件的调整相对较为简单，主要就是按照功能或者业务拆分成 Library ，处理好之前的引用的地方即可，但是对于拆分出来的 Library 的质量和后续维护工作是要求相对较高的，作为基础的组件，是需要为各业务模块提供基础的功能的，重要性是相对较高的。

基础组件库的编译版本设置一般是和主工程同步的，为了方便后续升级和维护配置，可以使用如下的方式来实现 library 使用同一份配置：

ext.libDefaultConfig = {