ci(android): Android APK 工作流墙钟偏长（串行 4 ABI + 清盘破坏 Cargo/Gradle 缓存回写） #1103

背景

有反馈 Android APK（.github/workflows/android-apk.yml）编译等待时间偏长。对照同仓库桌面端发布工作流后，确认：相对 Release Tauri (cross-platform) 的墙钟，Android 通常更慢；真正瓶颈是单 job 内串行交叉编译 4 个 ABI。

实测对比（同 tag）

触发：v2.0.0-Beta.2-tauri（2026-09-24）

近期成功 run 中位数大致：Android ~25 min，Release Tauri ~22 min。CI 墙钟有时可到 ~33 min（Windows checks），所以 Android 不一定是全仓库墙钟最长，但是：

• 比桌面 Release 慢一截；
• 是最长的 单构建 job 之一（~30+ min）。

时间分布（Android run 35989822568）

• 整 job ~32.4 min
• Build Android release APK ~30.5 min（约 94%）
• 命令：tauri android build --apk --target aarch64 armv7 i686 x86_64 --split-per-abi
• 日志中大致为串行：
  • 首轮 release 编译 ~6 min
  • aarch64 ~2 min（有 cache 时）
  • armv7 / i686 / x86_64 各 ~5–5.5 min

其余 Java/NDK/npm/前端/上传合计约 1–2 min，不是主因。

缓存问题

工作流在上传 artifact 前有 Free disk before artifact upload，会删除：

• src-tauri/target
• ~/.cargo/registry / ~/.cargo/git
• ~/.gradle/caches

同一次 run 中 Post Cache Cargo 为 0s，说明清盘发生在 rust-cache / setup-gradle 的 post-save 之前，阻碍缓存回写。开头仍可能命中旧 cache，但依赖变更后容易长期「半冷」。

建议（按收益）

1. 日常 / workflow_dispatch 默认只编 aarch64（真机主路径）；tag release 再打全 ABI（或可选 input）。
2. 或 对齐桌面 Release：按 ABI matrix 并行（墙钟可降到约单 ABI 水平；runner 分钟会上去）。
3. 评估是否仍需要 i686（32 位 x86 模拟器场景很少）。
4. 调整清盘顺序：在 Cargo/Gradle cache post 之后再删，或只删已打包完的中间产物，避免整树清掉 target / cargo / gradle cache。
5. （次要）工作流里已有 npm run build，Tauri android build 内会再编前端一次，可去掉重复步骤（省时有限）。

预期效果

• 仅 dispatch 打 arm64：墙钟有望从 ~25–33 min 降到 ~10–15 min 量级。
• 全 ABI matrix 并行：墙钟接近单 ABI，总 billed minutes 上升。
• 修好 cache 回写：依赖/工具链变更后的二次构建更稳。

参考

• Workflow：android-apk.yml
• Scripts：tauri:android:build:release（package.json：四 target + --split-per-abi）

愿意的话我可以跟一版 PR（优先：dispatch 默认 aarch64 + 修清盘/缓存顺序）。