MetaX组件化框架

目录

• MetaX 框架介绍
• MetaX 是如何设计的
• MetaX 运行效果

1. MetaX 框架介绍

MetaX 是 58 无线 Android 团队开发一套彻底的组件化框架，它意在降低底层库的升级成本、业务个性化成本和提升业务线编译速度

• 底层库的升级成本降低 50%

根据云效统计，2021年 App工厂底层库累计升级150次，涉及13个SDK，单个需求平均测试时间3天。使用 MetaX 单个需求平均测试时间1.5天，全年累计测试时间可减少225天

• 业务个性化定制成本降低 50%

App 工厂底层库涉及平台包括：同城、本地版、安居客、赶集、58到家、驾校一点通、房产经纪人、巧房等。各平台由于业务差异各自维护了一些通用底层库(平均每个平台2个)，使用 MetaX 由维护2套变成维护1套，各平台个性化组件人力维护成本节约 50%

• 业务线编译速度提升 90%

MetaX 支持业务线独立调试，业务线单人编译速度可提升 90%。以 58App 为例，本地一次全量编译时长 8分钟。MetaX 只需要1分钟，一人每天大约需要全量编译 20次，业务线每人每天可节约 20*7=140分钟

它产生的背景

当前集团的移动端 App、业务线、垂直业务库、业务中间件、底层库数量非常庞大：
#App58同城、58本地版、安居客、赶集、58到家、招财猫、移动经纪人、驾校一点通、站长端等业务线房产、招聘、二手车、二手房、黄页、金融垂直业务库部落、房产、本地版业务中间件App 工厂 SDK，多达 20几个底层库TEG SDK，数十个
面对这些量级的 App、组件，当前框架难以解决以下问题：

• 业务线无法独立开发、调试
• 依赖与实现未分离，底层库需求测试影响面大，不能聚焦改动范围
• 底层库无法自动化做到向下兼容
• 无法感知底层库的 api 变动、包大小变动、第三方依赖变动
• 业务模块间可以任意依赖调用，依赖规则不明确
• 耦合严重，多平台组件复用难度大
• 差异化定制、重构成本高

那么我们来看下 MetaX 框架是如何解决这些问题的。

2. MetaX 是如何设计的

组件结构

组件依赖规范

• api 库使用其他组件的能力：依赖其他组件的 api 库，而不能依赖其实现库
• lib 库使用其他组件的能力：依赖其他组件的 api 库，而不能依赖其实现库
• 打包工程依赖于各组件的 lib 库

组件能力

我们制定了一系列的标准和规范，并对这些标准规范开发了对应的脚本工具做自动化校验与执行

• 1. api 与实现解耦

包括对外接口标准、页面跳转、依赖注入等，除此以外，MetaX 还支持 RN/H5 native 组件的 api 与实现分离，解决这些跨端组件的变更、迭代、定制的痛点

• 1. 组件间通信方式

对外 api、消息总线

• 1. 自动校验组件的依赖规范

api 与实现库不能依赖其他组件的实现库

• 1. 对外 api 工具类自动生成

通过 apt 自动生成接口的对外工具类

• 1. 对外 api 变更检测

开发编译期会自动检测对外 api 的向下兼容性，MetaX 只允许每年升级一次组件的主版本号统一进行 api 变更

• 1. 自动生成 api 变更报告

自动生成对外 api 的修改报告，在提测、交付邮件中体现

• 1. 组件大小和依赖库变更报告

自动生成组件大小、依赖库的变更报告，在提测、交付邮件中体现

• 1. 自动生成 changelog

自动按格式生成 changelog，包含版本号、变更日志、对外 api 变化、组件大小和依赖变化等

• 1. 告别传统的单元测试

自动在 demo 中生成对外 api 的测试页面入口和测试类，可用于单元测试和 RD/QA 验证

• 1. 快速发布 aar

支持本地快速发布测试 aar，发布正式 aar 会自动修改组件版本号、生成 JavaDoc、打 Tag

• 1. 组件交付邮件

发布正式 aar 后，我们会发布交付邮件周知，包括版本号、变更日志、api 变化、组件大小和依赖变化、单元测试结果等

打包工程

对于打包工程，MetaX 提供了如下能力：

• 1. 一键创建 MetaX 工程脚手架

无论是新组件接入或是旧组件改造，让你告别复杂配置，快速适配 MetaX

• 1. 一键支持复合构建脚手架

你的组件可以独立编译，也可以在打包工程中进行源码级别的复合构建，对于组件调试、bug 排查、编译速度有大幅提升

• 1. 差异化定制

对组件 api 的实现层进行差异化定制，你可以定制某个 api 的实现，也可以参考 api 层重新开发一套新的实现库

• 1. 组件依赖和版本检测

打包工程会自动检测组件的 api 与实现库的依赖和版本关系，作出兼容性校验

关于 MetaX 的设计，我们来看下最后一部分，58App 接入 MetaX 后的目标架构

对于业务线、组件库的编译，我们希望达到这个状态：

业务线和组件库可以独立编译运行，也可以在 58App 中集成构建运行

3. MetaX 运行效果

接入改造、使用和效果部分选取埋点 SDK 为案例。

1. 组件接入改造

1.1

InitMetaXProject.py

快速创建 MetaX 工程

python3 InitMetaXProject.py ActionLogSDK /Users/kuangzhongwen/Desktop/projects

初始化效果：

脚本已帮助您创建好了一个 MetaX 模式的工程，包含 modules、依赖、插件等配置

2. 使用

2.1 自动检测 api 库与实现库依赖规范

api 库依赖检验：

实现库依赖检验：

2.2 快速生成接口工具类

api 接口可自动生成对应的接口包装类供外部调用者使用，实现库中接口实现类自动依赖注入，在旧模式下，我们对接口提供对应工具类需要靠纯手写：

2.3 对外 api 变更检测

在旧的模式中，我们无法自动化地做到 api 的向下兼容，如删除、修改方法、类名等，一旦变更，上层业务将进行对应的接入修改，否则会发生异常，同时这也大大增加了 QA 测试的工作量，而 MetaX 可以实现自动检测，一年只允许 1-2 次对外 api 升级：

2.4 aar 信息检测

aar 信息检测主要会检测 api 库与实现库的 aar 大小、依赖库变动信息，用于提供给 QA 验证、组件交付，而在旧模式中，无法提供这些数据

在

actionlog-lib

中添加新依赖：

implementation "com.wuba.wuxian.sdk:share-metax-api:1.8-SNAPSHOT-20220517194420"

构建 release 包时，会产出 aar 信息，并在 changelog、提测邮件、交付邮件中有体现：

2.5 aar 发布

1. 旧模式中，无法快速在本地发布测试 aar，只能通过修改版本，在云效进行发布，MetaX 支持本地快速发布测试 aar，测试 aar 自动带 snapshot 和时间戳
2. 旧模式发布的正式 aar 无 javadoc、版本号只能通过手动管理，MetaX 发布正式 aar 会生成 javadoc，并自动处理版本号

本地快速发布测试 aar

执行：

. MetaX publish test

快速发布正式 aar

执行：

. MetaX publish

2.6 changelog 自动生成

旧模式需要 RD 手动写 changelog，而 MetaX 支持 changelog 自动生成，除了变更日志外，changelog 内容中还包含对外 api 变化、aar 大小变化、依赖库变化

2.7 单元测试如此简单

传统的单元测试落地有两个难题：

1. 单元测试编写成本
2. 单元测试与 SDK demo 测试的重复工作

MetaX 通过编译期自动生成对外 api 测试 Activity，扫描对外 api 自动相关的测试方法，构建 demo apk 成功后可自动触发此页面测试(无需 Android 虚拟机/真机)，同时 QA/RD 也可通过点击此页面实现测试

2.8 质量保证 - 提测邮件 & 交付邮件

下图为 MetaX 组件发布正式 aar，触发交付流程：

提测邮件 & 交付邮件增加对外 api 变化、aar 大小、第三方依赖库变化、单元测试结果等信息，提升 QA 测效率，提高交付质量

3. 58App

新的工程结构，复合构建模式：