Compose 引入后，传统的截图对比与 Espresso 测试难以覆盖声明式特性。我们需要重新设计流水线，将“快速反馈 + 深度基准”结合，构建分层的测试矩阵。

流水线应包含：静态检查（ktlint、Detekt、Compose Metrics）、可视化回归（Paparazzi 或 Shot）、性能基准（Macrobenchmark）以及无障碍校验（Accessibility Test Framework）。

流水线拓扑

• Stage 1 - 静态分析：在 PR 级别运行 `./gradlew lint ktlintCheck detekt`，并开启 Compose Compiler Metrics 输出；
• Stage 2 - 可视化回归：触发 Paparazzi 渲染 Compose 组件快照，将差异图上传至 Artifact；
• Stage 3 - 性能与无障碍：夜间定时运行 Macrobenchmark 与无障碍脚本，结果同步到 DataDog/Grafana；
• Stage 4 - 部署与回滚：构建内部 Beta，配合 Firebase App Distribution 推送给 QA 与业务干系人。

GitHub Actions 实例

以下 YAML 片段给出了常见的 GitHub Actions 配置。我们将 Macrobenchmark 与 Paparazzi 拆分成可复用的 job，便于独立扩展并行度。

jobs:
   compose-static-checks:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v4
       - uses: gradle/gradle-build-action@v3
         with:
           arguments: lint ktlintCheck detekt

   compose-visual-regression:
     needs: compose-static-checks
     runs-on: macos-latest
     steps:
       - uses: actions/checkout@v4
       - uses: gradle/gradle-build-action@v3
         with:
           arguments: verifyPaparazziDebug

   compose-performance:
     needs: compose-visual-regression
     runs-on: android-large
     steps:
       - uses: actions/checkout@v4
       - uses: gradle/gradle-build-action@v3
         with:
           arguments: :benchmark:connectedCheck

可视化与回滚策略

我们在 App Startup 中注入发布版本号与 Git 提交哈希，日志上报至 ELK。Dashboards 以组件维度展示可用性、掉帧、无障碍通过率，一旦出现异常，可通过 Rollback Playbook 快速切回上一个稳定版本。