Android:项目模块化/组件化的架构之路(一)

前言

在Android开发中,随着项目的不断扩展,项目会变得越来越庞大,而随之带来的便是项目维护成本与开发成本的增加!每次调试时,不得不运行整个项目;每当有新成员加入团队时,需要更多的时间去了解庞大的项目。。。而为了解决这些问题,团队通常会将项目模块化,以此来降低项目的复杂度和耦合度,让团队可以并行开发与测试,让团队成员更加专注于自己所负责的功能模块开发。。。

对于一些大厂如BAT或者美团等这些大型互联网公司,都会自己造轮子,实现项目模块化。而对于中小型公司,限于成本因素,一般都是选用这些大厂造的优秀的轮子来进行项目模块化。本文以及后面一系列文章,将向大家分享我在项目模块化中的实践经验。我的项目模块化方案主要借鉴于饿了么微信美团的模块化技术文章,如有建议,欢迎提出!

推荐

个人博客:Android:项目模块化/组件化的架构之路(一)

文章发布将先在个人博客与微信公众号「Code满满」发布,欢迎大家关注!

模块化需要做什么

首先,在开始项目模块化之前,我们必须要明确模块化需要做些什么?这就等于写书之前必须得有个总纲,否则越写到后面,越是混乱。以下是我认为在模块化时需要注意的几个问题:

  • 如何拆分项目
  • 模块之间的通信
  • 模块内的代码隔离
  • 模块在调试与发布模式之间的切换

在明确了项目模块化中需要解决的问题后,我们需要选定一个优秀的组件化开源框架。在本方案中,我选择阿里的ARouter,也是目前比较流行的组件化框架之一,大家也可以选择其他开源框架。ARouter的具体使用本文就不在介绍了,大家可以在网上自行搜索,下面开始设计项目模块化的架构。

一、如何拆分项目

Android:项目模块化/组件化的架构之路(一)_第1张图片
模块化结构图例

如上图所示,我将项目大概划分为五层:

  • 宿主层: 不做具体的项目功能实现,只负责集成业务模块,组装成一个完整的APP
  • 业务模块层: 将项目的每个大功能模块拆分成的一个一个单独的module
  • 基础业务组件层: 此层最大的作用是为了复用,例如首页模块新盘模块中都有楼盘搜索这个功能,且UI显示相似,这时在两个模块中都实现楼盘搜索就显得繁琐了,像这种与业务有关联且需要多处使用的情况,我们完全可以将其抽离出来作为基础业务组件
  • 功能组件层: 项目中常用的功能库,如图片加载、网络请求等
  • 底层SDK: 从公司项目中长期积累出来的底层类库

以上是大多数项目模块化时的拆分方式,每个人也可以根据项目的实际情况进行调整。

二、模块之间的通信

1. 常用的通信方式

当项目被拆分成多个模块后,模块之间的良好的通信是我们必须考虑的问题。ARouter本身也提供一套通信机制,但是一般很难满足我们所有的需求,所以我们会容易想到的常用的几种通信方式:EvenBus、协议通信、广播或者是将通信的部分下沉到公共组件库。对于这几种方式,在一些大厂的技术文章中都有提到一些他们的看法,下面我简单总结一下:

  • EventBus: 我们非常熟悉的事件总线型的通信框架,非常灵活,采用注解方式实现,但是难以追溯事件,微信饿了么认为这是个极大的缺点,不是很推荐,但是美团觉得只要自身控制的好就行(自己设计了一套基于LiveData的简易事件总线通信框架)。
  • 协议通信: 通信双发必须得都知晓协议,且协议需要放在一个公共部分保存。虽然解耦能力强,但是协议一旦变化,通讯双方的同步会变的复杂,不方便。
  • 广播: 安卓的四大组件之一,常见的通信方式,但是相对EventBus来说,过重。
  • 下沉到公共组件库: 这是在模块化中常见的做法,不断的将各种方法、数据模型等公共部分下成到公共组件库,这样一来,公共组件库会变的越来越庞大,越来越中心化,违背了项目模块化的初衷。最后,越来越难以维护,不得不在重新拆分公共组件库。

2. 改善通信方式

上面说了一些常用的通信方式,可以看到大厂并不是很满意,那么大厂都是怎么解决的呢?没错,大厂往往都会有重造一个符合他们要求的通信框架!然而这不是我们想要的(中小型公司的实力和成本不允许啊:cry:),不过没关系,我们可以根据大厂们的思路,自己建造一个精简实用的通信架构,下面一起来看!

2.1 使用接口进行通信

接口通信概念并不是什么新颖的概念,微信在技术文章中着重说明过,ARouter框架也具备这种能力。下面我们配合一个小例子形象的说明一下。

eg:在一个房产项目中,有推荐与新盘两个模块,这两个模块使用相同的接口(传入参数不同)获取楼盘数据。

针对这种状况,一般我们下沉数据接口至公共组件库,然后推荐和新盘都去调用公共组件库中的楼盘接口获取数据。而上面也说过了,这种情况的后果就是,当有数十上百个接口被下沉到公共组件库后,公共组件库已然中心化且变得很庞大,这不是我们想要的。我们需要的是去中心化,开发成员只需要专注于自己负责的模块本身,减少模块之间的耦合。而接口化的通信方式给我们提供了这种可能。

什么是接口化通信?我们可以理解为将一个模块当作SDK,提供接口+数据结构给其他需要的模块调用,从而实现通信。我们完全可以将获取楼盘数据的具体实现放在新盘模块中,然后单独提供获取楼盘数据的接口和楼盘的数据结构给推荐模块,推荐模块通过调用提供的接口就可以直接获取需要的楼盘数据,不需要关注获取楼盘数据的具体实现。 这样,即使获取楼盘数据的具体实现发生变动,推荐模块也不需要做任何更改,且维护也很简单。

对于这种接口化的通信实现,ARouterIProvider就已经实现,完全可以满足我们的要求。具体如何使用IProvider,这里就不在详细介绍,大家可以网上自行搜索。

2.2 如何对外暴露接口

解决了通信手段的问题,我们就得考虑另一个问题,为其他模块提供的接口+数据结构我们应该放在哪里?下沉到公共模块吗?或者另外新建一个module用来维护这些接口+数据结构?但是这样一来,成本就有些大了,也不方便。

在微信的模块化文章中提出了一个解决方法,将你要暴露的接口+数据结构甚至其他想要暴露的文件都.api化,即将你要暴露的文件的后缀名改为api,然后通过特定的方法将api后缀的文件拷贝出来,在module外部重新组成一个新的module(也可称为SDK),而想要使用的模块只需要调用这个SDK即可。当然,拷贝文件和组件SDK是完全自动化的,并非手工,这样才能节省成本。

由于微信的模块化文章中没有涉及到.api化的具体实现,所以根据这种思路,我使用了其他方法来实现要达到的效果。具体思路如下:

  1. 创建一个名为_exports的文件夹,需要对外暴露的文件都放在里面
Android:项目模块化/组件化的架构之路(一)_第2张图片
_exports文件夹
  1. _exports文件夹打包成jar
/**
 * 创建 jar 包
 */
task makeExportJar(type: Jar) {
    baseName = "hpauth-exports"
    version = "1.0.0"
    extension = "jar"
    // java文件编译后的所在位置
    from('build/intermediates/classes/debug/')
    // kotlin文件编译后的所在位置
    from('build/tmp/kotlin-classes/debug/')
    include('com/homeprint/module/auth/_exports/**')
    // jar包导出路径
    destinationDir = file('build/_exports')
}
  1. 将jar发布到本地maven仓库(发布到本地仅仅针对个人开发的时候;团队开发时,大家使用各自的电脑,无法访问到你本地的maven仓库,所以这时需要在局域网中建立一个maven仓库,详情请查看《Android:超详细的本地搭建maven私服以及使用Nexus3.x搭建maven私服的讲解》)
artifacts {
    archives makeExportJar
}

uploadArchives {
    repositories {
        mavenDeployer {
            // 本地的maven仓库路径
            repository(url: uri("../repo"))
            pom.project {
                groupId 'com.homeprint.module'
                artifactId 'auth-exports'
                version '1.0.0'
            }
        }
    }
}
  1. 在需要的模块调用jar
  compileOnly 'com.homeprint.module:auth-exports:1.0.0@jar'

注: 此处必须使用compileOnly来调用,compileOnlyprovided的替代方法,provided将被google废弃。此处使用compileOnly代表,jar包只在编译时有效,不参与打包。如果使用api或者implementation,因为我们只是将文件拷贝出来成为一个单独的SDK,并未修改包名和文件名,当将多个模块集成为一个app时,会抛出异常,提示jar包中的文件已存在。

2.3 使用EventBus时,自建简单的事件索引

以上的通信手段能满足大多数的场景,但是也会遇到满足不了的情况,比如在一个模块中的线程执行任务,执行完毕后通知另一个模块做出改变,这种模块处于被动接收信息的模式下,一般我们使用的手段就是广播或者EventBus,而相比广播,EventBus更灵巧。

虽然微信不是很推荐,但是美团却是比较看重此种EventBus这种类型的通信手段。就个人而言,我认为只要能合理控制EventBus,这也是一种比较推荐的通信手段。而EventBus目前最被诟病的一点就是无法追溯事件,所以为了能更好的控制EvenBus,我们可以自建一个事件索引。

  • 首先,我们可以创建一个Event类,作为传递数据的统一实体类。
public class Event {
    private Object index;
    private T data;

    public Event() {

    }

    public Event(Object index, T data) {
        this.index = index;
        this.data = data;
    }

    public Object getIndex() {
        return index;
    }

    public void setIndex(Object index) {
        this.index = index;
    }

    public T getData() {
        return data;
    }

    public void setData(T data) {
        this.data = data;
    }
}
  • 在我们每次传递Event时,必须为事件添加index索引标识
  • 而我们可以在公共模块类中创建一个索引类,用于记录所有的索引标识,这样我们就可以根据这些标识,简单的做到事件追溯
class EventIndex {
    companion object {
        // 事件从修改昵称页面发送至用户信息页面
        const val EVENT_FROM_MODIFYNAME_TO_USERINFO = "From_ModifyName_To_UserInfo"
        // 事件从修改邮箱页面发送至用户信息页面
        const val EVENT_FROM_MODIFYEMAIL_TO_USERINFO = "From_ModifyEmail_To_UserInfo"
    }
}

还有值得注意的一点,在公共模块中,仅存放模块之间的通信索引标识;模块内使用EventBus通信,建立的索引放在对应模块内,给公共模块EventIndex文件降级,如下图示例:

Android:项目模块化/组件化的架构之路(一)_第3张图片
在这里插入图片描述

三、模块内的代码隔离

虽然在模块化时,我们已经将业务拆分成了一个一个单独的module,但是有的业务实在是庞大,即使单独拆分成一个module,仍然有些臃肿。但是如果将业务module继续拆分成单独的子module,又会显得过重。此时我们就要开始寻求比module更小一级的粒度,这一点《微信Android模块化架构重构实践》中给我们提出了Pins工程的思路。

Android:项目模块化/组件化的架构之路(一)_第4张图片
pins结构目录

如上图,我们可以在module中构建粒度更小的pins工程来拆分业务,可以更加清晰直观的明确业务内的职责分工,示例代码如下:

  sourceSets {
        def dirs = ['p_imageview','p_progressbar']
        main {
            dirs.each { dir ->
                java.srcDir("src/${dir}/main/java")
                res.srcDir("src/${dir}/main/res")
            }
        }
    }

上述代码做到的是仅仅是分割代码,pins工程之间还可以相互调用。而微信提出的是工程之间没有依赖关系存在,则不可以相互调用,类似于两个module之间,如果没有在gradle中注明依赖,则不可相互调用。所以,有些人就会提出,既然如此,为何不直接拆将Pins工程完全拆分成module?

论坛中开发者们给出的最多的答案是提升编译速度!不过快手的一位资深Android工程师说,微信内部已经放弃了Pins工程,虽然不知道是真是假,不过美团在借鉴微信的Pins工程时,也没有提出代码的完全隔离。就个人而言,我认为Pins工程是module化的一个过渡阶段,当Pins工程的体量达到一定程度时,必须进行完全的module化,所以也没有必要做到Pins工程之间的代码完全隔离,做到以上即可。如果有想实现代码完全隔离的,可以参考《Android Pins 工程结构》

四、组件的生命周期管理

在组件化开发时,每个组件都应该有自己独立的生命周期,这个生命周期类似于组件自己的Application,在这个生命周期中,组件可以做一些类库的初始化等工作,否则如果每个组件都将这些工作集中到壳工程的Applicaiton中实现的话,会显得壳工程的Application太过中心化,并且一旦需要修改,会很麻烦,且容易产生冲突。

基于上述原因,我们可以自己搭建一个简易的组件生命周期管理器,主要分为两步:

  1. 构建组件的生命周期模型,构建的模型持有整个app的Application引用,同时提供三个基础方法:生命周期创建、生命周期停止以及生命周期的优先级设置。
public abstract class BizLifeCycle {
    private Application app;
    // 优先级,priority 越大,优先级越高
    @IntRange(from = 0)
    private int priority = 0;

    public BizLifeCycle(@NonNull Application application) {
        this.app = application;
    }

    public Application getApp() {
        return app;
    }

    /**
     * 获取优先级,priority 越大,优先级越高
     */
    public int getPriority() {
        return priority;
    }

    public void setPriority(int priority) {
        this.priority = priority;
    }

    public abstract void onCreate();

    public abstract void onTerminate();
}

在每个组件中只要实现上述模型即可。

  1. 有了生命周期模型,我们还需要一个管理器,用于管理这些组件的生命周期模型,在这个管理器中,我们同样需要实现三个基础方法:生命周期模型的注册,生命周期模型的反注册以及执行已存在的生命周期模型。
public class BizLifeCycleManager {
    private static ArrayList sPinLifeCycleList;

    /**
     * 注册组件的生命周期
     */
    public static  void register(@NonNull T lifeCycle) {
        if (sPinLifeCycleList == null) {
            sPinLifeCycleList = new ArrayList();
        }
        if (!sPinLifeCycleList.contains(lifeCycle)) {
            sPinLifeCycleList.add(lifeCycle);
        }
    }

    /**
     * 执行组件生命周期
     */
    public static void execute() {
        if (sPinLifeCycleList != null && !sPinLifeCycleList.isEmpty()) {
            // 冒泡算法排序,按优先级从高到低重新排列组件生命周期
            BizLifeCycle temp = null;
            for (int i = 0, len = sPinLifeCycleList.size() - 1; i < len; i++) {
                for (int j = 0; j < len - i; j++) {
                    if (sPinLifeCycleList.get(j).getPriority() < sPinLifeCycleList.get(j + 1).getPriority()) {
                        temp = sPinLifeCycleList.get(j);
                        sPinLifeCycleList.set(j, temp);
                        sPinLifeCycleList.set(j + 1, temp);
                    }
                }
            }
            for (BizLifeCycle lifeCycle : sPinLifeCycleList) {
                lifeCycle.onCreate();
            }
        }
    }

    /**
     * 解除组件生命周期
     */
    public static  void unregister(@NonNull T lifeCycle) {
        if (sPinLifeCycleList != null) {
            if (sPinLifeCycleList.contains(lifeCycle)) {
                lifeCycle.onTerminate();
                sPinLifeCycleList.remove(lifeCycle);
            }
        }
    }

    /**
     * 清除所有的组件生命周期
     */
    public static void clear() {
        if (sPinLifeCycleList != null) {
            if (!sPinLifeCycleList.isEmpty()) {
                for (BizLifeCycle lifeCycle : sPinLifeCycleList) {
                    lifeCycle.onTerminate();
                }
            }
            sPinLifeCycleList.clear();
        }
    }
}

调用示例如下,直接在壳工程的Application中使用,因为生命周期模型中都设置有优先级,所以在设置了优先级的情况下,可以不必在意register的顺序。如此一来,将生命周期注册后,需要更改每个组件件的一些初始化工作,可以直接在组件的生命周期中修改,而不需要变更壳工程的Application。

  override fun onCreate() {
        super.onCreate()
        BizLifeCycleManager.register(CommonBizLifeCycle(this))
        BizLifeCycleManager.register(HttpBizLifeCycle(this))
        BizLifeCycleManager.register(RouterBizLifeCycle(this))
        BizLifeCycleManager.register(ThirdBizLifeCycle(this))
        BizLifeCycleManager.execute()
    }

五、模块在调试与发布模式之间的切换

项目开发时,一般提供调试环境与正式发布环境。在不同的环境中,app的有些功能是不需要用到的,或者是有所不同的。另外,在模块化开发时,有些业务模块在调试时,可以作为单独的app运行调试,不必每次都编译所有的模块,极大的加快编译速度,节省时间成本。基于,以上种种原因,我们就必须对项目的调试与正式环境做不同的部署配置,然而如果全靠每次手动修改,当模块量达到数十时,则会非常麻烦,且容易出错。所以我们需要尽可能的用代码做好配置。

首先,来看如何配置module在app与library之间的切换,实现module在调试时作为app单独运行调试。看示例代码,这也是比较常见的方式:

  • gradle.properties中,配置字段isAuthModule,控制auth模块是作为一个模块还是一个app
# true: 作为一个模块 
# false: 作为一个app
isAuthModule=true
  • auth模块的build.gradle文件中作如下配置:
// 获取 gradle.properties 文件中的配置字段值
def isApp = !isAuthModule.toBoolean()

// 判断是否为 app,选择加载不同的插件
if (isApp) {
   apply plugin: 'com.android.application'
} else {
   apply plugin: 'com.android.library'
}
......

android {
   defaultConfig {
        // library 是没有 applicationId 的,只有为 app 时,才有
         if (isApp) {
             applicationId "com.homeprint.module.auth"
         }
         ......
   }
   
   sourceSets {
          main {
              // 作为app与模块时的AndroidManifest.xml会有所不同,在不同状态时选择不同的AndroidManifest.xml
              if (isApp) {
                  manifest.srcFile 'src/main/AndroidManifest.xml'
              } else {
                  // 记得在 main 文件夹下创建 module 文件夹,添加AndroidManifest.xml
                  manifest.srcFile 'src/main/module/AndroidManifest.xml'
          }
   }
}

这样只要我们更改一下,gradle.properties文件中的配置字段,就可以自由实现module在模块与app之间的切换。下面我们再来看下,如何实现app在调试与发布环境时,加载不同的模块,看以下示例:

假如有两个模块,lib_debug 与 lib_release,lib_debug 是只有在调试环境才需要使用,
lib_release 是只有在正式环境才需要使用,以下提供两种方式实现

方式一:
 if(mode_debug){
     implementation project(':lib_debug')
 }else{
     implementation project(':lib_release')
 }


方式二:
 debugImplementation project(':lib_debug')
 releaseImplementation project(':lib_release')

以上两种方式,方式一类似于上述的模块在 app 与 library 之间的切换,方式二是使用 gradle 提供的方法实现

参考文章

《Android:项目模块化/组件化的架构之路(二)》
《Android:超详细的本地搭建maven私服以及使用Nexus3.x搭建maven私服的讲解》
《美团外卖Android平台化架构演进实践》
《微信Android模块化架构重构实践》
《Android工程模块化平台的设计》
《Android工程模块化平台的设计(整理优化)》
《Android Pins 工程结构》
《pins工程及自动生成文件夹》

你可能感兴趣的:(Android:项目模块化/组件化的架构之路(一))