前两天整理旧硬盘，我翻出一个 2016 年做的 Android 小项目，工程打开的一瞬间，build.gradle 里那行 com.android.tools.build:gradle:2.0.0 把我拉回了那个下午：三个人挤在小会议室里，产品经理拿着原型图说“这个按钮颜色再调一下，十分钟能好吧”，而我一边点着 Android Studio 2.0 的 Run 按钮，一边在心里祈祷 Instant Run 这次别抽风，现在回头看，Android Studio 2.0 不是一个“神版本”，但它确实是一个很有时代感的版本,值得聊聊。
先说清楚，Android Studio 2.0 不是 Android 2.0，它是当年 Android 开发工具的一次大版本更新，对很多开发者来说，它最直观的变化就是 Instant Run、更快的模拟器、GPU 调试能力，以及和云测试平台相关的集成思路，听起来都是“效率提升”，但在真实项目里,效率这两个字从来不是靠一个功能按钮就能解决的。
我印象最深的生活实例，是那个本地生活服务类 App，项目不算大，但页面多、改动频繁，客户每天都要看效果，升级到 Android Studio 2.0 后，我们最期待的就是 Instant Run：改一行文字、调一个 padding，理论上不用完整重装 Apk，点一下就能看到变化，刚开始确实爽，尤其是改 UI 小细节的时候，感觉自己像从绿皮火车换到了高铁，但问题也来了：有些改动不生效，有些时候应用状态变得很奇怪，最后我们还是得老老实实 Clean Project、Rebuild、重新安装，那种感觉就像你买了一台自动炒菜机，结果炒到一半还得自己颠勺，不是说 Instant Run 没价值，而是它当时还不够“无脑稳定”。
另一个实例是我带过一个刚学 Android 的学弟，他电脑配置一般，之前用旧版工具时，模拟器启动慢得能去泡杯面，后来换成 Android Studio 2.0，模拟器速度确实有提升，他第一次觉得“原来不用真机也能调界面”，但紧接着他又卡在 Gradle 下载、SDK 版本和插件兼容上，那天晚上他给我发截图，说“哥，我不是在学 Android，我是在学怎么让 IDE 不报红”，这句话我记了很久，工具版本更新，对老手是效率问题,对新手却可能是门槛问题。
所以我的个人观点很明确：Android Studio 2.0 的价值，不在于它当年宣传了多少新功能，而在于它暴露了一个很真实的问题——开发工具的创新，必须和稳定性、团队协作、CI 构建这些东西一起看，Instant Run 的理念很先进，模拟器提速也很实在，但如果团队里有人升级、有人没升级，Gradle 插件版本不统一，CI 上跑出来又是另一套结果，那所谓效率提升就会被沟通成本吃掉，我们后来就定了一个规矩：项目升级 IDE 可以，但必须先备份、先看 release notes、先在一个分支上试，Gradle 插件、构建脚本、测试机版本都要对齐，别小看一个版本号,它背后是一整条工具链。
我也不赞成“老版本崇拜”，有人一聊到 Android Studio 2.0 就说“还是老版本稳定”，这话只说对了一半，老版本稳定，往往是因为你熟悉它的坑；新版本有问题，也可能是因为你还没适配它的变化，工具终究是拿来干活的，不是拿来站队的，对老项目，我支持小步升级、固定构建环境；对新项目，我更倾向于在可控范围内使用维护中的版本，怀旧可以,但不能拿怀旧当借口拒绝解决实际问题。
如果今天让我给 Android Studio 2.0 一个评价，我会说：它是一个有冲劲、也有毛刺的版本，它让很多人第一次感受到“改代码不用等太久”的可能性，也让不少人第一次被 Instant Run 和 Gradle 兼容性教育，它不适合被神化，但也不该被遗忘，毕竟很多开发者对 Android 工具链的爱恨情仇,就是从那个版本开始变得具体起来的。
最后留个小问题：你第一次用 Android Studio 时，是哪个版本？有没有被 Instant Run、模拟器或者 Gradle 折磨过？如果有，欢迎在评论区聊聊，毕竟每个 Android 开发者的青春里，可能都住着一个让你又爱又恨的 IDE 版本。