企业官网建设流程全解析

1. 工程化背后的“软件清单”逻辑：比安装本身更重要的是为什么要装

很多刚接触 Android 开发的人，包括早期我自己，最初对“开发电脑装哪些软件”这件事的认知就是：装个 Android Studio，完事。直到真正上手做项目，发现新克隆下来的代码编译不过、接口抓不到包、同事给的产物包打不开、CI 上跑的脚本本地复现不了，才意识一个问题——开发环境中每一款软件背后都对应着一个明确的工程化痛点，装软件的本质是在为整个研发链路补短板。

所以这篇我不打算写成一份简单的“软件列表 + 下载链接”合集，而是想换个角度：以一条真实 Android 项目的研发链路为线索，按“编译构建 → 依赖管理 → 调试分析 → 版本协作 → 效率增强”的层次，讲讲一个相对完整、工程化程度较高的 Android 开发电脑上，通常有哪些常用软件，它们部署在什么场景下，解决什么问题，以及选型时有哪些容易被忽略的细节。

先说明一下，下面提到的软件以我个人的长期使用经验和团队周边的普遍实践为主，不一定适合每一个团队、每一个业务场景，但大体上能覆盖一条比较主流的 Android 工程化链路。另外，凡是付费工具，我都会尽量标注清楚，方便预算敏感的朋友自行取舍。

2. 最低层的底座：JDK 与构建工具链的版本陷阱

先聊一个很多教程不会专门讲但实际最容易踩坑的层面：JDK 和构建工具的版本矩阵。

Android 开发现在几乎离不开 JDK。Android Studio 内置了 JBR（JetBrains Runtime），很多新手以为这就够了，其实内置的 JBR 只是给 IDE 自身运行用的，Gradle 守护进程跑编译任务时用的是你在系统里配置的 JDK 路径，两者可能完全不同。项目里的compileOptions、kotlinOptions或compileOptions的 source/target compatibility 都在和 JDK 版本做匹配。一个常见的翻车现场就是：本地用 JDK 17 编译没问题，推到 CI 上用的 JDK 11，结果某个第三方库用到了新版 API，直接 NoSuchMethodError，或者反过来本地 JDK 版本过低，新版本 AGP（Android Gradle Plugin）直接拒绝运行。

因此在装软件这个环节，我建议把 JDK 显式地当作一项独立软件来管理，而不是依赖 IDE 的内置运行时。我的做法是：

• JDK 统一用某一种发行版固定版本，比如 Temurin 或 Zulu 的 JDK 17，因为从 AGP 8.x 开始，官方要求最低 JDK 17，用 17 可以兼顾主流的三方库要求。
• 通过环境变量或 Gradle 的org.gradle.java.home指定 JDK 路径，避免 IDE 设置和命令行环境不一致。
• 永远不要装“最新版” JDK 直接用于日常编译，最少等两三个版本迭代后再切，Android 工具链对新 JDK 的适配往往有明显滞后。

再说构建工具链本身。Android 工程化的基础三件套是：Android SDK + Build Tools + Platform Tools。前两者在你用 Android Studio 创建项目时通常会自动拉取，但工程化场景里更重要的是命令行环境。我见过不少开发者的电脑上 SDK 目录是有的，但sdkmanager、adb没有加到 PATH 里，结果一到写脚本、CI 本地复现的时候全卡在环境变量上。所以一个工程化做得比较好的开发机，一定会把ANDROID_HOME或ANDROID_SDK_ROOT配置干净，并把platform-tools和cmdline-tools的路径写进 shell 配置文件里。

这一层有一个容易被忽略的软件叫SDKMAN，它不是 Android 专属，但它能让 JDK、Gradle、Kotlin 之类的 JVM 系工具版本切换变得异常方便。我在工程化实践中强烈建议在 Mac/Linux 上装一个，Windows 上也可以用包管理器替代。究其原因，工程化开发不再是一个项目装一次环境，而是多个项目可能同时需要不同版本的 JDK/Gradle，SDKMAN 这类工具的“按目录切换版本”能力，直接决定了多项目并行时的体验。

3. 核心开发环境：Android Studio 与 IntelliJ IDEA 的真正分工

到了 IDE 这个层面，要打破一个很常见的误解：“ Android Studio 是基于 IDEA 的，所以装 Android Studio 就够了，不需要再装 IDEA。”

这句话只说对了一半。纯做 Android 开发，Android Studio（下称 AS）确实是主力，但如果你同时维护一些内部库、做 SDK 封装、写 JVM 层工具链，或者偶尔要开一些非 Android 的纯 JVM 工程，IDEA 的社区版或者旗舰版会让你更舒服。原因很简单：

• AS 对 Android 项目做了深度定制，比如布局预览、APK 分析器、Profiler 集成、模拟器联动等，这些是 IDEA 装了 Android 插件也做不到同等体验的。
• 但 AS 对纯 Java/Kotlin 库项目的支持并不比 IDEA 更优，因为它的 Android 相关插件会引入额外索引负担，打开一个巨型多模块工程时内存占用显著更大。我自己维护一些纯 Kotlin 库项目时，明显感觉 IDEA 的启动和索引速度更顺滑。
• 另外还有一个很现实的工程化场景：同时打开多个项目窗口时，AS 的内存消耗比 IDEA 大不少。这不是玄学，而是 Android 插件加载的组件更多。如果你的电脑内存有限，用 IDEA 开纯库工程，AS 开 App 主工程，能把资源压力分散很多。

AS 本身还有一个选型细节值得单独说：版本选择要跟 AGP 版本做匹配，不要盲目追求最新。我见过不太熟悉工程化的同学把 AS 更新到最新版，结果原有项目 AGP 版本过老，打开后各种插件不兼容，最后只能回滚 IDE 版本。有经验的开发者通常会在电脑里常备新旧两个 AS 版本，或者至少知道去哪下载历史版本，这在处理遗留项目时会非常管用。

提示：Android Studio 的新版并不总是兼容所有旧项目的 AGP。遇到打开老项目构建失败，先检查 AGP 与 IDE 的匹配关系，而不是怀疑自己代码写错了。

4. 网络调试的隐形基础设施：抓包工具与代理转发

真实工程化开发里，有一类软件算不上“显性主角”，但没有它们，联调、排障效率会直接断崖——就是网络相关的工具。

先说说抓包工具。Android 开发日常最常见的有两类场景：

• 调试 App 自己的 HTTP/HTTPS 请求，排查接口参数、响应结构、鉴权头；
• 排查第三方 SDK 上报、推送通道、WebView 资源加载路径。

这两类场景对工具的要求不太一样。纯 HTTP 层，国内外用得最多的还是Charles和Fiddler，前者付费但体验流畅，后者 Windows 上免费、用户量大，功能上其实都不差，只是界面和过滤操作习惯不同。另一款近期在开发者社区讨论度挺高的是Proxyman，macOS 原生、证书管理做得比较顺滑，团队里用的人也在变多。不过要注意的是，抓包工具的核心能力不止是“抓到包”，而是“能解密 HTTPS 流量”。无论用哪一款，都需要把 CA 证书安装到系统信任区而不是用户信任区，Android 7.0 之后用户信任区的证书对 targetSdk 较高版本的 App 是默认不生效的。这一步是很多人装上工具后却看不到明文请求的最主要原因。

再说代理转发工具。抓包工具本身承担了代理功能，但工程化场景下你往往需要一个更轻量的、专门的代理转发层，比如mitmproxy这类命令行方案。为什么？两个原因：

• 某些移动网络环境或境外服务联调需要把流量经过指定的代理通道，抓包工具的代理只是副产品，稳定性不够；
• 自动化测试脚本、接口回归脚本往往需要把一个统一的代理地址作为运行参数传入，命令行工具比 GUI 工具更容易脚本化、更容易接入 CI。

这里我想特别提醒一个工程化细节：抓包工具的代理端口不要和本地开发服务的端口撞车。比如你用 8080 启动了本地 Mock Server，而 Charles 默认的代理端口恰好也是 8888 或者你改成了 8080，那整个调试链路都会被连带搞挂。我在实际项目中遇到过不只一次，排查半天发现是端口冲突。工程化开发里，端口规划其实也是一种软件管理，不值得轻视。

5. 版本协作与仓库管理：Git 可视化工具的选择逻辑

版本管理这块，Git 命令本身是底层能力，但工程化开发电脑上几乎都会装一个Git 可视化客户端。原因也很实在：代码评审（Code Review）、分支关系梳理、冲突解决，这些场景在命令行里虽然都能做，但效率和数据可视化程度远不如 GUI。尤其是冲突解决，遇到复杂的 rebase 冲突，图形化的三方对比视图比纯文本 diff 直观得多。

工具选型上，我见过的主流路线大概有三条：

1. SourceTree：免费，界面直观，对 Git Flow 支持好，团队新手很快能上手。缺点是某些操作封装得太“贴心”，反而让你不知道底层实际执行了什么。
2. Fork：macOS 和 Windows 都有且免费，被很多开发者评价为轻量、快速、没有多余花哨功能。
3. GitHub Desktop或GitKraken：前者和 GitHub 深度绑定，适合重度依赖 GitHub 协作的团队；后者界面漂亮、跨平台，但免费版功能有裁剪，高级功能要订阅。

我的建议是：自己日常使用命令行为主，GUI 作为辅助。命令行的优势是可脚本化、可复用、不依赖图形界面；GUI 的优势是可视化浏览、直观处理分支。工程化水平比较高的开发机，不会把 GUI 当作唯一入口，而是在处理分支图、提交历史、冲突比对时打开 GUI 辅助。另外，不同 GUI 工具对 Git 中文路径、换行符、以及 SSH 密钥管理的处理细节并不一致，团队协作时最好统一工具版本或至少统一核心 Git 配置，否则经常出现“你那边 push 正常我这边报奇怪错误”的情况。

在这个层级，还要单独提一下Git 忽略规则和 Git LFS的配置。Android 工程里.jar、.aar、签名文件、本地配置文件如果没在.gitignore里处理干净，日积月累仓库会异常臃肿。而一些体积大的构建产物或资源如果必须入库，Git LFS 又是绕不开的工具。很多开发电脑上这俩东西不是“软件”，而是配置文件级别的存在，但工程化意义上它们和软件同等重要，因为一旦缺失，版本库的健康度会持续恶化。

6. 设备与模拟器的双子星：命令行工具和桌面管理工具

说到 Android 开发，设备调试自然是核心环节。跟设备打交道的软件，工程化层面其实分两条线：命令行链路和桌面可视化链路。

命令行链路的核心是adb 和 fastboot，它们随 Android SDK 一起分发，严格说不算额外软件，但在实际工作中利用率极高。我会在开发机上配置一系列基于 adb 的常用脚本，比如：

• 一键安装多渠道包到多台测试机；
• 拉取指定 App 的日志并按关键字过滤；
• 通过adb shell am start直接拉起指定 Activity 页面，替代手动点击；
• 通过adb reverse把手机端口映射到电脑，让真机可以直接访问本地服务。

这些脚本放到别的地方可能只是“个人小工具”，但在工程化语境里，它们代表了一种思维：重复性、可描述的设备操作都应该被脚本化和版本化管理，而不是每次手动点屏幕。

桌面可视化链路，最常见的自然是 Android Studio 自带的 Device Explorer 和模拟器管理界面。但工程化做得更重的团队，往往会再引入一个跨设备管理工具，比如Android 设备多管理器或 scrcpy 这类投屏控制软件。这里我非常推荐scrcpy，它开源免费，能低延迟地把手机屏幕镜像到电脑，并通过电脑键鼠操作手机。对需要频繁在真机上查看 UI、跨设备做演示、录制操作视频的场景来说，效率和便捷度是原生工具没法比的。而且它本身就是命令行软件，极其适合写进脚本自动化流程里。

模拟器层面也有一个常被忽略的工程化软件选择问题：你需要在电脑上跑多个不同 API Level 的模拟器吗？如果同时跑测试矩阵呢？现在 AS 内置的 Device Manager 对单模拟器场景很友好，但在并发跑多台模拟器做自动化测试时，资源占用和稳定性就考验机器了。很多工程化团队会给开发机装命令行版模拟器启动工具，配合测试脚本一起来管理模拟器的生命周期，把“软件”和“脚本”组合成一个完整的工具链，而这恰恰是“工程化”三个字和单纯“装软件”之间的分界线。

7. 容器与本地服务：为什么工程化开发机也需要 Docker 和数据库客户端

有个现象挺有意思：很多 Android 开发者觉得 Docker 是后端或者运维才需要的东西，自己的纯客户端开发用不上。但我的实际经验是，只要你的 App 依赖任何自建服务、内部接口或中间件，Docker 就该出现在你的开发机上。

最常见的场景：

• 后端代码还没完全联调好，本地要跑一个 mock server，直接起一个容器镜像比在本机折腾环境变量、语言运行时省事得多；
• 需要接推送、消息、存储等 SDK，连通性测试依赖一套本地或者自建的对应服务，容器让“一键拉起整套依赖环境”成为可能；
• 自动化测试要跑在固定环境里，容器可以帮你把测试依赖打包成一致的镜像，避免“在我电脑上能过”的尴尬。

和 Docker 配套的往往还有本地数据库客户端。Android 开发本身不直接操作数据库，但 Debug 阶段、埋点数据核对、服务端接口数据准备，都可能需要连库查数据。比较常见的工具有 DBeaver、Navicat、TablePlus 等，选型看平台和个人习惯。工程化上的关键点是：数据库连接信息不要硬编码在任何脚本或者 IDE 配置里。我见过很多团队在本地配了一堆数据库连接，人一离职、连接串散落在各处，新来的同事根本不知道某个库连的是哪个环境。更工程化的做法是把连接信息放在受版本控制的安全配置里或者用环境变量统一管理，这跟装哪款数据库软件本身同等重要。

容器化的另一个好处是解决“环境一致性”问题。Android 工程的依赖五花八门，CocoaPods 习惯是 iOS 那边的事，但 Android 侧也有 NDK、CMake、各种命令行工具链，这些在每个人的机器上版本很可能不一致。用 Docker 把构建依赖封装成镜像之后，整个团队的编译环境就稳定在一个可复现的状态里。开发机上的 Docker 和 Docker Compose 配置，本质上和代码仓库里的 Gradle 脚本是同一等级的工程制品，而不是一个孤立安装的软件。

8. 生产力增强的隐藏功臣：终端、剪贴板、窗口管理等小而关键的工具

最后聊几个看起来跟 Android 开发没有直接关系，但在真实工作流里几乎每天都要用到的生产力维度。工程化开发从来不只靠重型 IDE，那些“小而关键”的工具，往往决定了你一天的产出效率。

终端工具是第一个值得单独说的。Mac 上很多人用 iTerm2 或 Warp，Windows 上是 Windows Terminal。个人体验上，终端工具的选择和 shell 配置（Zsh + Oh My Zsh / PowerShell + PSReadLine）、别名管理、以及窗口分屏能力是强相关的。Android 工程化日常里，跑 Gradle、adb、Git、Docker、抓包命令行工具，几乎都要在终端里完成。如果你连终端都不顺手，效率会持续被小刀割肉。

剪贴板增强工具是第二类。别小看这个，开发过程中复制代码片段、日志关键字、接口返回样例是极高频率的操作。系统自带剪贴板只能存最近一条，而第三方工具可以保留多条历史并支持搜索，这在实际调试中能省很多重复查找时间，包括 Mac 上常见的 Paste、Windows 上的 Ditto 等。它们在软件清单里非常不起眼，但对日常效率的影响极大。

第三类是多显示器/窗口管理优化工具，比如窗口布局工具和虚拟桌面增强。做 Android 开发时经常要同时打开模拟器、Android Studio、浏览器、抓包工具、终端等多个窗口，窗口管理的顺畅程度直接关系到你切换上下文的成本。很多时候不是电脑性能不足，而是窗口操作太费神。工程化思维在这里的体现就是：用工具把“找回上下文”的损耗压缩到最小。

还有一类容易被忽略的工具是截图/录屏/标注软件。提 Bug、评审 UI、同步问题截图时，一套顺手的截图标注工具远比从 IDE 里导出截图方便。少数派、产品经理向同事常常提“工作效率”，但在工程化语境里，这其实是信息同步效率的一部分：一张清晰标注问题的截图，胜过一段几百字的描述。如果截图之后又能直接生成可分享链接，那团队协作的上下文传递速度还会更快。

9. 按开发环境分层的常用软件参考清单

前面几章按逻辑链路说了很多软件存在的“为什么”，这一节直接给一个浓缩的、按使用频次和环境维度整理的参考清单，方便你对着检查自己的开发机配置。

这张表没有把“垂直领域专用软件”放进去，比如音视频开发需要的 FFmpeg 工具链、性能优化需要的内存抓取剖析工具等，因为那些严格来说随具体业务而变，不属于一条通用 Android 开发链路的标配。但如果你的工作涉及相应领域，这些专用工具的安装与配置也应该纳入上表同等的管理粒度来对待。

10. 选型原则和最后几点个人体会

软件开发领域没有“唯一正确软件清单”，但选型背后有一些相对稳定的原则，在我带过的小团队里基本达成了共识，列出来供参考：

• 同一类工具不要贪多。装一个顺手的主力工具，最多再备一个可选项就够。比如抓包工具 Charles 主用、mitmproxy 偶尔脚本化，不要再装三五个功能重复的，白白增加心智负担。
• 优先考虑命令行可脚本化的工具。真实工程化场景里，“能写进脚本”和“只能手动点”的软件，长期价值判若云泥。Docker、mitmproxy、adb、scrcpy 这类工具之所以在工程化语境里地位高，就是因为他们能被脚本编排进 CI、回归测试、一键环境拉起这些流程。
• 版本和配置的规范化优先级高于工具本身的“新”。我见过太多所谓“软件装得新，工程做不动”的情况——工具全是新版，但项目的 AGP、Gradle、JDK 全都停留在旧时代，每次一编译就是一堆兼容性报错。工具链的核心价值在于跟项目匹配，而不是趋新。
• 电脑不是软件堆得越多越强。真正工程化到位的开发机，一定是一个配置清晰、冗余极少、大部分重复操作都能脚本化的环境。不用羡慕别人装了某个花哨工具，关键看它在你自己的工作流里解决了什么特定问题。

最后说几点个人在实操中的体会。第一，不要急着装全家桶，先把自己手头最痛的三个环节找出来，针对性补工具，比一次性装完二十个软件有效得多。第二，任何软件配置完之后，花一点时间把关键配置固化下来，或者写进项目的文档里，这对团队协作和新人上手是最实在的资产。第三，隔一段时间回顾一下你电脑里的软件清单，把那些三个月没打开过的工具卸掉或封存，这跟代码仓库里清理无效依赖一样，都是工程化健康度的一部分。

说到底，“Android 开发电脑装哪些软件”不是一份静态的答案，而是一个持续演进的过程。每个人、每个团队、每个业务阶段，最优解都会不同。希望这篇内容能帮你在搭建自己工具链的时候，少走一些弯路，把更多精力留在真正值得投入的代码和架构上。