企业官网建设流程全解析

简介：Android Studio Bumblebee（android-studio-2021.1.1.22-windows）是面向Windows x86_64平台的Android开发IDE安装包，对应Android Studio 4.4代际，适合移动开发者、测试人员或需要在离线环境部署IDE的团队使用，可解决新版SDK工具链集成、模拟器性能优化等问题。压缩包内含2000个文件，总计882.56MB，其中以670个jar库文件、517个py脚本、249个json配置为主体，同时保留大量ttf字体、dll动态库、exe可执行文件及license授权说明，覆盖IDE运行、Gradle构建、模板适配与底层依赖等完整组件。已有1111人下载学习。资源为Bumblebee 2021.1.1 Patch 2稳定版的完整Windows安装整合包，内含IDE运行所需组件，便于读者直接解压使用，省去官方下载与版本匹配流程，同时保留清晰目录结构，可按需提取JAR库、Python脚本或配置文件，适合快速搭建Android开发环境或进行版本回溯。

1. 为什么还在装 Bumblebee：2021.1.1.22 的适用场景与选型理由

Android Studio Bumblebee 是 2021 年初发布的 2021.1.1 大版本，Windows 平台上的完整安装包名是 android-studio-2021.1.1.22-windows.exe。它卡在北极狐之后、柴犬之前这个过渡带上，默认配套的 Android Gradle Plugin 以 7.0 到 7.1 为主。现在主动找这个历史版本下载的人，我接触到的基本都是三类：维护 2021 年前后创建的老工程、在离线或内网环境做安卓开发的机器、以及想在低配 Windows 上跑 IDE 的从业者。这篇笔记就把这个版本的安装、SDK 配置、Gradle 同步、打包和配置迁移串起来，把我实际操作中踩过的坑翻出来排一遍，给你一个可以直接照着复现的路径。

2. 安装与首次启动：JDK、SDK 与 Gradle 链路一次配齐

2.1 安装流程与系统权限：干净安装和目录选择

拿到android-studio-2021.1.1.22-windows.exe之后，安装本身没什么特殊，但有几个选择会影响后面半年用不用得顺手。一个是安装目录，一个是是否勾选导入旧设置，还有一个是首次启动时的 SDK 组件下载。

双击 exe 后会先走一遍安装向导，安装路径我一般会改到非 C 盘，比如D:\AndroidStudio。这个版本对磁盘占用不算小，加上后续 Gradle 缓存和 SDK 镜像，默认放 C 盘很容易把系统盘挤爆。安装目录不建议带中文或空格，后面 Gradle 构建脚本解析路径时出问题的概率会明显高一些。

首次启动时会问你是否导入之前的设置。如果你是从北极狐升级上来的，可以选导入；如果是第一次装，直接选不导入。混着选容易出现配置残留，比如旧的 SDK 路径找不到、代理设置被带过来之类。

启动后第一步会卡在 SDK 组件下载上。这个版本默认的 SDK 渠道在国内直连速度不稳定，建议先别急着点 Next，先确认网络或者把代理挂上再继续。SDK 组件里最核心的三个是 Android SDK Platform、Android SDK Build-Tools 和 SDK Platform-Tools。如果你只做 API 30 或 31 的工程，可以只勾对应平台，不用全量下拉。

# 安装完成后检查环境变量是否会跟系统已有 JDK 冲突 echo %JAVA_HOME% echo %ANDROID_HOME%

这两条命令在 cmd 里执行，目的是确认安装向导没有往系统环境变量里写旧路径。Bumblebee 内置了 JetBrains Runtime 11，正常情况下不依赖系统 JAVA_HOME。但如果你之前装过 JDK 8，系统环境变量还指旧版本，后面 Gradle 同步时可能报不兼容错误。逻辑上先查这两个变量，能排除掉一大半环境类翻车。

Bumblebee 的 SDK 默认位置在%LOCALAPPDATA%\Android\Sdk，也就是当前用户目录下的 Android 子目录。如果你不想放在 C 盘，可以在 Settings 里改，也可以直接建一个local.properties文件指向你的自定义目录。

# android/local.properties sdk.dir=D:\\Android\\Sdk

这个文件必须放在项目根目录，作用是把当前工程绑定到指定 SDK 路径。注意 Windows 路径里反斜杠要写成双反斜杠，或者用正斜杠也行，sdk.dir=D:/Android/Sdk这种写法更省事。我建议在首次打开工程时由 IDE 自动生成这个文件，别手写，手写容易把路径格式写错。

2.2 三件套版本对齐：JBR 11、SDK 与 Gradle 的匹配逻辑

Bumblebee 和后面几个版本最大的不同，是它内部自带的是 JDK 11，而不是 JDK 17。这个细节决定了很多老工程的 Gradle 版本选择。AGP 7.0 必须用 JDK 11，AGP 7.1 也是；如果你在这台机器上要跑 Android Gradle Plugin 4.x 的老工程，反而会因为 JDK 太新而出问题。

工程里的 Gradle 版本由gradle-wrapper.properties控制。Bumblebee 新建的模板工程一般会用 Gradle 7.0.2 或 7.2，对应 AGP 7.0 到 7.1，这是比较稳的组合。如果你拿到一个 2020 年之前的工程，它可能是指向 Gradle 6.5 和 AGP 4.1，这种组合在 Bumblebee 上也能跑，但要注意 JDK 必须切到 11。

# android/gradle/wrapper/gradle-wrapper.properties distributionBase=GRADLE_USER_HOME distributionPath=wrapper/dists distributionUrl=https\://services.gradle.org/distributions/gradle-7.0.2-bin.zip zipStoreBase=GRADLE_USER_HOME zipStorePath=wrapper/dists

这里distributionUrl就是整个构建链路的关键。它指向 Gradle 发行版的下载地址，bin后缀代表只下载二进制包，不带源码和文档，体积小一些。如果你的网络访问 gradle.org 有问题，可以把域名换成国内镜像地址，但后面要保证镜像里的版本号和distributionUrl一致。

SDK 版本和 AGP 的匹配也需要对齐。这个版本对compileSdkVersion的兼容范围比较大，API 30 和 31 都没问题，但如果你在低版本 AGP 上用太新的 compileSdk，Gradle 同步时会报failed to find target之类的错误。Bumblebee 能流畅处理的核心配置区间，我一般控制在 compileSdk 30 到 31、minSdk 21 到 24、targetSdk 30 到 31。

如果你在工程里同时碰到 Kotlin 版本和 Gradle 版本不兼容的报错，优先改 Kotlin Gradle Plugin 的版本而不是去改 Gradle 基础版本。Bumblebee 时代的 Kotlin 1.5.x 配 Gradle 7.0 是稳定的，Kotlin 1.6.x 配 Gradle 7.0.2 也可以。常见的误用是看到报错就盲目升级 Gradle 到 7.4 或 7.5，结果 AGP 7.0 又不支持了，陷入两头堵的尴尬。

3. 中文化与编辑器设置：把 Bumblebee 调成顺手的样子

3.1 中文语言包的安装节奏：插件搜索与版本匹配

很多人在搜索框里问"Android Studio 怎么设置中文"，这个问题在 Bumblebee 上有标准答案。它支持简体中文语言包，但和最新版本不一样的是，Bumblebee 里的中文插件不会默认出现在推荐列表里，而且版本匹配相对严格。

进入File > Settings > Plugins，在 Marketplace 搜索Chinese，一般能找到Chinese (Simplified) Language Pack / 中文语言包。这个插件由 JetBrains 官方维护，安装后重启就能看到全中文菜单。注意看插件说明里适用的 IDE build 范围，Bumblebee 对应的是 2021.1 这一代。如果你搜到的是一个最新版插件但显示不兼容，别硬装，去插件仓库翻历史版本，找一个标记 2021.1 兼容的再装。

菜单路径： File > Settings > Plugins > Marketplace > 搜索 "Chinese" > Install > Restart IDE

安装逻辑很简单，核心是版本错配的处理。Bumblebee 的插件仓库地址和最新版不一样，有时搜索结果里第一个是给新 IDE 用的，装上去重启后会提示 plugin incompatible，IDE 回到英文界面。这种情况把插件卸载，换历史版本重新装就行，不用重装整个 IDE。

除了中文插件，还有一个值得装的插件是.gitignore支持，它在工程右键菜单里直接生成忽略规则文件。Bumblebee 自带版本控制的适配，但.gitignore模板不是默认就有的。装完这两个插件后，界面的日常使用障碍基本就清除了。

3.2 字体、SDK 路径与自动检查的设置落点

中文化之后要设置的几个点，我按优先级排一下。第一个是字体渲染，Windows 上默认的 Consolas 在某些屏幕上看起来比较细，我把编辑器字体调成 JetBrains Mono，字号 14，行间距 1.2，长时间看代码会舒服一些。

File > Settings > Editor > Font Font: JetBrains Mono Size: 14 Line height: 1.2

第二个是 SDK 路径的核对。中文化之后菜单名变成了文件 > 设置 > 外观与行为 > 系统设置 > Android SDK，在这里可以看到当前 SDK 位置和已安装的 Platform 版本。如果你之前手动指定过local.properties，这里会同步显示出来。这个页面里还能装新的 SDK Platform，比如 API 32，不过在这个版本上我不建议装太新的 Platform，会和旧 AGP 产生兼容性摩擦。

第三个是关闭自动更新。Bumblebee 默认会检查 Canary 和稳定版更新，Windows 上经常会弹通知让你升级。如果你是因为老工程才用这个版本，直接到文件 > 设置 > 外观与行为 > 系统设置 > 更新里把自动检查更新关掉，省得每次打开工程都被打断。

内存设置在这个版本上是个值得提的点。Bumblebee 是 2021 年的产品，默认分配的内存比较保守。在Help > Change Memory Settings里可以把堆内存调到 2048 或 3072MB。注意这个设置生效需要重启 IDE，而且涉及 gradle daemon 的内存不要超过物理内存的一半。

Help > Change Memory Settings > Heap Size: 2048 MB

如果你同时开多个工程，这个数值建议保持 2048，不要贪高。IDE 堆内存和 Gradle daemon 的 JVM 参数是独立的两套体系，IDE 开太大反而会影响 Gradle 进程的可用内存。

4. Gradle 同步与构建排错：错误信息之后的真实原因

4.1 四条高频报错的定位路径

这一章是血泪经验集中区。Bumblebee 本身稳定性尚可，但工程上的问题几乎都集中在 Gradle 同步这个环节。下面四条是我在这个版本上遇到频率最高的报错，每条都按现象、原因、解决的顺序拆开说。

现象一：Gradle sync 失败，报Unable to find method 'getCompileSdkVersion()' on project。

这个报错在 2021 年的工程里出现得很典型。原因基本是 AGP 版本和 Gradle 版本不匹配，AGP 7.0 需要 Gradle 7.0 以上，如果你把 AGP 降到了 4.x，Gradle 还是 7.0，就会触发这种解析错误。解决方式是让两者落在官方兼容表里。AGP 7.0 配 Gradle 7.0 到 7.1，AGP 7.1 配 Gradle 7.2。我一般会先改build.gradle里的 AGP 版本，再去调gradle-wrapper.properties，两步操作中间不需要动代码。

现象二：一个让我印象很深的报错，SDK location not found. Define location with an ANDROID_HOME environment variable or by setting the sdk.dir。

原因是工程根目录没有local.properties，或者文件里 sdk.dir 指向的路径不存在。最常见的是从别人那里拷贝工程或者从版本库拉代码时，local.properties被 gitignore 掉，新机器上不会自动创建。解决方式就是在工程根目录新建local.properties，写入实际的 SDK 路径。我一般会建议顺手关掉 IDE 再写，避免 IDE 缓存覆盖你写的值。

现象三：Read timed out或者Could not resolve com.android.tools.build:gradle:7.0.0。

这个现象在国内网络环境里几乎是必现的。原因是 Gradle 和 AGP 的依赖默认从dl.google.com和repo.maven.apache.org下载，连接极不稳定。解决方式是给build.gradle里的仓库换成国内镜像。这一步不算修改工程逻辑，只影响依赖来源，可以放心改。

4.2 从 Gradle 版本到代理镜像的调整顺序

面对同步失败，我习惯按一个固定顺序排查，避免乱改一通把工程弄得更糟。第一步是先看gradle-wrapper.properties里的 Gradle 版本是否和 AGP 兼容，第二步是看build.gradle里的仓库配置，第三步才是看代码层面的编译错误。

// android/build.gradle（工程级） buildscript { repositories { maven { url 'https://maven.aliyun.com/repository/public' } maven { url 'https://maven.aliyun.com/repository/google' } maven { url 'https://maven.aliyun.com/repository/gradle-plugin' } google() mavenCentral() } dependencies { classpath 'com.android.tools.build:gradle:7.0.4' classpath 'org.jetbrains.kotlin:kotlin-gradle-plugin:1.5.31' } }

这段配置里，我把 Google 和 Maven Central 放在了阿里云镜像之后，实际下载时会优先走镜像，镜像拉不到才走官方源。gradle:7.0.4是 AGP 的精确版本号，kotlin-gradle-plugin对应 Kotlin 编译插件的版本。这套组合在 Bumblebee 上我实测过多次同步成功没出幺蛾子。

如果你在 Windows 上用管理员权限打开终端跑gradlew，还有可能遇见一个隐蔽问题：Gradle daemon 启动时被安全软件拦截，命令行提示类似start the windows daemon from a non-elevated terminal。这个报错的原意来自 Docker，但 Gradle 也会遇到同类问题，原因是高权限进程和普通权限进程对 daemon 缓存目录的访问冲突。解决方式是不要用管理员终端跑 gradlew，普通 cmd 或 IDE 里直接跑就行。

# 用普通权限在工程目录下执行同步 gradlew.bat assembleDebug --stacktrace

assembleDebug是构建 debug 变体的标准任务，--stacktrace会在失败时输出完整异常栈。如果你看到FAILURE: Build failed with an exception，重点去看Caused by那一段，那才是真正的问题来源。一个多年的习惯是，Gradle 的报错信息里，前面一大段往往是任务本身的输出，最后面的 Caused by 才是根因。

依赖下载速度的问题，还有一个处理位是修改gradle.properties里的超时时间。Gradle 默认的 socket 超时是 120 秒，国内网络环境下经常卡满这个时间才报错，白白等两分钟。我一般会主动调低一点，让它快速失败，方便立即重试。

# android/gradle.properties systemProp.org.gradle.internal.http.socketTimeout=60000 systemProp.org.gradle.internal.http.connectionTimeout=60000 org.gradle.daemon=true

这里把超时设为 60 秒，配合镜像源，能明显减少同步时的等待感。org.gradle.daemon=true会让 Gradle 以守护进程方式运行，后续构建复用已有 JVM，避免每次都要重新初始化。

5. 签名打包与构建提速：从 keystore 到 build 参数的一串实操值

5.1 生成签名文件与 release 构建类型配置

在这个版本上打包，菜单路径是Build > Generate Signed Bundle / APK。第一次打包从一个 keystore 开始。我见过很多人在这一步卡住，其实核心就三个：keystore 文件、keystore 密码、alias 信息。生成 keystore 可以用 Android Studio 的图形界面，也可以直接用keytool命令行，后者在 Windows 的 cmd 里就能跑。

keytool -genkeypair -v -keystore release.jks -keyalg RSA -keysize 2048 -validity 10000 -alias release

这条命令生成一个 RSA 2048 位的签名文件release.jks，有效期约 27 年，alias 是 release。命令执行过程中会要求输入 keystore 密码和证书信息，省份、城市那些可以随便填。生成后的 jks 文件放在工程目录之外，不要放进 git 仓库。

拿到 keystore 之后，在工程 app 模块的build.gradle里配置签名信息。Bumblebee 时代用的还是 Groovy DSL 的写法。

// android/app/build.gradle android { signingConfigs { release { storeFile file('../keystore/release.jks') storePassword 'your-keystore-password' keyAlias 'release' keyPassword 'your-key-password' } } buildTypes { release { minifyEnabled true shrinkResources true proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' signingConfig signingConfigs.release } } }

signingConfigs.release给 release 构建类型指定了签名文件，minifyEnabled true开启代码混淆，shrinkResources true在混淆基础上裁剪无用资源。proguardFiles里第一个是 Android 官方默认的混淆规则文件，优化级别较高；第二个是工程自己的规则文件，用来保留反射、JNI 等需要跳过的类。这样配置后，Build > Generate Signed APK 选择 release 变体，就会输出带正式签名的 APK。

整个过程中最容易翻车的是密码直接写在 build.gradle 里然后提交仓库。哪怕工程是私有的，也不建议这么干。我一般会把这个信息放到用户目录下的~/.gradle/gradle.properties里，然后在工程里用变量引用。

// 用变量引用外部配置 signingConfigs { release { storeFile file(RELEASE_STORE_FILE) storePassword RELEASE_STORE_PASSWORD keyAlias RELEASE_KEY_ALIAS keyPassword RELEASE_KEY_PASSWORD } }

这样 build.gradle 里不出现真实密码，就算工程被同步到别人手上，也不会暴露签名信息。Gradle 变量会在配置阶段自动注入。

5.2 混淆规则与内存、缓存参数的实际组合

混淆规则的维护是 release 构建里的重头戏。如果你的工程用了 Gson、OkHttp 这类库，或者依赖了反射、注解处理器，混淆规则缺一条就可能在运行时崩一个功能，而且崩得无声无息。

# android/app/proguard-rules.pro -keep class com.yourpackage.model.** { *; } -keepattributes *Annotation* -keepclassmembers class * { @com.google.gson.annotations.SerializedName <fields>; } -dontwarn okhttp3.** -dontwarn okio.**

第一条-keep class保留整个 model 包下的所有类，这是 Gson 反序列化最常见的需求；第二条保留注解属性，保证运行时注解不丢失；第三条保留带SerializedName注解的字段；后面两条是 OkHttp 相关的警告忽略规则。混淆规则不需要一次写全，先跑一遍 release 构建，再在测试机上过一遍核心流程，哪里崩了再补对应规则。

构建提速的参数在 Bumblebee 上能调出明显效果。默认配置下，一个新工程从冷启动到出包可能要四五分钟，加了下面这组参数后通常能压到两分钟以内。

# android/gradle.properties org.gradle.jvmargs=-Xmx2048m -Dfile.encoding=UTF-8 org.gradle.parallel=true org.gradle.caching=true android.enableJetifier=true android.useAndroidX=true

-Xmx2048m指定 Gradle daemon 的最大堆内存，这个值要和 IDE 内存设置错开，避免两个进程抢内存。org.gradle.parallel=true让多个模块并行构建，多模块工程提升最明显。org.gradle.caching=true开启构建缓存，改一个模块后重新构建，其他模块可以直接命中缓存。后面两行是 AndroidX 和 Jetifier 的开关，新工程通常已经默认开启，老工程要确认一下。

构建缓存目录默认在用户主目录下的.gradle/caches，如果你的 C 盘空间紧张，可以把它迁移到其他盘。在gradle.properties里指定：

# 自定义构建缓存目录 gradle.user.home=D:/gradle-home

这个参数会影响所有基于 Gradle 的工程，改完需要重启 IDE。迁移后再跑一次完整构建，让缓存重新落盘。注意这个目录不能有中文路径，否则部分依赖解析可能报错。

6. 把配置沉淀下来：Windows 上的环境迁移与一条验证命令

Bumblebee 的配置迁移比很多人想象得简单，它的 Windows 配置目录在%APPDATA%\Google\AndroidStudio2021.1.1下面。里面包括config、plugins、options三个核心子目录。config里存了代码风格、模板、快捷键等设置；plugins是已安装的插件；options是 IDE 级选项，包括刚才配的 SDK 路径和内存大小。

换到另一台 Windows 机器时，不需要全部重配。把整目录打包复制过去，放到新机器的同样路径下，启动 IDE 后所有设置直接生效。复制前最好关掉 IDE，避免后台线程往配置目录里写半截文件导致损坏。如果新旧机器上的用户名不一样，config里的用户级路径可能需要手动修正。

robocopy "%APPDATA%\Google\AndroidStudio2021.1.1" "D:\backup\AndroidStudio2021.1.1" /E /COPY:DAT

这条命令用 Windows 自带的 robocopy 镜像复制配置目录。/E复制所有子目录含空目录，/COPY:DAT只复制数据、属性和时间戳，不复制 ACL 权限。备份完成后，新机器上启动 IDE 前，先把目录拷到对应位置，再双击 exe 启动。

迁移验证我有一条习惯路线。新机器上打开工程后，先跑一次同步，再执行一次完整构建，确认链路闭环。

gradlew.bat clean assembleDebug --refresh-dependencies

clean清掉上次构建产物，--refresh-dependencies强制刷新依赖缓存。如果这条命令能跑完，说明 JDK、SDK、Gradle 和依赖仓库这条线上没有大问题。如果跑不完，优先看第一行的 Java 版本和最后的 Caused by，两条信息能解八成问题。

从那以后我每次在新机器上装这个版本，都强制走一遍"备份配置目录、恢复配置目录、验证 assembleDebug"三步。这套流程看着笨，但确实帮我避免了好几次环境不一致导致的翻车。希望这些参数和踩坑记录能帮你在 Bumblebee 上少折腾几轮，直接把精力花在工程本身。

本文还有配套的精品资源，点击获取