JetBrains Fleet 对 Android 开发的支持现状
JetBrains Fleet 对 Android 开发的支持现状
一个被反复推迟的"下一代 IDE"承诺
JetBrains 在 2021 年底首次公开 Fleet 的时候，整个技术圈的预期被拉得很高。官方博客的标题写得相当大胆："A lightweight editor and a full-fledged IDE in one app"。那时候 Kotlin 已经是 Android 开发的首选语言，JetBrains 既是 Kotlin 的创造者，又是 Android Studio 的底层平台 IntelliJ IDEA 的维护者， Fleet 看起来像是顺理成章的下一步——一个更轻、更快、更现代化的工具，专门给不想被重量级 IDE 拖慢的开发者的。
三年多过去，Fleet 的公开预览版（Public Preview）在 2023 年 3 月放出，到现在 2024 年底，它的 Android 支持仍然处于一个相当尴尬的位置。不是不能用，而是用起来处处透着"半成品"的气息。这种半成品感不是某个功能缺失那么简单，而是整个工作流的断裂——你能在 Fleet 里打开一个 Android 项目，甚至能编译运行，但当你真正想按照日常节奏写代码、调试、迭代的时候，会发现大量操作被迫跳回 Android Studio 或者命令行。
JetBrains 的产品经理在官方博客和 YouTube 视频里反复提到 Fleet 的"分布式架构"和"多语言支持"是核心卖点。这个架构确实有意思：编辑器前端和语言服务后端分离，理论上可以本地跑也可以远程跑。但对于 Android 开发者来说，这个架构带来的好处远不如它带来的麻烦明显。Android 开发本身就是一个高度依赖特定工具链的领域——Android Gradle Plugin、SDK Manager、模拟器、设备调试、Lint、ProGuard/R8 规则、签名配置——这些东西不是"支持 Kotlin 语法高亮和代码补全"就能覆盖的。
实际安装和项目打开：第一道门槛
Fleet 的安装包确实比 Android Studio 小很多。Mac 上大约 200MB 出头，启动速度也明显更快，冷启动到能看到界面大概两三秒，对比 Android Studio 在配置一般的机器上动辄十几秒的启动时间，这个体验差距很直观。但问题从打开一个现有 Android 项目就开始浮现。
Fleet 没有内置的 SDK 管理器。它依赖你本地已经配置好的 Android SDK 环境，而且检测逻辑比 Android Studio 脆弱得多。我在一台 M2 MacBook Pro 上测试，Android Studio 能自动识别通过 Homebrew 安装的 Android SDK 和通过 Android Studio 自带的 SDK Manager 安装的版本，Fleet 却经常只识别到其中一个，或者干脆提示 "Android SDK not found" 让你手动指定路径。这个手动指定的入口藏得相当深，不在项目设置里，要在全局的 Toolchains 配置里找，而且路径格式要求严格，不能有任何空格或特殊字符——这在 Windows 上简直是灾难。
更麻烦的是 Gradle 同步。Fleet 确实能触发 Gradle sync，但同步失败时的错误提示信息比 Android Studio 简略得多。Android Studio 的 Build 窗口会把 Gradle 的完整输出结构化展示，错误定位到具体文件和行号，Fleet 往往只给一行笼统的 "Gradle sync failed"，然后你得自己去终端跑 ./gradlew 看完整日志。这看起来是个小差异，但一天重复十几次的时候，累积的时间成本和烦躁感很真实。
我测试的项目是一个中等规模的 Kotlin 多平台项目，包含 Android app 模块、共享的 Kotlin/Native 模块、以及一些 Gradle convention plugins。Android Studio 2023.2.1 打开这个项目，Gradle sync 大约 40 秒完成；Fleet 的首次 sync 花了将近两分钟，而且期间界面没有明确的进度指示，只有一个不太显眼的 spinner 在状态栏转。这种不确定性在真实工作场景里很折磨人——你不知道它是真的在处理，还是已经卡死了。
代码编辑：核心体验的分裂
Fleet 的编辑器本身确实有一些亮点。它的语法高亮和基础补全基于 JetBrains 自家的 Fleet Protocol，响应速度比 Android Studio 的 IntelliJ 平台更快，尤其是在大文件里滚动和编辑的时候，几乎没有卡顿。Kotlin 的类型推断和基础补全也能工作，对于纯 Kotlin 业务代码的编写，手感是舒服的。
但 Android 开发不是纯 Kotlin 业务代码。XML 布局文件的支持在 Fleet 里相当薄弱。没有可视化布局编辑器，这个预期之内，毕竟 Fleet 定位轻量；但连基础的 XML 结构补全和属性提示都经常不完整，这就很难接受了。Android Studio 的 XML 编辑器背后有大量的 Android-specific 逻辑——哪些属性对哪些 View 有效、哪些属性有工具命名空间版本、哪些组合会导致 Lint 警告——Fleet 把这些都简化为通用的 XML 编辑，结果就是你在写 android:layout_width 的时候可能得不到预期的大小值枚举提示，写自定义属性的时候不会自动导入命名空间。
Compose 的支持更是个痛点。JetBrains 自己推的 Compose Multiplatform 在 Fleet 里的体验，坦白说，比 Android Studio 差一档。Preview 功能不存在，你得真机或模拟器运行看效果。@Preview 注解在代码里就是个普通的装饰，没有任何交互入口。Compose 的特定代码补全——比如 Modifier 链式调用的智能提示、remember 和 derivedStateOf 的模板——在 Fleet 里要么没有，要么触发条件比 Android Studio 更苛刻。考虑到 JetBrains 和 Google 在 Compose 上的合作关系，这个差距显得尤其讽刺。
重构功能也是缩水的。Android Studio 的 Rename 重构能跨语言边界工作——改一个 Kotlin 里的资源引用，对应的 XML 里的 android:id 或 tools:context 能联动更新；Fleet 的重命名基本局限于单语言内部。Safe Delete、Change Signature、Inline 这些在 Kotlin 代码里能工作，但遇到 Android 特有的模式就经常失效。比如你想删掉一个 Activity 类，Android Studio 会提示你在 manifest 里的注册需要处理，Fleet 不会。
构建和运行：命令行替代方案
Fleet 的构建菜单有 Build、Rebuild、Clean 这几个选项，但背后其实就是调用 Gradle task，没有 Android Studio 里那种针对 Android 构建流程的优化。Android Studio 的 Build 系统会智能判断哪些 module 需要重新编译、哪些 DEX 需要重新合并、什么时候可以跳过资源处理；Fleet 的构建往往更"笨"，全量操作更多，在大型项目里这个差距会放大。
运行和调试的配置是另一个断裂点。Fleet 支持创建 Android App 的运行配置，但配置界面比 Android Studio 简陋很多。Target device 的选择有时候不会自动列出已连接的模拟器，需要手动刷新或者输入 ADB 命令确认。模拟器管理本身不在 Fleet 内，你得另外开 Android Studio 的 Device Manager 或者命令行用 emulator 工具。这又回到了那个核心问题：Fleet 没有提供完整的 Android 开发闭环，它假设你已经有另一套工具链在运转，自己只负责其中一部分。
调试器倒是能工作，断点、单步、变量查看这些基础功能都有。但 Android 特有的调试场景覆盖不全。比如 Layout Inspector 没有，Database Inspector 没有，Network Inspector 没有，Background Task Inspector 也没有。这些不是"锦上添花"的功能，对于现代 Android 开发来说，它们是定位问题的标准工具。你在 Fleet 里遇到一个 UI 布局问题，要么靠猜，要么切回 Android Studio；遇到一个数据库查询异常，要么加日志重新编译，要么切回 Android Studio。
Logcat 的支持尤其让我失望。Fleet 有一个简单的日志视图，但过滤能力比 Android Studio 的 Logcat 窗口弱太多。按 tag、按 PID、按日志级别组合过滤、正则匹配、保存过滤配置——这些在 Android Studio 里都是日常操作，Fleet 的日志视图更像是一个 tail -f 的 GUI 包装。Android Studio 2022.3 之后重构的 Logcat 窗口其实做得相当好用，时间线视图、链接跳转、异常堆栈自动折叠，这些便利在 Fleet 里统统找不到。
版本演进和官方态度的微妙变化
Fleet 的版本更新节奏值得细品。2023 年 Public Preview 发布时，官方博客和社交媒体上的宣传重点之一是 "Fleet 将支持所有 IntelliJ 平台支持的语言和框架"，Android 被明确列为重点场景之一。但 2024 年的更新日志里，Android 相关的改进条目明显变少，而且措辞更谨慎。
2024.2 版本的 release notes 里，Android 相关的内容只有两条：一条是修复了某个特定场景下的 Gradle sync 问题，另一条是"改进了 Android 模拟器检测的稳定性"。对比 Kotlin 部分的十几条改进、Java 部分的二十多条，Android 的优先级看起来在下降。更关键的是，官方文档里关于 Android 开发的指南页面，从 2023 年的相对详细（虽然也已经比 Kotlin 或 Java 的指南简短），变成 2024 年的几乎是个 stub——几段通用描述，链接指向外部 Gradle 和 Android 文档，没有 Fleet 特有的工作流说明。
JetBrains 的开发者 advocate 在 Reddit 和 Twitter 上的回应也透露出一些信息。有用户直接问 "Fleet 会取代 Android Studio 吗"，得到的回答通常是回避式的："Fleet 和 Android Studio 面向不同的使用场景"。这个话术在 2023 年还不是标准答案，那时候的说法更积极一些，暗示 Fleet 最终会覆盖更多 IDE 场景。这种修辞变化本身就能说明问题——JetBrains 内部对 Fleet 的 Android 支持定位可能在收缩，从"替代方案"退化为"补充选项"。
一个更具体的信号是 Compose Multiplatform 的 IDE 支持策略。JetBrains 自己推的跨平台 UI 框架，在 Android Studio 里的支持反而比 Fleet 更完善。Android Studio 的 Compose Preview 支持 Kotlin/Native 目标（实验性），Fleet 却连基础的 Android Preview 都没有。如果 JetBrains 真的想把 Fleet 作为下一代主力工具，这个优先级安排是说不通的。
和竞品对比：Fleet 的处境更尴尬
把 Fleet 放在更大的编辑器/IDE 竞争格局里看，它的 Android 支持位置很别扭。
VS Code 配合 Android 扩展（由 Google 官方维护的 Android SDK 扩展和社区的 Kotlin 扩展）已经能形成一个相当可用的 Android 开发环境。虽然也有功能缺失，但 VS Code 的生态系统弥补了很多——社区插件丰富，配置灵活，而且免费。Fleet 是订阅制，个人开发者每年大约 70-100 美元（取决于具体套餐），企业更贵。这个付费门槛在功能不完备的情况下很难 justify。
Android Studio 本身当然是 Fleet 最直接的比较对象。Google 在 Android Studio 上的投入力度很大，2023 年到 2024 年的版本更新节奏（Giraffe、Hedgehog、Iguana、Jellyfish）每个都带来实质性的 Android 特定功能改进。Android Studio 也有性能问题，启动慢、内存占用高，但 Google 在持续优化，比如 2023.2 引入的 Baseline Profiles 和 2024.1 的改进型 Gradle 缓存，都是针对实际痛点的。Fleet 的"轻量"优势在 Android Studio 的这些优化面前被稀释了很多。
还有一个不太被提及的竞争者是 IntelliJ IDEA Ultimate。既然 Fleet 和 Android Studio 都基于 JetBrains 的技术，那为什么不直接用旗舰版 IDEA？IntelliJ IDEA Ultimate 的 Android 插件支持几乎和 Android Studio 功能对等，同时保留了 IDEA 的通用性和灵活性。Fleet 想打的"轻量 + 多语言"牌，在 IDEA 的轻量模式（Power Save Mode）和插件体系面前也没有绝对优势。
一个猜测：Fleet 的真实战略定位
基于这些观察，我个人倾向于认为 Fleet 的 Android 支持目前处于一种"维持但不投入"的状态。JetBrains 需要 Fleet 作为技术展示和产品线覆盖——证明他们能做下一代编辑器架构，抢占远程开发和云 IDE 的叙事空间，对抗 VS Code 和 GitHub Codespaces 的扩张。但 Android 开发不是 Fleet 能赢的战场，这里 Android Studio 的护城河太深，Google 的控制力太强，JetBrains 自己作为 Kotlin 供应商的角色也比作为 IDE 供应商的角色更不可替代。
更可能的剧本是：Fleet 最终会聚焦于后端开发（Java/Kotlin/Go/Rust）、数据科学（Python/Jupyter）、以及云原生场景（Kubernetes/远程开发），Android 支持保持在"能打开项目、能编辑代码、能跑基本构建"的底线水平，但不追求工作流完整性。这个策略在商业上说得通，但对那些被早期宣传吸引、期待 Fleet 成为 Android Studio 替代品的开发者来说，是个时间成本的浪费。
JetBrains 在 2024 年 10 月的 Fleet 路线图更新里提到"2025 年将重点提升远程开发体验和 AI 助手集成"，Android 没有被提及。这个 omission 在语境里是有意义的——如果 Android 仍在重点列表里，它会被列出来作为差异化卖点；不被提及，通常意味着资源分配的现实。
给实际开发者的建议：什么时候值得看一眼
如果你现在问我"Fleet 能用来写 Android 代码吗"，我的答案是：能，但前提是你很清楚自己在牺牲什么，并且愿意为此付出额外的工作流成本。
具体说，Fleet 可能适合的场景很窄：纯 Kotlin 逻辑模块的开发（比如一个独立的算法库、数据处理层），不涉及 Android 框架 API、不碰 XML、不需要实时预览；或者是已经高度脚本化的项目，构建和部署都通过 Gradle task 和自定义脚本完成，对 IDE 集成的依赖很低。即使是这些场景，Fleet 的优势也更多在于"启动快、界面干净"这些感性体验，而不是功能层面的不可替代。
对于大多数 Android 开发者——尤其是那些需要处理 UI、调试复杂交互、依赖 Android 特定工具链的——Fleet 目前的状态是"可以尝鲜，不宜主力"。这个判断在 Fleet 的 Public Preview 发布一年半之后仍然成立，本身就能说明问题。一个被寄予厚望的新工具，在核心用户群体里的采纳率如此有限，产品层面的反思是必要的。
JetBrains 的技术实力和社区信誉毋庸置疑，但 Fleet 的 Android 支持是一个提醒：好架构不等于好产品，技术先进性不等于用户价值。分布式编辑器后端、CRDT 协同编辑、LSP 协议适配——这些底层创新在论文和 demo 里很亮眼，但开发者最终是用"能不能在今天下午顺利改完这个 bug 并发布 hotfix"来投票的。
Fleet 的 Android 故事还远未结束，但如果 2025 年的更新日志里 Android 仍然只是边缘条目，那这个故事的结局可能已经不写自明了。