企业官网建设流程全解析

直接说结论：你找不到Android Device Monitor是正常的，不是眼睛出了问题，也不是装了个“假Android Studio”。新版本的Android Studio从3.0开始就把这个入口从菜单里移除掉了，甚至后来连整个工具集都默认不再捆绑。很多老Android开发习惯用里面的DDMS看日志、抓堆栈、看布局层级，突然某天升级完IDE，发现不但在菜单里找不到，就连网上老截图里的路径也没了，第一反应基本都是懵的。这篇文章就系统梳理一下：Android Device Monitor到底去哪儿了，各版本怎么找，以及新版IDE里面那些老功能分别被什么替代了，包括Windows下怎么把老monitor.bat手动调出来继续用。

如果你是刚接触Android Studio的新手，可能会觉得“找不到一个工具”有什么可纠结的——直接用它现在自带的功能不就行了？但如果你接手过老项目、看过老教程、或者需要排查一些“Profiler里看不出来”的底层问题时，就会发现ADM那套东西在某些场景下还是很能打的。所以这篇文章既适合新手了解新版工具的替代关系，也适合老开发回忆一下曾经的工作流到底去哪了。

1. 先搞清楚Android Device Monitor到底是什么

1.1 一个工具全家桶，不只是“监控器”

Android Device Monitor（简称ADM）其实不是一个单一功能的工具，它是Google在Eclipse时代推出的一整套调试和分析工具的集合，核心就是老外的DDMS（Dalvik Debug Monitor Server），但界面和入口统一被集成到了Monitor里。换句话说，你打开ADM之后能做的事情非常多：

• 查看所有已连接设备和模拟器的列表，支持端口转发、截图、录屏、重置设备等基础操作。
• 查看每个设备上运行的进程，选中一个进程就能看到该进程的堆栈、线程、内存分配情况。
• 抓取HPROF堆转储文件，用来做内存泄漏分析。
• 启动Method Profiling，记录某个时间段里每个方法的调用耗时和调用关系。
• 查看Logcat日志，支持按级别、按标签、按进程过滤。
• 浏览应用内部的数据库、SharedPreferences、文件目录，直接导出/导入文件。
• 模拟来电、短信、GPS定位、网络速度等模拟器状态，方便做场景测试。
• 通过Hierarchy Viewer查看App界面的视图层级和渲染耗时。

当年Android Studio还没有自己的Profiler时，这套工具几乎就是我调试App的“主力军”。尤其是看布局层级和抓内存快照，基本上是每日必用，所以突然被移除的时候，很多老开发是真的有点不习惯。

1.2 为什么Google在Android Studio 3.0之后把它移除了

很多人以为是Google“脑子一抽”或者为了强推新工具就砍掉了。从我的观察来看，根本原因是这套工具的技术栈实在太旧了。ADM基于Eclipse RCP（Rich Client Platform）构建，界面依赖SWT，跟Android Studio的IntelliJ IDEA框架完全不是一套体系。这就意味着Google要同时维护两套UI、两套交互逻辑、两套打包发布机制，成本非常高，而且新IDE里的很多新能力（比如实时Profiler、布局编辑器联动）在旧框架里根本没法实现。

另外还有一个很现实的原因：Android Studio 3.0自带了一套全新的Android Profiler，把CPU、内存、网络、电量这几个维度的分析都整合进了IDE窗口里，体验上比单独的ADM窗口要顺手得多。既然新工具已经能覆盖大部分场景，Google自然不愿意继续养着一个维护困难的老组件。从Android Studio 3.0开始，“Android Device Monitor”这个入口被正式标记为Deprecated，后来在新版里干脆彻底移除，连SDK里的monitor.bat文件都不再随新SDK Tool发布了。

所以归根结底：不是你找不到，是Google主动砍了，目的是让你用新的那套工具链。

2. 按版本找入口：旧版、过渡版、新版都怎么处理

2.1 Android Studio 2.x及更早版本：还有菜单入口

如果你用的是Android Studio 2.x版本，那恭喜你，还能看到完整的ADM入口。当时的正常路径是：

• 顶部菜单栏：Tools → Android → Android Device Monitor

点击之后会单独弹出Monitor窗口，里面就是熟悉的DDMS界面、Logcat、File Explorer、Simulator Control这些面板。如果你的AS还停留在2.x，那这篇内容你大概只需要知道“以后升级了该怎么办”就好。

不过我要额外提醒一句：Android Studio 2.x本身对新款手机和Android系统版本的支持已经非常有限了，很多新机型的ADB协议、GPU驱动、资源编译格式都超出了它的处理能力。如果你只是因为喜欢ADM而不升级IDE，其实得不偿失——新版IDE里那些被替代的工具反而更好用。

2.2 Android Studio 3.0到3.5左右：菜单消失，但SDK里还活着

Android Studio 3.0是一个分水岭，从这版开始“Android Device Monitor”的菜单入口被删掉了。但你如果留意过SDK目录，会发现它并没有完全消失，而是以独立脚本的形式被“藏”在了Android SDK目录里。

当时的路径大致是：

你的SDK目录/ ├─ tools/ │ ├─ monitor.bat │ ├─ ddms.bat │ ├─ hierarchyviewer.bat │ ├─ traceview.bat │ └─ bin/ │ ├─ monitor │ ├─ monitor.bat │ ├─ ddms │ └─ ddms.bat

在Windows上，你直接双击或命令行运行monitor.bat，就能重新把老ADM调出来。macOS和Linux上没有.bat后缀，直接在终端里执行monitor脚本就行。这一阶段虽然麻烦了点，但至少还“活着”，我用过很长一段时间的3.2版本，也一直是打开旧monitor来干活。

不过这里有个坑：新IDE自带的JDK版本已经慢慢从Java 8往Java 11升级了，而老monitor还是基于Java 8技术栈写的。如果你直接用新IDE的JDK启动monitor.bat，经常会遇到SWT加载失败或者界面起不来的情况。比较稳妥的办法是给monitor单独指定一个本机的JRE 8环境，后面我会专门说这个问题。

2.3 新版Android Studio：彻底没了入口，剩下SDK里的老文件

到了Android Studio 3.6、4.0及其以后的版本，Google进一步清理了老工具。新版SDK Tool里不再默认安装tools目录下的那套monitor相关脚本，很多人在自己的SDK目录下翻半天都找不到tools文件夹。即便你自己下载老版本SDK Tools解压进去，也有可能因为缺少依赖库而启动失败。

所以现在的真实状况是：如果你装的是近一两年的新版Android Studio（比如4.2、2020.3.1、2021.2.1、Android Studio Giraffe/Hedgehog等），SDK目录里基本不会再有monitor.bat了，菜单里也肯定找不到入口。想用老ADM只能通过手动下载老版SDK Tools，然后把缺少的脚本补全，还需要配合Java 8环境才能启动成功。

如果你不是特殊需求，我非常不建议在新版环境里去折腾老monitor。因为新版Android Studio在调试体验上已经把ADM的功能拆解得明明白白，你需要的每个功能都能在IDE里找到对应的替代位置，用的是新版工具反而更不容易碰到兼容性问题。

2.4 想用老工具还需要这些前置条件

依照我自己的经验和社区里的各种反馈，如果你确实需要手动调出老ADM，请先确认三件事：

1. 你手头有一个可用的JDK/JRE 8。JRE 8即可，不一定需要完整JDK。
2. 你的Android SDK目录里还有tools文件夹，或者你下载了对应的旧SDK Tools包。
3. 你的设备或模拟器能通过adb正常连接，因为在monitor里看不到设备的排查成本往往比启动工具本身还高。

这三条里最容易出问题的就是Java版本。很多同学默认装了最新JDK（比如JDK 17或JDK 21），跑去运行monitor.bat，启动时报了一堆奇怪的SWT错误，然后以为工具坏了。其实不是坏了，是老程序真跑不动新Java，必须给它换一个Java 8。这个我在第4章会展开讲怎么改脚本。

3. 新版Studio每一项功能分别去哪儿了

前面说过，ADM是个大杂烩。现在的新版Android Studio虽然没有一个叫“Device Monitor”的窗口，但它并没有把这些能力丢掉，而是拆成了多个独立工具，放在IDE的不同位置。下面我把老ADM里常见的几个功能面板，一一对应到新版的使用入口。

3.1 看日志：Logcat窗口

老DDMS正下方就是Logcat，支持过滤级别、标签、进程。新版Android Studio里，Logcat被做成了IDE底部的一个专属工具窗口，即使App没在运行也能查看历史日志。

新版Logcat的增强点我觉得有几个比较明显：

• 过滤语法更灵活，可以直接写package:mine、tag:你的标签、level:error、pid:1234这样的组合过滤条件。
• 日志可以像文本编辑器一样选中高亮，Ctrl+F搜索也更快。
• 模拟器和真机切换、多设备切换，直接下拉选择就行，不用再像ADM那样两个窗口来回找进程。

如果你习惯老式Logcat的“红色错误、绿色调试”配色，新版也可以自定义颜色。在Settings里搜Logcat，找到颜色设置，把Error、Warning、Info、Debug的配色改成你自己舒服的样子就行。

3.2 看CPU、内存、网络、能耗：Android Profiler

老ADM里的“性能分析”能力，现在被Android Profiler完全接管了。入口是IDE底部或右侧的“Profiler”标签，点击它会打开一个多面板分析窗口。

Android Profiler把监控数据分成了四块：

• CPU Profiler：查看方法的执行耗时、调用链、函数热点，有点类似老的Method Profiling，而且更直观。
• Memory Profiler：实时显示Java堆、Native堆、代码、图像等内存占用，还能记录内存分配轨迹和触发GC。
• Network Profiler：展示网络请求的时间线、请求头、响应体，对比老DDMS那堆纯数字好用太多。
• Energy Profiler：查看电量消耗的大致来源，对做省电优化很有帮助。

实际操作里，我用得最多的是Memory Profiler的“Java Heap Dump”功能。选中一个进程，点一下“Dump Java Heap”，过一会儿就能看到一个按对象数、浅堆大小、保留堆大小排序的列表，基本继承自老HPROF分析思路，但过滤和跳转代码的能力更强，排查内存泄漏效率比ADM时代高了不少。

3.3 看布局层级：Layout Inspector

老ADM的Hierarchy Viewer已经彻底退出历史舞台，对应的新版工具叫Layout Inspector。入口很简单：在真机或模拟器上打开App界面，然后从IDE菜单里选择Tools → Layout Inspector，就能打开实时布局树。

Layout Inspector能看到的不只是ViewGroup的嵌套关系，还能选中任何一个View，直接查看它当前的所有属性值，包括margin、padding、背景色、文本内容、可见性等。配合新版Android Studio的“Compose Preview”和布局校验器，调试UI的效率比当年用Hierarchy Viewer高得多。

不过要注意，新版Layout Inspector需要设备系统版本在API 21以上，低于这个版本再用不了。老项目如果minSdk特别低，只能继续用老办法。

3.4 浏览应用文件：Device File Explorer

老ADM里的File Explorer被独立成了IDE右侧的“Device File Explorer”窗口，入口在IDE右侧边栏上，一个文件夹图标的按钮就是。点击后展开就是一个类似系统文件管理器的界面，能查看应用沙箱内的所有文件。

它和老版File Explorer一样，默认只能访问/data/data/包名/等应用私有目录里能读到的部分。如果你想看debuggable应用的全部私有数据，需要App本身是debuggable打包，或者设备已root。操作上右击文件即可Upload、Download、Delete、Save As，跟老ADM基本一致。

DevE（Device File Explorer的简称）还有个好处是稳定性比老版好太多。老File Explorer在加载大目录或者大量小文件时经常卡死，新版基本没这问题。

3.5 截屏、录屏、模拟操作：模拟器扩展控件

老ADM里的截屏、模拟来电、模拟短信、GPS位置模拟等功能，在新版被拆到了两个地方：

• 截屏/录屏：在IDE工具栏或Logcat工具栏上都有小图标，也可以按快捷键Ctrl+Shift+S（Windows/Linux）或Cmd+Shift+S（macOS）直接截取。
• 模拟来电/短信/GPS/电池/指纹/网络：在模拟器侧边栏里找一个带“三点或齿轮”的扩展控件（Extended Controls）按钮，点开后有专门的分类标签页。

扩展控件里除了老三样，还有虚拟传感器、指纹、屏幕方向、亮度和电池状态等模拟选项，覆盖场景比DDMS当年更全。如果你做的是导航、直播、支付类应用测试，这一步非常关键。

3.6 无线调试、签名信息这类额外需求

热搜词里还出现了“Android Studio无线连接调试vivo手机”“Android Studio获取MD5”这些相关问题，我额外说两句，因为确实有不少人是在找ADM时顺带遇到这些需求。

先说无线调试：现在Android 11及以上系统自带“无线调试”功能，在开发者选项里打开后，手机和电脑连同一个WiFi，然后使用adb pair 手机IP:端口和adb connect 手机IP:端口完成配对连接，之后Android Studio里就能看到这台设备，跟USB连接几乎一样。这个过程完全不需要老ADM参与，实际体验很顺畅。

再说获取签名MD5：老教程里常提到通过ADM或一些工具查看应用签名信息，但正经做法是使用JDK自带的keytool，命令大概是：

keytool -list -v -keystore release.jks -alias your_alias

运行后会输出SHA1、SHA256、MD5等内容。这个跟ADM没有任何关系，所以别再翻旧文档了。

4. 如果坚持要把monitor.bat叫出来，怎么操作

4.1 定位SDK目录里的monitor.bat

确认过你真的需要老monitor之后，第一步是找到它。老版本SDK Tools里它的常见位置是下面这样：

你的Android SDK目录/ └─ tools/ └─ bin/ ├─ monitor.bat (Windows) ├─ monitor (macOS/Linux) └─ ...

当然也有一些版本的SDK Tools把monitor.bat直接放在tools根目录下，所以找不到bin的时候可以去上一级目录看看。如果你用的是新SDK，里面没有tools文件夹，先从Android官方下载一个旧版“SDK Tools”压缩包，解压后把tools文件夹复制到你的SDK根目录下。注意版本尽量选25.x左右，再新的tools里已经默认不发布monitor相关脚本了。

为了省事，我一般会先打开命令行执行：

adb --version

能看到ADB版本的话，说明设备调试环境基本没问题。接着再确认SDK位置，可以用Android Studio里的“SDK Manager”查看当前SDK路径，通常在Settings → Languages & Frameworks → Android SDK里能直接看到，然后按上面的路径往回找tools。

4.2 Windows/macOS启动步骤和Java环境处理

找到monitor.bat之后，最常遇到的启动问题就是Java环境不兼容。我建议先在本机装一个独立的Java 8运行时，比如用OpenJDK 8或Temurin 8，把它单独解压到一个目录，不要干扰你在命令行里用的其他Java版本。

然后有两种方式让它生效：

第一种，临时设置JAVA_HOME后再启动，不影响全局环境。Windows的cmd里这样写：

set JAVA_HOME=C:\path\to\jdk8 set PATH=%JAVA_HOME%\bin;%PATH% monitor.bat

macOS/Linux终端里这样写：

export JAVA_HOME=/path/to/jdk8 export PATH=$JAVA_HOME/bin:$PATH ./monitor

第二种，直接改monitor.bat脚本里的Java查找逻辑。用文本编辑器打开monitor.bat，找到找Java的部分，把JAVA_HOME强行指定成你的Java 8路径。这个方法更“根治”，但每次重装或者移动SDK目录都得再改一次，所以我个人更推荐第一种临时变量方式，反正启动完就完事了。

启动之后，如果看到熟悉的DDMS面板和Device列表，就说明成功了。如果双击图标没反应，优先怀疑Java版本，换成Java 8基本能解决80%的问题。

4.3 启动后连接真机或模拟器的基本用法

monitor启动后会显示已连接的设备和模拟器列表。如果你之前已经在命令行里用adb连了设备，这边一般能直接看到；如果列表是空的，先在命令行手动执行adb devices确认设备是否识别，识别不了的话，再回Android Studio里检查一下ADB设备连接。

老monitor连上设备之后，有几个操作我觉得非常值得保留：

• 在Devices列表里点中某个进程，按绿色的“Start Method Profiling”按钮，过一段时间再点Stop，就能生成一份方法调用记录，保存成trace文件后用traceview打开分析，对定位卡顿问题很有用。
• 选中进程后点“Dump HPROF file”，生成的内存快照可以在MAT（Memory Analyzer Tool）里做深层次分析，这是当年排查内存泄漏的经典玩法。
• 模拟器控制面板里可以手动设置GPS坐标、模拟来电和短信，适合做一些自动化之外的场景测试。
• Logcat面板里选中指定进程，日志会自动过滤到当前进程，这个过滤逻辑其实比新版还直白一点，不熟悉的同学上手会更快。

4.4 老monitor.bat在Android 8.0以上设备的局限

如果你用到的设备或模拟器系统版本在Android 8.0（API 26）及以上，还会遇到一个比较头疼的问题：老monitor对Android 8.0以上的一些调试接口兼容性并不好。最典型的表现有：

• Device列表能显示设备，但点击进程后HPROF dump经常失败。
• Method profiling记录出来的调用树不完整，甚至出现“Profiling cannot be started because the application is not debuggable”之类的提示。
• Hierarchy Viewer对Android 5.0以上系统就已经逐渐失效了，系统版本越高越难用。

所以如果你面对的测试设备全是新机型，我的建议是能不用老monitor就别用。它更适合用来做老项目兼容性验证、研究AOSP源码这种偏底层一点的场景，而不是日常开发调试的主力工具。

5. 常见问题排查清单与我的实操体会

5.1 高频问题速查表

我根据自己踩过的坑和社区里高频出现的问题，整理了一张速查表。如果你在找“Android Device Monitor在哪”以及尝试使用老工具时遇到问题，可以直接对照着排查。

这张表基本覆盖了我能想到的所有高频问题，剩下的一些小概率问题，可以在命令行里带着日志跑monitor看看具体报错信息。

5.2 几个亲手踩过的坑

第一个坑：Java模块冲突。我电脑原本装了多个JDK，默认Java是17，启动monitor.bat时报了个非常隐晦的“Failed to initialize Java SWT”错误，差点以为是SDK Tools下载坏了。后来把JAVA_HOME切到Java 8，问题瞬间消失。所以看到SWT三个字母就条件反射地检查Java版本，基本没错。

第二个坑：老monitor连了新模拟器但一直显示“offline”。新版模拟器默认的ADB端口和旧monitor预期的不完全一致，并且它的ADB协议已经迭代了好几轮。解决办法是先杀掉模拟器，通过命令行手动指定端口启动老版本模拟器镜像，或者干脆老monitor只连真机。真机上做测试的话，兼容性问题相对少一点。

第三个坑：Android Studio 3.2时代打开老monitor时，IDE会不断提示“This feature is deprecated”，点“Don't show again”之后就不会再打扰你了。很多同学被这个弹窗唬住，以为不能用，其实是能用的，只是Google在提醒你别太依赖它。

这些坑都是真实踩过的，写出来是希望大家别重复走弯路。

5.3 现在做开发更推荐的工作流

很多话我说到前面了，最后专门留一点篇幅说下我现在的实际工作流。坦白讲，我已经彻底放弃在开发机上调老monitor了，新版Android Studio自身的工具链已经足够应付99%的调试需求。

日常看日志用Logcat窗口，配好过滤条件之后比什么工具都好用；看性能用Android Profiler，一条时间轴看CPU、内存、网络、电量，全局视野远比老DDMS里那个单进程面板清晰；改UI就开Layout Inspector，所见即所得；传文件就Device File Explorer，拖拽上传下载都很顺畅。这套组合才是Google真正希望你用的姿势。

只有在研究AOSP源码、看系统进程级调试信息或者手头有老SDK和Java 8环境的时候，我才会把老monitor作为一个特殊工具拿出来用。而且我会单独放在虚拟机或备用机里跑，不污染主开发环境。

如果你现在的工作流还是“必须依赖Android Device Monitor”，我建议你花半天时间熟悉一下替代工具，把Logcat过滤规则、Profiler的基本操作、Device File Explorer的目录结构这几个点过一遍。适应之后你会发现，新的工具链虽然变化很大，但在效率和易用性上确实是一个质的提升。