直接说结论你找不到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时代推出的一整套调试和分析工具的集合核心就是老外的DDMSDalvik 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 RCPRich 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请先确认三件事你手头有一个可用的JDK/JRE 8。JRE 8即可不一定需要完整JDK。你的Android SDK目录里还有tools文件夹或者你下载了对应的旧SDK Tools包。你的设备或模拟器能通过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这样的组合过滤条件。日志可以像文本编辑器一样选中高亮CtrlF搜索也更快。模拟器和真机切换、多设备切换直接下拉选择就行不用再像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基本一致。DevEDevice File Explorer的简称还有个好处是稳定性比老版好太多。老File Explorer在加载大目录或者大量小文件时经常卡死新版基本没这问题。3.5 截屏、录屏、模拟操作模拟器扩展控件老ADM里的截屏、模拟来电、模拟短信、GPS位置模拟等功能在新版被拆到了两个地方截屏/录屏在IDE工具栏或Logcat工具栏上都有小图标也可以按快捷键CtrlShiftSWindows/Linux或CmdShiftSmacOS直接截取。模拟来电/短信/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_HOMEC:\path\to\jdk8 set PATH%JAVA_HOME%\bin;%PATH% monitor.batmacOS/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”生成的内存快照可以在MATMemory Analyzer Tool里做深层次分析这是当年排查内存泄漏的经典玩法。模拟器控制面板里可以手动设置GPS坐标、模拟来电和短信适合做一些自动化之外的场景测试。Logcat面板里选中指定进程日志会自动过滤到当前进程这个过滤逻辑其实比新版还直白一点不熟悉的同学上手会更快。4.4 老monitor.bat在Android 8.0以上设备的局限如果你用到的设备或模拟器系统版本在Android 8.0API 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在哪”以及尝试使用老工具时遇到问题可以直接对照着排查。问题现象可能原因解决办法Android Studio菜单里找不到Android Device Monitor使用3.0以上版本入口已被移除用新版替代功能或从SDK tools里手动启动monitor.batSDK目录里没有tools文件夹新版SDK Tools不再打包monitor下载旧版SDK Tools如25.x解压后复制进去monitor.bat双击没反应Java版本不兼容或找不到Java设置JAVA_HOME指向Java 8后再启动启动monitor报SWT加载失败JDK版本太高9换成JRE 8务必在环境变量里生效Device窗口连不上模拟器/真机adb没识别设备先执行adb devices确认驱动和开发者选项状态点了进程后无法Dump HPROF设备系统版本过高或App非debuggable改用Android Profiler的Java Heap Dump功能找不到模拟器控制面板老DDMS里的入口新版已拆分使用模拟器侧边栏Extended Controls需要查看内存快照老工具不稳定使用新版Android Profiler导出后用MAT或自带分析这张表基本覆盖了我能想到的所有高频问题剩下的一些小概率问题可以在命令行里带着日志跑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”点“Dont 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的目录结构这几个点过一遍。适应之后你会发现新的工具链虽然变化很大但在效率和易用性上确实是一个质的提升。
Android Device Monitor去哪了？新版Android Studio调试工具替代方案详解
直接说结论你找不到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时代推出的一整套调试和分析工具的集合核心就是老外的DDMSDalvik 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 RCPRich 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请先确认三件事你手头有一个可用的JDK/JRE 8。JRE 8即可不一定需要完整JDK。你的Android SDK目录里还有tools文件夹或者你下载了对应的旧SDK Tools包。你的设备或模拟器能通过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这样的组合过滤条件。日志可以像文本编辑器一样选中高亮CtrlF搜索也更快。模拟器和真机切换、多设备切换直接下拉选择就行不用再像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基本一致。DevEDevice File Explorer的简称还有个好处是稳定性比老版好太多。老File Explorer在加载大目录或者大量小文件时经常卡死新版基本没这问题。3.5 截屏、录屏、模拟操作模拟器扩展控件老ADM里的截屏、模拟来电、模拟短信、GPS位置模拟等功能在新版被拆到了两个地方截屏/录屏在IDE工具栏或Logcat工具栏上都有小图标也可以按快捷键CtrlShiftSWindows/Linux或CmdShiftSmacOS直接截取。模拟来电/短信/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_HOMEC:\path\to\jdk8 set PATH%JAVA_HOME%\bin;%PATH% monitor.batmacOS/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”生成的内存快照可以在MATMemory Analyzer Tool里做深层次分析这是当年排查内存泄漏的经典玩法。模拟器控制面板里可以手动设置GPS坐标、模拟来电和短信适合做一些自动化之外的场景测试。Logcat面板里选中指定进程日志会自动过滤到当前进程这个过滤逻辑其实比新版还直白一点不熟悉的同学上手会更快。4.4 老monitor.bat在Android 8.0以上设备的局限如果你用到的设备或模拟器系统版本在Android 8.0API 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在哪”以及尝试使用老工具时遇到问题可以直接对照着排查。问题现象可能原因解决办法Android Studio菜单里找不到Android Device Monitor使用3.0以上版本入口已被移除用新版替代功能或从SDK tools里手动启动monitor.batSDK目录里没有tools文件夹新版SDK Tools不再打包monitor下载旧版SDK Tools如25.x解压后复制进去monitor.bat双击没反应Java版本不兼容或找不到Java设置JAVA_HOME指向Java 8后再启动启动monitor报SWT加载失败JDK版本太高9换成JRE 8务必在环境变量里生效Device窗口连不上模拟器/真机adb没识别设备先执行adb devices确认驱动和开发者选项状态点了进程后无法Dump HPROF设备系统版本过高或App非debuggable改用Android Profiler的Java Heap Dump功能找不到模拟器控制面板老DDMS里的入口新版已拆分使用模拟器侧边栏Extended Controls需要查看内存快照老工具不稳定使用新版Android Profiler导出后用MAT或自带分析这张表基本覆盖了我能想到的所有高频问题剩下的一些小概率问题可以在命令行里带着日志跑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”点“Dont 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的目录结构这几个点过一遍。适应之后你会发现新的工具链虽然变化很大但在效率和易用性上确实是一个质的提升。
