目录
- metaX 框架介绍
- metaX 是如何设计的
- metaX 运行效果
metaX 是 58无线 Android 团队开发的一套增强版的组件化框架，它制定了一系列的标准和规范，来解决现有组件化工程测试成本高、api 无法保证向下兼容、差异化定制与重构成本高、无法感知变动细节、业务线编译调试耦合平台环境等问题。对于这些标准和规范，metaX 框架提供了一套全自动化的脚本工具保障它们可以正常稳定地运转。
- 产出9个大类规范，30个具体细节规范
涵盖组件的开发、迭代、测试、接入、升级等全流程，规范是 metaX 组件化的核心输出，适用于集团所有的 App/移动端组件
- 对规范实现了全自动化地检测，自动化覆盖率达到 90%
对规范实现了全自动化地检测，保证它们可以正常稳定地运转，自动化覆盖率达到 90%。metaX 框架产出 10个编译期脚本，2个测试期工具，2个运行期工具，2个工程化脚手架，共覆盖 27 个规范
- 底层库的升级成本降低 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、业务线、垂直业务库、业务中间件、底层库数量非常庞大：
面对这些量级的 App、组件，当前框架难以解决以下问题：
- 业务线编译调试耦合平台环境
- 依赖与实现未分离，底层库需求测试影响面大，不能聚焦改动范围
- 底层库无法自动化做到向下兼容
- 无法感知底层库的 api 变动、包大小变动、第三方依赖变动
- 业务模块间可以任意依赖调用，依赖规则不明确
- 耦合严重，多平台组件复用难度大
- 差异化定制、重构成本高
那么我们来看下 metaX 框架是如何解决这些问题的。
组件结构
组件依赖规范
- api 库使用其他组件的能力：依赖其他组件的 api 库，而不能依赖其实现库
- lib 库使用其他组件的能力：依赖其他组件的 api 库，而不能依赖其实现库
- 打包工程依赖于各组件的 lib 库
组件能力
我们制定了一系列的标准和规范，并对这些标准规范开发了对应的脚本工具做自动化校验与执行
-
- api 与实现解耦
包括对外接口标准、页面跳转、依赖注入等，除此以外，metaX 还支持 RN/H5 native 组件的 api 与实现分离，解决这些跨端组件的变更、迭代、定制的痛点
-
- 组件间通信方式
对外 api、消息总线
-
- 自动校验组件的依赖规范
api 与实现库不能依赖其他组件的实现库
-
- 对外 api 工具类自动生成
通过 apt 自动生成接口的对外工具类
-
- 对外 api 变更检测
开发编译期会自动检测对外 api 的向下兼容性，metaX 只允许每年升级一次组件的主版本号统一进行 api 变更
-
- 自动生成 api 变更报告
自动生成对外 api 的修改报告，在提测、交付邮件中体现
-
- 组件大小和依赖库变更报告
自动生成组件大小、依赖库的变更报告，在提测、交付邮件中体现
-
- 自动生成 changelog
自动按格式生成 changelog，包含版本号、变更日志、对外 api 变化、组件大小和依赖变化等
-
- 告别传统的单元测试
自动在 demo 中生成对外 api 的测试页面入口和测试类，可用于单元测试和 RD/QA 验证
-
- 快速发布 aar
支持本地快速发布测试 aar，发布正式 aar 会自动修改组件版本号、生成 JavaDoc、打 Tag
-
- 组件交付邮件
发布正式 aar 后，我们会发布交付邮件周知，包括版本号、变更日志、api 变化、组件大小和依赖变化、单元测试结果等
打包工程
对于打包工程，metaX 提供了如下能力：
-
- 一键创建 metaX 工程脚手架
无论是新组件接入或是旧组件改造，让你告别复杂配置，快速适配 metaX
-
- 一键支持复合构建脚手架
你的组件可以独立编译，也可以在打包工程中进行源码级别的复合构建，对于组件调试、bug 排查、编译速度有大幅提升
-
- 差异化定制
对组件 api 的实现层进行差异化定制，你可以定制某个 api 的实现，也可以参考 api 层重新开发一套新的实现库
-
- 组件依赖和版本检测
打包工程会自动检测组件的 api 与实现库的依赖和版本关系，作出兼容性校验
关于 metaX 的设计，我们来看下最后一部分，58App 接入 metaX 后的目标架构
对于业务线、组件库的编译，我们希望达到这个状态：
业务线和组件库可以独立编译运行，也可以在 58App 中集成构建运行
接入改造、使用和效果部分选取埋点 SDK 为案例。
1. 组件接入改造
1.1 快速创建 metaX 工程
初始化效果：
脚本已帮助您创建好了一个 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 验证、组件交付，而在旧模式中，无法提供这些数据
在 中添加新依赖：
构建 release 包时，会产出 aar 信息，并在 changelog、提测邮件、交付邮件中有体现：
2.5 aar 发布
旧模式中，无法快速在本地发布测试 aar，只能通过修改版本，在云效进行发布，metaX 支持本地快速发布测试 aar，测试 aar 自动带 snapshot 和时间戳
旧模式发布的正式 aar 无 javadoc、版本号只能通过手动管理，metaX 发布正式 aar 会生成 javadoc，并自动处理版本号
本地快速发布测试 aar
执行：
快速发布正式 aar
执行：
2.6 changelog 自动生成
旧模式需要 RD 手动写 changelog，而 metaX 支持 changelog 自动生成，除了变更日志外，changelog 内容中还包含对外 api 变化、aar 大小变化、依赖库变化
2.7 不一样的单元测试和 demo 测试
传统的单元测试落地有两个难题：
- 单元测试编写成本
- 单元测试与 SDK demo 测试的重复工作
metaX 通过编译期自动生成对外 api 测试 Activity，扫描对外 api 自动相关的测试方法，构建 demo apk 成功后可自动触发此页面测试(无需 Android 虚拟机/真机)，同时 QA/RD 也可通过点击此页面实现测试
2.8 质量保证 - 提测邮件 & 交付邮件
下图为 metaX 组件发布正式 aar，触发交付流程：
提测邮件 & 交付邮件增加对外 api 变化、aar 大小、第三方依赖库变化、单元测试结果等信息，提升 QA 测效率，提高交付质量
