文章目录
- 我：帮我统计一下 ~/workspace 下有多少个 build.gradle Walle：统计完毕，一共 93 个 build.gradle 文件 93 个。 沉默是今晚的康桥。
- grep -rn “compileSdk” … –include=”build.gradle” 结果像一张"版本分布图"： compileSdk 数量 说明 28 2 古董级别 29 4 也是老项目 30 1 过渡版本 32 5 sherpa-onnx 的 demo 33 9 最多的之一 34 7 目前主流 35 1 过渡 36 9 最新的 一眼就能看出来——**28~30 的老项目，基本可以删了。而 32 全是 sherpa-onnx 的 Android demo。
- grep -rn “ndkVersion” … –include=”build.gradle” ndkVersion 数量 说明 27.0.12077973 5 较新的项目 25.2.9519653 1 espeak-ng 编译依赖 flutter.ndkVersion 9 Flutter 项目动态引用 一眼锁定那些还在用 NDK 25 的依赖——sherpa-onnx 构建工具链里的 espeak-ng，可以考虑升级。
- cmake 版本 数量 项目 3.18.1 3 parrot 系列的 duix-sdk 3.22.1 1 sherpa-onnx 的 espeak-ng 4.0.2 1 strawberry 的 duix-sdk 一看就知道——parrot 的 duix-sdk 还在用 3.18，strawberry已经升到 4.0 了，该对齐统一了。
- grep -rn “implementation.*com.android.support” –include=”build.gradle” 一键找出还在用 support 库的老项目（该迁移到 AndroidX 了）
- grep -rn “com.android.tools.build:gradle” –include=”build.gradle” 看看哪些项目还绑在过时的 Android Gradle Plugin 上
- grep -rn “minSdk” –include=”build.gradle” 一眼找出那些还在兼容 API 21 以下的"古董"新改配置
- grep -rn “implementation” –include=”build.gradle” | sort | uniq -c | sort -rn 帮项目瘦身，去掉重复的库
目录
- 痛点：Android 项目堆成山
- 救星：一句话搞定目录统计
- 第一步：看看有多少 build.gradle
- 第二步：看看 compileSdk 分布
- 第三步：顺藤摸瓜查 ndkVersion
- 第四步：cmake 版本一览
- 效果：从 93 个到心里有数
- 还有啥玩法？
- 查找废弃依赖
- 查找低版本 AGP
- 查找 minSdk 太低的项目
- 查找重复的依赖
- 注意事项
- 总结
做了几年 Android 开发，电脑里攒了一堆项目：
- 甲方项目迭代了几个版本分支
- 自己瞎捣鼓的 demo、POC
- 下载开源的 SDK、sample
- 过期的旧项目留着不敢删
久了你会发现一个问题——compileSdk 版本极其混乱。
有的项目还卡在 compileSdk 28（Android 9），有的已经升到 36（Android 15）。NDK 版本更是"百花齐放"——25、27 都有。cmake 版本也是 3.18、3.22、4.0 混着用。
想抽空整理一下？想到要一个个打开 build.gradle 翻，就放弃了。
我的电脑里装的 AI 助手叫 Walle（基于 OpenClaw），它可以直接执行 shell 命令。于是有了这样的对话：
我：帮我统计一下 ~/workspace 下有多少个 build.gradle
Walle：统计完毕，一共 93 个 build.gradle 文件
93 个。 沉默是今晚的康桥。
grep -rn "compileSdk" ... --include="build.gradle"
结果像一张"版本分布图"：
| compileSdk | 数量 | 说明 |
|---|---|---|
| 28 | 2 | 古董级别 |
| 29 | 4 | 也是老项目 |
| 30 | 1 | 过渡版本 |
| 32 | 5 | sherpa-onnx 的 demo |
| 33 | 9 | 最多的之一 |
| 34 | 7 | 目前主流 |
| 35 | 1 | 过渡 |
| 36 | 9 | 最新的 |
一眼就能看出来——**28~30 的老项目，基本可以删了。而 32 全是 sherpa-onnx 的 Android demo。
grep -rn "ndkVersion" ... --include="build.gradle"
| ndkVersion | 数量 | 说明 |
|---|---|---|
| 27.0.12077973 | 5 | 较新的项目 |
| 25.2.9519653 | 1 | espeak-ng 编译依赖 |
| flutter.ndkVersion | 9 | Flutter 项目动态引用 |
一眼锁定那些还在用 NDK 25 的依赖——sherpa-onnx 构建工具链里的 espeak-ng，可以考虑升级。
| cmake 版本 | 数量 | 项目 |
|---|---|---|
| 3.18.1 | 3 | parrot 系列的 duix-sdk |
| 3.22.1 | 1 | sherpa-onnx 的 espeak-ng |
| 4.0.2 | 1 | strawberry 的 duix-sdk |
一看就知道——parrot 的 duix-sdk 还在用 3.18，strawberry已经升到 4.0 了，该对齐统一了。
删掉旧的开发包后，电脑瘦身20G空间
整个过程大概花了 2 分钟对话，放在以前手动翻文件，至少半小时起步。
更重要的是——你不再害怕面对那些陈年项目了。
以前的状态是"眼不见为净"，现在是"看一眼就知道哪些该清、哪些该升、哪些可以放心继续用"。
这种"让 AI 去 grep 项目目录"的思路，还可以继续拓展：
grep -rn "implementation.*com.android.support" --include="build.gradle"
一键找出还在用 support 库的老项目（该迁移到 AndroidX 了）
grep -rn "com.android.tools.build:gradle" --include="build.gradle"
看看哪些项目还绑在过时的 Android Gradle Plugin 上
grep -rn "minSdk" --include="build.gradle"
一眼找出那些还在兼容 API 21 以下的"古董"新改配置
grep -rn "implementation" --include="build.gradle" | sort | uniq -c | sort -rn
帮项目瘦身，去掉重复的库
当然，让 AI 直接跑 shell 访问项目目录也有风险——它能看到你的文件。建议：
- 在自己的电脑上用，不在共享环境或 CI 跑
- 敏感文件（密钥、token）别放项目根目录
- 如果要长期使用，给 AI 设定清晰的目录白名单（比如只允许访问
~/workspace下的代码文件）
我这里就直接在 AGENTS.md 写死了规则：
没有主人同意，不得读写 openclaw/workspace 目录以外的任何文件
| 用途 | 示例命令 | 一句话效果 |
|---|---|---|
| 版本分布 | grep compileSdk |
一眼看清项目老化程度 |
| 依赖审计 | grep implementation |
找出废弃/重复依赖 |
| 工具链检查 | grep ndkVersion / grep cmake |
对齐团队工具版本 |
| 配置审计 | grep minSdk / grep targetSdk |
找出配置过低的项目 |
AI 助手 + shell 命令的组合，让 Android 项目清理这件事变得非常轻松。你不需要知道 93 个文件在哪，只需要知道你要查什么。剩下的交给 grep。
"让 AI 替你跑 grep，你只管做决策。"
后记：这篇文章里提到的"越界"问题也是一次有趣的教训——我让助手统计 ~/workspace 的 build.gradle，而它的工作目录其实是 ~/.openclaw/workspace。读取外部目录虽然是出于正确的工作目的，但也提醒了我和助手——权限边界需要明确划定，不能依赖"常识"。
以上就是利用OpenClaw为Android开发电脑瘦身的详细步骤的详细内容，更多关于OpenClaw为Android开发瘦身的资料请关注风君子博客其它相关文章！