Android 模拟器“起不来”可能指完全不同的问题：没有虚拟设备、命令找不到、图形初始化失败，或者模拟器已经运行，只是 App 崩溃了。先定位故障在哪一层，再改配置，能避免在 SDK、GPU 和应用代码之间来回试错。

第一层：是否有可用的虚拟设备

遇到：

no emulator images (avds) found

先区分系统镜像与 AVD。镜像提供要运行的 Android 系统，AVD 则是使用相应镜像、设备配置和数据的虚拟设备实例。下载了镜像，不代表已经创建了可启动的 AVD。

可以先枚举设备：

emulator -list-avds

如果没有设备，在 Android Studio 的设备管理入口选择设备配置和系统镜像，创建 AVD，再重新枚举。若界面有设备而命令行没有，先检查是不是用了另一套 SDK、另一个系统账号或不同设备目录。官方命令行说明

第二层：命令是否来自预期的 SDK

旧项目中可能出现：

android list avd 不是内部或外部命令

历史上的一种处理是进入包含旧 android 脚本的 SDK tools 目录执行。但不同代际的工具入口和目录不同，不能把旧路径加入 PATH 就认定所有 SDK 都适用。

先核对可执行文件实际在哪里。Windows 可使用：

where.exe emulator
where.exe adb

macOS 或 Linux 可以使用：

command -v emulator
command -v adb

将结果与 Android Studio 配置的 SDK 位置对照。找不到命令时，先确认对应组件是否存在，再修正调用路径；不要因为一个旧命令不可用，就删除整套 SDK 或重复安装全部组件。

第三层：图形初始化和音频输出分开看

2018 年的一次启动日志同时出现：

Could not initialize emulated framebuffer
audio: Failed to create voice 'goldfish_audio'
warning: opening audio output failed
audio: Failed to create voice 'adc'

当时把 Graphics 改为 Software—GLES2.0 后可以继续运行。这个变化首先切换的是图形渲染路径，因此它提供的是图形兼容性线索，不能仅凭同时出现的日志断言音频驱动就是根因。

遇到类似图形问题，可以在保留同一 AVD 的前提下，对照硬件与软件渲染。具体选项名称随版本变化，应看相应版本的设置和官方模拟器排错说明。软件渲染可能改善兼容性，但也会影响性能，不应当作所有机器的永久默认值。

一次只改变一个设置，并分别记录是否能启动、画面是否正常、声音是否可用。只有这样，才能判断改动影响的是哪一部分。

第四层：App stopped 要查应用崩溃日志

如果模拟器桌面已经正常打开，而启动 App 后提示 stopped，问题已经到了应用层。先在 Logcat 中选中对应进程和时间段，找异常类型、Caused by 及第一处业务栈，再判断是否与图形相关。Logcat 使用说明

“use host gpu 没勾选”只能是某些历史环境中的线索，不能解释所有应用崩溃。空指针、资源问题、权限、原生库和系统镜像兼容性，也可能导致应用退出。

保留数据，再做环境对照

排查前记录 SDK、Emulator、镜像、宿主系统和显卡信息，以及最先出现的错误。优先做枚举、路径检查和可恢复的设置对照。

不要一上来擦除 AVD 数据或删除设备；这些操作可能破坏测试环境，却没有回答故障究竟发生在哪一层。如果其他 App 能运行、只有目标 App 崩溃，优先回到目标应用的日志，不要继续盲改模拟器配置。