Android Studio 插件推荐，去掉花里胡哨的
Android Studio 插件推荐，去掉花里胡哨的
为什么写这篇
我装过太多插件了。有些插件装完第三天就卸载，有些用了三年还在更新列表里躺着。Android Studio 的插件生态和 VS Code 那种"装个颜色主题都要发 Twitter" 的氛围不太一样，这里更偏工程向，但也确实有不少鸡肋。
这篇只聊我还在用的、或者曾经深度用过最终放弃的。不聊彩虹括号、不聊进度条养猫、不聊代码区背景放二次元图。只聊对写 Android 代码有实际影响的工具，以及它们各自埋了什么雷。
Key Promoter X：肌肉记忆的代价
这个插件免费，JetBrains 官方插件仓库直接搜。功能极其简单：你每次用鼠标点了一个本可以用快捷键完成的操作，它就在右下角弹个气泡告诉你对应的快捷键是什么。
我 2019 年装的，当时刚从 Eclipse 切过来，快捷键体系一团糟。装了两周后开始烦，三个月后发现自己右手离开键盘的次数明显少了。六个月后我把它卸载了——不是因为没用，是因为它已经完成了使命，继续留着反而干扰注意力。
但这里有个坑：Key Promoter X 统计的快捷键是基于 IntelliJ 默认 keymap 的。如果你用的是 Eclipse 或者 Visual Studio 的 keymap 映射，它提示的快捷键可能是错的，或者提示了一个你根本没绑定的组合。我同事就遇到过，他用的 macOS 系统，插件提示的 Cmd + Shift + F12 和他实际绑定的冲突，结果按下去弹出了完全不同的功能，反而打断了心流。
另外一个不太明显的局限：它对触摸板手势无能为力。现在 MacBook 用户大量用三指拖拽、Force Touch 查定义，这些操作插件识别不到，自然也不会提示快捷键替代方案。所以它本质上是为"鼠标 + 键盘" 传统配置设计的，对现代触控操作覆盖不全。
我现在不推荐新人长期开着它，建议集中用两到三周，刻意练习，然后卸载。留着当常驻插件，右下角弹窗的干扰成本会超过它带来的收益。
Rainbow Brackets：被过度妖魔化的颜色
我知道我开头说不聊彩虹括号，但这个插件的讨论本身值得说几句。Rainbow Brackets 给嵌套的括号配对上色，大括号、中括号、圆括号分别用不同颜色层级渲染。
网上对它的态度两极分化。一派说"装了之后代码结构一目了然，再也不怕嵌套地狱"，另一派说"颜色污染严重，看久了眼睛疼，显得很不专业"。
我实际用下来的感受是：它对 Kotlin 的作用远大于 Java。Kotlin 的 lambda 嵌套、DSL 写法（比如 Compose 的声明式 UI、Gradle Kotlin DSL）确实容易产生深层嵌套，这时候颜色配对能降低认知负荷。但 Java 的传统写法，嵌套层级通常不深，Rainbow Brackets 的收益有限，反而让代码区像圣诞树。
真正的问题在于性能。2022 年某个版本（具体是 Rainbow Brackets 6.x 系列）有个内存泄漏，打开大文件（比如自动生成的 R.java 或者 ProGuard 映射文件）时，IDE 会卡顿数秒。JetBrains 官方论坛有人开帖追踪，作者修复了几个版本才稳定。我现在没装它，不是因为功能没用，而是我不愿意承担插件崩溃连带 IDE 无响应的风险。Android Studio 本身已经够重了，插件的稳定性权重应该高于功能炫技。
如果你非要装，建议把大文件自动禁用打开（Settings -> Editor -> Color Scheme -> Rainbow Brackets -> 有文件行数阈值设置），或者干脆只给特定语言启用。
String Manipulation：文本处理的隐藏高手
这个插件也是免费的，作者 Oleksii Kovalov，更新很勤快。功能看起来杂：大小写转换、排序行、过滤重复、编码解码、递增/递减数字、对齐光标……像是个文本编辑器的功能大杂烩。
但它有个场景是 Android 开发独有的高价值：处理资源文件。
举个例子，你复制了一段从设计稿或者后端接口文档来的颜色值列表，格式是 #FF5733, #33FF57, #3357FF，你要转成 Android 的 colors.xml 格式。String Manipulation 的 "Switch Case" 配合多光标，几步就能批量格式化成 <color name="color_1">#FF5733</color> 这种标准 XML。不用开终端写 sed，不用复制到 VS Code 里用正则替换。
另一个我常用的功能是 "Increment/Decrement" 数字。写 RecyclerView 的 ViewHolder 时，经常要手动给一堆 id 赋值，比如 R.id.text_view_1、R.id.text_view_2，多光标选中数字后按 Alt + Shift + I 自动递增，比手敲快得多。
坑也有。它的排序功能对 Unicode 中文处理有问题，按字母排序时中文字符的次序不符合拼音预期，而是按 Unicode 码点排的。如果你要整理包含中文注释或者中文资源名的列表，这个功能基本不可用。另外它的 "Escape/Unescape" 对 Android 特定的 XML 转义规则覆盖不全，比如 < 和 > 没问题，但 @string/foo 这种 Android 特有的资源引用格式不会被特殊处理，有时候转义结果不是你想要的。
adb-idea：命令行的偷懒替代
这个插件作者是 Philippe Breault，GitHub 上开源的。功能是把常用的 adb 命令绑到 IDE 的菜单和快捷键上：卸载应用、杀掉应用、启动应用、清除数据、重启并运行……
听起来很基础，但实际省的时间累积起来很可观。Android Studio 自带的 Run 按钮有时候不会触发完整的 clean install，尤其是你改了签名配置或者 manifest 之后，AS 的增量部署会偷懒。adb-idea 的 "ADB Restart App" 和 "ADB Clear App Data and Restart" 这两个动作我绑了快捷键 Ctrl + Alt + Shift + R 和 Ctrl + Alt + Shift + C，测试流程时不用切终端敲 adb shell pm clear 那一大串。
但它有个致命依赖：你的 adb 必须在系统 PATH 里，而且 Android Studio 要能探测到正确的 adb 路径。如果你用的是 Android Studio 自带的 adb，通常没问题；但如果你额外装了 platform-tools，或者用了某些国产手机厂商的魔改 adb（比如早年华为、小米的配套工具），插件会找不到 adb 或者找到错误的版本，命令执行失败但报错信息很不明显，就弹个红色气泡说 "adb command failed"，你得自己排查是路径问题还是设备连接问题。
另外一个局限：它对无线调试的支持是后来才加的，早期版本只认 USB 连接。现在支持了，但偶尔会出现设备列表缓存不同步的问题，IDE 里显示的设备状态和实际 adb devices 不一致，这时候重启插件或者重新插拔设备才能恢复。
我现在还装着，但已经不是每个项目都开。Compose 项目的预览功能越来越完善之后，纯 UI 调整的频率下降，adb 操作的需求也跟着少了。
Android ButterKnife Zelezny：被时代淘汰的典型
这个插件我必须提，不是推荐，是作为反面教材。它曾经是黄油刀（ButterKnife）的标配插件，按个快捷键就能自动生成 findViewById 的注解绑定代码。2016 年到 2018 年，几乎每个 Android 项目教程都会提到它。
现在 ButterKnife 本身已经被 Jetpack 的 ViewBinding 取代，Jake Wharton 2020 年正式宣布 ButterKnife 进入维护模式。但这个插件还在插件仓库里，下载量依然不低，很多老旧教程还在推荐新人安装。
坑在于：它生成的代码模板是基于旧版 ButterKnife API 的，如果你项目里用了 10.x 之后的版本，生成的 @BindView 包路径可能不对，或者缺少 R2.id.xxx 的引用（ButterKnife 在 library module 里需要用 R2 替代 R）。更麻烦的是，有些项目迁移到 ViewBinding 之后，老开发者肌肉记忆还在，下意识按快捷键，结果生成了一堆废弃的 ButterKnife 代码，编译报错一堆，新人根本看不懂为什么。
我的建议是：如果你维护的是 2019 年之前的老项目，且确实还在用 ButterKnife，可以装；任何新项目、任何准备迁移到 ViewBinding 或者 Compose 的项目，远离它。插件的便利性是建立在技术债务上的，这笔账迟早要还。
SonarLint：静态分析的噪音与价值
SonarSource 出的官方插件，免费。规则库很全，从空指针风险到复杂度超标，从硬编码密码到资源泄漏，覆盖的维度比 Android Lint 更广。
我 2021 年在团队里推过这个工具，初衷是统一代码质量基线，避免 Code Review 时来回扯皮"这里该不该判空"。实际推行时发现几个问题。
第一是规则粒度太细，默认开启的规则集对 Android 项目不友好。比如它会对 onCreate 里调用 super.onCreate 的顺序做检查，但 Android 的 Activity 生命周期里这个调用顺序有时候需要故意调整（比如某些 Theme 相关的 hack）。SonarLint 会标黄甚至标红，开发者要么花时间 suppress，要么养成无视警告的习惯，后者更危险。
第二是性能。大型项目（我们当时有 30+ module）的全量扫描会触发长时间的索引重建，Android Studio 的内存占用能从 4GB 飙到 8GB 以上。2022 年的某个版本（SonarLint 7.x）有个 bug，扫描完不释放内存，必须重启 IDE。官方 issue 列表里有人反馈，修复花了两个月。
第三是它和 Android Lint 的规则冲突。同样一个 SparseArray 替代 HashMap<Integer, Object> 的场景，Android Lint 推荐用 SparseIntArray 之类的特化版本，SonarLint 可能只提示用 SparseArray 泛型版，两者建议不一致，开发者无所适从。
我现在个人的用法是：只开安全相关规则（SQL 注入、硬编码密钥、日志敏感信息泄漏），关掉风格类和性能类规则，把 Android Lint 干不了的事情交给它。这样噪音可控，核心价值也保留。团队推广的话，建议先绑定 SonarQube 服务器统一规则集，而不是每个人本地用默认配置。
JSON To Kotlin Class (JsonToKotlinClass)：生成器的边界
这个插件在插件仓库里名字很长，作者叫 Wu Sean。功能是把 JSON 字符串转成 Kotlin data class，支持 Gson、Moshi、Jackson、Kotlinx Serialization 等多种序列化框架的注解。
我用它处理过后端接口文档给的示例 JSON。实际体验是：80% 的场景它能省时间，20% 的场景它埋的坑能让你调试两小时。
一个典型坑是类型推断。JSON 里 "count": 0 这种字段，插件会推断成 Int，但如果后端实际返回的是 Long（比如用户量大的场景），运行时 Gson 默认按 Double 读然后转 Int，大数会截断。插件生成的代码不会加 @SerializedName 的额外类型提示，这个风险它不会告诉你。
另一个坑是嵌套结构的命名。后端 JSON 里经常有一堆叫 data、item、list 的嵌套对象，插件按层级生成 Data、DataX、DataXX 这种名字，或者把父类名拼接进去变成 UserDataData。如果你接口有十几个，生成的类名很快失控，项目里充斥着 ApiResponseDataDataXX 这种东西。
第三个坑更隐蔽：它对 JSON 里的 null 处理默认是可空类型（Type?），但有些后端接口的字段是"有时有有时没有"，插件按第一次见到的样本生成，如果样本里没出现某个字段，它可能直接漏掉，或者如果样本里全是 null，它生成 Any? 这种毫无意义的类型。
我的用法是：用它生成初版，然后手工 review 每一个字段的类型和可空性，重命名所有自动生成的含糊类名，最后加上 @SerializedName 显式映射。它适合当草稿生成器，不适合当最终代码直接提交。另外，如果你的项目用了 Kotlinx Serialization，它的注解生成支持比 Gson 弱一些，有些高级特性（比如 JsonNames 多别名）不会自动加上。
Material Theme UI：主题插件的性能原罪
这个我必须单独说，因为它是插件仓库里下载量最高的主题插件之一，但也是我唯一明确建议"不要装"的插件。
作者 Elior Boukhobza 做得很用心，主题配色确实好看，文件图标集也丰富，连工具窗口的边框圆角都调了。但问题恰恰在这里：它改动得太深了。
Material Theme UI 会替换 IDE 的 Look and Feel 实现，注入自定义的 UI 组件渲染器。Android Studio 基于 IntelliJ 平台，但每个版本的 Android Studio 并不是对应 IntelliJ 的最新稳定版，而是某个特定分支加上 Google 自己的修改。Material Theme UI 的更新节奏和 IntelliJ IDEA 社区版对齐，对 Android Studio 的兼容性经常滞后。
我亲历过的两次崩溃：2021 年 Arctic Fox 版本，装完 Material Theme UI 后 Settings 窗口打不开，点击就卡死，必须手动删配置文件恢复；2023 年 Giraffe 版本，主题切换后编辑器光标消失，重启无效，只能禁用插件。两次都是插件论坛里一堆人反馈，作者修复了一到两周。
更隐蔽的问题是它和其他插件的冲突。比如和 Rainbow Brackets 同时装，颜色渲染层级会打架；和某些自定义字体插件（比如 JetBrains Mono 的旧版本配置）一起，行高计算会出错，代码看起来歪歪扭扭。
我现在用 Android Studio 自带的 Darcula，偶尔切到新版默认的 Dark 主题。图标集用 Studio 自带的 Atom Material Icons（Google 官方集成进来的，稳定性有保障），不再碰第三方全量主题。审美牺牲一点，换来的是不担心明天更新后 IDE 打不开。
Translation：读文档的辅助，不是替代
这个插件作者 Yii.Guxing，开源在 GitHub，支持谷歌、百度、有道、阿里翻译等多个引擎。功能是在 IDE 里选中文本，快捷键弹出翻译结果，或者直接把注释、字符串替换成翻译后的内容。
我对它的态度比较矛盾。一方面，它确实降低了读英文文档的门槛，很多 Stack Overflow 的答案、GitHub issue 里的讨论，快速扫一遍中文概要能省时间。另一方面，我观察到团队里有些开发者形成了依赖：遇到报错信息第一反应是选中翻译，而不是先读英文原文尝试理解。
翻译插件对技术术语的处理一直是个问题。比如 Android 里的 Context，它可能翻译成"上下文"、"语境"、"环境"，但技术语境下这些译法都不准确，反而干扰理解。再比如 LifecycleOwner，直译成"生命周期所有者"听起来像废话，但实际指的是具备生命周期感知能力的组件。翻译插件不会告诉你这些约定俗成的技术映射。
还有一个实际坑：百度翻译和有道翻译的 API 需要申请密钥，免费额度有限。团队里如果有人把密钥配在共享的开发环境里，额度用完所有人一起挂。谷歌翻译曾经不需要配置，但 2022 年之后因为网络原因，国内直连基本不可用，必须走代理或者换其他引擎。
我现在还装着，但给自己定了规则：报错信息和核心 API 文档必须读原文，只有读博客、非技术讨论类内容时才用翻译。插件设置里把"自动替换选中文本"关掉，避免手滑把代码里的英文标识符改成中文。
GitToolBox：Git 信息的过度展示
这个插件功能很细：在行尾显示每行代码的最后修改作者和时间、显示当前分支和远程的 ahead/behind 数量、自动 fetch、状态栏增强……
我装了三个月，卸载了。原因不是功能不好，是信息密度过高导致注意力分散。
行尾 blame 信息这个功能，在排查"这段代码谁写的、什么时候改的"时确实有用，但它常驻显示意味着你每看一行代码，视线都会被行尾的灰色小字吸引一下。研究过认知负荷的应该知道，这种边缘视觉的干扰虽然微弱，但持续累积会显著降低深度思考的效率。而且 Android Studio 自带的 Annotate 功能（右键行号 -> Git -> Annotate）已经能按需查看 blame，不需要常驻。
自动 fetch 功能也有坑。如果你工作在一个大型 monorepo，或者分支很多且远程更新频繁的团队，自动 fetch 会频繁触发后台索引更新，IDE 时不时卡一下。我关掉自动 fetch 改成手动后，流畅度明显提升。
ahead/behind 计数在状态栏显示，这个功能本身不错，但它的数字更新有延迟。你刚 push 完，状态栏可能还显示落后远程 2 个 commit，需要等几秒或者切一下窗口才刷新。有几次我误以为 push 失败，重复操作导致远程出现冗余 commit。
现在我用 Android Studio 自带的 Git 工具窗口 + 终端手动操作，不再依赖这个插件。信息获取多两步，但注意力更干净。
插件管理的个人原则
聊了这么多具体插件，最后说说我筛选插件的几个标准，不是作为结论，只是作为参考。
第一，优先 JetBrains 官方认证或者 Google 官方维护的。认证标志是个小盾牌，不是绝对安全，但更新节奏和兼容性测试至少有个底线。很多个人开发者维护的插件，作者换工作、换技术栈之后就不再更新，留着一个过期插件在 IDE 里，每次升级 AS 都是个雷。
第二，装之前看最近更新时间和 issue 列表。超过一年没更新的插件，除非功能极其简单且稳定，否则不装。Android Studio 的版本迭代很快，底层平台 API 变动频繁，停更的插件大概率在某次升级后崩溃。
第三，功能重叠的只留一个。Android Studio 自带的功能在持续增强，比如内置的 Database Inspector 已经能替代很多第三方 SQLite 插件，Profiler 的网络监控能替代部分抓包工具插件。先确认原生功能是否够用，再考虑插件补充。
第四，定期清理。我每半年会扫一遍已装插件列表，三个月没打开过设置界面的就卸载。插件不是收藏，每个都在启动时加载、占用内存、可能冲突。
第五，敏感项目禁用插件。处理金融、医疗等合规要求高的代码时，我会开一个新的 IDE 配置（Help -> Edit Custom Properties 可以指定配置目录），只装最基础的插件，避免第三方插件潜在的数据收集风险。虽然大多数插件是本地运行的，但谁知道哪个版本会引入联网同步设置的功能。
这篇没有穷尽所有插件，比如没聊 PlantUML 集成、没聊 JRebel for Android（这个已经死了）、没聊各种 AI 辅助编码的新插件——那些值得另开一篇单独说。这里只覆盖了我长期使用、有足够踩坑经验积累的工具。
装插件是为了让 IDE 更顺手，不是让 IDE 变成圣诞树。保持克制，定期审视，比追逐新插件更重要。